OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

> Pimp Your Zaurus: 1gbyte Nand Flash Upgrade, ...first seen on my Zaurus C750 ;)
ranma
post Jun 15 2008, 03:59 AM
Post #1





Group: Members
Posts: 5
Joined: 13-October 07
Member No.: 20,818



Hi all!

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

CODE
          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. smile.gif
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
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. smile.gif
Go to the top of the page
 
+Quote Post
 
Start new topic
Replies
the_oak
post Jun 16 2008, 05:23 AM
Post #2





Group: Members
Posts: 426
Joined: 10-February 04
From: Virginia, USA
Member No.: 1,794



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.

If you pre-tin the new memory chip leads, would that extend them enough to make soldering less risky?
Go to the top of the page
 
+Quote Post
ranma
post Jun 16 2008, 12:34 PM
Post #3





Group: Members
Posts: 5
Joined: 13-October 07
Member No.: 20,818



QUOTE(the_oak @ Jun 16 2008, 05:23 AM) *
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. smile.gif
Unfortunately JFFS2 does not perform well with big filesystem sizes, maybe I'll try YAFFS instead.

QUOTE
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. smile.gif

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'.
Go to the top of the page
 
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 2nd September 2014 - 08:45 AM