DFU upload causes memory corruption (patch)
Werner Almesberger
werner at openmoko.org
Tue Mar 13 04:21:33 CET 2007
Hi Harald,
I think I found the origin of the DFU upload problem. For the readers
on the list: Harald reported that the devirginator left an incorrect
environment in stage 2 if using a recent version of u-boot.
This turned out to be caused by the environment the devirginator
obtains from the Neo being broken. And this was in turn caused by
dfu-util transferring zero bytes. I found that DFU uploads (i.e., Neo
to PC) failed to work with SVN revision 1284, where I did indeed make
some trivial changes to DFU. Luckily, I also noticed that u-boot
behaved a little strange even before that. E.g., it wouldn't
recognize the "reset" command after a (successful) DFU upload.
The attached patch seems to fix this. Harald, can you please check if
this agrees with the general logic of the USB stack ?
BTW, JTAG watchpoints are nice :-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/
-------------- next part --------------
Index: u-boot/drivers/usbdfu.c
===================================================================
--- u-boot.orig/drivers/usbdfu.c
+++ u-boot/drivers/usbdfu.c
@@ -484,7 +484,8 @@ static int handle_upload(struct urb *urb
remain = len;
debug("copying %u bytes ", remain);
- memcpy(urb->buffer, ds->ptr, remain);
+// memcpy(urb->buffer, ds->ptr, remain);
+ urb->buffer = ds->ptr;
ds->ptr += remain;
urb->actual_length = remain;
More information about the openmoko-uboot
mailing list