[U-Boot] Newbie SPL question for socfpga_sockit

[Marek Vasut <marex@denx.de>]

On 04/12/2016 06:09 PM, Stefan Roese wrote:
> On 12.04.2016 18:00, Marek Vasut wrote:
>> On 04/12/2016 05:53 PM, Dinh Nguyen wrote:
>>>
>>>
>>> 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.
>>
>> You mean the revert is needed on SoCFPGA, right ? I tried bashing Stefan
>> about the patch a bit and I am tempted to just revert it for now, since
>> there seems to be no time to repair it proper :(
> 
> Hmmmm. My priorities seem to have shifted a bit just now. ;)
> 
> I'll definitely try to fix this issue on SoCFPGA with the USB
> scanning patches in this release. As we don't want to go back
> to USB scanning times in the range of more than 20 seconds!
> Please give me something like 1 week for this.

OK, thanks!

> Marek, how can I reproduce this issue? Can I use the SoCrates
> board for this?

I think you can, but I just pulled out SoCrates from the drawer and it
doesn't enable port power when I start the USB. On the other hand, my
SoCrates is a bit abnormal, so it might be the board in this case.

> Could you perhaps double-check this on this
> board? Which USB sticks are known to fail?

Any stick fails for me :)

> Thanks,
> Stefan
> 


-- 
Best regards,
Marek Vasut