Getting a cross-compiled environment set up on a Linux PC
(running CentOS 5 with functioning yum and all updates to yum as of May 2008)
Throughout this document, please note the command prefixes. Only do things as root as necessary, as you can and will mess up your working Linux box if you do everything as root.
$ => implies non-root ("slug" account) # => implies root
I'm also using the notation [/absolute/path] to show the present working directory, and "~" to mean the home directory of the current user (whether it is root or slug). To do this on your system, type:
export PS1='[\w]\$ '
Assuming you don't already have a user "slug", you have to first create that user.
[~]# useradd -m slug [~]# su - slug [~]$ cd /home/slug
Next, get the master Makefile from the NSLU2 repository:
[~]$ wget http://www.nslu2-linux.org/Makefile
[~]$ wget http://monotone.ca/downloads/0.29/monotone-0.29.tar.gz [~]# cd /usr/src; tar xzvf ~slug/monotone-0.29.tar.gz [/usr/src]# cd monotone-0.29; ./configure [/usr/src/monotone-0.29]# make [/usr/src/monotone-0.29]# chmod ugo+rw . -R [/usr/src/monotone-0.29]$ make check <--- NOTE: DONE AS NON-ROOT IN ORDER TO NOT FAIL!!
The above should complete with no errors - one test is to have errors and make sure monotone detects them. Note that it will take about an hour to run on a P4-2.0GHz with 1GB RAM.
[/usr/src/monotone-0.29]# make install
Next, Psyco JIT Compiler needs to be installed in order to increase performance. This is only on i386-type build platforms. Download the version you need by first determining the version of python you have.
[/usr/src/monotone-0.29]$ cd ~ [~]$ python -V
[~]$ wget http://downloads.sourceforge.net/psyco/psyco-1.6-src.tar.gz [~]# cd /usr/src [/usr/src]# tar xzvf ~slug/psyco-1.6-src.tar.gz [/usr/src]# cd psyco-1.6 [/usr/src/psyco-1.6]# python setup.py install
To confirm it worked:
[~]$ ls /usr/lib/python2.4/site-packages/psyco/
For 1.5.2 only, tar xzvf'ed it in /usr/src so it would be in the /usr/src/psyco-1.5.2 location. Then copy (per the INSTALL.txt) the psyco folder to the python site-packages directory as follows. Note that you may have to change your python directory if different than version 2.3 below
[~]# cd /usr/src/ [/usr/src]# tar xzvf ~slug/psyco-1.5.2-src.tar.gz [/usr/src]# cp -r psyco-1.5.2/psyco /usr/lib/python2.3/site-packages/
Next, download the Monotone database for building SLUG packages:
[~]$ make update-master
This takes about 6 hours (P4-2GHz with 1GB RAM) as it downloads a 160MB OpenEmbedded Monotone file, verifies certificates, keys, revisions, etc.
Next, setup the build environment for CentOS. You'll be prompted for the root password as some packages (via yum) will be installed.
[~]$ make setup-host-centos
The monotone database file is built with monotone 0.29. If you have a monotone version upper than this, you need to update it. Note that this is a very long (and unstable) process (I have not been able to update the database on my Amd64 box running Ubuntu (feisty) with the monotone supplied with the system, nor with the 0.34 and 0.36 versions I compiled). For this reason, I greatly recommend you compile your version of monotone with version 0.29 only. When the make update-master process proceeds, you'll be able to confirm this by seeing the line OE-this-is-for-mtn-0.29.mtn.bz2 from the snapshot download.
You'll see some messages as those shown below:
You will have to install quilt separately. See http://centos.karan.org/ You will have to install git separately. See http://rpmforge.net/ You will have to install monotone separately. See http://venge.net/monotone/
I first did
[~]# yum install git* [~]# yum install quilt* [~]# yum install python-sqlite2 [~]# rpm -ivh http://www.python.org/pyvault/centos-4-i386/help2man-1.29-1.noarch.rpm
If you use another version of monotone (besides 0.29), you have to update the database, and re-generate all caches. This was necessary as the make above will likely fail (but will partially work, enough to get the .mtn file)
[~]$ mtn db migrate --db=monotone/nslu2-linux.mtn [~]$ mtn db regenerate_caches --db=monotone/nslu2-linux.mtn
The first took about 5 minutes - note if you use Monotone 0.29 the step above doesn't seem to be necessary.
Next, it told me that I should run (which I did) the regenerate caches, and that took a VERY long time - 13,085 entries and took 30 minutes to get to 865. I let it run overnight (it took about 6 hours). Again, note that this is NOT NECESSARY if you use monotone 0.29.
examples found from page 98 here:
I ran this again just to be sure (but it wasn't needed):
[~]# make setup-host-centos
Next, this may take some time... it goes thru certificates and keys. It took me about 10 minutes.
[~]$ make setup-openembedded
Next step will fail, because you have to manually download the Intel source code for RedBoot and the Intel microcode for the Ethernet device:
Next, you'll have to download the Intel microcode. You must manually download IPL_ixp400NpeLibrary-2_4.zip from HERE. See "Intel IXP400 software - NPE microcode (non-crypto)" and click on the BLUE "2.4" text. You will need to agree to the Intel Public License to do so - please do read it! You'll have to go through a few dialog boxes where you click "AGREE" so this can't be automated. If you do not agree, stop here and go back to the Linksys firmware. I'll assume you download that file and put it in the slug home directory somehow. Don't even think about crypto support, the IXP420 doesn't have the hardware for it. The IXP465, etc. have this hardware however.
Note that (per rwhitby) if you search on the IXP 400 family on the Intel web site, you'll find 3.0.1 (or higher) but that only supports 43x and 46x processors (not 420 on the NSLU2). So don't waste your time even thinking about 3.0.1.
[~]$ mkdir downloads [~]$ cp IPL_ixp400NpeLibrary-2_4.zip downloads [~]$ cd downloads [~/downloads]$ md5sum -b IPL_ixp400NpeLibrary-2_4.zip >IPL_ixp400NpeLibrary-2_4.zip.md5
Next, let's do some actual builds!
[~/downloads]$ cd ~ [~]$ make slugosle (took about 6 hours to finish - 760 tasks) [~]$ make slugosbe (about 2 hours as some stuff can be re-used) [~]$ make update (this updates all packages, keys, etc.)
After this is done, the files you compiled will be in this directory:
Extra info - for non-CentOS linux distributions NOTE: Both the above currently fail around task 569 of 645 for Deb or Ubuntu users
git is now called gitfm
This can be fixed by deleting the errant mtd-utils-native_1.0.0+git.bb file from the folder
as by the instruction at
Section 2 Build errors
Q 10 gitfm is run instead of git
Once you have built slugosle and slugosbe, add /home/slug/slugos/tmp/cross/bin to your path. This is done via appending these statements to /home/slug/.bashrc and re-sourcing it:
[~]$ cat >>~/.bashrc (then paste in this text): export PATH="$PATH:/home/slug/slugos/tmp/cross/bin:"
then "CTRL-D" to exit and save. Now, re-source your .bashrc file:
[~]$ source ~/.bashrc
Next, check out the kernel via:
[~]$ svn co http://svn.nslu2-linux.org/svnroot/kernel/trunk /home/slug/kernel
After doing that, I got a bunch of stuff that looks like it was downloaded, and then it said "Checked out revision 1062".
Now, to make Apex (boot loader), do the following:
[~]$ cd /home/slug/kernel [~/kernel]$ ln -s ../downloads .
Next, you need "devio" RPM package (not part of CentOS or default yum repository):
[~/kernel]$ cd ~; wget http://22.214.171.124/pub/nslu2/sources/devio-1.3-1.i386.rpm [/home/slug]# rpm -ivh ~slug/devio-1.3-1.i386.rpm
To use the debian config do this (otherwise it defaults to slugos config) to make Apex:
[~/kernel]$ make APEX_CONFIG=debian apex
Now you should have several apex'es - dmsg600, fsg3, nas100d, nslu2 and nslu2-16MB (FatFlash), all for Debian. To get the ones for slugos, then just "make apex" and you'll get the same versions of apex except all for slugos.
To upgrade APEX (i.e., to a newer version), do this:
[~/kernel]$ svn up (should show something like: ""At revision 1062."") [~/kernel]$ make clobber-apex (this just deletes all the old binaries) [~/kernel]$ make APEX_CONFIG=debian apex
These are the default commands for the build (which are enabled):
kernel/apex-1.4.18/src/apex/Kconfig NOTE: there are the changes to the defaults: kernel/patches/apex/enable-commands.patch
Now, where are those images? type:
[~]$ find . -name '*.bin'
and you'll see some directories named 'deploy'. Those are where the compiled images are located. NOTE: you'll see the files like 'slugosle-4.4-beta-nslu2.bin'. That is the actual image you would upload to flash per the various instructions in the wiki's:
I had some issues with this at first, for some reason. I used the image compiled, and it gave me a message about "cannot find eRcOmM". I think it might be related to not using slugimage so I would recommend using that. Here it is:
[~]# ln -s /home/slug/slugos/tmp/work/i686-linux/slugimage-native-1.0-r12/slugimage \ /usr/local/bin/
then look at the SlugImage page.
I used the first instructions, as I use and trust TFTP. I know that a lot of the instructions warn about not using it, there are better ways, etc. but that is the only instruction set that will work with both Linux and Windows environments (at least that I know), without having to install SerComm, etc. utility (which I don't want). And if you compile your own RedBoot, you can access all RAM and all FLASH area within RedBoot.
Note that you can always use SlugImage to replace parts of the image, instead of replacing the whole thing. I did this for FatSlug, as I only wanted to upgrade the Apex bootloader (for >32MiB memory detection).
NOTE: I assume you know how to use SlugImage? to pack and unpack parts of the image. Something useful is to be able to replace the apex boot loader with a more recent one (that supports 256MiB via "sdram-init" and support for 16MiB flash). If you're running slugos and you run the turnup scripts, and after the first reboot the external drive doesn't get re-mounted, that's because your apex command line needs to be modified. Do it as follows (in APEX - for SlugOS - unknown for Debian):
type "print" in Apex (CTRL-C while Apex is booting and "copying").
cmdline *= root=/dev/mtdblock4 rootfstype=jffs2 console=ttyS0,115200
You need to append "init=/linuxrc". Do it as follows:
setenv cmdline *= root=/dev/mtdblock4 rootfstype=jffs2 console=ttyS0,115200 init=/linuxrc
It is saved automatically, so when you reboot your "turnup" scripts will now work properly. Note that this is not necessary for newer versions of Apex (1.5.14 and above), but for 1.5.13 I required this workaround (thanks to rwhitby).
Now, let's say you want to make some mods to the kernel source files. I had asked on the IRC channel in how to do this, and the easiest way was via checking out the kernel and rebuilding. I didn't feel that comfortable in doing that, so I decided to do it via the compile process here.
So, let's assume you want to try out some mods that were suggested in the kernel bug for OOM errors for FatSlugs?: http://bugzilla.kernel.org/show_bug.cgi?id=7760 How to start this? First, let's assume you've already got a complete system working per above, and you've compiled the slugosbe image. That would be in the path:
So, let's proceed to modify the file common-pci.c per recommendation above. The file to modify is here (note line break):
I manually patched and copied common-pci.c and put it in the ~/tmp directory. Here I do a diff:
[~/slugos]$ diff tmp/work/nslu2be-linux/linux-ixp4xx-126.96.36.199+svnr1066-r0/\ linux-2.6.24/arch/arm/mach-ixp4xx/common-pci.c ~/tmp/common-pci.c 326c326 < dmabounce_register_dev(dev, 2048, 4096); --- > dmabounce_register_dev(dev, 16384, 131072);
So now just copy the patch to the appropriate directory above via:
[~/slugos]$ cp ~/tmp/common-pci.c tmp/work/nslu2be-linux/\ linux-ixp4xx-188.8.131.52+svnr1066-r0/linux-2.6.24/arch/arm/mach-ixp4xx/common-pci.c
Now we have to "fake" the process into re-compiling the parts necessary:
[~/slugos]$ rm tmp/work/nslu2be-linux/linux-ixp4xx-184.108.40.206+svnr1066-r0/\ linux-2.6.24/arch/arm/mach-ixp4xx/common-pci.o [~/slugos]$ rm tmp/stamps/nslu2be-linux/\ linux-ixp4xx-220.127.116.11+svnr1066-r0.do_compile [~/slugos]$ make slugosbe
That will re-compile the kernel, as we manually removed the "do_compile" file in the path above (so that means it assumes it's not there and needs to be re-run). Lucky for us, it only looks at the missing .o files so it only needs to re-compile the common-pci.c file to create common-pci.o and then merge / link to the rest of the kernel files and such to make the 8MB flash image.