Messages

1

Hardware Mods / 128 Mb Memory Upgrade

« on: July 05, 2009, 12:19:18 pm »

FYI, I was just looking at a C3000 p2rom:

The table of supported NAND chips starts at offset 0x1c4a0.

Supported are:
Toshiba TC58512FT (Maker 0x98, Device 0x76, 64MByte)
Toshiba TC58DVG02AFT (Maker 0x98, Device 0x79, 128MByte)
Samsung K9F1208U0M (Maker 0xec, Device 0x76, 64MByte)
Samsung K9K1G08U0M (Maker 0xec, Device 0x79, 128MByte)
Samsung K9F2808U0C (Maker 0xec, Device 0x73, 16MByte)
Samsung K9F5608U0C (Maker 0xec, Device 0x75, 32MByte)

Erase size 0x4000, block size 0x200, oob size 0x10 for all of them.
Another value (bank size?) is 0x4000000 for all of them except the Maker 0xec Device 0x76, where it is 0x8000000.

In theory any chip that has the right Maker/Device and matching parameters and is command set compatible should work.
I'd try looking at 128MB or 256MB usb sticks or 256MB/512MB CF cards for matching parts (My old 64MB usb stick uses a TC58512FT compatible TC58DVM92A1FT 64MByte TSOP48, but the sticks PCB has room for two chips).

HTH

2

Hardware Mods / Pimp Your Zaurus: 1gbyte Nand Flash Upgrade

« on: July 12, 2008, 06:21:49 pm »

The nand driver is included in the sharp source tree (or in the cacko source tree, for that matter).
Hacking the driver shouldn't be too difficult, I hope to find the time to do that the coming weekend.
The hacked driver would expose the NAND as just another mtd partition, which can then be formatted using JFFS2.
Using a FS not specifically designed for flash would also be possible, but a big "don't do that" since ther is no wear-leveling.
Unfortunately JFFS2 does not perform well with big filesystem sizes, maybe I'll try YAFFS instead.

Well, it took a bit longer than expected, but it is basically working now.
I can mount jffs2 and read/write to the partition.
I get occasional crc errors though (probably because I commented out the write verification code, that is not converted yet).
For testing I only used 128MB instead of the full size:

Code: [Select]

bash-3.00# df  
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/root                32768     32664       104 100% /
/dev/ram1                  108        29        79  27% /dev
/dev/loop0               26368     26368         0 100% /usr
/dev/mtdblock3           25600     21660      3940  85% /home
none                     10240        24     10216   0% /dev/shm
/dev/mtdblock4          131072     30020    101052  23% /usr/mnt.rom/cf
bash-3.00# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 006d0000 00020000 "Filesystem"
mtd1: 00700000 00004000 "smf"
mtd2: 02000000 00004000 "root"
mtd3: 01900000 00004000 "home"
mtd4: 08000000 00040000 "NAND flash partition 0"
mtd5: 20000000 00040000 "NAND flash partition 1"

Interesting tidbits:
dd if=/dev/mtdblock of=/dev/null clocks in at about 2MB/s (on the 64MB flash)
This corresponds nicely to a benchmark I did on the PIO reads from the CPLD, however if I use the pxa dma engine I can read at >10MB/s.

Well, slight problem with trying to use dma: Apparently I overread the part where the docs state that byte-reads are only allowed for on-chip peripherals
and all external reads have to be 8-byte aligned.
Unfortunately the data register is not 8-byte aligned and only byte-readable.

Aligned dma copies from/to the w100 framebuffer seem to work fine though (didn't get much testing though).

3

Hardware Mods / Pimp Your Zaurus: 1gbyte Nand Flash Upgrade

« on: June 16, 2008, 04:34:32 pm »

Wow!  Really nice mod. Is hacking the NAND driver a trivial matter (asking because from what I hear, Sharp did not release source files). Is hacking the driver the only thing that needs to be done to have the Zaurus see and use the new NAND storage as ROM?  Would love to see a screenshot of System Properties showing all that internal memory.

The nand driver is included in the sharp source tree (or in the cacko source tree, for that matter).
Hacking the driver shouldn't be too difficult, I hope to find the time to do that the coming weekend.
The hacked driver would expose the NAND as just another mtd partition, which can then be formatted using JFFS2.
Using a FS not specifically designed for flash would also be possible, but a big "don't do that" since ther is no wear-leveling.
Unfortunately JFFS2 does not perform well with big filesystem sizes, maybe I'll try YAFFS instead.

If you pre-tin the new memory chip leads, would that extend them enough to make soldering less risky?

Maybe.
I think applying flux to the old chip leads may also help a lot.

Interesting tidbits:
dd if=/dev/mtdblock of=/dev/null clocks in at about 2MB/s (on the 64MB flash)
This corresponds nicely to a benchmark I did on the PIO reads from the CPLD, however if I use the pxa dma engine I can read at >10MB/s.

Hooking up the chip-enable to the green led is just a temporary measure, I'm thinking of hooking it up using a transistor, with the base connected to CE0 using a resistor,
the emitter connected to CE1 an the collector connected to CE (while also leaving the pull-up in place).

This should act so that a low-level on CE1 gets only passed on to CE if CE0 is high-level and so works around the 'Sharp Kernel turns on/off both CE0 and CE1'.

4

Hardware Mods / Pimp Your Zaurus: 1gbyte Nand Flash Upgrade

« on: June 15, 2008, 01:48:17 pm »

Very nice! Now how about 1GB RAM? That would REALLY make my day!

I'm not sure the pxa would support that (and haven't looked into the datasheet).

BTW, unit striptease:

Before mod:
[img]http://uguu.de/~ranma/S6004377s.jpg\" border=\"0\" class=\"linked-image\" /]

After mod:
[img]http://uguu.de/~ranma/S6004398s.jpg\" border=\"0\" class=\"linked-image\" /]

Better view of the flash stack:
[img]http://uguu.de/~ranma/S6004389s.jpg\" border=\"0\" class=\"linked-image\" /]

5

Hardware Mods / Pimp Your Zaurus: 1gbyte Nand Flash Upgrade

« on: June 15, 2008, 07:59:48 am »

Hi all!

I recently looked into how the NAND is hooked up on the Zaurus (my C750):

Code: [Select]

          TP6
            TP5
          TP4
---------   TP3
|Xilinx | TP2
|CPLD   |   TP1
|       |
---------
TP1 => CE0
TP2 => CE1! (unused?)
TP3 => /WP
TP4 => /WE
TP5 => ALE
TP6 => CLE

I also found two nicely compatible 8GBit TSOP48 Toshiba Flash Chips in a CNMemory 2GByte CF Card.

So I soldered one of the 8GBit chips on top of the already existing 512MBit chip (all signals except CE are shared).
Soldering was a bitch though (pins did almost, but not quite reach the pins below), but with lots of solder, cursing, solderwick and patience
I eventually had all relevant pins connected.
Since the Linux kernel unfortunately always enables/disables both CE signals I couldn't simply use the CE1 signal from the CPLD, but for now
(first tests) I hooked up CE to the Cathode of the Green EMail-LED (which is normally always off and the transistor acts as an inverter, so
'on' == low, exactly what I need) and a 10k pull-up.

The system boots fine and a hacked up 'fiddle with CEs and read IDs' kernel module finds both Chips just fine:

Code: [Select]

Trying to read id from Flash on CE0
Got maker=98 device=76
Trying to read id from Flash on CE1|GreenLED
Got maker=98 device=d3
According to drivers/mtd/nand/nand_ids.c maker 0x98 is 'Toshiba', device 0x76 is a 'NAND 64MiB 3,3V 8-bit' and
device 0xd3 is the shiny new 'NAND 1GiB 3,3V 8-bit' (Yay!).

This should actually already exercise all control signals, so the only remaining task is to modify the built-in sharp_sl nand driver to properly support two chips.