[UPDATE] DOCBoot support for NFTL-based DOC2000

Dan Brown dan_brown at ieee.org
Wed Apr 6 09:12:54 EDT 2005


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




More information about the linux-mtd mailing list