However, using some compression technologies a 2MByte flash part can also be used successfully if:

1. The kernel is stored in a compressed form in FLASH. The kernel would be decompressed into RAM when the system is booted. We can expect compression to reduce the kernel size by 40-60%. This would leave approximately 1.3MByte to 1.7MByte for a file system.

2. Then there are 3 options for the file system:

• The file system is very small (approximately 1.3MByte to 1.7 MByte).

• The filesystem is also compressed on FLASH and decompressed into RAM (as with a romfs file system). This could support a read-only file system of approximately 2.2MByte to 4.3MByte in RAM. This is about the same file system size that could be supported on a 4MByte flash part!

• Or, if a read-write file system is needed, a compressed, write-able, flash filesystem (like JFFS2) could be used. In this case, the filesystem is not compressed, but rather the contents of the filesystem are compressed and decompressed into RAM on-the-fly as needed.

The main difference between uClinux used in the BSP and desktop Linux is uClinux is designed to work with processors that do not have memory management unit (MMU) support. This hardware limitation means one process can write to memory "owned" by another process, or even owned by the Linux kernel. There is no processor hardware to memory access violations. No MMU support also means other features, like fork() are not supported (but vfork() is supported).

uClibc supports a subset of the functionality supported by glibc. The differences can be found on the uClibc website.

Given an rrbin file, say linux.rr, you can see the 3 ASCII lines using the following command:

The technical approach to MMU-less shared library support used by the XFLAT shared libraries without an MMU has some limitations that shared library support with an MMU does not. In particular, you cannot access global variables across shared library boundaries. This is not so much a consequence of the shared library implementation as it is a consequence of the GOT-less implementation that is the standard for embedded ARM binaries: The absence of a GOT and the limitations of the FLAT/XFLAT binary formats do not support the indirection that you would need to relocate the data references. Consider the following trivial code example:

#include <unistd.h>
extern char *optarg;

This will not compile under xflat-gcc even though the code usage is consistent with the getopt() man page. In order to explain why this will not compile, we'll have to dig a little deeper "under the hood:"

The global variable optarg is defined in the libc shared library. So you will never be able to able to access it directly from your code using extern char * optarg; given the limitations on the access of global variables. But why does this cause a compilation error?

The Cadenux tool change retains the header files that you use under a directory path something like: /opt/Cadenux/[processor]/[kernel]/crossdev/arm-uclinux/include. If you look at unistd.h in that include directory, you will see that it includes getopt.h (at least under the version of uClibc current used in the toolchain). And if you look at getopt.h in that same directory, you will see that it already contains extern char *optarg;. So what is happening?

xflat-gcc is described here. Note that xflat-gcc is not really a compiler; it is a wrapper around the real compiler, arm-uclinux-gcc. The main thing that xflat-gcc does is to redirect the source of all of the compiler's include files. When you "#include <unistd.h>," you don't get the header file from the /opt/Cadenux/[processor]/[kernel]/crossdev/arm-uclinux/include directory. Rather, xflac-gcc will take the unistd.h header file from /opt/Cadenux/[processor]/[kernel]/crossdev/arm-uclinux/include/xflat! Similarly, when unistd.h includes getopt.h, that header file will also come from the xflat header file subdirectory.

Now, look at this .../xflat/optarg.h. It is tiny, it contains little more than:

#include_next <getopt.h>
#include <xflat_accessors.h>

#undef optarg
#define optarg (*(char**)xflat_varptr(XFLAT_OPTARG))

So, when you reference the variable optarg, you don't actually reference the variable, you actually dereference a function that returns a pointer to the variable. Because of this definition, the extern char *optarg; declaration in your C code will not compile. You could #undef optarg before the extern, but then you build would only fail at link time (or worse yet, maybe at run time!).

The solution: Just remove the extern char * optarg;; you don't need it.

xflat-gcc performs this same trick on numerous other variables exported from libc such as errno, stdout, etc. and it does this without any special knowledge or code changes in the user code. But a few exported variables, like optarg, optind, and environ are more troublesome, primarily because the man page usages suggests that they be explicitly externed. You can see the full list of such variables at ..include/xflat/xflat_accessors.h. Should I be concerned with the performance implications of these data accessors? Read on.

Typical dereferencing in this manner should not cause an measurable performance degradation if it is infrequent. However, such dereferencing could be a performance issue if such a variable is referenced at a high duty, say, in a "tight" loop. Then the small amount of processing required to access the variable could become a performance issue. In this case, you might want to save a pointer to the variable reference so that you do not call the accessor function at a high rate. For example, instead of:

#include <stdio.h>
...
int i;
for (i = 0; i < 10000; i++)


fprintf(stderr, "Error number %s\n", i);

Try something like:

#include <stdio.h>
...
FILE *mystderr = stderr;
int i;
for (i = 0; i < 10000; i++)


fprintf(mystderr, "Error number %s\n", i);

Then, the stderr accessor function is called only once and outside of the "tight" loop.

Using such accessor functions has been a common practice with uClibc (stdout, stderr, etc. were already really function calls). XFLAT just required that this practice be extended.

foo_t foo;

Where foo_t would be any type and foo could be any name. The you write an accessor function like:

foo_t *get_foo(void) { return &foo; }

You would build this into your shared library. It is now an exported function that can be called across shared library boundaries. Then, in your program, change code like:

foo_t *foo = &foo;
foo.bar = 1;
foo_t bar = foo;

to:

foo_t *foo = get_foo();
(*get_foo()).bar = 1;
foo_t bar = (*get_foo());

Notice that in every case except for the first, the following macro will do the job with no code changes:

/* Instead of extern foo_t foo, use */
extern foo_t *get_foo(void);
#define foo (*get_foo())

For a device using embedded Linux, the software in the device will be in one of five categories:

The above information is intended to provide an overview. Refer to the appropriate licenses to determine what software needs to be included in the source code bundle for your specific case.

Use the following steps when converting an application from using fork() to using vfork(). These steps were derived from an email sent by Joe deBlaquiere on Tue, 21 Nov 2000 to the uclinux-dev@uClinux.org list.

1. You need to make sure that the child process doesn't modify global data (or data within the current stack frame of the vfork() call) except resources which are duplicated by the system call such as file descriptors. Any data modified will be modified in the parent process.
2. You cannot return back up the call stack from the routine where the vfork() occurs. As long as the child process is calling down, it is working out of the unused portion of the stack. If you return back up, you'll surely squash the parent's stack.
3. The parent process will hang until the child process performs the exec() or exit(). It is possible that you can reach a deadlock condition if you blindly replace fork() with vfork().

The two BSP configuration utility files to be modified are:

• toolchain/config-tools/memconfig.tk - GUI generation file that allows the part to be selected. To add a part to the GUI, simply find a similar part and duplicate the logic. Usually only three lines need to be changed. Remember to increment the number of items in the menu list and add information to the help string.
• toolchain/config-tools/memconfig.c - logic to build a reasonable BSP configuration. When adding support for a new part, simply add a string identifying the part and add the string to the table of known parts. For flash parts, you need to provide the size of the part and the size of the largest erase block. Typically only two lines need to be changed.
• toolchain/config-tools/memconfig.h - header file used by the BSP configuration utility. This is a different file than the memconfig.h file generated by the BSP configuration utility (and stored in the rrload/ and linux/include/asm/arch/ directories). Add a new define for the part and increase the number of supports parts. This is also typically a two line change.

Real-time configuration:

1. You can enable / disable the real-time related features using the Linux kernel configuration utility (make xconfig or make menuconfig in the linux directory). They are located in the kernel hacking menu.
2. The instrumentation to monitor either interrupt latency or preemption latency significantly degrades performance. Only use these features during development.
3. Do not enable interrupt latency instrumentation (CONFIG_ILATENCY) at the same time you enable kernel preemption (CONFIG_PREEMPT).

For the Linux 2.6 kernel:

For Linux driver development:

If you don't have yum configured here you will find a clear guide to configure it.

2. Disable SELinux so the command mkfs can be used (necessary for build the BSP's fs image)

You can know if SELinux is active by running sestatus on a terminal. If it says:

SELinux is already disabled, otherwise you can disable it by editing the file /etc/sysconfig/selinux and set SELINUX=disabled. You will need to reboot your machine to apply the cahnges.