Messages in this thread | | | From | Robert Jarzmik <> | Subject | Re: [PATCH v2 00/16] DocG3 fixes and write support | Date | Sun, 13 Nov 2011 11:41:49 +0100 |
| |
Mike Dunn <mikedunn@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
| |