Ticket #676 (reopened defect)

Opened 3 years ago

Last modified 18 months ago

dfu-util upload causes data corruption

Reported by: laforge@… Owned by: willie_chen@…
Priority: normal Milestone:
Component: host utilities Version:
Severity: normal Keywords: dfu
Cc: werner HasPatchForReview:
Blocked By: #1843 Estimated Completion (week):
PatchReviewResult: Blocking:
Reproducible:

Description (last modified by roh) (diff)

It seems like dfu-util upload results in a corrupted image.

the problem seems to be independant of hardware.

--

remark: dfu-util upload means from device -> pc

dfu uses upload/download in a 'device centric' view, NOT in a 'host centric' one

Change History

Changed 2 years ago by willie_chen@…

  • owner changed from laforge@… to michael@…

Changed 2 years ago by willie_chen@…

  • owner changed from michael@… to willie_chen@…

Changed 2 years ago by werner@…

  • cc werner@… added

I wonder if DFU upload ever moved beyond being good enough for the
devirginator to pick up the environment, but not much else ? I.e.,
is it even supposed to work flawlessly now ?

Changed 2 years ago by laforge@…

yes, it is supposed to work just fine, and in fact I have used it quite a bit
with GTA01.

Changed 2 years ago by mickey@…

  • status changed from new to closed
  • resolution set to fixed

Newer GTA02 prototypes have no problems with usb upload. Closing this as FIXED.

Changed 20 months ago by mmontour

  • priority changed from high to normal
  • status changed from closed to reopened
  • resolution fixed deleted

Re-opening because I have seen an IRC report that suggests dfu-util -U data corruption is still present with production GTA02, and because I can reproduce it on my production GTA01Bv4.

Prior to this test I executed "nand erase kernel" from the u-boot console. I then downloaded a kernel image, uploaded it to a different filename, and compared the results. As shown by the following log, no errors were reported but the uploaded file differs from the downloaded one at byte offset 12289.

Host PC is Intel x86_64, OpenSuSE 10.3. u-boot is u-boot-gta01bv4-1.3.1+gitr52+dc633f4be2527f844158aa5085c278b0c3039d3f-r0.bin and dfu-util was downloaded today from http://buildhost.openmoko.org/daily/workdir/deploy/glibc/tools/dfu-util-0.1+svnr4160

root@tuxbox:/scratch/moko> ./dfu-util-0.1+svnr4160 -R -d 0x1457:0x5119 -a kernel -D ./uImage-2.6.24+gitr0+7a1370a816b9348dd8f36a667905dd3533cefc9b-r4-om-gta01.bin
dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x1457:0x5119...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1457:0x5119] devnum=9, cfg=0, intf=0, alt=3, name="kernel"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
bytes_per_hash=36019
Starting download: ################################################## finished!
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode

root@tuxbox:/scratch/moko> ./dfu-util-0.1+svnr4160 -R -d 0x1457:0x5119 -a kernel -U ./kernel.dat
dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x1457:0x5119...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1457:0x5119] devnum=11, cfg=0, intf=0, alt=3, name="kernel"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
Resetting USB to switch back to runtime mode

root@tuxbox:/scratch/moko> ls -l uImage-2.6.24+gitr0+7a1370a816b9348dd8f36a667905dd3533cefc9b-r4-om-gta01.bin kernel.dat
-rw-r--r-- 1 root root 2097152 2008-08-09 20:52 kernel.dat
-rw-r--r-- 1 mmontour users 1800952 2008-08-09 20:48 uImage-2.6.24+gitr0+7a1370a816b9348dd8f36a667905dd3533cefc9b-r4-om-gta01.bin

root@tuxbox:/scratch/moko> cmp uImage-2.6.24+gitr0+7a1370a816b9348dd8f36a667905dd3533cefc9b-r4-om-gta01.bin kernel.dat
uImage-2.6.24+gitr0+7a1370a816b9348dd8f36a667905dd3533cefc9b-r4-om-gta01.bin kernel.dat differ: byte 12289, line 63

Changed 19 months ago by wesselch

I have a further issue by dfu_util.
I had install the filesystem Openmoko-Freerunner-20080424-om-gta02.rootfs.jffs2 and related kernel successfully and after several installation (e.g. python, mofi, etc.) I want to backup the fs.

Therefore I followed the instruction from wiki and get foolowing result at 246,1MB upload:
[root@SVDL002 openmoko]# ./backup_om.sh
dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=78, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
dfu_upload error -108

What's wrong here? dfu_util or my system?
My system:
IBM 342 (two single CPU)
1,5GB RAM
Fedora Core 6

Nedd some help, before try the Debian for FR, christian

Changed 19 months ago by roh

  • description modified (diff)
  • cc werner added; buglog@…, werner@… removed
  • component changed from u-boot to host utilities
  • summary changed from dfu-upload on GTA02v1 causes data corruption to dfu-util upload causes data corruption
  • version current svn head deleted
  • keywords dfu added

Changed 19 months ago by roh

see also #1843

Changed 19 months ago by kho

When I try to upload the root fs from my Neo Freerunner to the PC with dfu-util as mentioned in the http://wiki.openmoko.org/wiki/Pre-Flash_Backup page, I get an error near the end of the upload operation - the good-rootfs.jffs2 file has size 258076672 at that time.

$ dfu-util -a rootfs -R -U good-rootfs.jffs2
dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=6, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
dfu_upload error -84

---
dfu-util version: 0.1+svn4556
U-Boot from NOR boot menu: 1.3.2-moko12 (May 9 2008 - 10:28:48)

Regards,
Klaus

Changed 19 months ago by ulukay

exact same error and filesize for me

freerunner.qtopia.running $: time dfu-util -R -a rootfs -U rootfs.jffs2dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Found Runtime: [0x1d50:0x5119] devnum=3, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuERROR, status = 14
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
dfu_upload error -84

real 41m45.465s
user 0m0.136s
sys 0m5.084s

-rw-r--r-- 1 root root 258076672 2008-08-21 13:56 rootfs.jffs2

latest svn version of dfu-util
gta02
ubuntu 8.04 x64
intel G965 chipset mobo with 82801H usb controller

Changed 19 months ago by madhatter

slightly different error, same filesize for me, too:

[root@risby openmoko]# ./dfu-util -a rootfs -R -U ./tom-rootfs-20080910.jffs2
dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = appIDLE, status = 0
Device really in Runtime Mode, send DFU detach request...
Resetting USB...
Opening USB Device...
Found Runtime: [0x1d50:0x5119] devnum=62, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
dfu_upload error -108
[root@risby openmoko]#

-rw-r--r-- 1 root root 258076672 2008-09-10 09:23 tom-rootfs-20080910.jffs2

on phone: U-Boot 1.3.2-moko12

Changed 18 months ago by xbaldauf

Same error "-84" for me, same filesize:

dfu-util - (C) 2007 by OpenMoko? Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x1d50:0x5119...
Found Runtime: [0x1d50:0x5119] devnum=8, cfg=0, intf=0, alt=6, name="rootfs"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuERROR, status = 14
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x1000
dfu_upload error -84

-rwxr--r-- 1 root root 258076672 2008-09-20 16:54 rootfs

Changed 18 months ago by laforge

  • blockedby set to 1843

(In #1843) thanks for the detailed analyisis, it really describes well why many people have been experiencing various upload related problems (and it was never working, at least not on GTA02 where the erazeblock size is much bigger than on GTA01).

I'm right now working on altering the code. It's not as straight-forward as you may think. We are under tight constraints by the DFU spec, i.e. whatever amount of bytes the host asks us for, we need to deliver it. If we'd return less than what was asked for, this would implicitly mean
the end of a transmission. I also do not want to introduce a second buffer (for the URB), since
that would mean we always need to memcpy() and it would further increase the memory requirements
of u-boot.

The current code structure is a result from trying to implement UPLOAD based on the infrastructure that DOWNLOAD provided. For download it makes sense to think in terms of nand
erase blocks. For upload it actually makes much more sense to think in terms of whatever amount
of bytes the host requests.

I'll try to rework the logic accordingly.

Note: See TracTickets for help on using tickets.