Re: [UPDATE] DOCBoot support for NFTL-based DOC2000

Dan Brown
2005-04-06T18:23:50Z

Dan Brown wrote:
> Zeri Virgo wrote:
>
>> OOB Data: 36 7f eb 1f 3b aa ff ff ff ff ff ff ff ff ff ff
>
> Sounds right, at first glance. The OOB data actually follows each block
> (perhaps that's just a terminology issue :) )

Ah, I see it! That OOB data is actually wrong, it should be:

?? ?? ?? ?? ?? ?? 55 55 ff ff ff ff ff ff ff ff

Here's the whole sordid story:

1) The only reason DOCBoot has been working for *me* lately is because
I've been lazy/stupid.

2) Specifically, although I've been updating my copies of the kernel
code to keep pace with CVS changes, I have *failed* to update my
mtd/utils subdirectory.

3) Thomas recently made a modification to nandwrite. It forces all OOB
bytes not designated as "free" to 0xff. Perfectly sensible.

4) There is apparently a long-standing oddity in diskonchip.c, in which
I set the number of ECC bytes to 6, and designate the last 8 bytes as
"free" bytes. This leaves two bytes (right after the ECC) unaccounted for.

5) DOCBoot puts magic numbers in those exact two OOB bytes.

6) As a result, recent versions of nandwrite will erase the information
DOCBoot needs to identify kernel pages. I've been blissfully unaware of
this because I've been using an older version.

7) So, I've changed diskonchip.c to designate all of the last 10 bytes
as "free". It seems like the right thing to do, since only the first 6
bytes are used by the hardware itself. BUT ....

8) I have this nagging feeling there was a reason for 4).

9) I think this may break compatibility with any jffs2 filesystems
written before the change, because the cleanmarker will be in the wrong
place. Hmm... maybe I should back out the change. David? Thomas? Opinions?

10) AAAARRRGGGHHHH!!!!

-Dan