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

Dan Brown
2005-04-06T13:13:00Z

Zeri Virgo wrote:

>> ...<snip>...
>> Loading kernel ... page 0x.... <- this seems to start at zero and be
>> going up at roughly 0x200 a second up to 0xFFFF then restarting at
>> zero again over and over.
>

The page number you see there is the offset (in 512-byte pages) on the
diskonchip that DOCBoot is currently scanning, trying to find your
kernel. DOCBoot looks for a special tag in the OOB area of each page
belonging to your kernel image. I can think of two reasons for this
process to loop forever:

1) The image didn't get written properly (using nandwrite without the
-o option would certainly have this effect, but you indicated that you
did use -o).
2) DOCBoot is having trouble reading your device, perhaps because my
new non-TSOP DOC2k support is not general enough.

>> Just to give you a clearer picture, the bzImage is 1148021 bytes and
>> doc_spl is 1187472 bytes. The nandwrite command writes doc_spl from 0
>> up to the erase block at 0x118000 which is well within the 0x208000
>> firmware area.
>
>
> Hey, I just noticed that 0x11c000 (0x118000 + 4000) is only 1163264
> bytes - doesn't that mean doc_spl wasn't fully written to the chip!?

No. Each 512-byte page on the flash is associated with 16 bytes of
out-of-band (OOB) data. doc_spl contains this data interspersed with
the normal data. nandwrite reports the page address, which only
reflects the location of the normal data. So, the amount of normal data
in doc_spl is

length * 512 / (512 + 16)

In your case that's 1151488, or 0x119200 bytes of normal data. Thus the
image should end in the erase block which starts at 0x118000 and ends at
0x11C000, as reported by nandwrite.

Note that a partially-written image would NOT result in an infinite loop
in DOCBoot, because (as you saw) it will eventually wrap all the way
around to the start of the device if it can't find the number of tagged
pages it's expecting. After it wraps around, it will (stupidly) make up
the missing pages by reloading tagged pages from the start of the device.

I'm not sure where to go next. Can you please run "mtd_debug info
/dev/mtd0" and tell me the result, just as a sanity check?

-Dan