diff mbox

[U-Boot] Newbie SPL question for socfpga_sockit

Message ID 5706C59C.9000403@denx.de
State RFC
Delegated to: Marek Vasut
Headers show

Commit Message

Marek Vasut April 7, 2016, 8:39 p.m. UTC
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)

Best regards,
Marek Vasut

Comments

George Broz April 7, 2016, 11:31 p.m. UTC | #1
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.

Best regards,
--George

>
> Best regards,
> Marek Vasut
Marek Vasut April 7, 2016, 11:36 p.m. UTC | #2
On 04/08/2016 01:31 AM, 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.

OK. Then I should probably go hunting for Kingston DataTraveler SE9,
right ? Can you give me a link to the stick you have, so I know what
crappy device to look for ? Thanks!

Best regards,
Marek Vasut
George Broz April 7, 2016, 11:51 p.m. UTC | #3
On 7 April 2016 at 16:36, Marek Vasut <marex@denx.de> wrote:
> On 04/08/2016 01:31 AM, 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.
>
> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
> right ? Can you give me a link to the stick you have, so I know what
> crappy device to look for ? Thanks!

Here it is [1] - I have the 8GB version.

I think there will always be crappy sticks that don't work... but do you
have any advice as to what properties will/might generally cause a problem?

[1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG


FYI - here is the verbose lsusb output for this particular device for
what it's worth:

Bus 001 Device 005: ID 0930:6545 Toshiba Corp. Kingston DataTraveler
102 Flash Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0930 Toshiba Corp.
  idProduct          0x6545 Kingston DataTraveler 102 Flash Drive /
HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
  bcdDevice            1.00
  iManufacturer           1 Kingston
  iProduct                2 DataTraveler SE9
  iSerial                 3 0014857749E5ECB0173000D3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Best regards,
--George Broz

>
> Best regards,
> Marek Vasut
Stefan Roese April 8, 2016, 5:16 a.m. UTC | #4
On 08.04.2016 01:51, George Broz wrote:

<snip>

>>>> 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.
>>
>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>> right ? Can you give me a link to the stick you have, so I know what
>> crappy device to look for ? Thanks!
> 
> Here it is [1] - I have the 8GB version.
> 
> I think there will always be crappy sticks that don't work... but do you
> have any advice as to what properties will/might generally cause a problem?
> 
> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG

I have exactly this stick here (16GiB) version. And it is detected just
fine in both, current mainline Armada XP (theadorable) and x86 boards
(conga-qeval20-qa3-e3845). Here my lsusb output:

Bus 001 Device 004: ID 0930:6545 Toshiba Corp. Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0930 Toshiba Corp.
  idProduct          0x6545 Kingston DataTraveler 102/2.0 / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
  bcdDevice            1.10
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              300mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

HTP.

Thanks,
Stefan
 


> 
> FYI - here is the verbose lsusb output for this particular device for
> what it's worth:
> 
> Bus 001 Device 005: ID 0930:6545 Toshiba Corp. Kingston DataTraveler
> 102 Flash Drive / HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
> Device Descriptor:
>    bLength                18
>    bDescriptorType         1
>    bcdUSB               2.00
>    bDeviceClass            0 (Defined at Interface level)
>    bDeviceSubClass         0
>    bDeviceProtocol         0
>    bMaxPacketSize0        64
>    idVendor           0x0930 Toshiba Corp.
>    idProduct          0x6545 Kingston DataTraveler 102 Flash Drive /
> HEMA Flash Drive 2 GB / PNY Attache 4GB Stick
>    bcdDevice            1.00
>    iManufacturer           1 Kingston
>    iProduct                2 DataTraveler SE9
>    iSerial                 3 0014857749E5ECB0173000D3
>    bNumConfigurations      1
>    Configuration Descriptor:
>      bLength                 9
>      bDescriptorType         2
>      wTotalLength           32
>      bNumInterfaces          1
>      bConfigurationValue     1
>      iConfiguration          0
>      bmAttributes         0x80
>        (Bus Powered)
>      MaxPower              200mA
>      Interface Descriptor:
>        bLength                 9
>        bDescriptorType         4
>        bInterfaceNumber        0
>        bAlternateSetting       0
>        bNumEndpoints           2
>        bInterfaceClass         8 Mass Storage
>        bInterfaceSubClass      6 SCSI
>        bInterfaceProtocol     80 Bulk-Only
>        iInterface              0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x81  EP 1 IN
>          bmAttributes            2
>            Transfer Type            Bulk
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0200  1x 512 bytes
>          bInterval               0
>        Endpoint Descriptor:
>          bLength                 7
>          bDescriptorType         5
>          bEndpointAddress     0x02  EP 2 OUT
>          bmAttributes            2
>            Transfer Type            Bulk
>            Synch Type               None
>            Usage Type               Data
>          wMaxPacketSize     0x0200  1x 512 bytes
>          bInterval               0
> Device Qualifier (for other device speed):
>    bLength                10
>    bDescriptorType         6
>    bcdUSB               2.00
>    bDeviceClass            0 (Defined at Interface level)
>    bDeviceSubClass         0
>    bDeviceProtocol         0
>    bMaxPacketSize0        64
>    bNumConfigurations      1
> Device Status:     0x0000
>    (Bus Powered)
> 
> Best regards,
> --George Broz
> 
>>
>> Best regards,
>> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
Marek Vasut April 8, 2016, 12:36 p.m. UTC | #5
On 04/08/2016 07:16 AM, Stefan Roese wrote:
> On 08.04.2016 01:51, George Broz wrote:
> 
> <snip>
> 
>>>>> 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.
>>>
>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>> right ? Can you give me a link to the stick you have, so I know what
>>> crappy device to look for ? Thanks!
>>
>> Here it is [1] - I have the 8GB version.
>>
>> I think there will always be crappy sticks that don't work... but do you
>> have any advice as to what properties will/might generally cause a problem?
>>
>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
> 
> I have exactly this stick here (16GiB) version. And it is detected just
> fine in both, current mainline Armada XP (theadorable) and x86 boards
> (conga-qeval20-qa3-e3845). Here my lsusb output:

I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
all. Ouch :-(

[...]
Best regards,
Marek Vasut
George Broz April 8, 2016, 10:40 p.m. UTC | #6
On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>> On 08.04.2016 01:51, George Broz wrote:
>>
>> <snip>
>>
>>>>>> 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.
>>>>
>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>> right ? Can you give me a link to the stick you have, so I know what
>>>> crappy device to look for ? Thanks!
>>>
>>> Here it is [1] - I have the 8GB version.
>>>
>>> I think there will always be crappy sticks that don't work... but do you
>>> have any advice as to what properties will/might generally cause a problem?
>>>
>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>
>> I have exactly this stick here (16GiB) version. And it is detected just
>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>
> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
> all. Ouch :-(
>
> [...]
> Best regards,
> Marek Vasut

For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:

SMSC
3300-EZK
A1515AC13
515AR3A
ASETV

Best regards,
--George
Marek Vasut April 10, 2016, 5:47 p.m. UTC | #7
On 04/09/2016 12:40 AM, George Broz wrote:
> On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>> On 08.04.2016 01:51, George Broz wrote:
>>>
>>> <snip>
>>>
>>>>>>> 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.
>>>>>
>>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>>> right ? Can you give me a link to the stick you have, so I know what
>>>>> crappy device to look for ? Thanks!
>>>>
>>>> Here it is [1] - I have the 8GB version.
>>>>
>>>> I think there will always be crappy sticks that don't work... but do you
>>>> have any advice as to what properties will/might generally cause a problem?
>>>>
>>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>>
>>> I have exactly this stick here (16GiB) version. And it is detected just
>>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>>
>> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
>> all. Ouch :-(
>>
>> [...]
>> Best regards,
>> Marek Vasut
> 
> For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:
> 
> SMSC
> 3300-EZK
> A1515AC13
> 515AR3A
> ASETV

OK, that's the standard/recommended USB3300 PHY. I will keep fiddling
with the Kingston SE9 USB stick to see what's going on, that's probably
some other issue than the cache issue though.
George Broz April 11, 2016, 2:03 a.m. UTC | #8
On 10 April 2016 at 10:47, Marek Vasut <marex@denx.de> wrote:
> On 04/09/2016 12:40 AM, George Broz wrote:
>> On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
>>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>>> On 08.04.2016 01:51, George Broz wrote:
>>>>
>>>> <snip>
>>>>
>>>>>>>> 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.
>>>>>>
>>>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>>>> right ? Can you give me a link to the stick you have, so I know what
>>>>>> crappy device to look for ? Thanks!
>>>>>
>>>>> Here it is [1] - I have the 8GB version.
>>>>>
>>>>> I think there will always be crappy sticks that don't work... but do you
>>>>> have any advice as to what properties will/might generally cause a problem?
>>>>>
>>>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>>>
>>>> I have exactly this stick here (16GiB) version. And it is detected just
>>>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>>>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>>>
>>> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
>>> all. Ouch :-(
>>>
>>> [...]
>>> Best regards,
>>> Marek Vasut
>>
>> For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:
>>
>> SMSC
>> 3300-EZK
>> A1515AC13
>> 515AR3A
>> ASETV
>
> OK, that's the standard/recommended USB3300 PHY. I will keep fiddling
> with the Kingston SE9 USB stick to see what's going on, that's probably
> some other issue than the cache issue though.
>
On my third order for an OTG USB mini cable from Amazon, I finally got an
actual OTG cable!

On the SoCKit, using this cable the "dwc_otg_core_host_init: Timeout!"
messages no longer appear.

A few of the USB sticks I have here are immediately recognized and function
normally - a first for me with the latest version of u-boot. For
others, like the
Kingston SE9 stick, I get the same result as you - it's not detected at all.

I have yet to find one of the non-working USB sticks on the SoCKit
fail with the
same sort of long timeout followed by the zombie behavior exhibited by the
DE0/Kingston combination.

Best regards,
--George Broz

> --
> Best regards,
> Marek Vasut
Marek Vasut April 11, 2016, 2:02 p.m. UTC | #9
On 04/11/2016 04:03 AM, George Broz wrote:
> On 10 April 2016 at 10:47, Marek Vasut <marex@denx.de> wrote:
>> On 04/09/2016 12:40 AM, George Broz wrote:
>>> On 8 April 2016 at 05:36, Marek Vasut <marex@denx.de> wrote:
>>>> On 04/08/2016 07:16 AM, Stefan Roese wrote:
>>>>> On 08.04.2016 01:51, George Broz wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>>>> 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.
>>>>>>>
>>>>>>> OK. Then I should probably go hunting for Kingston DataTraveler SE9,
>>>>>>> right ? Can you give me a link to the stick you have, so I know what
>>>>>>> crappy device to look for ? Thanks!
>>>>>>
>>>>>> Here it is [1] - I have the 8GB version.
>>>>>>
>>>>>> I think there will always be crappy sticks that don't work... but do you
>>>>>> have any advice as to what properties will/might generally cause a problem?
>>>>>>
>>>>>> [1] http://www.amazon.com/Kingston-Digital-DataTraveler-DTSE9H-16GBZET/dp/B00DYQYITG
>>>>>
>>>>> I have exactly this stick here (16GiB) version. And it is detected just
>>>>> fine in both, current mainline Armada XP (theadorable) and x86 boards
>>>>> (conga-qeval20-qa3-e3845). Here my lsusb output:
>>>>
>>>> I bought the kingston stick and it's not detected on SoCFPGA SoCkit at
>>>> all. Ouch :-(
>>>>
>>>> [...]
>>>> Best regards,
>>>> Marek Vasut
>>>
>>> For what it's worth - here is the marking on the OTG chip on the de0_nano_soc:
>>>
>>> SMSC
>>> 3300-EZK
>>> A1515AC13
>>> 515AR3A
>>> ASETV
>>
>> OK, that's the standard/recommended USB3300 PHY. I will keep fiddling
>> with the Kingston SE9 USB stick to see what's going on, that's probably
>> some other issue than the cache issue though.
>>
> On my third order for an OTG USB mini cable from Amazon, I finally got an
> actual OTG cable!
> 
> On the SoCKit, using this cable the "dwc_otg_core_host_init: Timeout!"
> messages no longer appear.
> 
> A few of the USB sticks I have here are immediately recognized and function
> normally - a first for me with the latest version of u-boot. For
> others, like the
> Kingston SE9 stick, I get the same result as you - it's not detected at all.
> 
> I have yet to find one of the non-working USB sticks on the SoCKit
> fail with the
> same sort of long timeout followed by the zombie behavior exhibited by the
> DE0/Kingston combination.

Thanks for checking. I also have the SE9 here and it fails indeed, I
will have to look into it later.
Dinh Nguyen April 12, 2016, 3:53 p.m. UTC | #10
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
Marek Vasut April 12, 2016, 4 p.m. UTC | #11
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 :(
Dinh Nguyen April 12, 2016, 4:08 p.m. UTC | #12
On 04/12/2016 11:00 AM, 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 thusb at 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 :(
> 

Yes, I applied your attached patch as is, not realizing it was a revert
of 'c998da0d "usb: Change power-on / scanning timeout handling"'.

I also tested with a revert as well.

Dinh
Stefan Roese April 12, 2016, 4:09 p.m. UTC | #13
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.

Marek, how can I reproduce this issue? Can I use the SoCrates
board for this? Could you perhaps double-check this on this
board? Which USB sticks are known to fail?

Thanks,
Stefan
Marek Vasut April 12, 2016, 4:11 p.m. UTC | #14
On 04/12/2016 06:08 PM, Dinh Nguyen wrote:
> 
> 
> On 04/12/2016 11:00 AM, 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 thusb at 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 :(
>>
> 
> Yes, I applied your attached patch as is, not realizing it was a revert
> of 'c998da0d "usb: Change power-on / scanning timeout handling"'.
> 
> I also tested with a revert as well.

Grumble ... I will either look into the patch or revert it. I am not
sure yet. Still, the dcache issue is not gone even with the DDR patches.
Marek Vasut April 13, 2016, 11:09 a.m. UTC | #15
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
>
diff mbox

Patch

>From 1d9326d5db29f2dca8639e8929eac780e1bd29a3 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex@denx.de>
Date: Sat, 2 Apr 2016 00:20:37 +0200
Subject: [PATCH] Revert "usb: Change power-on / scanning timeout handling"

This reverts commit c998da0d67091f800933e59b8693913764a9e8f4.
---
 common/usb_hub.c | 317 +++++++++++++++++--------------------------------------
 include/usb.h    |   4 -
 2 files changed, 94 insertions(+), 227 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index e6a2cdb..d621f50 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -30,7 +30,6 @@ 
 #include <asm/processor.h>
 #include <asm/unaligned.h>
 #include <linux/ctype.h>
-#include <linux/list.h>
 #include <asm/byteorder.h>
 #ifdef CONFIG_SANDBOX
 #include <asm/state.h>
@@ -50,19 +49,9 @@  DECLARE_GLOBAL_DATA_PTR;
 #define HUB_SHORT_RESET_TIME	20
 #define HUB_LONG_RESET_TIME	200
 
-#define PORT_OVERCURRENT_MAX_SCAN_COUNT		3
-
-struct usb_device_scan {
-	struct usb_device *dev;		/* USB hub device to scan */
-	struct usb_hub_device *hub;	/* USB hub struct */
-	int port;			/* USB port to scan */
-	struct list_head list;
-};
-
 /* TODO(sjg@chromium.org): Remove this when CONFIG_DM_USB is defined */
 static struct usb_hub_device hub_dev[USB_MAX_HUB];
 static int usb_hub_index;
-static LIST_HEAD(usb_scan_list);
 
 __weak void usb_hub_reset_devices(int port)
 {
@@ -120,15 +109,6 @@  static void usb_hub_power_on(struct usb_hub_device *hub)
 		debug("port %d returns %lX\n", i + 1, dev->status);
 	}
 
-#ifdef CONFIG_SANDBOX
-	/*
-	 * Don't set timeout / delay values here. This results
-	 * in these values still being reset to 0.
-	 */
-	if (state_get_skip_delays())
-		return;
-#endif
-
 	/*
 	 * Wait for power to become stable,
 	 * plus spec-defined max time for device to connect
@@ -140,30 +120,12 @@  static void usb_hub_power_on(struct usb_hub_device *hub)
 		pgood_delay = max(pgood_delay,
 			          (unsigned)simple_strtol(env, NULL, 0));
 	debug("pgood_delay=%dms\n", pgood_delay);
-
-	/*
-	 * Do a minimum delay of the larger value of 100ms or pgood_delay
-	 * so that the power can stablize before the devices are queried
-	 */
-	hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);
-
-	/*
-	 * Record the power-on timeout here. The max. delay (timeout)
-	 * will be done based on this value in the USB port loop in
-	 * usb_hub_configure() later.
-	 */
-	hub->connect_timeout = hub->query_delay + 1000;
-	debug("devnum=%d poweron: query_delay=%d connect_timeout=%d\n",
-	      dev->devnum, max(100, (int)pgood_delay),
-	      max(100, (int)pgood_delay) + 1000);
+	mdelay(pgood_delay + 1000);
 }
 
 void usb_hub_reset(void)
 {
 	usb_hub_index = 0;
-
-	/* Zero out global hub_dev in case its re-used again */
-	memset(hub_dev, 0, sizeof(hub_dev));
 }
 
 static struct usb_hub_device *usb_hub_allocate(void)
@@ -370,168 +332,6 @@  int usb_hub_port_connect_change(struct usb_device *dev, int port)
 	return ret;
 }
 
-static int usb_scan_port(struct usb_device_scan *usb_scan)
-{
-	ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
-	unsigned short portstatus;
-	unsigned short portchange;
-	struct usb_device *dev;
-	struct usb_hub_device *hub;
-	int ret = 0;
-	int i;
-
-	dev = usb_scan->dev;
-	hub = usb_scan->hub;
-	i = usb_scan->port;
-
-	/*
-	 * Don't talk to the device before the query delay is expired.
-	 * This is needed for voltages to stabalize.
-	 */
-	if (get_timer(0) < hub->query_delay)
-		return 0;
-
-	ret = usb_get_port_status(dev, i + 1, portsts);
-	if (ret < 0) {
-		debug("get_port_status failed\n");
-		if (get_timer(0) >= hub->connect_timeout) {
-			debug("devnum=%d port=%d: timeout\n",
-			      dev->devnum, i + 1);
-			/* Remove this device from scanning list */
-			list_del(&usb_scan->list);
-			free(usb_scan);
-			return 0;
-		}
-	}
-
-	portstatus = le16_to_cpu(portsts->wPortStatus);
-	portchange = le16_to_cpu(portsts->wPortChange);
-	debug("Port %d Status %X Change %X\n", i + 1, portstatus, portchange);
-
-	/* No connection change happened, wait a bit more. */
-	if (!(portchange & USB_PORT_STAT_C_CONNECTION)) {
-		if (get_timer(0) >= hub->connect_timeout) {
-			debug("devnum=%d port=%d: timeout\n",
-			      dev->devnum, i + 1);
-			/* Remove this device from scanning list */
-			list_del(&usb_scan->list);
-			free(usb_scan);
-			return 0;
-		}
-		return 0;
-	}
-
-	/* Test if the connection came up, and if not exit */
-	if (!(portstatus & USB_PORT_STAT_CONNECTION))
-		return 0;
-
-	/* A new USB device is ready at this point */
-	debug("devnum=%d port=%d: USB dev found\n", dev->devnum, i + 1);
-
-	usb_hub_port_connect_change(dev, i);
-
-	if (portchange & USB_PORT_STAT_C_ENABLE) {
-		debug("port %d enable change, status %x\n", i + 1, portstatus);
-		usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_C_ENABLE);
-		/*
-		 * The following hack causes a ghost device problem
-		 * to Faraday EHCI
-		 */
-#ifndef CONFIG_USB_EHCI_FARADAY
-		/*
-		 * EM interference sometimes causes bad shielded USB
-		 * devices to be shutdown by the hub, this hack enables
-		 * them again. Works at least with mouse driver
-		 */
-		if (!(portstatus & USB_PORT_STAT_ENABLE) &&
-		    (portstatus & USB_PORT_STAT_CONNECTION) &&
-		    usb_device_has_child_on_port(dev, i)) {
-			debug("already running port %i disabled by hub (EMI?), re-enabling...\n",
-			      i + 1);
-			usb_hub_port_connect_change(dev, i);
-		}
-#endif
-	}
-
-	if (portstatus & USB_PORT_STAT_SUSPEND) {
-		debug("port %d suspend change\n", i + 1);
-		usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_SUSPEND);
-	}
-
-	if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
-		debug("port %d over-current change\n", i + 1);
-		usb_clear_port_feature(dev, i + 1,
-				       USB_PORT_FEAT_C_OVER_CURRENT);
-		/* Only power-on this one port */
-		usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
-		hub->overcurrent_count[i]++;
-
-		/*
-		 * If the max-scan-count is not reached, return without removing
-		 * the device from scan-list. This will re-issue a new scan.
-		 */
-		if (hub->overcurrent_count[i] <=
-		    PORT_OVERCURRENT_MAX_SCAN_COUNT)
-			return 0;
-
-		/* Otherwise the device will get removed */
-		printf("Port %d over-current occured %d times\n", i + 1,
-		       hub->overcurrent_count[i]);
-	}
-
-	if (portchange & USB_PORT_STAT_C_RESET) {
-		debug("port %d reset change\n", i + 1);
-		usb_clear_port_feature(dev, i + 1, USB_PORT_FEAT_C_RESET);
-	}
-
-	/*
-	 * We're done with this device, so let's remove this device from
-	 * scanning list
-	 */
-	list_del(&usb_scan->list);
-	free(usb_scan);
-
-	return 0;
-}
-
-static int usb_device_list_scan(void)
-{
-	struct usb_device_scan *usb_scan;
-	struct usb_device_scan *tmp;
-	static int running;
-	int ret = 0;
-
-	/* Only run this loop once for each controller */
-	if (running)
-		return 0;
-
-	running = 1;
-
-	while (1) {
-		/* We're done, once the list is empty again */
-		if (list_empty(&usb_scan_list))
-			goto out;
-
-		list_for_each_entry_safe(usb_scan, tmp, &usb_scan_list, list) {
-			int ret;
-
-			/* Scan this port */
-			ret = usb_scan_port(usb_scan);
-			if (ret)
-				goto out;
-		}
-	}
-
-out:
-	/*
-	 * This USB controller has finished scanning all its connected
-	 * USB devices. Set "running" back to 0, so that other USB controllers
-	 * will scan their devices too.
-	 */
-	running = 0;
-
-	return ret;
-}
 
 static int usb_hub_configure(struct usb_device *dev)
 {
@@ -666,33 +466,104 @@  static int usb_hub_configure(struct usb_device *dev)
 	for (i = 0; i < dev->maxchild; i++)
 		usb_hub_reset_devices(i + 1);
 
-	/*
-	 * Only add the connected USB devices, including potential hubs,
-	 * to a scanning list. This list will get scanned and devices that
-	 * are detected (either via port connected or via port timeout)
-	 * will get removed from this list. Scanning of the devices on this
-	 * list will continue until all devices are removed.
-	 */
 	for (i = 0; i < dev->maxchild; i++) {
-		struct usb_device_scan *usb_scan;
+		ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
+		unsigned short portstatus, portchange;
+		int ret;
+		ulong start = get_timer(0);
+		uint delay = CONFIG_SYS_HZ;
+
+#ifdef CONFIG_SANDBOX
+		if (state_get_skip_delays())
+			delay = 0;
+#endif
+#ifdef CONFIG_DM_USB
+		debug("\n\nScanning '%s' port %d\n", dev->dev->name, i + 1);
+#else
+		debug("\n\nScanning port %d\n", i + 1);
+#endif
+		/*
+		 * Wait for (whichever finishes first)
+		 *  - A maximum of 10 seconds
+		 *    This is a purely observational value driven by connecting
+		 *    a few broken pen drives and taking the max * 1.5 approach
+		 *  - connection_change and connection state to report same
+		 *    state
+		 */
+		do {
+			ret = usb_get_port_status(dev, i + 1, portsts);
+			if (ret < 0) {
+				debug("get_port_status failed\n");
+				break;
+			}
+
+			portstatus = le16_to_cpu(portsts->wPortStatus);
+			portchange = le16_to_cpu(portsts->wPortChange);
+
+			/* No connection change happened, wait a bit more. */
+			if (!(portchange & USB_PORT_STAT_C_CONNECTION))
+				continue;
+
+			/* Test if the connection came up, and if so, exit. */
+			if (portstatus & USB_PORT_STAT_CONNECTION)
+				break;
+
+		} while (get_timer(start) < delay);
+
+		if (ret < 0)
+			continue;
 
-		usb_scan = calloc(1, sizeof(*usb_scan));
-		if (!usb_scan) {
-			printf("Can't allocate memory for USB device!\n");
-			return -ENOMEM;
+		debug("Port %d Status %X Change %X\n",
+		      i + 1, portstatus, portchange);
+
+		if (portchange & USB_PORT_STAT_C_CONNECTION) {
+			debug("port %d connection change\n", i + 1);
+			usb_hub_port_connect_change(dev, i);
+		}
+		if (portchange & USB_PORT_STAT_C_ENABLE) {
+			debug("port %d enable change, status %x\n",
+			      i + 1, portstatus);
+			usb_clear_port_feature(dev, i + 1,
+						USB_PORT_FEAT_C_ENABLE);
+			/*
+			 * The following hack causes a ghost device problem
+			 * to Faraday EHCI
+			 */
+#ifndef CONFIG_USB_EHCI_FARADAY
+			/* EM interference sometimes causes bad shielded USB
+			 * devices to be shutdown by the hub, this hack enables
+			 * them again. Works at least with mouse driver */
+			if (!(portstatus & USB_PORT_STAT_ENABLE) &&
+			     (portstatus & USB_PORT_STAT_CONNECTION) &&
+			     usb_device_has_child_on_port(dev, i)) {
+				debug("already running port %i "  \
+				      "disabled by hub (EMI?), " \
+				      "re-enabling...\n", i + 1);
+				      usb_hub_port_connect_change(dev, i);
+			}
+#endif
+		}
+		if (portstatus & USB_PORT_STAT_SUSPEND) {
+			debug("port %d suspend change\n", i + 1);
+			usb_clear_port_feature(dev, i + 1,
+						USB_PORT_FEAT_SUSPEND);
 		}
-		usb_scan->dev = dev;
-		usb_scan->hub = hub;
-		usb_scan->port = i;
-		list_add_tail(&usb_scan->list, &usb_scan_list);
-	}
 
-	/*
-	 * And now call the scanning code which loops over the generated list
-	 */
-	ret = usb_device_list_scan();
+		if (portchange & USB_PORT_STAT_C_OVERCURRENT) {
+			debug("port %d over-current change\n", i + 1);
+			usb_clear_port_feature(dev, i + 1,
+						USB_PORT_FEAT_C_OVER_CURRENT);
+			usb_hub_power_on(hub);
+		}
 
-	return ret;
+		if (portchange & USB_PORT_STAT_C_RESET) {
+			debug("port %d reset change\n", i + 1);
+			usb_clear_port_feature(dev, i + 1,
+						USB_PORT_FEAT_C_RESET);
+		}
+	} /* end for i all ports */
+
+	return 0;
 }
 
 static int usb_hub_check(struct usb_device *dev, int ifnum)
diff --git a/include/usb.h b/include/usb.h
index 5adad36..ed2336b 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -556,10 +556,6 @@  struct usb_hub_descriptor {
 struct usb_hub_device {
 	struct usb_device *pusb_dev;
 	struct usb_hub_descriptor desc;
-
-	ulong connect_timeout;		/* Device connection timeout in ms */
-	ulong query_delay;		/* Device query delay in ms */
-	int overcurrent_count[USB_MAXCHILDREN];	/* Over-current counter */
 };
 
 #ifdef CONFIG_DM_USB
-- 
2.7.0