Openmoko Bug #1843: u-boot's DFU upload garbles data at block boundary
Openmoko Public Trac
bugs at docs.openmoko.org
Wed Aug 20 05:41:09 CEST 2008
#1843: u-boot's DFU upload garbles data at block boundary
---------------------+------------------------------------------------------
Reporter: wiml | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: GTA02v6
Severity: major | Keywords:
Blockedby: | Reproducible:
Blocking: |
---------------------+------------------------------------------------------
I was trying to verify my downloaded kernel by re-uploading it again to
compare. The uploaded version differed in an interesting way: at offset
0x01f000, exactly 0x20000 bytes were missing (so that the uploaded file
contained at 0x01f000 the data that was at 0x03f000 in the original file).
This does not seem to be a dfu-util bug, but a u-boot bug.
Looking at the u-boot source code, I think the problem is in
handle_upload() in usbdfu.c, where it handles the wraparound at the end of
the NAND block. There are three bugs here:
- when it copies a new blockful of data, it copies it into the same
buffer that urb->buffer was already pointing to, thus overwriting the
beginning of the last buffer before it is sent back to the requestor
- it then calls memcpy() to copy the beginning of the newly-read block to
after the end of the buffer that urb->buffer is pointing to. If
ds->nand->erasesize is the same as the _buf[] array, then this will write
past the end of the _buf[] array and smash some other item in RAM.
- if a requested buffer exactly reaches the end of the block that's been
buffered in ds->buf, then handle_upload() will read a new NAND block into
the buffer even though it is not needed. (The test for (len > remain)
should probably go before the test for ds->ptr, not after?)
I would submit a patch, but I don't have a build environment set up for
uboot (or any jtag hardware for recovery from bad flashing, for that
matter) --- this is just from reading the uboot-dfu.patch file in svn.
I also wonder if this is related to ticket #676, although the comments in
that bug indicate corruption starting at 0x3001, not 0x1f000, so it may be
unrelated.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1843>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
More information about the buglog
mailing list