[PATCH v2 00/16] DocG3 fixes and write support

[Robert Jarzmik]

Mike Dunn <mikedunn at newsguy.com> writes:

> How did you figure out these operating modes and the protected part stuff?  From
> reverse-engineering a disassembled binary?  I'm impressed.  You don't get that
> level of detail from just monitoring cpu accesses to the device during normal
> operation.
Retro-engineering and the nandwrite tests.
You see nandtest did not work. I could see why, and made some additionnal
tests. The result was that writting to page 0 and page 1 gave back the AND of
these both pages.

And from there, I checked what was the difference between DOCG3 IPL and SPL, and
landed on the "mode" register.

> BTW, I'm coming around to your thinking that the nand interface is not
> appropriate for these chips.  Even though they are nand, the lack of any
> standard nand interface means the nand base does not do much for you except
> obfuscate.  Memory based bbt maintenance is handled in nand base, maybe a couple
> other minor things.  I hope I change my mind; otherwise I'll have to rework the
> G4 driver :-(
I don't know for G4, but I'm more convinced for G3 as well, as NAND interface
provides some state machine in the chip (where the last seek occured, ...).

> I still strongly suspect that the G3 is very similiar to the P3 in my Treo
> 650.  At some point down the road I'll test it out on the P3.  Device capacity
> might be the only difference between the two devices.  If so, the G3 driver
> might even work on the P3 right out of the box.
And if not right out of the box, I'll bet on :
 - adding a DOC_CHIPID_P3 ...
 - and if the chip is bigger, amend doc_setup_addr_sector(0 and
 doc_setup_writeaddr_sector() to input another byte of address (ie. add a line
 with doc_flash_address(docg3, (sector >> 24) & 0xff).

Cheers.

--
Robert