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 <ma...@denx.de> wrote: >>>>> On 04/07/2016 03:14 PM, George Broz wrote: >>>>>> On 6 April 2016 at 19:05, Marek Vasut <ma...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
