Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > Hello, Aleš. I've seen that your assignment was completed. I added you > > to grub contributors. Feel free to create a branch in branches/usb. > > Right now I'm busy but next week I should be able to assist. Perhaps > > even this week. Right now I send uncommitted changes sitting in my > > yeeloongfw branch. It's largely your rebased changes + few other things > > like shutting the controller down before booting OS to avoid memory used > > by OS to be clobbered by e.g. HCCA.
Yes, thanks, I was also sometimes thinking what happens when ohci module is unloaded or OS booting started, but I never had time to check it, I have little bit another priorities... > > Branch usb should contain pci improvements + your usb changes. If you > > have trouble with bzr or are short on time me (or perhaps someone else) > > can give a hand. > > This branch can go into mainline. Since mainline usb is in deplorable > > state there is no need to pass this changes through experimental at all. > > Merging into mainline doesn't mean that no further developpement should > > be done on usb, just that this part is already a huge improvement. > > > > > I've created a branch "usb" where I put all the yeeloong work and > previous version of your patch. Could you merge your latest patch into > it and test the whole on your systems? Ufff, I will try to do it but I am also busy probably whole this week and maybe I will need a help with bzr, I will see... So don't expect it soon. > >> 2. > >> Some devices (at least my APACER cardreader "ID 058f:6366 Alcor Micro > >> Corp. Multi Flash Reader") are not working on UHCI. Such device does not > >> accept any control message and UHCI returns status 0x450007 - it means > >> STALL during sending SETUP packet. > >> It looks to be the same problem as described by Vladimir: "I have > >> somewhat similar issue with Geode OHCI controller right now: devices and > >> speeds are correctly seen but trying to send a message results in a halt > >> in first TD and error code 5.". > >> > >> > > The problem was that the port was plainly off due to Geode reaction on > > incorrect writes differring from that of other controllers. > > > >> But I have problem on UHCI, not on OHCI - on computer with OHCI is this > >> device working well (it is normal USB Mass Storage Bulk-Only device with > >> SCSI subclass)! Maybe it depends on "combined controllers" UHCI-EHCI, > >> OHCI-EHCI (?) - device is working on computer with OHCI only computer > >> and it is not working on computer with UHCI-EHCI controller. But any > >> other device is working well on both computers... I don't understand, I > >> currently have no idea what can be wrong. Does anybody know...? > >> > >> > >> > > Does this device work under OS on this computer? Some ports are plainly > > underpowered. This device works fine under Linux and Windows in the same UHCI port. But the underpower can be good idea - OSes are using EHCI, not UHCI and there could be some difference in power handling. On UHCI I cannot find any power handling... And You remember to me that we are not handling overcurrent on OHCI - but I have no idea what to do in this case. > > > >> 3. > >> There is not working USB hub support, GRUB does not see device connected > >> via USB hub - does anybody know some details or have some specification > >> of USB Hub class ? I cannot find it on USB site (maybe I have not > >> sufficient patience...). > >> > >> > >> I will probably focus in OHCI speed-up now, i.e. I try to do some other > >> handling of ED to prevent changes in OHCI registers which are slowing > >> down OHCI performance (OHCI is approx. 3 times slower than UHCI now from > >> this reason). > >> > >> > > How useful would the interrupts be for this matter? If the answer is > > "very useful" I can implement them. Also we need some restructuring of > > code of both ohci and grub in general to decrease the wait time. I think > > specifically all the waits in init sequence. If system has 2 OHCI > > controllers currently you need to wait twice as long as with 1 > > controllers while it's possible to init them in parallel and not wait > > longer than in the case of one controller. I think interrupt is not important in this case, don't hurry. Why: A. Wait in initialization phase is not so critical from my point of view - it happens only once when ohci module is loaded - for example compare it with the time consumed by some BIOS starts... But nothing against such improving, it can be done when interrupts will be available. B. The main problem is changing of Control or Bulk Head registers on begin and end of each transfer because for each transfer we have another allocated memory for ED and after transfer we de-allocate it. It was one of thing which little bit surprised me when I first read OHCI specification and then I saw GRUB source code - it is different than ED/TD handling suggested in OHCI specification. Registry change and ED de-allocation have to be done on really disabled and inactive ED - and such situation is only after SOF (when related list is disabled before, of course). Such waiting can be avoided if EDs memory will not change - we can allocate necessary EDs only once when device is detected and enumerated / configured and do all necessary work only with TDs - in this case, if we will not change ED addresses, it is not necessary to do changes in OHCI registers on each transfer (with exception of "list filled" bit setting but it can be done asynchronously without waiting for SOF in this case) and all should be more faster, I hope as on UHCI. Also TDs have to be handled in little bit different way in this case because each ED must point to one valid memory address of TD structure even if there is no transfer and queue is empty - and this empty TD have to be used as "starting" (first) TD of next transfer - in fact we should do it in the similar way as it is described in OHCI specification in HCD sample. Seth Goldberg wrote: > USB devices are notoriously difficult to get right. During development of > USB device support (mainly mass-storage devices), we discovered numerous > devices, usually super-cheap devices, that were not spec compliant or that > didn't implement this-or-that command, etc. It's truly amazing that they > work > at all (they clearly only test on Windows, and that's all they care about). > So prepare yourself for a LOT of working trying to figure this stuff out (or > at least try to use Linux's implementation as a technical guide to avoid > rediscovering all of this horribleness. Yes, I agree, it is never ending story... I am sometimes looking into Linux (for example, issuing the Request Sense after each SCSI command is idea taken from Linux source). Maybe I need to look there more often... But Linux has little bit different "working environment" for USB device driver than GRUB2. Sometimes I am also looking into some USB development forums / development mail lists - but there is lot of unsorted information and it is not easy to find the right case and related solution there... - it is often wasting of time. But, from my point of view, current status is not so bad - I have 10 fairly different USB mass storage devices and all devices are working well on OHCI and 9 of them are working well on UHCI. GRUB2, when it is installed on HD or booting CD, is now able to boot Linux from USB flash on my older computer without BIOS USB booting support. That is what I needed some months ago, i.e. I am satisfied... After all, GRUB2 is bootloader only, so probably nobody can expect full USB functionality as in Linux/Windows... :-) Best regards Ales _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
