From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dinh Nguyen Date: Tue, 12 Apr 2016 11:08:33 -0500 Subject: [U-Boot] Newbie SPL question for socfpga_sockit In-Reply-To: <570D1B92.2040102@denx.de> References: <56EA09DA.5040504@denx.de> <56EEC7DE.7050605@opensource.altera.com> <56EED309.40305@denx.de> <56F17B81.1050301@opensource.altera.com> <56F6F695.8030204@denx.de> <57037868.1080204@electromag.com.au> <5704362B.30708@denx.de> <57045C40.8040502@denx.de> <5704E847.3020405@denx.de> <5705C055.20305@denx.de> <5706C59C.9000403@denx.de> <570D1A04.3010605@opensource.altera.com> <570D1B92.2040102@denx.de> Message-ID: <570D1D81.9090101@opensource.altera.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: >>>> On 04/07/2016 03:14 PM, George Broz wrote: >>>>> On 6 April 2016 at 19:05, Marek Vasut 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