I upgraded my J720 to 128MB RAM. Just ordered a few Samsung K4S511632C-KC75 Chips, these are compatible with the J720.
First i desoldered the two 16MB Chips from the ROM/RAM with a Hot-Air soldering station. Then i put the new RAM Chips in place and soldered them on to the board.
On the left side is the board with 128MB and on the right one with 32MB.
In Linux it does work! You need a modified bootloader http://www.sp-net.at/jlime/releases/mongo/bootloaders/729/jlinexec.exe and another mem= value in the PARAMS.txt.
\Storage Card\zimage \Storage Card\ root=/dev/hda2 mem=128m rootdelay=2
Notes from a archived JLime wiki page
Original RAM chips
Original RAM chips are Samsung's K4S281632B-TL1H Simpad Original RAM chips
Simpad originally is equipped with Samsung's K4S561632A. As far as I can see these are just twice bigger versions of Jornada's chips. Replacement chips
Opensimpad.org suggests Micron's MT48LC32M16A2TG-75:
Datasheet Size: 512Mb (64MB) Geometry: 8M x 16Bit x 4 Banks Supply voltage: 3.3V Max. frequency: 133MHz for CL=3, 100MHz for CL=2 Interface: LVTTL Package: 54 pin TSOP II Operating current: 110mA Row addressing: A0 - A12 Bank addressing: BA0, BA1 Column addressing: A0 - A9
According to the above what we need matching is:
16bit width 4 banks 3.3V supply voltage timings
We also need A12 lines of the RAM chips to be connected to the CPU (Original RAM chips have this pin as NC - not connectedl). I have determined with a multimeter that these pins are connected to pin 77 of the ROM board connector, so I think connection to the CPU is present. Replacement chips
According to Hitachi DRAM chips numbering documentation, we are looking for chips with names matching HM5151165??TT-75. Searching for HM5151165* in Google produces no results. Hynix
According to http://www.hynix.com/products/consumer/sdrsdram.jsp, Hynix had never manufactured SDRAM chips bigger than 256Mb. IDT Infineon/Siemens/Qimonda HYB39S512160ATE-7.5
Datasheet Size: 512Mb (64MB) Geometry: 8M x 16Bit x 4 Banks Supply voltage: 3.3V Max. frequency: 133MHz (100MHz at CL=2?) Interface: LVTTL Package: 54 pin TSOP II Operating current: 123mA Row addressing: ? Bank addressing: BA0, BA1 Column addressing: ?
LGS Lifetime Micron
According to Micron's Online catalogue they have never manufactured 1024Mbit (128MB) RAM chips) MT48LC32M16A2TG-75
These 64MB chips were suggested at opensimpad.org, details are shown above. Motorola Nanya NEC
According to DRAM chips numbering documentation, NEC had not manufactured DRAM chips bigger than 128Mb. Samsung
According to Samsung sdr prouct guide feb04.pdf and http://www.chipmunk.nl/dram/Samsung.htm, we are looking for chips with names matching K4S511632?-[TU]?75, where:
K - Samsung memory 4 - DRAM 51 - 512Mb 16 - 16bit organization 3 - 4 banks 2 - LVTTL interface ? - revision (any) [TU] - packaging (TSOPII or TSOPII lead-free) ? - temperature range (any) 75 - PC133 timing (133MHz CL=3, 100MHz CL=2)
There also seem to exist semi-unofficial 1024Mbit chips, for example present in Samsung M390S5658BT1-C7A 2GB ECC SDRAM DIMM modules, namely K4S1G0632B. Unfortunately these are 8bit organized, so useless for us (we need 16bit organization). Searching for K4S1G1632B* in Google produces no results. Unfortunately it seems that Samsung does not manufacture 1024Mbit SDRAM chips with 16bit organization, so upgrading memory to 256MB (2048Mb) is not possible with their parts. K4S511632D-UC75
Datasheet Size: 512Mbit (64MB) Geometry: 8M x 16Bit x 4 Banks Supply voltage: 3.3V Max. frequency: 133MHz (CL=3) Interface: LVTTL Package: 54 pin TSOP II Operating current: 85mA Row addressing: A0 - A12 Bank addressing: BA0, BA1 Column addressing: A0 - A9
SpecTek Texas Instruments Toshiba Vitelic Cheaper alternative
Maybe a cheaper solution (source of chips) would be a SODIMM SDRAM module for a laptop with 64MB chips with matching timing. Viability depends on prices of RAM chips from Memphis. Piggybacking
http://www.cobbleware.com/gp32/gp32ram.html Memory geometry change Memory geometry before the upgrade As seen by the RAM chips
K4S281632B (page 3 of the datasheet) uses 9 bits (CA0 - CA8) for column addressing , 12 bits (RA0 - RA11) for row addressing and is divided into four banks addressed by two bits (BA0 and BA1). We have two of them on the ROM board. Their geometry can then be described as 16 (bits) x 512 (columns) x 4096 (rows) x 4 (banks) x 2 (chips). As seen by the CPU
According to this page the CPU has one memory bank enabled and uses 14 bits for row addressing. It means that it sees the memory as 32 (bits) x 16384 (rows) x 512 (columns) x 1 (bank). I specify rows as a “smaller” unit, because row count is the one CPU knows about. This means that column number is just calculated out of an address to retrieve, bus width and row count. For example when doing reads of incremented addresses one by one, the CPU increases row number every four bytes (as ram is 32bit wide). After row count overflows (reaches 0 again), column number increments. It means that from the CPUs point of view row is a smaller unit than column. Memory geometry after the upgrade As seen by the RAM chips
K4S511632C-KC75 (page 4 of the datasheet) uses 10 bits (A0 - A9) for column addressing , 13 bits (A0 - A11) for row addressing and is divided into four banks addressed by two bits (BA0 and BA1). We have two of them on the ROM board. Their geometry can then be described as 16 (bits) x 1024 (columns) x 8192 (rows) x 4 (banks) x 2 (chips). As seen by the CPU
The only thing we can do to make the CPU see whole new RAM is to increase amount of bits for row addressing to 15 by setting DRAC00,DRAC01,DRAC02 to 1,1,0. According to this Post about MDREFR (“apart from MDCNFG, you might also need to halve the refresh-rate (value in bits [15:4] of the MDREFR-Register) to account for 8K of refresh-adresses rather than 4K with the 128Mbit types.”) and the initial vaule of MDREFR, we should write MDREFR with a value of 0x30740151. I think that column address is calculated out of row bit count value and address to be retrieved. The CPU would then see the memory as 32 (bits) x 32768 (rows) x 1024 (columns) x 1 (bank). What happens to bank selecting?
According to HP flashboard documentation this is how cpu addressing pins are connected to the SDRAM chips (I have verified this on the ROM board with a multimeter): pin name ram pin ram pin name 80 A9 23 A0 81 A10 24 A1 83 A11 25 A2 85 A12 26 A3 87 A13 29 A4 89 A14 30 A5 90 A15 31 A6 92 A16 32 A7 3 A17 33 A8 5 A18 34 A9 7 A19 22 A10 8 A20 35 A11 73 A21 20 BA0 75 A22 21 BA1 77 A23 36 A12
According to the SA1100 developer's manual (page 32) CPU uses A9-A23 for DRAM addressing, hence the shift between address pins. What consequences does having bank select bits in the middle of row select bits? Memory cell addresses change The problem
During normal wince operation bootloader stored in ROM reconfigures DRAM access registers of the SA1110. We are in a tricky situation where our bootloader (or kernel) is in DRAM and we need to reconfigure it. Even worse - physicall addresses will change. Linux decompression routines expect kernel image and initrd/initramfs to be present in memory at continuous addresses. We will have to come up with a solution which will assert this. Finding out the remapping
I tried to come up with the address recalculation routine, but it could not cope with the reality. So I took the practical shortcut.
It turns out that if we store the kernel in the 16MB range [0xc0000000:0xc0ffffff], we don't have to do any recalculations at all, because addresses of these locations do not change.
For the ramdisk we can use the 32MB range [0xc3000000:0xc4ffffff]. The only thing we need to do is to start put the ramdisk at locations starting with 0xc1000000 and tell the kernel that it starts at 0xc3000000. Status
I got a ROM board with a german version of wince. I have replaced K4S281632B-TL1H with K4S511632C-KC75. ROM board with replaced chips boots fine, but wince (as expected) still sees 32MB of RAM. With some changes to linexec I am able to use all 128MB under linux:
/ # mount none -t tmpfs /mnt/ram -o size=110M / # dd if=/dev/sda bs=1M count=105 | md5sum 105+0 records in 105+0 records out 30355be21ab2d6f9002fdb0634bcf729 - / # dd if=/dev/sda bs=1M count=105 of=/mnt/ram/memtest 105+0 records in 105+0 records out / # md5sum /mnt/ram/memtest 30355be21ab2d6f9002fdb0634bcf729 /mnt/ram/memtest / #
You can download linexec builds for 32/64/128MB versions at the 7xx downloads page.
For now I am too lazy to test initrd support :).