NSLU2-Linux
view · edit · print · history

HowTo.ModifyMemorySize History

Hide minor edits - Show changes to markup

August 06, 2008, at 04:00 PM by sluggy -- fixes
Changed lines 109-110 from:

<hr> The problem relay is, the ixp4xx processor series has a DMA (Direkt Memory Access) engine which can only do transfers to the first 64MB of memory. DMA transfers to and from higher merory regions need the "dma trampolin" code which transfers the data by other ways to this regions. If a lot of memory/dma space is used, situations can happen where this hook may reject a dma transfer request, and when this was a data transfer involving the usb drive (via internal pci bus), its doomed.

to:

The problem really is, the ixp4xx processor series has a DMA (Direkt Memory Access) unit which can only do transfers to the first 64MB of memory. DMA transfers to and from higher memory regions need the "dma trampolin" code which transfers the data by other ways to this regions. If a lot of memory/dma space is used, situations can happen where this hook may reject a dma transfer request, and when this was a data transfer involving the usb drive (via internal pci bus), its doomed.

Changed lines 115-117 from:

Since problems happen mostly under high memory usage conditions, a slug with more then 64MB of memory can run perfectly fine, and sudden crash if for example a fsck on the filesystem starts, using lots of memory...

to:

Since problems happen mostly under high memory usage conditions, a slug with more then 64MB of memory can run perfectly fine, and sudden crash if for example a fsck on the filesystem starts, using lots of memory...

sluggy

August 06, 2008, at 03:56 PM by sluggy -- added notes about cause of crashes with >64MB ram
Added lines 108-114:

<hr> The problem relay is, the ixp4xx processor series has a DMA (Direkt Memory Access) engine which can only do transfers to the first 64MB of memory. DMA transfers to and from higher merory regions need the "dma trampolin" code which transfers the data by other ways to this regions. If a lot of memory/dma space is used, situations can happen where this hook may reject a dma transfer request, and when this was a data transfer involving the usb drive (via internal pci bus), its doomed. There seems to be no easy fix, inherent problem in the DMA code...

Published patches try to lower the risk of trapping into such situations, but are more or less hacks only. Since problems happen mostly under high memory usage conditions, a slug with more then 64MB of memory can run perfectly fine, and sudden crash if for example a fsck on the filesystem starts, using lots of memory...

July 16, 2008, at 02:16 AM by sdm485 --
Changed line 97 from:

'The >64M Memory Problem'

to:

The >64M Memory Problem

July 16, 2008, at 02:15 AM by sdm485 --
Changed line 97 from:

The >64M Memory Problem

to:

'The >64M Memory Problem'

July 16, 2008, at 02:14 AM by sdm485 --
Changed line 97 from:

The >64M Memory Problem

to:

The >64M Memory Problem

July 16, 2008, at 02:13 AM by sdm485 -- Info on 4.10-alpha and >64M memory
Changed lines 5-6 from:
to:
Changed lines 92-106 from:
to:

slugos-alpha-4.10

This version runs linux kernel 2.6.24.7 and seems as solid as all of the recent 'beta/alpha' versions, that is, it works as expected and is very reliable. It can be installed using upgrade mode and upslug2 and it automatically configures itself for available memory. This is done using apex as the second bootloader as described above. One thing to consider though is to modify /etc/profile to include /usr/sbin and /sbin in the path to avoid some package problems. Unslung packages can be installed as well if you add the /opt/bin and /opt/sbin directories to the path. This has not been tested recently so please edit this if necessary.

The >64M Memory Problem


There has been an ongoing discussion regarding the inability of ARM processors to support memory sizes larger than 64M. Under heavy disk access, the USB subsystem will die and make the fatslug effectively hung. It is actually still sane but it can't do much of anything since it relies completely on the USB subsystem for its' rootfs, swap etc. One of the symptoms of this state is that you can still ping the thing.

The problem is apparently in the kernel code that requests DMA buffers beyond the pre-allocated pools. It has a problem (please correct me if my simplification is wrong) that if things get so busy that the kernel either runs out of buffers (unlikely) or cannot supply one of the requested size, the response is 'not ideal', so to speak. Some testing revealed that while the kernel was requesting USB buffers ranging in size from 4k to 64k, the subsystem was only offering sizes of 2k and 4k. A simple fix offered by Levente Nagy ( http://bugzilla.kernel.org/show_bug.cgi?id=7760 ) was to increase the size of the buffers offered by the subsystem. He used 16k and 128k. Testing shows that 32k and 64k works fine especially since the kernel does not request more than 64k anyway.

This is not a complete fix of the issue but one that ensures that there is always a buffer available to the USB subsystem. This is probably a good idea anyway since this subsystem must work for the operating system to function. Since it is only necessary on ARM processors that have a lot of memory anyway, it seems a reasonable accommodation.

Since making the modification to the kernel suggested, I have seen no problems or errors. I have done multiple rsync transfers of approximately 1 million files and 14G and, while it takes a while, it works. Earlier reports of a serious loss of performance on an Ext3 filesystem are also resolved by this kernel modification.

June 11, 2008, at 01:34 PM by Rob Lockhart -- Updated info regarding >64MB problems
Changed lines 70-73 from:

This version uses the 2.6.23.14 kernel. At the moment, there is a problem with ARM kernels and more than 128M of RAM. You might want to configure for 128M until it is fixed. Maybe memscan -u 0x0+128M but I haven't tried it.

To use the additional memory, you must modify the startup string in apex by adding the commands 'sdram-init; memscan -u 0x0+256M;' to the beginning of the string. Otherwise it will default to 32M.

to:

This version uses the 2.6.23.14 kernel. At the moment, there is a problem with ARM kernels and more than 64M of RAM. You might want to configure for 64M until it is fixed. Maybe 'memscan -u 0x0+64M' but I haven't tried it. More details here.

To use the additional memory, you must modify the startup string in apex by adding the commands:

 sdram-init; memscan -u 0x0+256M;

to the beginning of the string. Otherwise it will default to 32M.

Deleted lines 92-95:
January 24, 2008, at 12:33 PM by fcarolo -- converted external links to wiki links
Changed lines 16-17 from:

Changing to the Apex 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. 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:

Changing to the Apex 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. 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.

Changed lines 22-23 from:

If you want to return to Redboot, you must download the entire image and then put your slugs MAC address in the right place before telling apex to overwrite itself (one way street again) 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.

to:

If you want to return to Redboot, you must download the entire image and then put your slugs MAC address in the right place before telling apex to overwrite itself (one way street again) 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.

Changed line 44 from:

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.\\

to:

Update Nov 19 '06: I just used the information on 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.\\

Changed lines 54-55 from:

See also FatSlug

to:

See also FatSlug

January 24, 2008, at 12:41 AM by sdm485 -- added a mention about the current ARM kernel memory >128M problem.
Changed lines 70-71 from:

This version uses the 2.6.23.14 kernel.

to:

This version uses the 2.6.23.14 kernel. At the moment, there is a problem with ARM kernels and more than 128M of RAM. You might want to configure for 128M until it is fixed. Maybe memscan -u 0x0+128M but I haven't tried it.

January 24, 2008, at 12:31 AM by sdm485 --
Changed lines 8-9 from:

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. It is best not to fiddle with a bootloader as it is the piece of software you need to recover from a disaster. The RedBoot loader which comes with the default for the nslu2 sets the hardware for 32M of memory (there is some dispute about how much). This cannot be changed without rebuilding the software and that is risky. Early builds such as OpenSlug 2.7 and earlier had the command line hardcoded into the kernel and they ignored any information passed to them by the bootloader. There are two alternatives; replace the bootloader or add a second bootloader that can be changed. The ultimate goal, in any case, is to configure the hardware and pass the correct memory size to a kernel that is listening.

to:

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. It is best not to fiddle with a bootloader as it is the piece of software you need to recover from a disaster. The RedBoot loader which comes with the nslu2 sets the hardware for 32M of memory (there is some dispute about how much). This cannot be changed without rebuilding the software and that is risky. Early builds such as OpenSlug 2.7 and earlier had the command line hardcoded into the kernel and they ignored any information passed to them by the bootloader. There are two alternatives; replace the bootloader or add a second bootloader that can be changed. The ultimate goal, in any case, is to configure the hardware and pass the correct memory size to a kernel that is listening.

January 24, 2008, at 12:30 AM by sdm485 -- major overhaul and cleanup
Changed lines 6-40 from:

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.

UPDATE

It 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.

to:

General Info

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. It is best not to fiddle with a bootloader as it is the piece of software you need to recover from a disaster. The RedBoot loader which comes with the default for the nslu2 sets the hardware for 32M of memory (there is some dispute about how much). This cannot be changed without rebuilding the software and that is risky. Early builds such as OpenSlug 2.7 and earlier had the command line hardcoded into the kernel and they ignored any information passed to them by the bootloader. There are two alternatives; replace the bootloader or add a second bootloader that can be changed. The ultimate goal, in any case, is to configure the hardware and pass the correct memory size to a kernel that is listening.

Apex Bootloader

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. Current versions include a command to scan for hardware and configure the SDRAM controller as needed and a memory scanning command to determine the amount of contiguous memory available. These can be used configure the RAM and pass the memory size to the kernel. Previous versions required that you specify in the config file the number of banks and their size. Apex can be used as the primary bootloader or as you will note in recent slugos releases, the secondary bootloader.

Changing the Bootloader

Changing to the Apex 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. 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.

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 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 download the entire image and then put your slugs MAC address in the right place before telling apex to overwrite itself (one way street again) 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.

Added lines 26-27:

Modifying Redboot in Place

Deleted lines 53-82:

APEX and a FatSlug

Updated 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

January 23, 2008, at 11:55 PM by sdm485 --
Changed lines 106-107 from:

The default startup command used by apex does not do any memory scanning to check for more than the default amount of SDRAM (32MB total). You must add these scanning commands to the apex startup command via the serial terminal (still need that) using 'setenv'. The great thing is that apex is saving these changes to the parameters in the flash chip and they are not lost between resets or power cycles.

to:

The default startup command used by apex does not do any memory scanning to check for more than the default amount of SDRAM (32MB total). You must add these scanning commands to the apex startup command. The program apex-env can be used if you don't have a serial terminal. Apex saves these changes to the parameters in the flash chip and they are not lost between resets or power cycles.

January 23, 2008, at 11:50 PM by sdm485 --
Changed lines 117-118 from:

To use the additional memory, you must modify the startup string in apex by adding the commands 'sdram-init; memscan -u 0x0+256M; to the beginning of the string. Otherwise it will default to 32M.

to:

To use the additional memory, you must modify the startup string in apex by adding the commands 'sdram-init; memscan -u 0x0+256M;' to the beginning of the string. Otherwise it will default to 32M.

January 23, 2008, at 11:49 PM by sdm485 -- added a bit about apex-env
Changed lines 115-116 from:

This version uses the 2.6.23.14 kernel. I got tired of having the reenter the modified startup string each time I reflashed so I modified the defconfig file in openembedded/packages/apex/apex-nslu2-1.5.13/ to add those commands as part of the default startup environment.

to:

This version uses the 2.6.23.14 kernel.

To use the additional memory, you must modify the startup string in apex by adding the commands 'sdram-init; memscan -u 0x0+256M; to the beginning of the string. Otherwise it will default to 32M.

The program apex-env can be installed to manipulate the apex environment without requiring a serial port. Each time you flash a new image, any changes to the apex environment strings are lost. The reason doing this is to allow recovery from a possibly damaged apex. So rewriting the info is a small price to pay for the recovery ability.

It is possible to modify the defconfig file in openembedded/packages/apex/apex-nslu2-1.5.13/ to add those commands as part of the default startup environment.

Changed lines 132-135 from:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuilt the image. You do not have to rebuild the kernel as it is all put together in 'slugos-image' and each time you run slugos-image, it builds a new image so no need to delete stamps there either.

This image also boots a standard 32M nslu2 so I think (IMO) it would be very nice to incorporate the memory commands to the default build. It would also be nice to move the location of apex nonvolatile env variables to the sysconf block so that they can survive reflashing as well. I just am not sure if the read write routines to this block (in turnup for instance) will trash the strings. A lot of unused space though.

to:

You must delete the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuild the image. You do not have to rebuild the kernel as it is all put together in 'slugos-image' and each time you run slugos-image, it builds a new image so no need to delete stamps there either.

January 20, 2008, at 12:21 AM by sdm485 --
Changed lines 126-127 from:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuilt the image. You do not have to rebuild the kernel as it is all put together in 'slugos-image' and each time you run slugos0image, it builds a new image so no need to delete stamps there either.

to:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuilt the image. You do not have to rebuild the kernel as it is all put together in 'slugos-image' and each time you run slugos-image, it builds a new image so no need to delete stamps there either.

January 19, 2008, at 06:51 PM by sdm485 --
Changed lines 126-129 from:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuilt the image.

This image also boots a standard nslu2 so I think (IMO) it would be very nice to incorporate the memory commands to the default build. It would also be nice to move the location of apex nonvolatile env variables to the sysconf block so that they can survive reflashing as well. I just am not sure if the read write routines to this block (in turnup for instance) will trash the strings. A lot of unused space though.

to:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuilt the image. You do not have to rebuild the kernel as it is all put together in 'slugos-image' and each time you run slugos0image, it builds a new image so no need to delete stamps there either.

This image also boots a standard 32M nslu2 so I think (IMO) it would be very nice to incorporate the memory commands to the default build. It would also be nice to move the location of apex nonvolatile env variables to the sysconf block so that they can survive reflashing as well. I just am not sure if the read write routines to this block (in turnup for instance) will trash the strings. A lot of unused space though.

January 19, 2008, at 06:44 PM by sdm485 --
Changed lines 126-127 from:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and then rebuilt the image.

to:

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and rebuilt the image.

January 19, 2008, at 06:43 PM by sdm485 --
Changed lines 117-125 from:

CONFIG_ENV_DEFAULT_STARTUP_OVERRIDE=y

CONFIG_ENV_DEFAULT_STARTUP="sdram-init; memscan -u 0x0+256M; copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel \ autoboot.; boot"

CONFIG_ENV_DEFAULT_STARTUP_ALT_P=y

CONFIG_ENV_DEFAULT_STARTUP_ALT="copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot"

to:

CONFIG_ENV_DEFAULT_STARTUP_OVERRIDE=y
CONFIG_ENV_DEFAULT_STARTUP="sdram-init; memscan -u 0x0+256M; copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot"
CONFIG_ENV_DEFAULT_STARTUP_ALT_P=y
CONFIG_ENV_DEFAULT_STARTUP_ALT="copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot"

January 19, 2008, at 06:42 PM by sdm485 --
Added line 118:
Added line 120:
Added line 122:
January 19, 2008, at 06:41 PM by sdm485 --
Changed lines 117-123 from:

[- CONFIG_ENV_DEFAULT_STARTUP_OVERRIDE=y CONFIG_ENV_DEFAULT_STARTUP="sdram-init; memscan -u 0x0+256M; copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot" CONFIG_ENV_DEFAULT_STARTUP_ALT_P=y CONFIG_ENV_DEFAULT_STARTUP_ALT="copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot" -]

to:

CONFIG_ENV_DEFAULT_STARTUP_OVERRIDE=y CONFIG_ENV_DEFAULT_STARTUP="sdram-init; memscan -u 0x0+256M; copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel \ autoboot.; boot" CONFIG_ENV_DEFAULT_STARTUP_ALT_P=y CONFIG_ENV_DEFAULT_STARTUP_ALT="copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot"

Changed lines 129-131 from:

sdm485

to:
January 19, 2008, at 06:40 PM by sdm485 --
Changed line 117 from:

small

to:

[-

Changed lines 122-123 from:
to:

-]

January 19, 2008, at 06:39 PM by sdm485 --
Changed line 117 from:

-small-

to:

small

January 19, 2008, at 06:38 PM by sdm485 -- info for changing startup string in beta-4.9
Changed lines 4-5 from:
to:
Added lines 112-131:

slugos-beta-4.9

This version uses the 2.6.23.14 kernel. I got tired of having the reenter the modified startup string each time I reflashed so I modified the defconfig file in openembedded/packages/apex/apex-nslu2-1.5.13/ to add those commands as part of the default startup environment.

-small- CONFIG_ENV_DEFAULT_STARTUP_OVERRIDE=y CONFIG_ENV_DEFAULT_STARTUP="sdram-init; memscan -u 0x0+256M; copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot" CONFIG_ENV_DEFAULT_STARTUP_ALT_P=y CONFIG_ENV_DEFAULT_STARTUP_ALT="copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot.; boot"

I then deleted the apex-nslu2-1.5.13 stamps as well as the contents of the /tmp/work/armv5teb-linux/apex-nslu2-1.5.13-r1 directory and then rebuilt the image.

This image also boots a standard nslu2 so I think (IMO) it would be very nice to incorporate the memory commands to the default build. It would also be nice to move the location of apex nonvolatile env variables to the sysconf block so that they can survive reflashing as well. I just am not sure if the read write routines to this block (in turnup for instance) will trash the strings. A lot of unused space though.

sdm485

sdm485

January 08, 2008, at 12:33 PM by fcarolo -- fixed false wikilink
Changed lines 74-75 from:

- select the platform (INTEL IXP42x?)

to:

- select the platform (INTEL IXP42x)

December 30, 2007, at 05:50 PM by sdm485 --
Changed lines 109-110 from:
to:

sdm485

December 30, 2007, at 05:46 PM by sdm485 --
Changed lines 103-106 from:

Things have gotten much easier with the this version of slugos. The principle reason is that the Apex bootloader has been added as a second stage bootloader. The boot sequence is Redboot loads and launches Apex which loads and launches Linux. It is therefore possible to have control over the boot parameters via apex while not risking a corrupted initial bootloader. Very safe and very configurable.

The default startup command used by apex does not do any memory scanning to check for more than the default amount of SDRAM (32MB total). You must add these scanning commands to the apex startup command via the serial terminal (still need that) using setenv startup. The great thing is that apex is saving these changes to the parameters in the flash chip and they are not lost between resets or power cycles.

to:

Things have gotten much easier with this version of slugos. The principle reason is that the Apex bootloader has been added as a second stage bootloader. The boot sequence is: Redboot loads and launches Apex which loads and launches Linux. It is therefore possible to have control over the boot parameters via apex while not risking a corrupted the initial bootloader (Redboot). Very safe and very configurable. You have upslug2 to flash new images which is much better and safer than the serial port downloads required if apex is the only bootloader.

The default startup command used by apex does not do any memory scanning to check for more than the default amount of SDRAM (32MB total). You must add these scanning commands to the apex startup command via the serial terminal (still need that) using 'setenv'. The great thing is that apex is saving these changes to the parameters in the flash chip and they are not lost between resets or power cycles.

December 30, 2007, at 05:41 PM by sdm485 -- added info for slugos-beta-4.8
Added lines 3-4:
Added lines 99-110:

slugos-beta-4.8

Things have gotten much easier with the this version of slugos. The principle reason is that the Apex bootloader has been added as a second stage bootloader. The boot sequence is Redboot loads and launches Apex which loads and launches Linux. It is therefore possible to have control over the boot parameters via apex while not risking a corrupted initial bootloader. Very safe and very configurable.

The default startup command used by apex does not do any memory scanning to check for more than the default amount of SDRAM (32MB total). You must add these scanning commands to the apex startup command via the serial terminal (still need that) using setenv startup. The great thing is that apex is saving these changes to the parameters in the flash chip and they are not lost between resets or power cycles.

For my fatslug, I interrupted the apex boot by pressing ^C at the appropriate time. I then entered the command 'setenv startup sdram-init; memscan -u 0x0+256m; copy $kernelsrc $bootaddr; wait 10 Type ^C key to cancel autoboot; boot'. This stored the startup command string at nor:0x7c000 which is the configured env(ironment) storage area.

June 02, 2007, at 10:12 AM by sdm485 -- minor edits
Changed lines 80-84 from:

- 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 builtin 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 entry is 0x04000000. Note that the default entry is 0x02000000 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 to commands 'sdram-init' and 'memscan' so check that they are selected in the 'Commands' menu.

to:

- 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.

Changed lines 89-91 from:

The rest of the entries should work fine. You save the configuration and then 'make' it. The result is an apex.bin file. 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 unslung 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.

to:

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.

Deleted line 93:
June 02, 2007, at 10:06 AM by sdm485 -- Updates and revisions
Changed lines 11-16 from:

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.

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. If you issue the boot command, it copies the rootfs to RAM as well and jumps to the beginning of linux (at 0008000h) and the system boots as normal. The APEX website has the info for doing these steps. See http://wiki.buici.com/wiki/Main_Page

to:

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

Changed lines 25-26 from:

CMDLINE_ROOT= "mem=64M".

to:

CMDLINE_ROOT= "mem=64M". (This is deprecated, sdm485).

Changed lines 68-101 from:

Download the APEX source (1.4.5) and run 'make menuconfig' which builds and presents a configuration screen. You might have to install a few packages to get menuconfig to work.

First, you select the platform (INTEL IXP42x?)

Second, select the compiler in general setup. Since I compiled APEX on a 'slug', I sort of cheated by shortening the string to just /usr/gcc 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.

Third, set the implementation to NSLU2

Fourth, set the endian-ness (very important) I use Openslug which is bigendian.

Fifth, 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 entry is 0x04000000. Note that the default entry is 0x02000000 which corresponds to 32M byte across two chips in one bank (a standard NSLU2).

The rest of the entries should work fine. You save the configuration and then 'make' it. The result is an apex.bin file. 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. (edit: i'm afraid it is, it appears that it can be fixed by chainloading apex while it executes - may be fixed in the future, if author gets a FatSlug)

You cannot use the serial port to configure APEX. It is necessary, however, to tell APEX to write itself to flash. The APEX boot command line string still does not work (at least not for me) but I don't think it is APEX. The boot command line workaround presently used in the kernel overrides any bootloader command line. It will probably always be the case because of a fault in the Redboot binary used as the default bootloader.

to:

Updated 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 builtin 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 entry is 0x04000000. Note that the default entry is 0x02000000 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 to 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. 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 unslung 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.

April 20, 2007, at 10:57 AM by Henrik --
Changed line 104 from:

See also MemoryExpansion

to:

See also FatSlug

April 20, 2007, at 10:35 AM by Henrik --
Added lines 103-104:

See also MemoryExpansion

March 28, 2007, at 12:40 AM by Rob Lockhart -- added instructions about restoring Redboot as the boot loader from Apex
Changed lines 17-19 from:

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.

to:

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.

March 28, 2007, at 12:36 AM by Rob Lockhart -- added note about checking JTAG connection
Changed lines 11-12 from:

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......

to:

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.

February 08, 2007, at 03:52 AM by Mannkind -- Comment on Flashing RedBoot for 64MB when you only have 32MB
Added lines 61-62:

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

November 19, 2006, at 09:08 PM by Steve G -- Redboot with a 64M slug
Changed lines 56-57 from:

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.
dd if=/dev/mtdblock0 of=redboot.bin

to:

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.
dd if=/dev/mtdblock0 of=redboot.bin\\

November 19, 2006, at 09:06 PM by Steve G -- Redboot with q 64M slug
Added lines 56-60:

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.
dd if=/dev/mtdblock0 of=redboot.bin Then I used a hex editor to put the MAC address in (offset 0x3FFB0) and found & changed the instruction that sets up the memory controller (in my case offset 0x0020b0 changed from e3a01008 to e3a0100a; the last byte is what gets written to SDR_CONFIG). So now I have a Fatslug but I still have Redboot upgrade mode & TFTP.

November 10, 2006, at 03:38 AM by Szafran --
Changed lines 83-84 from:

is no fault of APEX.

to:

is no fault of APEX. (edit: i'm afraid it is, it appears that it can be fixed by chainloading apex while it executes - may be fixed in the future, if author gets a FatSlug)

November 06, 2006, at 03:49 AM by sdm485 -- additional info
Changed lines 11-12 from:

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.

to:

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......

Changed lines 56-93 from:

Steve G

to:

Steve G

APEX and a FatSlug

Download the APEX source (1.4.5) and run 'make menuconfig' which builds and presents a configuration screen. You might have to install a few packages to get menuconfig to work.

First, you select the platform (INTEL IXP42x?)

Second, select the compiler in general setup. Since I compiled APEX on a 'slug', I sort of cheated by shortening the string to just /usr/gcc 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.

Third, set the implementation to NSLU2

Fourth, set the endian-ness (very important) I use Openslug which is bigendian.

Fifth, 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 entry is 0x04000000. Note that the default entry is 0x02000000 which corresponds to 32M byte across two chips in one bank (a standard NSLU2).

The rest of the entries should work fine. You save the configuration and then 'make' it. The result is an apex.bin file. 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.

You cannot use the serial port to configure APEX. It is necessary, however, to tell APEX to write itself to flash. The APEX boot command line string still does not work (at least not for me) but I don't think it is APEX. The boot command line workaround presently used in the kernel overrides any bootloader command line. It will probably always be the case because of a fault in the Redboot binary used as the default bootloader.

sdm485

October 21, 2006, at 11:55 PM by sdm485 -- consolidated recent info and removed outdated stuff
Changed lines 3-22 from:

<Tiersten> packages/hal/arm/xscale/ixdp425/current/include/hal_platform_extras.h

<dyoung> http://www.intel.com/design/network/applnots/25430801.pdf

<dyoung> page 17.

<dyoung> Right, so for ka6sox's immediate problem, we just need to change the mmu table tiersten mentioned ahdn change the SDRAM options in ixdp425.h

<dyoung> ka6sox, SDRAM_CONFIG_2x16Mx16 did you say?

<ka6sox-laptop> yes

<ka6sox-laptop> that is the correct configuration.

Patches available in sluggo/fatslug.patch.

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.

The Redboot loader may initialize the memory as 64M in size even though only 32M of hardware is actually available. This can be determined by writing test data into the lower 32M (0000000h-1FFFFFFh) and seeing if it can be seen in the next 32M (2000000h-3ffffffh). If this really is the case, then the Redboot loader can be used for a 64M fatslug. It would be great if someone could check this out and update this information. I was told that the Redboot loader supports 128M or RAM already but have no personal experience about that.

to:

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.

Changed lines 13-16 from:

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.

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. If you issue the boot command, it copies the rootfs to RAM as well and jumps to the beginning of linux (at 0008000h) and the system boots as normal. The APEX website has the info for doing these steps.

to:

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.

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. If you issue the boot command, it copies the rootfs to RAM as well and jumps to the beginning of linux (at 0008000h) and the system boots as normal. The APEX website has the info for doing these steps. See http://wiki.buici.com/wiki/Main_Page

Changed line 23 from:

It 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. It is not the best method, but one way to do it is to modify the file:

to:

It 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:

Changed lines 25-26 from:

CMDLINE_ROOT= "mem=64M". A better way is to modify the hidden config file in the kernel build directory by adding the parameter there.

to:

CMDLINE_ROOT= "mem=64M".

Steve G describes another alternative below. I have used his method and it works fine.

Changed lines 32-33 from:

I have not done it but I think the ideal way to do a FatSlug would be to retain Redboot and use the upgrade mode to load in a modified image. This would limit you to 64M maximum memory but my tests have shown that there are other problems if you try to use more memory. When I tell my system to use the full 128M it has, I get DMA errors and it hangs. I was told that this an active problem in the 2.6.16 kernel that is part of the Openslug 3.7 beta build.

to:

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.

October 21, 2006, at 11:25 PM by sdm485 -- minor cleanup
Changed lines 19-20 from:

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. This is done by the bootloader during configuration. The bootloader does this by writing a hardware register SDR_CONFIG during boot.

to:

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.

Changed lines 41-42 from:

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'. This is 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.

to:

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.

October 20, 2006, at 09:24 PM by Steve G -- Experiences of Redboot & Apex
Added lines 53-64:

I finally managed to get my 64M (2 chips 16Mx16) configuration working!
- Using Redboot, the SDR_CONFIG register at 0xCC000000 is always 0x18 (= 32 MB 2 chips).
If I manually write 0x1A (= 64MB 2 chips) there before booting I get a 64M system
Otherwise I get a kernel panic whenever I access beyond 32MB.
dd if=/dev/mtdblock4 of=<somewhere in ramfs> is a good way to eat up RAM

- Using Apex built for 32MB or 64MB is exactly the same when testing Apex in RAM :-(
...except that it's a little more difficult to write that register!

- But if I flash a 64MB version of Apex all is well. It puts 0x1A in the SDR_CONFIG
register and boots straight into a stable 64MB system.

October 16, 2006, at 05:19 PM by Steve G -- Formatting
Changed line 50 from:

releases/slugos-3.10-beta/openembedded/packages/linux/ixp4xx-kernel/2.6.16/94-nslu2-setup.patch

to:

releases/slugos-3.10-beta/openembedded/packages/linux/ixp4xx-kernel/2.6.16/94-nslu2-setup.patch\\

October 16, 2006, at 05:19 PM by Steve G -- File to edit for a fatslug
Added lines 48-53:

In my case I had to edit:
releases/slugos-3.10-beta/openembedded/packages/linux/ixp4xx-kernel/2.6.16/94-nslu2-setup.patch In fact, that file even has comments in it about a "fatslug".

Steve G

June 05, 2006, at 12:17 PM by sdm485 --
Changed lines 21-22 from:

The Redboot loader may initialize the memory as 64M in size even though only 32M of hardware is actually available. This can be determined by writing test data into the lower 32M (0000000h-1FFFFFFh) and seeing if it can be seen in the next 32M (2000000h-3ffffffh). If this really is the case, then the Redboot loader can be used for a 64M fatslug. It would be great if someone could check this out and update this information.

to:

The Redboot loader may initialize the memory as 64M in size even though only 32M of hardware is actually available. This can be determined by writing test data into the lower 32M (0000000h-1FFFFFFh) and seeing if it can be seen in the next 32M (2000000h-3ffffffh). If this really is the case, then the Redboot loader can be used for a 64M fatslug. It would be great if someone could check this out and update this information. I was told that the Redboot loader supports 128M or RAM already but have no personal experience about that.

Changed lines 39-44 from:

CMDLINE_ROOT= "mem=64M".

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'. This is 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 retain Redboot and use the upgrade mode to load in a modified image. This would limit you to 64M maximum memory but my tests have shown that there are other problems if you try to use more memory. When I tell my system to use the full 128M it has, I get DMA errors and it hangs. I think that this is a hardware limitation that would require a patch to get around. It seems to work fine with 64M.

to:

CMDLINE_ROOT= "mem=64M". A better way is to modify the hidden config file in the kernel build directory by adding the parameter there.

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'. This is 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 retain Redboot and use the upgrade mode to load in a modified image. This would limit you to 64M maximum memory but my tests have shown that there are other problems if you try to use more memory. When I tell my system to use the full 128M it has, I get DMA errors and it hangs. I was told that this an active problem in the 2.6.16 kernel that is part of the Openslug 3.7 beta build.

June 01, 2006, at 05:37 AM by sdm485 --
Changed lines 33-34 from:

UPDATE

to:

UPDATE

Added lines 45-46:

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.

June 01, 2006, at 05:30 AM by sdm485 -- Update and information on how to do it
Changed lines 33-34 from:

My experience so far is that changing the bootloader will not make the kernel use the added memory. It appears (to me, at least) that the kernel boots with command line arguments that include mem=32M. This overrides any arguments from the bootloader. I am trying to reconfigure the kernel with different arguments but have not been successful yet. Any info on this process would be a big help.

to:

UPDATE

It 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. It is not the best method, but 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".

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'. This is 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 retain Redboot and use the upgrade mode to load in a modified image. This would limit you to 64M maximum memory but my tests have shown that there are other problems if you try to use more memory. When I tell my system to use the full 128M it has, I get DMA errors and it hangs. I think that this is a hardware limitation that would require a patch to get around. It seems to work fine with 64M.

May 28, 2006, at 12:46 PM by sdm485 -- More info on the process
Added lines 18-35:

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. This is done by the bootloader during configuration. The bootloader does this by writing a hardware register SDR_CONFIG during boot.

The Redboot loader may initialize the memory as 64M in size even though only 32M of hardware is actually available. This can be determined by writing test data into the lower 32M (0000000h-1FFFFFFh) and seeing if it can be seen in the next 32M (2000000h-3ffffffh). If this really is the case, then the Redboot loader can be used for a 64M fatslug. It would be great if someone could check this out and update this information.

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.

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.

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. If you issue the boot command, it copies the rootfs to RAM as well and jumps to the beginning of linux (at 0008000h) and the system boots as normal. The APEX website has the info for doing these steps.

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.

My experience so far is that changing the bootloader will not make the kernel use the added memory. It appears (to me, at least) that the kernel boots with command line arguments that include mem=32M. This overrides any arguments from the bootloader. I am trying to reconfigure the kernel with different arguments but have not been successful yet. Any info on this process would be a big help.

sdm485

June 22, 2005, at 03:10 PM by tman --
Deleted lines 17-23:

Tip to increase available user ram slightly

You can also free up a small amount of user ram for use by other packages by disabling the UPNP functionality using the Web configuration pages.

RobHam June 2005

June 21, 2005, at 05:28 PM by RobHam -- Tip added to free up a little user ram by disabling UPNP
Changed lines 17-25 from:

Patches available in sluggo/fatslug.patch.

to:

Patches available in sluggo/fatslug.patch.


Tip to increase available user ram slightly

You can also free up a small amount of user ram for use by other packages by disabling the UPNP functionality using the Web configuration pages.

RobHam June 2005

December 08, 2004, at 08:00 AM by dyoung --
Changed line 17 from:

Patches available in sluggo/fatso-patch.

to:

Patches available in sluggo/fatslug.patch.

December 06, 2004, at 02:49 AM by dyoung --
Added lines 16-17:

Patches available in sluggo/fatso-patch.

December 06, 2004, at 12:50 AM by rwhitby --
Changed lines 1-15 from:

This is the software side of Fattening Your Slug.

to:

This is the software side of Fattening Your Slug.

<Tiersten> packages/hal/arm/xscale/ixdp425/current/include/hal_platform_extras.h

<dyoung> http://www.intel.com/design/network/applnots/25430801.pdf

<dyoung> page 17.

<dyoung> Right, so for ka6sox's immediate problem, we just need to change the mmu table tiersten mentioned ahdn change the SDRAM options in ixdp425.h

<dyoung> ka6sox, SDRAM_CONFIG_2x16Mx16 did you say?

<ka6sox-laptop> yes

<ka6sox-laptop> that is the correct configuration.

December 05, 2004, at 11:45 PM by ka6sox --
Changed line 1 from:

Describe ModifyMemorySize here.

to:

This is the software side of Fattening Your Slug.

view · edit · print · history · Last edited by sluggy.
Based on work by sluggy, sdm485, Rob Lockhart, fcarolo, Henrik, Mannkind, Steve G, Szafran, tman, RobHam, dyoung, and rwhitby.
Originally by ka6sox.
Page last modified on August 06, 2008, at 04:00 PM