 NSLU2-Linux
General
Projects
Wiki Resourceshosting by:  |
This is the software side of Fattening Your Slug. In order to actually use the extra RAM, the kernel needs to be able to see it. To do that, the RAM must be enabled during bootup. The bootloader does this by writing a hardware register (SDR_CONFIG) during boot. Steve G has determined that the Redboot loader initializes the memory controller for 32M size. This will make any added memory unaccessable to linux unless the initialization value is changed either by rebuilding Redboot or figuring out a way to change the value just prior to jumping to the kernel. There were reports that Redboot was already configured for more memory but this is not consistent with the findings of Steve G below. It is probably possible to run a kernel configured for more memory than this and have it appear to work until you actually use memory beyond the hardware limit. You can always run a kernel configured for less memory than you actually have. Another possibility is that there have been different configurations of Redboot used by Linksys. An alternate bootloader is the APEX bootloader. The advantages of it is that the size of memory can be adjusted and it boots a bit faster. It can be compiled from source and supports the NSLU2. The parameters of interest are in the .config file. Here you define number of banks you have and how big they are. I compiled it natively on my other slug (OpenSlug 2.7). Like Redboot, APEX provides facilities to examine, change and download memory. Changing the bootloader is very serious business. Essentially, you get it right the first time or you start putting together a JTAG interface to start over. A serial connection is an absolute must as you must communicate with the bootloader to do things. I took a chance with APEX and it worked just fine. However, I was fully prepared to make the JTAG interface and start uploading. The wise person would confirm that their JTAG rig works before changing bootloaders..... This means, specifically, confirm that you can detect the processor and flash with these instructions. To change to APEX, you must boot into Redboot using your serial connection. You then use Redboot to download the APEX bootloader to RAM. You then start APEX by jumping to the beginning of the downloaded file. If all is well, you will see APEX boot up. For testing, you can now use APEX to boot into linux to see if it works. Of course this will overwrite APEX and you have to start over if you want to actually replace Redboot. It appears that APEX is not able to change the configuration register if it is booted like this and so the kernel will still only see the amount of memory as configured by Redboot. You must make APEX the initial bootloader to have it control the memory configuration. (Update: This is probably not true anymore, sdm485) To replace Redboot, you get APEX running and then use it to copy itself into Flash memory. After this is done, Redboot will no longer be there and APEX will begin execution on powerup. You can use APEX to download other copies of APEX via XMODEM (over the serial cable) and can test these and write them to Flash. You can also download other images and execute them from APEX. You will notice that APEX (configured for OpenSlug) automatically copies the kernel to RAM when it starts. The APEX website has the info for doing these steps. See http://wiki.buici.com/wiki/Main_Page If you want to return to Redboot, you must use APEX to download Redboot and copy it over APEX. I have no experience at doing this and it carries all the risks described above. One way to do this would be to copy APEX to RAM, then run it from RAM, then download the entire flash backup (you did back it up!) into RAM, then copy just the Redboot part back into the flash. Some instructions can be found here. UPDATEIt is necessary to pass the correct command line parameter to the kernel on boot. This requires adding the necessary change to the build environment and recompiling the image and kernel. One way to do it is to modify the file: your_build_directory/openembedded/packages/linux/ixp4xx-kernel.inc by commenting out the existing CMDLINE_ROOT statement by putting a '# ' at the beginning and adding a new line: CMDLINE_ROOT= "mem=64M". (This is deprecated, sdm485). Steve G describes another alternative below. I have used his method and it works fine. If you have already built an image on your setup (using the Makefile 'make openslug-image') then you will need to delete the kernel directory from the openslug/tmp/work directory and the stamp files associated with the kernel compiling process in openslug/tmp/stamps. The directory and files will then be copied from the download directory when you enter the command 'make openslug-image'. These are probably more deletions than are necessary but it works. Once the build completes, the kernel and flashdisk images will be found in the openslug/tmp/deploy/images directory. You want the zimage-nslu2be image for the kernel and the file ending with flashdisk.img for the entire thing. I have not done it but I think the ideal way to do a FatSlug would be to figure out how to get Redboot to load the correct value to SDR_CONFIG. This would allow the continued use of upgrade mode. I recently built 2.6.18 and it does not report any DMA errors so this previous issue has been resolved. Note that you can leave the system intact and load in a modified kernel into RAM via Redboot (there is a HowTo about this) and then jump to the kernel to launch linux. This allows you to examine the messages to see if you are getting the correct command line and if your system is using the extra memory. If something goes wrong, a reboot will return you to your original system for another try. sdm485 In my case I had to edit: I finally managed to get my 64M (2 chips 16Mx16) configuration working! - Using Apex built for 32MB or 64MB is exactly the same when testing Apex in RAM :-( - But if I flash a 64MB version of Apex all is well. It puts 0x1A in the SDR_CONFIG Update Nov 19 '06: I just used the information on "http://www.nslu2-linux.org/wiki/HowTo/BuildYourOwnRedBoot" to make a version of RedBoot that will boot my 64M slug. Actually I got a binary RedBoot by doing this on my other (Unslung) slug. NOTE: I used the 20061119 information from Steve G to dump my firmware, hexedit the memory controller (for 64MB), and flash my bootloader. I only had 32MB of memory -- I was thinking of upgrading soon. Worked great EXCEPT I couldn't boot into my OS anymore. RedBoot worked great, but the device would just sit there flashing all day long. I tried everything I could think of, and then finally went back to the original firmware. Rebooted and everything worked fine. I guess you can't set the memory controller to 64MB when you only have 32MB. Anyone have thoughts on this? --Mannkind Steve G APEX and a FatSlugUpdated to APEX-1.5.4 Download the APEX source (1.5.4) and run 'make menuconfig' which builds and presents a configuration screen. You might have to install a few packages to get menuconfig to work. - select the platform (INTEL IXP42x?) - select the compiler in general setup. Since I compiled APEX on a 'slug', I sort of cheated by shortening the string to just /usr/bin/ and let the symbolic links deal with the actual location. Of course this assumes you have the compiler installed. It will be more complicated in a cross-compiling environment. - set the implementation to NSLU2 - set the endian-ness (very important) I use Openslug (now SlugOS/BE) which is bigendian. - In 1.5.4 (and probably some previous versions too), you can either configure Apex with the number of banks and the bank size or use built in commands to figure this out. To do it manually, set the memory configuration in Platform Setup . This is the part that deals with the memory chips. If you have 4 chips, you have to enable both banks. Each bank must be the same size and you have to specify the size. For 16Mx16 chips the appropriate size entry is 0x04000000. Note that the default entry is 0x02000000 with no second bank which corresponds to 32M byte across two chips in one bank (a standard NSLU2). To have Apex figure out the memory configuration dynamically, you will need the commands 'sdram-init' and 'memscan' so check that they are selected in the 'Commands' menu. - configure your kernel command line in the 'Environment' menu by first selecting to override the target command line and then adding your own 'root=/dev/mtdblock4 rootfstype=jffs2 init=/linuxrc rtc-x1205.probe=0,0x6f'. If you are manually configuring the memory size then you also have to add the 'mem=xxxM' statement where xxx is total size of memory. - if you are determining the memory configuration dynamically at boot, you need to modify the startup command line 'sdram-init; memscan -u 0x0+256m; copy $kernelsrc $bootaddr; wait 50 Type ^C to cancel autoboot.; boot'. If you are using manual configuration, the default startup command line is fine. The rest of the entries should work fine. You save the configuration and then 'make' it. The result is an apex.bin file in the /src/arch-arm/rom directory. This is the file you upload to the slug to try it out. Try it in RAM first to make sure it works. It should boot linux too but will only report 32M which is no fault of APEX but rather a characteristic of the stock 'nslu2' kernel which has a hardcoded command line that apex cannot take precedence over. The zImage-ixp4xxbe kernel does not have the hardcoded command line so you must supply a good one from the bootloader. The serial port is necessary to tell APEX to write itself to flash and this process is covered at the Apex author's website 'http://wiki.buici.com/wiki/Main_Page'. This is the potentially hazardous part of the process. I very highly recommend that you test the apex.bin file in RAM before writing it to flash. The erasing and writing process is very fast but as with all such commands, they must be entered correctly the first time. sdm485 See also FatSlug |
