Debian and FatSlugs

*Obviously* this will void the warranty of your SLUG.

Editing this page as I just got my VeryFatSlug to work. That is, a 256MiB NSLU2, using 4 chips (double-stacked), 512Mib each, 16bits wide, using this wiki and more importantly, this wiki.

First, you'll need the newer Apex, with a new command, called sdram-init. You can get Apex 1.4.18

I loosely followed this website instructions. Except, I didn't use the user-land command "apex-env". I compiled Apex 1.4.18 using the source file and using the instructions here. Note that the pre-compiled binary image for the NSLU2 will not work as a second-stage bootloader. I tried it, and the NSLU2 continually rebooted back into Apex.

Then, I downloaded slugimage and ran it as follows (to disassemble the Debian-Installer RC2 binary image). Note that I changed the Perl file to have .pl extension, so I knew it was a Perl script. I ran this from Cygwin.

 $ ./slugimage.pl -u -i di-nslu2.bin
 Read 2 blocks into <RedBoot>
 Read 0x00006 bytes into <EthAddr>
 Read 1 blocks into <SysConf>
 Read 0x1FFE0 bytes into <Loader>
 Read 11 blocks into <Kernel>
 Read 32 blocks into <Ramdisk>
 Read 1 blocks into <FIS directory>
 Read 0x00010 bytes into <Trailer>
 Wrote 0x00040000 bytes from <RedBoot> into "RedBoot"
 Wrote 0x00020000 bytes from <SysConf> into "SysConf"
 Wrote 0x0001FFE0 bytes from <Loader> into "apex.bin"
 Wrote 0x00140004 bytes from <Kernel> into "vmlinuz"
 Wrote 0x00400000 bytes from <Ramdisk> into "ramdisk.gz"
 Wrote 0x00000010 bytes from <Trailer> into "Trailer"

Now, I just have to replace the apex.bin with the one made for Apex 1.4.18.

 $ slugimage.pl -p -o di-nslu2-newapex.bin -b RedBoot -s SysConf 
       -L apex-debian-nslu2-arm-1.4.18.bin -k vmlinuz -r ramdisk.gz 
       -t Trailer

Now, I booted into Redboot via CTRL-C of console when I saw the "+" upon rebooting (using SerialPortMod wiki). I suppose you could telnet into Redboot instead but I was lazy.

Next, I put the file "di-nslu2-newapex.bin" on my TFTP server in /tftpboot directory, and then followed these instructions to retrieve the file via TFTP into RAM, then do cksum on both NSLU2 and linux server, then copy file from RAM into flash.

I did the following (assuming TFTP server on 0.99 and NSLU2 is 0.10):

 RedBoot> ip_address -l 192.168.0.10 -h 192.168.0.99
 RedBoot> load -r -v -b 0x01000000 -h 192.168.0.99 di-nslu2-newapex.bin
 RedBoot> cksum

(do this on both the NSLU2 and the TFTP server and verify equal checksums)

 RedBoot> fis write -f 0x50060000 -b 0x01060000 -l 0x7a0000
 RedBoot> reset

Now, I verified that the installer would boot. It did, going first into Redboot, then Apex bootloader (2nd stage). However, it still doesn't detect 256MiB. Now, gotta change the boot config parameters for Apex per this page. When I replaced Redboot with Apex, I could not modify the environment parameters. With this new Apex 2nd stage loader, I notice that the parameters don't work via the apex "setenv" command, as copied per this page. The commands of interest are shown below:

 apex> printenv
 ...
 startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; 
   wait 10 Type ^C  to cancel autoboot.; boot

 apex> setenv startup sdram-init; memscan -u 0+256m; copy -s $kernelsrc 
   $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C to cancel 
   autoboot.; boot

(NOTE: dunno if no quotes or double quotes are needed - I used no quotes and it worked! With quotes, it doesn't work. Note also that the "-u" passes ATAG_MEM to kernel)

 apex> printenv
 fis-drv *= nor:0x7e0000+4k
 cmdline *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug
 cmdline-alt *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug
 bootaddr *= 0x00008000
 ramdiskaddr *= 0x01000000
 kernelsrc *= fis://kernel
 kernelsrc-alt *= fis://kernel
 ramdisksrc *= fis://ramdisk
 ramdisksrc-alt *= fis://ramdisk
 startup = sdram-init; memscan -u 0+256m; copy -s $kernelsrc $bootaddr; 
   copy -s $ramdisksrc  $ramdiskaddr; wait 10 Type ^C to cancel autoboot.; boot

Just for kicks, I tried the commands above on the 1.4.18 Apex boot loader:

 # sdram-init
  2 banks of 2 512Mib chips
 # memscan -u 0+512m
  0x0 0x10000000 (256 MiB)

(note: memscan only showed 256MiB which is correct)

Note that I did try to install with FatSlug, but I couldn't get my FatSlug to detect properly (at first), so I went ahead and installed D-I RC2?, then after getting it working, modified the Apex bootloader and then got it to work per the above instructions. I think that if you were to install with FatSlug, the extra memory would be recognized by the installer and perhaps more options would be available.

======================old info below====================

This page is based on work by Gerardo Martínez Bernat. Original instructions were are in Spanish and were translated by Dave Nash.

For some time I have wanted to increase the memory in my Slug. Now I have finally installed a pair of 16Mx16 chips (Micron branded, which are fairly easy to find). Once you have performed the upgrade you will realise that there is still work to do!

The intention of this document is to explain the steps that I have performed to upgrade the first level boot loader, and also the second level (introduced in the RC1 of Debian Etch)

You will need

• NSLU2 with increased memory
• a board with MAX3232, ICL3232 or similar for the serial port
• the Apex source code
• a JTAG interface, you can make a home made Wiggler-type (optional but recommended to help things go well)
• toolchain for armv5b (arm big-endian) and for arm (arm little-endian). For arm BE you can use the toolchain that you generate with the OpenSlug Master Makefile, and for arm LE you can use that provided by emdebian.

I will assume that you have all this, that the serial port is working, and that you have the source code of Apex ready. The first step is to substitute Redboot with Apex in order to use all the memory. Next, if you use Debian, it is necessary to substitute the second level loader with another that can pass a command-line to the kernel.

Step 1: Substitute Redboot with Apex

Copy the Apex configuration for Openslug and enter the configuration menu.

cd /usr/src/apex
cp src/mach-ixp42x/openslug_config .config
make menuconfig

Go to General Setup, choose the option Cross Compiler prefix, and enter the prefix for the armv5b compiler. In my case

/opt/armv5b-softfloat-linux/gcc-3.3.5-glibc-2.2.5/bin/armv5b-softfloat-linux-

Now go to Platform Setup to configure the loader for your upgraded memory. If you have 2 chips choose Enable SDRAM bank 0 and leave Enable SDRAM bank 1 unselected. If you have 4 chips then enable both. In Size, in bytes, of each SDRAM bank enter in hexadecimal, the number of bytes of each pair of chips. In my case I have 64Mb in a single bank (two chips) so I selected only bank 0 and entered 0x04000000 for the size.

Once we are working on this, it's recommendabable to add the kernel command line so in case we use OpenSlug, it will be able to use all the memory.

Go to Environment, select Default kernel command line and add at the end "mem=64M@0x0"

Exit the configuration program, save and compile.

make

This will make the binary file of the first bootloader ("apex.bin"), but before saving it, it is useful to test it to be sure that it works.

IF it doesn't work and you save it, you can only restore the Slug using JTAG. You have been warned!

Install the serial port circuit and start Minicom (or similar program, just be sure it supports xmodem). When the Slug starts a "+" will appear. Press Ctrl-C at this point and wait a few seconds for the Redboot command-line to appear. Now we will copy the bootloader to RAM:

RedBoot> load -b 0x1000000 -r -m xmodem

Transfer the Apex image ("apex.bin") via xmodem. In Minicom press Ctrl-A to enter command mode and then S to send files. Once Apex is in RAM you only have to execute it:

RedBoot> g 0x1000000

You will see something like this:

APEX Boot Loader 1.4.7 -- Copyright (c) 2004,2005,2006 Marc Singer

APEX comes with ABSOLUTELY NO WARRANTY. It is free software and you
are welcome to redistribute it under certain circumstances.
For details, refer to the file COPYING in the program source.

apex => mem:0x00200000+0xdb20 (56096 bytes)
env => nor:120k+8k (no-write)

Use the command 'help help' to get started.

# copy nor:0x60010+0xffff0 0x00008000
1048560 bytes transferred

Press Ctrl-C to stop the boot process.

If all has gone well up to this point, you can overwrite RedBoot. To do so enter the following:

apex> erase nor:0
apex> copy $apex nor:0

It is not necessary to do another xmodem transfer of apex because we will flash the image previously saved in RAM. Now restart the Slug and see if Apex boots correctly.

apex> reset

If it does, you have completed the most complicated step. If not, you will have to use JTAG to restore the firmware.

Step 2: Substitute the Debian second-stage loader with Apex with the appropriate command-line

From this point you can try things out safe in the knowledge that you can recover the Slug without JTAG

The first thing is to prepare the second Apex binary. This time it is more complicated but nothing unusual.

Copy the Apex configuration for NSLU2 arm and go to the configuration menu.

cd /usr/src/apex
cp src/mach-ixp42x/debian-nslu2-arm_config .config
make menuconfig

Enter General Setup, go to the option Cross compiler prefix, and enter the prefix for the arm compiler, in my case /opt/arm-xscale-linux-gnu/gcc-4.0.3-glibc-2.3.6/bin/arm-xscale-linux-gnu- Return to configure the memory in Platform Setup (This should not be necessary but just in case!) Now go to Environment, select Default kernel command line and add to the end "mem=64M@0x0"

Exit the configuration program, save and compile:

make

The binary you get from this is for little-endian architecture so now you have to do some "byteswapping" using the following script (courtesy of Peter Korsgaard):

#!/usr/bin/python
# swap every 32bit word in input and write it to output

import array, sys

if len(sys.argv) != 3:
sys.stderr.write('Invalid arguments.\n')
sys.stderr.write('Usage: %s \n' % sys.argv[0])
sys.exit(1)

if sys.argv[1] == '-':
file = sys.stdin
else:
file = open(sys.argv[1], 'rb')

input = file.read()
a = array.array('I')
# add padding if needed
a.fromstring(input + '\0' * (4-len(input)&3))
a.byteswap()

if sys.argv[2] == '-':
file = sys.stdout
else:
file = open(sys.argv[2], 'wb')

a.tofile(file)

Run it:

./byteswap.py apex.bin apex-swap.bin

As before, it is convenient to test before saving to flash. Enable the serial port, open minicom, and boot the Slug. Press Ctrl-C to pause the boot. Now you can transfer the binary via xmodem.

apex> xreceive 0x1000000

You will see a "C" appear, at that moment it transfers the binary "apex-swap.bin".

Execute the new loader:

apex> go 0x1000000

At this point, just in case, you must test if you can boot Debian without interrupting the load with CTRL-C. If it boots properly you can save it to flash. It is very important to save from the first Bootloader, NEVER FROM THE SECOND.

Boot the Slug and press Ctrl-C to enter the Apex command line (I REPEAT: THE FIRST APEX). And now do the following:

apex> xreceive 0x1000000

It transfers "apex-swap.bin" by xmodem but do not boot it. Note the size of the file in hexadecimal. Now save to flash:

apex> erase nor:0x60000+0x20000
apex> copy mem:0x1000000+0xYYYY nor:0x60010 (where 0xYYYY is the size of the
file noted)

Now it's all done so restart and make sure it all works properly.

p2p@pitufo:~$ free
total used free shared buffers cached
Mem: 62568 61160 1408 0 388 30212
-/+ buffers/cache: 30560 32008
Swap: 65528 24 65504

If it doesn't boot, remember that you can always restore the firware that you want using the first Apex without any need for JTAG.

NOTE: The process I have described above has worked perfectly for me and is safe provided you take the necessary precautions. Nevertheless I am not responsible for any damage caused as a consequence of following this guide.

IT IS BELIEVED THAT THIS IS AN ACCURATE TRANSLATION (EXCEPT WHERE NOTED) OF THE ORIGINAL GUIDE AT http://www.nslug.es/node/137 , HOWEVER THIS TRANSLATION IS PROVIDED AS A FAVOUR AND NO RESPONSIBILITY IS ACCEPTED FOR ANY INACCURACIES. PLEASE MAKE SURE YOU READ IT ALL AND UNDERSTAND IT BEFORE PERFORMING ANY OF THE STEPS DESCRIBED. YOU ARE RESPONSIBLE FOR YOUR OWN ACTIONS!