0xFFFF
0xFFFF copied to clipboard
use libusb-1?
Error: You are trying to use broken libusb-1.0 library (either directly or via wrapper) which has slow listing of usb devices. It cannot be used for flashing or cold-flashing. Please use libusb 0.1.
Is it still an issue? Some distros have stopped shipping libusb-0.1 so it becomes a pita.
Yes, it is still an issue.
Blame to distributions which stopping shipping the only suitable libusb library for flashing or blame to libusb-1.0 developers who fully ignore this issue...
https://sourceforge.net/p/libusb/mailman/message/34985373/ https://github.com/libusb/libusb/issues/237
@pali didn't you consider to temporarily bundle libusb0 (while libusb1 upstream slacking on the issue)?
Ehm... why bundle in upstream project?? It is up to downstream distribution to distribute package software with all dependences so it would work. It is not responsibility of upstream projects, even more downstream distributions hate bundling because it is breaking linking of system shared libraries like DLL hell.
Yes, mostly downstream distributions do dislike bundling. But in a case where more and more distributions throwing off libusb0, having own bundled (or, well, it can be called even "forked") is less maintenance evil than backporting old, dead (no updates) and unsupported (by original upstream) library.
So, forking libusb0 and shipping it with the 0xFFFF (until libusb upstream resolve the issue) looks not so evil in this context.
And, talking on distributions: unfortunatelly, their policies, in most, is "drop the software that requires old libraries that we already dropped", rather than "return dropped library because of very that software". So, users will need to create non-official package repos for their distros and maintain the 0xFFFF+libusb0 on their own 😿
So now every software needs to start bundling working version of libusb, just because distributions are unable to do it? Ridiculous! So blame to distributions if they are dropping old libraries without providing some working replacement.
I tried this on Fedora with a wrapper libusb-0.1 which actually should be libusb1.0, and commented out the checking of libusb, it worked for me for flashing n900 firmware.
If there is some way to reproduce the issue on N900 I can have some debugging. Or it is not a problem now any more?
Maybe you have in fedora faster enumeration... @daveyoung Are you able to enter into OMAP boot rom? To verify: Put usb cable into phone which is turned off and you should have output like this:
# 0xFFFF -I
0xFFFF v0.6 // Open Free Fiasco Firmware Flasher
Not a local device
Waiting for USB device...
Found USB device: RX-51 (0x421:0x106) in Cold flashing mode
USB device product string: Nokia USB ROM
USB device serial number string: (not detected)
Detected USB device: (not detected)
Waiting for ASIC ID...
Detected OMAP3430 chip
Device: (not detected)
HW revision: (not detected)
NOLO version: (not detected)
Kernel version: (not detected)
Initfs version: (not detected)
Software release version: (not detected)
Content eMMC version: (not detected)
Root device: (not detected)
USB host mode: (not detected)
R&D mode: (not detected)
Sending OMAP memory boot message...
Waiting for USB device...
Found USB device: SU-18/RX-44/RX-48/RX-51 (0x421:0x105) in NOLO mode
USB device product string: Nokia N900 (Update mode)
USB device serial number string: ...
Detected USB device: RX-51
Initializing NOLO...
Device: RX-51
Look for Detected OMAP3430 chip and device in cold flash mode (in which is for 0.3s after startup).
Pali, I did a quick test, get below:
Run 0xFFFF -I, then immediately plug the usb cable to N900, got below:
./0xFFFF -I
0xFFFF v0.7 // Open Free Fiasco Firmware Flasher
Not a local device
Waiting for USB device...
Found USB device: RX-51/RM-680/RM-696 (0x421:0x106) in Cold flashing mode
USB device product string: Nokia USB ROM
USB device serial number string: (not detected)
Detected USB device: (not detected)
Waiting for ASIC ID... Detected OMAP3430 chip (revision 87) Device: (not detected) HW revision: (not detected) NOLO version: (not detected) Kernel version: (not detected) Initfs version: (not detected) Software release version: (not detected) Content eMMC version: (not detected) Root device: (not detected) USB host mode: (not detected) R&D mode: (not detected) Sending OMAP memory boot message...
Waiting for USB device...
Found USB device: RX-51/RM-680/RM-696 (0x421:0x106) in Cold flashing mode
Opening USB...
Error: usb_open failed: No such device or address
Waiting for USB device...
Found USB device: SU-18/RX-44/RX-48/RX-51/RM-680/RM-696 (0x421:0x105) in NOLO mode
USB device product string: Nokia N900 (Update mode)
USB device serial number string: MUM335307
Detected USB device: RX-51
Initializing NOLO... Device: RX-51 HW revision: 2101 NOLO version: 1.4.14 Kernel version: 2.6.28-20103103+0m5 Initfs version: (not detected) Software release version: RX-51_2009SE_20.2010.36-2_PR_MR0 Content eMMC version: RX-51_2009SE_1.2009.41-1.MENA+EU Root device: flash USB host mode: disabled R&D mode: enabled R&D flags: no-omap-wd,no-ext-wd,no-lifeguard-reset
Great! That seems to work. So are you really using libusb1.0 via libusb-compat? And finally somebody fixed that bug in libusb1.0 without notice of anybody? Or just that problem is platform/system/hardware specific, and you are just luck? I just cannot tell you. Probably you could follow that libusb https://github.com/libusb/libusb/issues/237 bug where I put code examples which can be used for reproducing or verification...
Yes, I'm sure it is via libusb-compat, but Fedora libusb takes two patches below: 0001-Link-with-znodelete-to-disallow-unloading.patch 0002-Revert-use-atexit-to-call-libusb_exit.patch
I'm not sure if they are relevant or not. Will check your link later.. Thanks a lot!
libusb-1.0.21 didn't work for me when i've commented out the check
Either upgrading my hardware helped, or libusb-1.0.22 works:
0xFFFF v0.8 // Open Free Fiasco Firmware Flasher
Not a local device
Waiting for USB device...
Found USB device: RX-51/RM-680/RM-696 (0x421:0x106) in Cold flashing mode
USB device product string: Nokia USB ROM
USB device serial number string: (not detected)
Detected USB device: (not detected)
Waiting for ASIC ID...
Detected OMAP3430 chip (revision 87)
Device: (not detected)
HW revision: (not detected)
NOLO version: (not detected)
Kernel version: (not detected)
Initfs version: (not detected)
Software release version: (not detected)
Content eMMC version: (not detected)
Root device: (not detected)
USB host mode: (not detected)
R&D mode: (not detected)
Sending OMAP memory boot message...
Waiting for USB device...
Found USB device: SU-18/RX-34/RX-44/RX-48/RX-51/RM-680/RM-696 (0x421:0x105) in NOLO mode
USB device product string: Nokia N900 (Update mode)
USB device serial number string: MUM442480
Detected USB device: RX-51
Initializing NOLO...
Device: RX-51
HW revision: 2101
NOLO version: 1.4.14
Kernel version: 2.6.28-20103103+0m5
Initfs version: (not detected)
Software release version: RX-51_2009SE_21.2011.38-1_PR_MR0
Content eMMC version: RX-51_2009SE_10.2010.13-2.VANILLA
Root device: flash
USB host mode: disabled
R&D mode: enabled
R&D flags:
Works as well with 1.0.21. I suppose switching to 8th gen i7 helps somehow.
So seems libusb-1 needs new hardware and old libusb-0.1 works with both old and new hardware? I'm really not going to drop support of old hardware just because new version of some library is incompatible with old hardware, plus in case when we already have a library which is working fine on both old and new hardware.
That's my hypothesis. I don't have the old hardware around to test it.