The RAM was pretty easy to solder onto the empty pads.

So, now I have the RAM attached, does anyone know the value of the capacitors that need to be added? The factory RAM has 14 capacitors nearby, and the second set of pads has corresponding empty slots on the motherboard. Unfortunately, the capacitors aren't labeled.

Can anyone give me some insight here? Thanks! I attached a picture showing the RAM and the empty spaces on the motherboard.

It seems that the capacitors are on the power supply and ground lines. What function would a capacitor serve in-line to the data and ground lines? Do these caps just provide a power-smoothing effect?

Thank you!!!

My knowledge of microelectronics only stretches far enough to know what to look up on Wikipedia, but that might be enough to help you: http://en.wikipedia.org/wiki/Decoupling_capacitor

Quote:
So logic circuit boards often have a decoupling capacitor between power supply and ground right next to each logic IC. These capacitors decouple every IC from every other IC in terms of supply voltage dips.

AFAIK the actual capacitance value isn't all that critical.

Peter

Just use 100nF caps, I think they're 0603 size. That's what we used on the other chip.

edit: You'll need a way of configuring the extra RAM before the unit actually uses any of it. The central, ISTR, works the same way as the carplayer did in that 0xe000 has the "run linux" code in there, which is run direct from flash and hence you can munge the enables for the second SDRAM bank in there. The sequence is more involved than the carplayer's due to it being SDRAM as opposed to FPM; download the SA1110 datasheet for more info.

The existing SDRAM init code will be in the main loader, at 0x0 in flash, but I don't recommend you attempt to modify and reflash this as if you get it wrong you will need to either:

a) Desolder/reprogram/resolder the flash TSOP
b) FInd that old SA1110 intel reflasher program that bit-bangs a parallel port JTAG (DLC5 cable) in order to drive the boundary scan of the CPU to reprogram the attached intel flash.

Doing it at 0xe000 means you can reflash over serial if it doesn't work.

Good luck! 32MB should pretty much make the central fly with big disks..

Hugo

Thanks Peter, I went ahead soldered the caps down and powered up the board. No smoke. Nothing changed, as expected. I assume the chips get power from the board even though the RAM doesn't recognize them.

Hugo, that was perfect timing, thank you. I'll look into the empeg flash program and see what I can do.

Note to self:

Pull original flash from the /proc/flash* device.

http://empegbbs.com/ubbthreads/showflat.php/Cat/0/Number/50465/page/0/fpart/2/vc/1
There are 2 paths for the boot; if the boot is a normal one then it jumps to 0xe000 (which *is* writable) with r0=hwrev, r1=ram (MB), r2=rom (MB). Early mk1s didn't set up registers like this though, I think (if r0 is >9 then assume it's rev3).

SA-1110 Developer's Manual:

7. In systems containing DRAM or SDRAM, enable banks by setting MDCNFG:DE[3:0]. For
each SDRAM bank pair that has one or both banks enabled, this will force a pass through the
"MRS" (mode register set) state and back to "idle". The MRS commands will program
SDRAM device(s) with the CAS latencies indicated by MDCNFG:TDL2x and
MDCNFG:TDL0x. The burst type and length will always be programmed to sequential and
one (1), respectively.

8. In systems containing SDRAM or SMROM, optionally enable auto-power-down by setting
MDREFR:EAPD and MDREFR:KAPD.

Per page 10-7 in the SA1110 Developer's Guide:

MDCNFG:DE[0] and MDCNFG:DE[1] should be set to 1 to enable memory banks 0 and 1.

MDCNFG:DRAC[1:0] should be set to b10. This will enable 11 row address bits for the ram. (2^11) * 16 = 32,768

Tweaked code from blob bootloader set to my specs:
/* ENABLE SDRAM BANKS */
ldr r2, [r0, #MDCNFG ]
orr r2, r2, #0x00000003
orr r2, r2, #0x00020000
str r2, [r0, #MDCNFG]

Now, I either have to compile this or translate to object code by hand. Then insert the 4 lines before the code taken from 0xe000 and cross my fingers.

Does anyone have an ARM toolchain available and can translate my 4 lines?

Does anyone have the name of the assembler you prefer? I haven't ever compiled assembly before. Would gcc be able to handle this?

ISTR that there was more to it than just enabling the bank; you had to do 8 (junked) accesses first to get the state machine set up correctly. The datasheet does say the right thing here though.

The e000 code is pretty small, you should be able to disassemble it with

arm-elf-objdump -bbinary -marm file.bin (or similar, sorry I can't try it myself).

This outputs the dump in a form that I believe is ok to source into gas. You need to then link it (otherwise forward references aren't fixed up, I believe) and objcopy it to binary - something like

arm-elf-objcopy -O binary input.linked output.bin

Maybe disassemble it again for good measure to check... you should be able to find the debug print code in there near the end (see where it calls it with r0 pointing to an obvious string?) and add some debug just in case everything falls over?

Possibly Peter or John or someone else who still has access to the old empeg cvs might be able to point a little more?

Hugo

edit: forgot to say, I think there are precompiled empeg toolchains around that will do just nicely for modifying this file... but you will need a modified kernel to actually notice the extra memory.

Thanks much altman. I'm now up and running on my new HDD, so I'll be proceeding soon.