[U-Boot] Newbie SPL question for socfpga_sockit

[Dinh Nguyen <dinguyen@opensource.altera.com>]

On 04/07/2016 06:31 PM, George Broz wrote:
> On 7 April 2016 at 13:39, Marek Vasut <marex@denx.de> wrote:
>> On 04/07/2016 03:14 PM, George Broz wrote:
>>> On 6 April 2016 at 19:05, Marek Vasut <marex@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)
> 
> The patch applied cleanly. The behavior is unchanged with both
> dcache on and off. The "good" sticks still work, and "bad" sticks still don't.
> 

Not sure if this helps, but with this patch and dcache off, my "bad"
stick (SanDisk Cruzer U 4C530200250418114310) is now working.

Dinh