Bug 5882

(In reply to comment #0)
> Busybox 1.20.2 built using buildroot on a mini2440 FriendlyArm board.
> 
> When using flashcp to flash a kernel image to an MTD device, the kernel sends
> the following via kmesg:
> nand_do_write_ops: Attempt to write not page aligned data

Can you show strace output of such flashcp run?

> Padding the image file to 128KB (this flash's erase size) works.  Seems like
> flashcp should do this or have an option to do so.

Looking at code, I'd guess padding to 8kb should be enough. But I need to see strace output to be sure.

(In reply to comment #1)

you don't want to assume any specific padding size.  i also don't think that's the problem here (you shouldn't have to pad to erase block size).

the kernel message says the write is not aligned.  which means busybox's flashcp should probably only write in whole pages.

of course, the strace as Denys requested should show the issue.

(In reply to comment #2)
> (In reply to comment #1)
>
> you don't want to assume any specific padding size.  i also don't think
that's
> the problem here (you shouldn't have to pad to erase block size).

The code wasn't doing any partial erases.
Only writes.

> the kernel message says the write is not aligned.

Exactly! *write*, not *erase* is reported to be partial.

Looking at the source code, I see that writes are not padded to the flash pad size, but erases are (as mentioned).  As a test I did a simple redirect of the same kernel image to the mtd device file 'cat image > /dev/mtdblock4' after doing a flash_eraseall of the device.  The same kernel generated error resulted.  If I pad the image, the error message does not occur.  I had a look at the mtd flashcp source code and saw that it also does not do padding with writes.  So it seems like the Busybox flashcp is compatible with the mtd-utils version, so perhaps this is more of a feature request than a bug.

It just surprised me that writes weren't being padded with flashcp, since it seemed contrary to the high level user friendly behavior that it appears to have, which is the reason why I created the bug.  My solution for now is to just pad the image.  If functionality was added for this, perhaps an additional command line switch would be the way to go, so as not to stray from being compatible with the mtd-utils functionality.

(In reply to comment #3)

i meant you shouldn't have to pad your writes to erase block sizes.  write(program) & erase block sizes are independent quantities.

the mtd-utils flashcp isn't intelligent here.  it just reads & writes in a large enough chunk to not matter to any existing flash rather than dynamically querying the flash layout at runtime.

(In reply to comment #4)
> I had a look
> at the mtd flashcp source code and saw that it also does not do padding with
> writes.

Did you try it? Meaning: did you confirm that standard flashcp issues a short write at the end?

(In reply to comment #5)
> (In reply to comment #3)
> the mtd-utils flashcp isn't intelligent here.  it just reads & writes in a
> large enough chunk to not matter to any existing flash

Well, what will it do with the last, partial block?

for (;;) {
     cnt = read(file, buf, LARGE_ENOUGH_CHUNK);
     if (cnt < 0) error;
     write(flash, buf, cnt); // cnt can be less than LARGE_ENOUGH_CHUNK!
     if (cnt < LARGE_ENOUGH_CHUNK) eof;
}

See? When done in simplistic manner, the last write won't be a "large enough chunk".