[SLOF] [PATCH 1/2] Move archsupport.fs into board-qemu directory

Nikunj A Dadhania nikunj at linux.vnet.ibm.com
Fri Jan 8 19:54:36 AEDT 2016


Thomas Huth <thuth at redhat.com> writes:

> On 04.01.2016 11:12, Nikunj A Dadhania wrote:
>> Thomas Huth <thuth at redhat.com> writes:
>> 
>>> On 04.01.2016 10:17, Thomas Huth wrote:
>>>> On 23.12.2015 02:43, Alexey Kardashevskiy wrote:
>>>>> On 12/22/2015 07:25 AM, Thomas Huth wrote:
>>>>>> The "hv-cas" hypercall is only available on board-qemu.
>>>>>> Including archsupport.fs on board-js2x breaks the boot
>>>>>> process there. Thus the archsupport.fs file should
>>>>>> reside in the board-qemu/slof directory instead and
>>>>>> only be included from there.
>>>>>
>>>>>
>>>>> Thanks, applied.
>>>>>
>>>>> Does js2x boot now? :)
>>>>
>>>> Unfortunately not yet, there are a couple of problems left:
>>>>
>>>> - dma-alloc & dma-map-in and friends do not work yet, causing the
>>>>   libusb code to abort when trying to allocate memory
>>>>   => I have a patch for this pretty much ready, will send it later
>>>>
>>>> - But even with the dma-alloc fixed, the new libusb code does not seem
>>>>   to work right with real hardware yet, I get messages about STALLs and
>>>>   timeouts when I connect an USB device
>>>
>>> FWIW, here's the console output of the USB scan:
>>>
>>> Scanning USB
>>>   OHCI: initializing
>>>   OHCI: initializing
>>>   EHCI: Initializing
>>>   OHCI: initializing
>>>     USB Storage
>>>        SCSI: Looking for devices
>>> USB: Error STALL 0xE967000
>>> ED Halted
>>> ohci_transfer_bulk: headp 0E967011 tailp 0E967010 next_td 00000000 attr
>>> 00405101
>> 
>> Controller asserted a HALT on the endpoint. Can you enable ohci debug
>> usb-ohci.c - OHCI_DEBUG_PACKET and OHCI_DEBUG
>
> Now I'm back from vacation ... but currently I don't have the
> PowerStation with me anymore .... I'll try when I'm back at the
> location where I left it...
>
> Anyway, IIRC the original Forth USB stack had similar issues with
> stalled USB storage devices once - from time to time, real USB storage
> devices seemed to report "STALLED" randomly, maybe because they could
> not deliver the data fast enough?
> So the original Forth USB stack was equipped with some code to handle
> the "STALLED" state. If you're interested, search for STALLED in:
> https://github.com/aik/SLOF/blob/slof-JX-1.7.0-5/slof/fs/usb/usb-storage.fs
>
> Maybe the new USB stack needs some similar handling code, too, if it
> is not there yet?

We have some similar code in lib/libusb/usb-ohci.c

                if (ret == USB_STALL) /* Call reset recovery */
                        usb_msc_resetrecovery(pipe->dev);

>
>>> Timed out waiting for interrupt 45
>>> Timed out waiting for interrupt 45
>>> USB-DISK: Bulk commad failed!
>>>           101000000000000 DISK     : "Ut163    USB2FlashStorage 0.00"
>>>   OHCI: initializing
>>> ohci_send_ctrl: timed out - failed
>>> Request: 80 06 00 01 00 00 08 00
>>> USB: Error DEVICENOTRESPONDING 0xE96ED00
>>> Timed out waiting for interrupt 45
>>> usb-ohci: unable to setup device on port 1
>>>
>>> Any ideas what could cause these issues?
>> 
>> 4 OHCI controller and one EHCI controller are there on the js2x ?
>> This looks a bit strange. It might have companion controller which is
>> not supported in SLOF USB stack.
>
> Ah, that's because the PowerStation (and js21) has a built-in USB chip,
> which features two OHCI controllers and one EHCI - which is however broken
> and thus disabled by the firmware. To get USB 2.0 speed, too, I've once
> added a USB 2.0 PCI card which comes with two more OHCI controllers and one
> EHCI controller, so that's why there are 4 OHCI controllers in above output.

That makes sense.

Regards,
Nikunj



More information about the SLOF mailing list