[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut]

On 04/07/2016 03:14 PM, George Broz wrote:
> On 6 April 2016 at 19:05, Marek Vasut <marex at denx.de> wrote:
>> On 04/07/2016 03:42 AM, George Broz wrote:
>>
>> Hi,
>>
>>>>> U-Boot SPL 2016.03 (Apr 05 2016 - 17:57:23)
>>>>> drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
>>>>> drivers/ddr/altera/sequencer.c: CALIBRATION PASSED
>>>>> drivers/ddr/altera/sequencer.c: Calibration complete
>>>>> Trying to boot from MMC1
>>>>>
>>>>> First time that an SPL built from a recent version has run successfully
>>>>> on that board.
>>>>>
>>>>> Will try it out on de0 tomorrow morning...
>>>>
>>>> This is great news, thanks!
>>>
>>> This patch also fixes the intermittent SDRAM calibration failures on my
>>> de0_nano_soc board. Thanks so much!
>>
>> Great
>>
>>> Now with up-to-date versions of SPL and image... I have some
>>> USB questions/news/observations:
>>>
>>> When using an OTG cable between USB port and mass storage
>>> device, the de0_nano_soc board is able to detect and access some USB
>>> sticks. The detection with these is almost immediate from when 'usb start'
>>> is entered. If the same (working) USB stick is used with a non-OTG cable,
>>> I get the timeout messages from before:
>>>
>>> dwc_otg_core_host_init: Timeout!
>>> dwc_otg_core_host_init: Timeout!
>>>
>>> and this is true even if I add 'dr_mode = "host" '
>>
>> I don't think the driver supports the dr_mode property yet. Patch is
>> welcome.
>>
>>> to the dts for usb1
>>> of the de0
>>> (and rebuild/reload). The older SPL/image that ships from the Terasic factory
>>> detects USB sticks with a non-OTG cable, (the cable that ships with the unit).
>>> What is the correct "expected" behavior here?? Is an OTG cable required or
>>> not?
>>
>> The DWC2 driver tests the value of the OTG ID pin, so if you don't use
>> OTG cable with correct ID pin setup, the host won't work.
>>
>>> Even with the OTG cable, some USB sticks "fail" in a not-so-great way.
>>> I have a Kingston stick and the sequence goes like this:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0:   Core Release: 2.93a
>>> scanning bus 0 for devices...
>>>
>>> <<< 1 minute, 41 seconds pass before >>>
>>> ... Device NOT ready
>>>    Request Sense returned 00 00 00
>>>
>>>  <<< then another  24 seconds pass before >>>
>>>
>>> 2 USB Device(s) found
>>>
>>> It was able to read some information about the stick:
>>>
>>> => usb info
>>> :
>>> 2: Mass Storage,  USB Revision 2.0
>>> - Kingston DataTraveler SE9 0014857749E5ECB0173000D3
>>> - Class: (from Interface) Mass Storage
>>> - PacketSize: 64  Configurations: 1
>>> - Vendor: 0x0930  Product 0x6545 Version 1.0
>>>    Configuration: 1
>>>    - Interfaces: 1 Bus Powered 200mA
>>>      Interface: 0
>>>      - Alternate Setting 0, Endpoints: 2
>>>      - Class Mass Storage, Transp. SCSI, Bulk only
>>>      - Endpoint 1 In Bulk MaxPacket 512
>>>      - Endpoint 2 Out Bulk MaxPacket 512
>>>
>>> BUT, the stick cannot be accessed otherwise, for example:
>>>
>>> => usb part 0
>>> ## Unknown partition table type 0
>>>
>>>
>>> Is there any feature of the USB stick that would indicate
>>> whether or not it is "compatible" with u-boot?
>>
>> Can you do "dcache off" before you do "usb reset" and see if that fixes
>> the problem ?
> 
> The behavior is unchanged if "dcache off" done before "usb reset".

Try with the attached patch (and probably with dcache off)

Best regards,
Marek Vasut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Revert-usb-Change-power-on-scanning-timeout-handling.patch
Type: text/x-patch
Size: 11819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160407/b9185f72/attachment.bin>