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