DSM-G600, DNS-3xx and NSA-220 Hack Forum

Background

When shopping for a BYOD NAS solution; I ultimately chose the DNS-323 based on it's good overall reputation and strong hacking community. However; I did wish that it offered 128MB of RAM like many competing offerings. My interest in additional RAM is primarily for running additional applications (e.g. SqueezeCenter) rather than for network throughput optimization - although I'll take any improvements I can get.

I was inspired by the success others have reported in upgrading RAM on other embedded devices (e.g. NSLU2 and WL500gp); based on the fact that other NAS use the same Marvell Soc and have 128 MB RAM; I assumed the upgrade would be possible.

WARNING - this procedure is risky! Don't attempt this if you don't have a good idea of what you're doing and more importantly if you can't afford to throw away your DNS-323 if you make a mistake!

There are two steps to upgrading the RAM in the DNS-323. First; you must replace the 32MB DDR1 modules on the board with 64MB modules that support the same timing and organization. Second; the U-Boot image in the DNS-323 flash must be patched to support 128MB of RAM. The two steps can be completed separately. This is good it allows for full debugging of the RAM replacement before making the risky U-BOOT patch. A DNS-323 with 64MB x2 RAM modules will run fine as a stock 64MB machine without the U-BOOT patches.

Pre-reqs

1) DNS-323 (obviously); but for clarity this was done on REV B1 hardware with firmware 1.04 (I've since upgraded to 1.05). I don't know what would happen on A1 hardware or with older firmware; although likely the same general procedure could be made to work.

1) Serial access. It is possible without it; but to double check things and be safe (or at least safer) you need access to the U-Boot console.

2) Correct replacement RAM chips; see below.

3) Decent tools for SMT resoldering; see below.

4) Good skills with Linux, etc. While the steps are straight-forward; this is not a newbie process. Poking U-Boot is very risky; you need to understand what's going on, how to double check your work, you must not make any mistakes, and you need to be prepared for everything to go wrong anyway.

5) JTAG access is recommended; if something goes wrong with U-BOOT patching - that's the only recourse. I have the hardware; but hadn't finished getting that working. I was impatient and went ahead anyway; but I fully expected the box to fail to boot after my U-BOOT hack and then I was going to finish up JTAG access. So in short; I got lucky - you might or might not.


Step 1 - Upgrading the Memory

The replacement memory must be TSOP packaged DDR333 or DDR400 SDRAM organized as 32Mx16. In particular 64Mx8 memory probably won't work! Getting the right chips is critical - laptop SODIMMs are often a good place.

See Oleg's Asus WL500gp Memory Upgrade Tutorial for more details; the DNS-323 takes the same memory as the WL500gp. That thread discusses some details of removing RAM modules and also of suitable 32Mx16 options.

I used Samsung K4H511638D-UCB3 chips from a Samsung M470L6524DU0-CB3 200 pin SODIMM module. They were about $30 shipped from MemoryTen.

I'm not going to reproduce a tutorial on removing and replacing the chips here; see the link on the WL500gp or search the net for SMT resoldering advice. But I'll share a few personally experiences.

#1 It is very easy to lift traces and ruin your board if you don't know what you're doing or don't use the right tools. I spent a ton of time on my first project (a WL500w) fixing my mistakes after lifting pads and pulling up trace wires.

#2 Heat gun methods do work very nicely; but I went with a specialty Weller Heat Gun (yes it's $100) for this kind of stuff to avoid collateral damage. I'm sure this can all be successfully done with a $5 soldering iron (and I did finally make the WL500w work using a $20 paint heat gun + lots of fix-up) if you're some great expert - but for me it's a hobby and spending tons of time repairing damage isn't fun. I used high quality metallic duct tape to shield the capacitors and such on the bottom side while heating the ram chip.

#3 Even with good tools and soldering that looks right; it's easy to either bridge legs or have bad connections. When I first completed my soldering my DNS-323 would start up; blink the lights once then shut down (I confirmed from U-Boot code that the lights blink prior to memory initialization). I was ready to remove the chips and start over but decided to resolder instead. I couldn't see much difference; but after resoldering the legs the unit booted fully!

Once you replace the memory modules; your DNS-323 should reboot like normal. If your machine doesn't reboot; you probably have a soldering mistake. Re-check all pins. If the soldering is fine; then maybe you have incompatible RAM chips...

U-Boot and the Linux kernel will both still report 64 MB of RAM at the end of this step.

Step 2 – Patching U-Boot

RAM initialization on the DNS-323 is handled by the U-Boot bootloader. While some U-Boot code (for development boards and such) is designed to dynamically detect memory configuration (likely from DIMM modules); the code for directly attached chips uses hardcoded values.

The U-Boot source for the DNS-323 document the various RAM configuration options and provide values for various development setups as well as the actual values used by the DNS-323 with 64 MB of memory.

While there are a bunch of memory controller settings stored in various registers; it turns out that we only need to modify two of them for the 128MB upgrade since we’re using replacement DDR1 memory with the same timings and other configuration. This is ideal since it means that the stock U-Boot image will boot on the new chips. This should prevent any potential future U-Boot upgrade in a new firmware from bricking an upgraded unit (it would just revert to 64MB behavior and need a new patch).

The existing memory timing information for the DNS-323 can be obtained by reading the memory configuration registers using the U-Boot shell:

Marvell>> md F1001400

Here is the relevant output cross-referenced with names from the U-Boot sources (I reformatted the output a bit):

f1001400: 03148400    SDRAM_CONFIG_REG
          04041000    SDRAM_DUNIT_CTRL_REG
          11602220    SDRAM_TIMING_CTRL_LOW_REG
          0000040c    SDRAM_TIMING_CTRL_HIGH_REG
f1001410: 00000010    SDRAM_ADDR_CTRL_REG 
          00000000    SDRAM_OPEN_PAGE_CTRL_REG    
          00000000    SDRAM_OPERATION_REG
          00000062    SDRAM_MODE_REG
f1001420: 00000000    SDRAM_EXTENDED_MODE_REG
          00000000    
          00063305
          00000000    SDRAM_OPERATION_CTRL_REG
f1001500: 00000000
          03ff0001    SDRAM_BANK0_SIZE
          10000000
          00000000
f1001510: 20000000
          00000000
          30000000
          00000000

Disclaimer: If your values do not match the above settings; then you should not proceed with  the patch without recalculating with values appropriate for your device.

The only two memory parameters that we need to alter for the 128MB upgrade are SDRAM_ADDR_CTRL_REG and SDRAM_BANK0_SIZE. The first needs to be adjusted because our replacement chips are twice the density (512Mb versus 256Mb) of the originals. The second needs to be adjusted to indicate that the overall memory in BANK0 has doubled (I believe they are separate settings as it is possible for a single bank to have more than two chips on some layouts – so the memory controls needs to know both the density per chip and the total memory).

SDRAM_ADDR_CTRL_REG needs to be changed from 0x10 to 0x20.
SDRAM_BANK0_SIZE needs its high 16 bits changed from 0x3ff to 0x7ff

Because the change is so small; it seemed much safer to patch the existing U-Boot rather than trying to recompile it from sources and load that (remember I don’t have JTAG functioning yet).

It is very easy to locate the SDRAM_BANK0_SIZE constant by dumping of U-Boot ("dd if=/dev/mtblock4 of=uboot.bin"). The value appears only once (its store LE so it shows up as “01 00 ff 03” if you use “hexdump –C uboot.bin”)  and an inspection of nearby data reveals other memory constants as well. The actual location is offset 0x14C8 for my copy of U-Boot.

SDRAM_ADDR_CTRL_REG is harder to find; since its such a small value it is inlined by the assembler rather than being stored alone in the binary image.

The actual U-BOOT code that loads the value is:

ldr  r6, 0x10

Assembled that corresponds to 0xE3A06010 (“10 60 A0 E3” in LE output from hexdump). This value also only appears once in the U-Boot image (near other instructions that reference the memory contants including SDRAM_BANK0_SIZE). It is at offset 0xE30.

With the U-Boot locations of the memory constants identified; all we need to do is update the two bytes that changed.

The exact bytes changes are:

0x14CB (decimal 5323)  3 -> 7
0xE30 (decimal 3632) 1 -> 2

I made the changes by editing my uboot.bin manually and then once I’d triple checked everything using the following dd commands to change those two bytes of /dev/mtdblock4 (warning make sure you use /dev/mtdblock4 NOT /dev/mtd4).

dd if=uboot.bin of=/dev/mtdblock4 bs=1 skip=5323 seek=5323 count=1 conv=notrunc
dd if=uboot.bin of=/dev/mtdblock4 bs=1 skip=3632 seek=3632 count=1 conv=notrunc

Next; double check the changes:

diff uboot.bin /dev/mtdblock4

Finally; reboot and hope everything went well. If it did U-Boot will report 128MB of RAM and Linux will confirm the same.

I verified the memory by compiling the newest version of memtester and running it. I was able to pin 105MB of memory and several iterations ran with all tests passing.

Good luck.

-Jeff

Last edited by jdoering (2008-06-10 03:15:24)