A better fix for host endianness of dfu-util

[wiml]

The byte-swapping code in dfu-util depends on some nonportable system headers. Rather than extend autoconf to check more and more systems' headers, I just wrote a portable byteswap routine. (Since the routine is only called once per run of dfu-util, it hardly needs an optimized assembly implementation.) A patch is attached. I can upload and download updates fine from my (big-endian ppc) host.

[wiml]

A patch to make dfu-util more portable

[wiml]

See also: #684 (original endianness bug report), the change in r2770 (when the code my patch changes was added), and r3830 / r3831 (when said code was made more portable but still unnecessarily system-dependent).

[RuiSeabra]

Although my backup did go on for about 50MB longer than previously, the proposed patch isn't a full fix, unfortunately.

It failed with the same error:

dfu-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=6, 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 -62

[wiml]

Replying to RuiSeabra:

dfu_upload error -62

I don't 100% understand the DFU mechanism, but looking at dfu-util it doesn't look to me like your error -62 is an endianness problem. (I don't know what it is, though. Applying the patch I attached to #1842 might produce more informative output. It should probably go in another trac ticket though.)

[RuiSeabra]

Of two laptops with the same Ubuntu version (8.04, Heron), only fails on the AMD64.

I read somewhere in the wiki that it would fail with that 62 error... but maybe the other report was wrong... I'll check 1842 later on.

[roh]

Replying to RuiSeabra:

Although my backup did go on for about 50MB longer than previously, the proposed patch isn't a full fix, unfortunately.

please do not confuse this issue (endian problems) with dfu-util upload (device->computer) 'backup' problems.
that is bug #676 / #1843

means your problems in comment:2 and comment:4 have probably nothing do to with this ticket.

[RuiSeabra]

I just retested, and it works for me on the following CPU:

rms@roque:/media/disk/moko/2008.8.26$  cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 72
model name	: AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping	: 2
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 1600.03
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 72
model name	: AMD Turion(tm) 64 X2 Mobile Technology TL-60
stepping	: 2
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy
bogomips	: 1600.03
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

(which previously didn't, so it worksforme now).

[laforge]

Thanks, I've applied the patch to subversion (Rev. 4696)