docboot: nandwrite: Input file is not page aligned

docboot: nandwrite: Input file is not page aligned

[Joseph M Dupre (AVAB Inc.)]

I am trying to use the /mtd/docboot tool to place a boot image on a 
DOC 2000 (INFTL version), but nandwrite is failing:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 08000000 00004000 "DiskOnChip 2000 (INFTL Model)"
mtd1: 00a14000 00004000 " DiskOnChip BDK partition"
mtd2: 075dc000 00004000 " DiskOnChip BDTL partition"
# flash_eraseall /dev/mtd1
erasing 16 Kibyte @ 74000 -- 4 % complete
Skipping badblock @ 0x00078000
Erasing 16 Kibyte @ a10000 -- 99 % complete.
# nandwrite -o /dev/mtd1 doc_spl
Input file is not page aligned: Success
Data did not fit into device, due to bad blocks.
: Success

First, what is this "Input file is not page aligned" error and how do 
I make the doc_spl image so that it is page aligned?

Second,  there is only one bad block on the 10MB BDK partition, so 
there shouldn't be any problem loading my doc_spl which is only 1.9MB 
(Unless nandwrite is not aware of bad blocks.) How do I fix that 
issue?

Third,  when the kernel reads the bbt it reports two bad blocks:
nand_read_bbt: Bad block at 0x00080000
nand_read_bbt: Bad block at 0x03370000
nand_read_bbt: Reserved block at 0x07ffc000
That, in conjunction with the badblock reported by flash_eraseall, 
indicates to me that the IPL is actually using 2 eraseblocks.
(0x0080000 - 0x00078000 = 0x00008000)
I thought the IPL is only supposed to be in the first erase block.  
Is that correct?

Thanks a mega,

- Joe

Re: docboot: nandwrite: Input file is not page aligned

[Dan Brown]

I can shed some light on some of these issues:

Joseph M Dupre (AVAB Inc.) wrote:
> I am trying to use the /mtd/docboot tool to place a boot image on a 
> DOC 2000 (INFTL version), but nandwrite is failing:
> 
> # cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 08000000 00004000 "DiskOnChip 2000 (INFTL Model)"
> mtd1: 00a14000 00004000 " DiskOnChip BDK partition"
> mtd2: 075dc000 00004000 " DiskOnChip BDTL partition"
> # flash_eraseall /dev/mtd1
> erasing 16 Kibyte @ 74000 -- 4 % complete
> Skipping badblock @ 0x00078000
> Erasing 16 Kibyte @ a10000 -- 99 % complete.

First thing to note:  The "Skipping badblock" is reporting the location 
of the bad block *relative to the start of mtd1*, not relative to the 
start of the entire device.  More on this below.

> # nandwrite -o /dev/mtd1 doc_spl
> Input file is not page aligned: Success
> Data did not fit into device, due to bad blocks.
> : Success
> 
> First, what is this "Input file is not page aligned" error and how do 
> I make the doc_spl image so that it is page aligned?

This is odd.  Can you show me the output of the 'make' command (in 
particular, it prints some info on the # and types of sectors in 
doc_spl)?  Also, what is the exact size of your doc_spl?

> Second,  there is only one bad block on the 10MB BDK partition, so 
> there shouldn't be any problem loading my doc_spl which is only 1.9MB 
> (Unless nandwrite is not aware of bad blocks.) How do I fix that 
> issue?

This is a bug in nandwrite.  Only the first error message (not page 
aligned) is real.  The second one is a completely bogus consequence of 
the first.  Basically, the first error skips over the entire writing 
process to a piece of code designed to close down all the files.  It 
also checks the amount of unwritten data (in your case, ALL of it), and 
reports an error if any data was unwritten.  Ugh.

> Third,  when the kernel reads the bbt it reports two bad blocks:
> nand_read_bbt: Bad block at 0x00080000
> nand_read_bbt: Bad block at 0x03370000
> nand_read_bbt: Reserved block at 0x07ffc000
> That, in conjunction with the badblock reported by flash_eraseall, 
> indicates to me that the IPL is actually using 2 eraseblocks.
> (0x0080000 - 0x00078000 = 0x00008000)
> I thought the IPL is only supposed to be in the first erase block.  
> Is that correct?

Here's what's really happening:

  - The IPL does indeed take up just one block, the first block.
  - The MediaHeader takes up the second block.
  - /dev/mtd1 starts at the third block, at 0x8000.
  - Nandwrite reports a bad block at 0x78000 from the start of mtd1.
  - Adding in the start address of mtd1 we get 0x78000 + 0x8000 = 0x80000.
  - This agrees with the bbt scan.

Hopefully we can figure out your 'not page aligned' issue with some more 
info.

	-Dan

Re: docboot: nandwrite: Input file is not page aligned

[Joseph M Dupre (AVAB Inc.)]

On 11 Oct 2005 at 9:42, Dan Brown wrote:

> This is odd.  Can you show me the output of the 'make' command (in
> particular, it prints some info on the # and types of sectors in
> doc_spl)?  Also, what is the exact size of your doc_spl?
> 
> Hopefully we can figure out your 'not page aligned' issue with some
> more info.

Thanks Dan,

Here is the output from
'make KERN=/tftpboot/kernel-initrd INITRD=/tftpboot/rootfs.gz'
cc -O2  -fno-builtin -nostdinc -c doc_bootstub.S
ld -N -Ttext 0 -o doc_bootstub.elf doc_bootstub.o
objcopy -O binary doc_bootstub.elf doc_bootstub
cc makespl.c -o makespl -DCHECKSUM_LOCATION=0x`nm doc_bootstub.elf | 
grep checksum | cut -d " " -f 1`
cat cmdline | ./makespl doc_bootstub /tftpboot/kernel-initrd doc_spl -
i /tftpboot/rootfs.gz 
Commandline is "root=/dev/ram0 rw init=/linuxrc"
3 bootstub sectors, 10 real-mode sectors, 2420 kernel sectors, 1737 
initrd sectors

The generated doc_spl is 2201760 bytes.

I am using the uClibc "Buildroot" toolchain.  Dev machine is i686 and 
target is i486 with a DOC 2000 (MD2202-D128)

Originally I was using the MTD utils generated by Buildroot to erase 
and load the DOC, but they were using mtd source from Debian's 
archive dated 22/1/05.  I built the current versions of the MTD utils 
but have the same error.

- Joe  

Re: docboot: nandwrite: Input file is not page aligned

[Dan Brown]

Joseph M Dupre (AVAB Inc.) wrote:

>3 bootstub sectors, 10 real-mode sectors, 2420 kernel sectors, 1737 
>initrd sectors
>  
>
Seems reasonable...

>The generated doc_spl is 2201760 bytes.
>  
>
Also reasonable.  Each page is 512 data + 16 OOB

2201760 = 4170 * (512 + 16)

4170 = 3 + 10 + 2420 + 1737

>I am using the uClibc "Buildroot" toolchain.  Dev machine is i686 and 
>target is i486 with a DOC 2000 (MD2202-D128)
>
>Originally I was using the MTD utils generated by Buildroot to erase 
>and load the DOC, but they were using mtd source from Debian's 
>archive dated 22/1/05.  I built the current versions of the MTD utils 
>but have the same error.
>
>  
>
Well, I guess the next step is to examine the code in nandwrite carefully.  What it does is query the device (in your case /dev/mtd1) to find out the size of the data (should be 512) and oob (should be 16) portions of a page.  It also queries the size of the file to be written, and verifies that the filesize is an integer multiple of the pagesize.  We can get at much of the same info using mtd_debug:

./mtd_debug info /dev/mtd1

Could you send me the output from that?  On my DOC device it says (among other things):

mtd.erasesize = 16384 (16K)
mtd.oobblock = 512
mtd.oobsize = 16

If you get the same result, then we're in really weird territory, and I'd start to wonder if the mtd tools just don't build (or run) properly under uClibc.  Is there any chance you can use a standard glibc environment to doublecheck?

	-Dan

Re: docboot: nandwrite: Input file is not page aligned

[Joseph M Dupre (AVAB Inc.)]

On 11 Oct 2005 at 14:02, Dan Brown wrote:

> ./mtd_debug info /dev/mtd1
> 
> Could you send me the output from that?  On my DOC device it says
> (among other things):
> 
> mtd.erasesize = 16384 (16K)
> mtd.oobblock = 512
> mtd.oobsize = 16
> 
> If you get the same result, then we're in really weird territory, and
> I'd start to wonder if the mtd tools just don't build (or run)
> properly under uClibc.  Is there any chance you can use a standard
> glibc environment to doublecheck?

I get this output for 'mtd_debug info /dev/mdt1':

mtd.type = MTD_NANDFLASH
mtd.flags = MTD_CLEAR_BITS | MTD_ERASEABLE | MTD_OOB | MTD_ECC
mtd.size = 10567680 (10M)
mtd.erasesize = 16384 (16K)
mtd.oobblock = 512 
mtd.oobsize = 16 
mtd.ecctype = MTD_ECC_SW
regions = 0

Yes I think can set up a clean glibc system on this hardware to test. 
I had a Linux From Scratch system up and running at one time.  If I 
can only find it now...

- Joe

Re: docboot: nandwrite: Input file is not page aligned

[Joseph M Dupre (AVAB Inc.)]

On 11 Oct 2005 at 14:02, Dan Brown wrote:

> >I am using the uClibc "Buildroot" toolchain.  Dev machine is i686 and
> > target is i486 with a DOC 2000 (MD2202-D128)

> Well, I guess the next step is to examine the code in nandwrite
> carefully.
> I'd start to wonder if the mtd tools just don't build (or run)
> properly under uClibc.  Is there any chance you can use a standard
> glibc environment to doublecheck?

Dan,

I was just now successful in writing doc_spl to the device using 
nandwrite generated with glibc-2.2.5 on a RedHat 7.3 partition.

So, evidently there is a problem with the uClibc libraries and 
nandwrite, although there are no errors or warnings generated when 
compiling with uClibc.

I am just learning C, so I won't be very useful in examining the 
nandwrite code "carefully".  Perhaps you could suggest some 'talking 
points' I could bring up with the uClibc people.

- Joe

Re: docboot: nandwrite: Input file is not page aligned

[Joseph M Dupre (AVAB Inc.)]

On 11 Oct 2005 at 14:02, Dan Brown wrote:

> If you get the same result, then we're in really weird territory, and
> I'd start to wonder if the mtd tools just don't build (or run)
> properly under uClibc.  Is there any chance you can use a standard
> glibc environment to doublecheck?

OK, issue solved.  There is no problem with nandwrite using uClibc 
librarires.  Docboot works "as advertised" using the uClibc buildroot 
tools. 

My problem was that the doc_spl file was getting corrupted when I 
transferred the image from the build machine to the target.  The 
ftpget command in the uClibc buildroot environment is truncating the 
file durring transfer.  Thus the error messages about "not page 
aligned" were correct.  Sorry.

- Joe 

Re: docboot: nandwrite: Input file is not page aligned

[Dan Brown]

Joseph M Dupre (AVAB Inc.) wrote:

>OK, issue solved.  There is no problem with nandwrite using uClibc 
>librarires.  Docboot works "as advertised" using the uClibc buildroot 
>tools. 
>  
>
Glad to hear it's working for you!  Pity you had so much trouble 
figuring out the problem, but suffering builds character :)

    -Dan

>My problem was that the doc_spl file was getting corrupted when I 
>transferred the image from the build machine to the target.  The 
>ftpget command in the uClibc buildroot environment is truncating the 
>file durring transfer.  Thus the error messages about "not page 
>aligned" were correct.  Sorry.
>
>- Joe 
>  
>