use libusb-1? #3
Comments
|
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/ |
|
@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. 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 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: Look for |
|
Pali, I did a quick test, get below: Run 0xFFFF -I, then immediately plug the usb cable to N900, got below: ./0xFFFF -I0xFFFF v0.7 // Open Free Fiasco Firmware Flasher Not a local device Waiting for USB device... Waiting for ASIC ID... Waiting for USB device... Waiting for USB device... Initializing NOLO... |
|
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 libusb/libusb#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: 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: |
|
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. |
Is it still an issue? Some distros have stopped shipping libusb-0.1 so it becomes a pita.
The text was updated successfully, but these errors were encountered: