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

[Dan Brown <dan.brown@nrl.navy.mil>]

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