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". Best regards, --George Broz > >> Thanks again for the calibration fix! Let me >> know if there is something else I can test! > > Yeah, I CCed you on the DDR patches, so you can reply with your > Tested-By for SoCkit and Nano-SoC. Thanks > > Best regards, > Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot