Aleš Nesrsta wrote: > Hi Vladimir and others, > > first of all thanks for immediate advice about Bazaar. > > Attached is the usb patch related to OHCI and USB MS (SCSI). > (There is also very small patch for uhci.c - it signals in debug print > failed transaction even if it finished correctly.) > Patch is done against Bazaar source revision 2391 but. > I checked if files changed by me were changed by somebody other between > version 1.98 and current Bazaar revision - it looks like none of files > was changed in the meantime. So, in fact the patch should work also > against 1.98 release. > > I've adjusted it for yeeloongfw branch. Attached. It also fixes 2 further problems: after port reset you have to power it up by writing (1 << 1) and in usbms code tries to read config[0] even if configcnt = 0. With this patch I was able to use PCI OHCI controller but not Geode. I discovered that one of yeeloong external ports (upper right one) it routed to PCI OHCI and I was able to load kernel from stick inserted into this port. > In patch remains some added or extended debug prints - You can delete > them. > It's better to leave them until some parts stabilise. > I have them still in my source because I will probably sooner or later > continue in "researching" mainly in these directions: > - Why STALL (or maybe NAK?) is not properly indicated on OHCI (at least > on my computer) and instead of it timeout occurs (or hang in old source, > before timeout was added). > I think that interrupt you use just notifies that some progress is done. And old way of detecting was mostly correct. But I may be wrong. Another possibility is that some devices don't work correctly on the speed they report. > - OHCI can switch itself into Unrecoverable Error in some cases - it > should be detected and recovered by some reset > - Some devices are not working on UHCI > Speed or power problems perhaps. You may need to configure the amount of current available to device. Does they work with booted OS? > - UHCI is not working properly when module is removed and inserted again > - Maybe in future I change EDs into more "static" allocation - because > there is too big performance penalty with safe EDs and TDs allocation > and setup in OHCI registers and then reseting in OHCI registers and > deallocation of them - we should wait twice for SOF, i.e we lost approx. > 2ms per each USB access. In suggested example of OHCI driver in OHCI > specification are EDs allocated permanently (whole time of driver > activity, not only on communication time) - it should improve speed of > OHCI because we will not need to change ED addresses in registers on > OHCI and we will not have to wait for SOF more. > > It's a good idea. > Maybe it is not fully true the comment "Each SCSI command should be > followed by Request Sense. If not so, many devices STALLs or definitely > freezes.". I discovered it in time when also some others bugs were not > solved and maybe it is not necessary in many cases, who knows...? But I > dont have sufficient patience to do such deep testing (every command on > every device...). > > Right now I would prefer something working rather than fast but half-working. > I found at home one device which has another USB MS subclass - > SFF-8070i. I tried to look into specifications of other subclasses than > SCSI and I discover that all of them are SCSI based and with exception > of QIC-157 (which is tape oriented) all should have implemented basic > SCSI command which are used in GRUB. There is only one thing which can > cause incompatibility - ATAPI SCSI commands must have size of command > block length set to 12 bytes (instead of variable length 6,8,10,... > defined in "normal" SCSI). You can add a field for this in scsi structures. > It could make troubles on SCSI subclass > devices but I tried all my devices with SCSI subclass with > ATAPI-compatible length of command and all devices are working normally > - so I think it should be safe to use ATAPI format of commands > universally for any subclass and I tried to "add support" for most of > USB MS subclasses - in fact I only extended one condition in usbms.c... > I did not testing devices subclasses RBC, UFI and MMC-2 - I don't have > such devices - can do somebody such tests ? > Is MMC-2 subclass of cardreaders? > Tests and "researching" were made on 10 devices, all of them are working > now (3 USB flash disks, 3 cameras - problem with control packet max. > length and also another subclass support, 1 USB external disk, 1 > universal card reader "21 in one" - problem with more LUNs, 1 SDHC card > reader, 1 mobile phone - problem with "the same" enpoint numbers 01 & 81 > and toggling of bulk transfer). > > There is also potential problem with powering and current GRUB USB > "philosophy" - unfortunately, USB bus is enumerated in time when OHCI > module is loaded and activated. > It can make trouble on PC where it is necessary to do "SMM ownership > change" - which results (on my computer) in power-off and power-on of > USB bus - or on computers which have not powered USB bus before OHCI > module is loaded. Many devices has very long time between powering of > then and proper function on USB bus - it could be also problem of > Yeeloong. > But currently I have no idea how to solve it in GRUB. In "normal" OS the > registering of new USB device (enumerating) is done probably via > interrupt from hub port status change when newly attached USB device > becomes really ready. I plan on adding IRQs. But first things first. > But in GRUB we cannot do such solution. What we > can do now is: > - set longer waiting period after powering of USB bus > I would go for this right now and change to interrupts afterwards. > I will look into yeeloongfw branch, I got Bazaar working yesterday > evening only... I agree with You, first should be solved known problems > on simple base. > Unfortunately, I probably cannot help You as I don't have GEODE or > Yeeloong... I can hope only that my corrections would help You or > inspire You in some other ways. > I don't think it's something deeply specific to Geode. Other than having Geode MSR instead of PCI configuration space it's normal OHCI. Actually with your patch when you forgot to power device up it resulted in similar symptoms on PCI OHCI controller. OHCI specification mentions different ways to configure power settings. I guess geode defaults to another mode than most controllers do. Or perhaps I need to somehow enable ports. > >> The fixes I've come up with are available in yeeloongfw branch. I've >> adjusted your previous patch to work on top of yeeloongfw branch. >> > > > I implemented also such timeouts independently, You can use finally the > better solution... > But the timeout probably should never happen if all is programmed well, > so probably there is still something bad somewhere... > > Timeout may happen also because of hw problem. They should be kept even after we chase all the bugs in the code. >> AFAIR According to spec if these values are the same queue is empty. >> >> > Yes, but there is question WHEN it is done. OHCI HC is doing things > sequentially (and in parallel with CPU via DMA). OHCI HC is doing so > called "retiring" of TDs AFTER values in ED are the same. I.e., when You > detect the same value in ED and make deallocation of ED and TDs, OHCI > can do something in TDs memory location at this time. "Retiring finish" > signaled by interrupt from DoneHead should be the LAST thing which OHCI > HC is doing, so it is more safe to use it - and such interrupt is used > by driver in Linux and Windows also (as it is in example in OHCI > specification). > > ok > But if You have better results with the old style of transfer end > detection, it is signal that I have still something wrong in my code - > maybe it is related to problem with mising STALL or NAK indication from > OHCI (or possibly also Unrecoverable error state). > Or it can be also some HW bug - when You look into Linux USB drivers > source code, You will find some workarounds related to HW "specialites" > of some OHCI chips... > > Perhaps you need clearing more interrupt status bits? > I did not noticed this mail, I will look into it - I made also some > simple workaround in OHCI initialization function but I don't know if it > is correct. Another bad thing is also re-powering of USB bus which I > mentioned above. > Taking USB controller by force is of course wrong but with some BIOSes it's the only choice > Best regards > Ales > > > ------------------------------------------------------------------------ > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko