Instructions for building uClinux (20110810) and Linux Kernel 3.1 for NUC7xx.Preface
This document explains how to setup a build environment to compile the latest (as of 10/28/2011) uClinux for the NUC700 platform. I imported the contents of the uClinux-dist-20110810 archive as the first commit in my GIT repository, and applied patches on top of that. Rebasing onto newer uClinux releases will be very easy this way, and it helps keep track of the changes between the mainline uClinux and the NUC700 specific stuff.
I ported Wan ZongShun's Linux kernel patches (http://nuc700.sourceforge.net/
) to the current kernel 3.1-rc9. As my nuc700 branch is branched from Linus Torvalds' kernel branch, we can merge in upstream changes into the nuc700 branch by running "git merge master" or "git rebase master".Toolchains
Picking the correct toolchain(s) is tricky and you can spend a lot of time running into all sorts of weird compilation and linking problems. Then, on the device, you might end up with executables that either don't load at all or crash instantly or when they execute a particular function call.
I experimented with the following toolchains:
4. arm-2011.03 (Code Sourcery)2004 toolchain (gcc 3.4.0) for userland and 2008 toolchain (gcc 4.2.4) for kernel:
Problems with userland: something wrong with dropbear (don't remember the details).2006 toolchain (gcc 3.4.4) for userland and 2008 toolchain (gcc 4.2.4) for kernel:
Problems with userland: had to patch elf2flt.c to get rid of these errors:
ERROR: reloc type R_ARM_PC24 unsupported in this context
However, "long long" seems to produce code that makes executables go from "ram" (good) to "gotpic" (bad).2011 toolchain (gcc 4.5.2) for both userland and kernel:
The kernel hangs on "Uncompressing Linux", never printing "done, booting the kernel".2011 toolchain (gcc 4.5.2) for userland and 2008 toolchain (gcc 4.2.4) for kernel:This combination works great and is what I am using and recommend.
So the bottom line is that you need two toolchains, one for the kernel, one for the userland. Download and unpack these two archives:
1. "Sourcery G++ Lite 2011.03-46 for ARM uClinux" from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1804
(direct link: https://sourcery.mentor.com/sgpp/lite/arm/portal/package8744/public/arm-uclinuxeabi/arm-2011.03-46-arm-uclinuxeabi-i686-pc-linux-gnu.tar.bz2
In order to use the Code Sourcery toolchain for the userland and the arm-linux-tools-2008 toolchain for the kernel, you have to place the appropriate directories in your PATH variable:
$ export PATH="/path/to/arm-2011.03/bin:/path/to/arm-linux-tools-20080623/usr/local/bin:$PATH"
Check that the toolchains are installed properly by running:
$ arm-linux-gcc -vInstall dependencies
gcc version 4.2.4
$ arm-uclinuxeabi-gcc -v
gcc version 4.5.2 (Sourcery G++ Lite 2011.03-46)
libssl needs makedepend, which you can find in xutils-dev.
Further, you need genromfs so the build system can create a romfs.img file which can be flashed, and some other tools:
$ sudo apt-get install xutils-dev genromfs libtool texinfoClone the uClinux distribution at git://github.com/rhuitl/uClinux.git
$ git clone git://github.com/rhuitl/uClinux.git uClinux-dist-nuc700
$ git submodule init
This repository is based on uClinux-dist-20110810 (or newer versions in the future) and has a few nuc700-specific patches. Further, the folders linux-2.0.x, linux-2.4.x and linux-3.x have been removed to save ~780 MiB space.
We will use our own kernel which is based on Linus Torvalds' kernel branch (3.1-rc9 at the moment), with a lot of patches by Wan ZongShun and a few of my own.
The 3.0.0 kernel that ships with uClinux has a lot of patches applied, but at first glance, none of them seem relevant for the nuc700 platform. Might be interesting to add their patchset to our kernel, too.
Git's submodule feature is used for libraries and programs I added. They allow pulling in upstream changes in these projects without losing our own patches, e.g., for no-MMU compatibility and static linking.Clone the kernel tree at git://github.com/rhuitl/linux.git
$ cd uClinux-dist-nuc700Checkout my nuc700 branch
$ git clone git://github.com/rhuitl/linux.git linux-3-nuc700
$ git checkout nuc700Create a symlink to fulfill the uClinux build system's expectations
$ ln -s linux-3-nuc700 linux-3.1Configure uClinux (don't enter the kernel directory)
$ make menuconfig
Select "Customize Application/Library Settings", then exit and save. In the following menu, you can just exit and save again.WARNING:
Don't enable lots of applications at once. Try to get a successful build using a minimum set of applications first, and once that works, select one more application and rebuild. This way it is easy to spot applications that don't build on our platform, and unfortunately, due to static linking and the lack of a MMU, there are a lot of programs in the uClinux distribution that don't build out of the box.
You might need to run make a second time if the romfs directory didn't exist before and it complains about missing targets for romfs.img (needs fixing).
Don't do parallel makes (e.g., make -j4), the uClinux build system is broken in this regard and will mess up the order how packages are compiled. Parallel builds of the kernel work fine, of course.
Finally, the build process should complete with these lines:
genromfs -f romfs.img -d romfs
The ROMFS image romfs.img is ready
The kernel zImage is at linux-3.1/arch/arm/boot/zImage, the romfs image at ./romfs.img.Final remarks
Note: I am using a FOSCAM FI8904W, so you may need to make modifications as appropriate
for your device.
Note: The Wifi driver (Via vt6656, in the staging area) does not work. I've spent some days debugging it, but I never got lucky. At least the kernel panics I used to get in response to "ifconfig eth1 up" are gone with the upgrade from 2.6.38 to 3.1. There have been some no-MMU related patches, so maybe one of them cured the kernel panic that I suspect was because of a corruption of the kernel's timer list.
Now, I get this error message:
# ifconfig eth1 up
Config_FileOperation file Not exist
kernel BUG at mm/nommu.c:415!
So far I couldn't track down who called vunmap() and why, guess I need to print a backtrace.
Note that the Config_FileOperation message is unrelated to the problem.