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 firmware configuration solution herein supports four-chip solutions.
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 4Mx16×4 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 work for four-chip configurations. 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. APEX 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 build the ATAG structure passed to the Linux kernel.
This means you need to update APEX in flash which can be tricky or use one of the Debian distributions that depends on APEX as a second stage loader.
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’
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 properly in my tests.
Copyright by http://wiki.buici.co … lug+Memory+Expansion
Kopiert von https://web.archive. … xpansion#Attachments, da sonst nicht weiter verohanden. Ich suche noch Bilder.