Debian and FatSlugs
*Obviously* this will void the warranty of your SLUG.
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
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;
(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;
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
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.
Go to General Setup, choose the option Cross Compiler prefix, and enter the prefix for the armv5b compiler. In my case
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.
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:
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:
You will see something like this:
If all has gone well up to this point, you can overwrite RedBoot. To do so enter the following:
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.
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.
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:
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):
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.
You will see a "C" appear, at that moment it transfers the binary "apex-swap.bin".
Execute the new loader:
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:
It transfers "apex-swap.bin" by xmodem but do not boot it. Note the size of the file in hexadecimal. Now save to flash:
Now it's all done so restart and make sure it all works properly.
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!