NSLU2 Memory Expansion -- Fat Slug
From Buici
The NSLU2 RAM memory capacity, as shipped, is 32MiB. The ixp4xx XScale CPU is capable of addressing up to 256MiB. In order to increase this capacity, you'll need to install new memory chips and you'll need to make that memory available to your favorite operating system
Contents |
References
[1] Four-chip memory expansion, the piggy back method.
[2] Photos of the four-chip solution.
Installing Memory
There are two ways to increase the RAM on your Slug. You can either double up with chips of the same organization, or you can replace the chips on the board with higher capacity ones. I'm sure that the former method works, but I don't believe that the configuration solution herein supports four-chip configurations.
The board comes with 2 128Mib chips. You're looking for 256Mib or 512Mib chips. Some folks have been successful in harvesting SDRAM chips from DIMMs they've found. Good luck to you bargain hunters. I tired of the search and bought chips from Digikey. What you need are chips with the following characteristics.
- Synchronous DRAM, PC133 compliant (7.5ns), 3.3v
- 54 pin TSOP II packaging
- 256Mib (16Mx16) or 512Mib chips (32Mx16)
The manufacturer of the original memory, ISSI, does not have 512Mib chips for sale on DigiKey's site. There are 256Mib chips. IMHO, if I'm going to go through the hassle of replacing the memory, I'm going to spend a little more to quadruple the RAM instead of doubling it.
I bought the 512Mib Micron memory: MT48LC32M16A2.
You'll need rework equipment to remove the old memory and replace it with the new. I have access to a microscope and Metcal soldering station. We use ChipQuick and low-temperature solder to ease the old parts from boards. You'll need to remove the battery holder from your Slug before working on the memory chips.
I found that Kingston sells a DIMM part [KVR133X64C3/128] with four 4Mx16x4 chips. These are the same organization as the chips that come on the slug.
Configuring the Slug for More RAM via APEX
Up to now, most folks have been either recompiling RedBoot or replacing RedBoot with APEX so that the larger memories are configured and detected. As of version 1.4.17, APEX has support for enabling larger memory on the SLUG without either of these tedious tasks.
Let me be clear that I haven't verified that this will in a four-chip configuration. Because we're running APEX as a second-stage loader from SDRAM, when we change the memory configuration register, there should be no way for APEX to set the mode register of the second bank of memory. Version 1.4.17 performs a cache lock-down while reinitializing SDRAM, so it may work.
What we have to do is simple. We need to update the SDRAM configuration register so that the SDRAM controller allows us to address the extra memory. RedBoot will already have configured the SDRAM mode registers. Schematically, it looks like this:
- RedBoot initializes the hardware.
- RedBoot loads APEX (as if it were the Linux kernel) and executes it.
- APEX updates the memory configuration register.
- APEX rescans memory.
- APEX boots the kernel with an accurate memory map.
In APEX 1.4.17, there is a special command, sdram-init, that re-configures the SDRAM configuration register and then searches for unique memory. There is another new command, memscan, that scans memory and constructs the memory map APEX uses to construct the ATAG for RAM.
This means you need to update APEX in flash which I will not describe here as the procedure depends on the endian-ness of your system and features of your distribution.
Putting this together means you need to change the startup variable in APEX to include sdram-init and a memory scan. You can do this from the console by interrupting the boot process with a ^C while APEX copies the kernel and ramdisk from flash, or you can use the user-space program apex-env. It is important to insert the new commands at the beginning of the command list and to maintain all of the other commands. Single quotes around the startup commands are important to prevent expansion of the APEX variable references.
# apex-env ... startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C to cancel autoboot.; boot # apex-env setenv startup 'sdram-init; memscan -u 0+256m; copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C to cancel autoboot.; boot'
64MiB May be the Limit
There appears to be an issue with the Linux kernel and more than 64MiB of memory on the Slug. If you find that your fat-slug is having lock-up or crash problems and you are using more than 64MiB of memory, try changing the memscan command so that only 64MiB are recognized.
memscan -u 0+64m
Configuring the Slug for More RAM via arm-kernel-shim
For those who do not use APEX, but still want to use more memory, the arm-kernel-shim has support for reconfiguring the SDRAM controller and passing the correct memory size to the kernel. It isn't as flexible as APEX in that it cannot detect memory. This support was added in version 1.4 of [the shim].
Potential Future Work
Version 1.4.17 of APEX implements a cache lock-down in sdram-init in order that the SDRAM controlled may be taken off-line while SDRAM is reconfigured. I'm not sure that all of this should be OK since we're supposed to disable the refresh counter while we bring-up SDRAM.
Moreover, I've been unable to verify that the cache lock-down is even necessary. When I disable that portion of the code, the SDRAM is still reinitialized. It is possible that the SDRAM controller refuses to go offline, or perhaps I'm not flushing the cache as I expect to.
