Re: [PATCH v3] mtd: nand: Add driver for M-sys / Sandisk diskonchip G4

[Robert Jarzmik <robert.jarzmik@free.fr>]

Mike Dunn <mikedunn@newsguy.com> writes:

> On 11/10/2011 02:06 PM, Robert Jarzmik wrote:
> Interesting.  We took separate paths in this reverse engineering effort.  I
> observed activity during operation of the native OS using TrueFFS library, and
> you engaged more in trial-and-error, guided by inspection of disassembled code
> (if I'm not mistaken).  You may have made some more discoveries beyond my
> observation.  I have to inspect your code.  I know that reading oob-only was a
> different "sequence" than a normal page read.  Never saw oob-only write.
Ah, that seems different from docg3.
In docg3, look at doc_read_page_prepare(), and pay attention to the "offset"
parameter of the function. This one allows you to "seek" in the page directly to
the OOB area.

For the write, look at doc_write_seek(), and pay attention to the "ofs"
parameter of the function. And the write length (ie. the number of bytes written
the IO space) _can_ be 16, 512, or even 528).

> Ah, yes.  Never considered this.  If I understand you correctly, you are
> pointing out the fact that my hack for deferring oob write until after the page
> data is written breaks when multiple nandwrite processes are running.  I haven't
> tested with access from multiple processes yet.  But yes, the hack assumes only
> one process is accessing the device.
Alas, I did exactly as you did, driven by nandwrite :)

>  Even if you can write oob-only, you can't subsequently
> write the page data (with or without writing its ecc bytes), can you?
I don't know. I tried to write the OOB only, and the page only, or both, but in
1 page_write call. I never tried to do it in 2 page_program cycles ... I'll try
to make one write (without the oob, in raw mode), and then one write with the
oob to check.

>> No, mine G3 has no such blocks.
> Then how do you know it's one bit per block?
When I was retro-engineering the SAFTL partition scheme, I found out that when
UBoot (proprietary mioa701 bootloader) reads a binary partition (in my case
MSIPL), it always loads page4 of bi-block(0,1), and then scans from block (5,6)
onward for the first block where :
  page[block >> 3] & (1 << (block & 0x7)) == 1
Then, if the first block was 10 for example, the SAFTL header will be looked in
blocks (10..2048), and not (5..2048).

Now, in block(5,6) I have the SAFTL header (I know because of the CNAND tag),
you can check on my wiki.

So the only logical conclusion for skipping these first blocks is that they
actually are bad blocks.

> You're probably right.  I had no ambitions of trying to update the table
> anyway.  Only to read it and update the bbt table in RAM accordingly,
Yes, that's a good review comment you could do on docg3 driver which behaves
... poorly in this area :)

Cheers.

-- 
Robert