On Tue, 2016-04-12 at 18:11 +0200, Marek Vasut wrote:
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.
Yup, same to my case. The DDR works as can boot to Linux at CV socdk but still same issue with USB. I am still suspecting the issue between the cache and DDR area.
With that, I tried to patch both L1 and L2 cache auxiliary register but doesn't help. Attaching the change here and hope can spark some thoughts.
diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h index d588f94..8c1d217 100644 --- a/arch/arm/include/asm/pl310.h +++ b/arch/arm/include/asm/pl310.h @@ -17,8 +17,11 @@ #define L2X0_CTRL_EN 1
#define L310_SHARED_ATT_OVERRIDE_ENABLE (1 << 22) +#define L310_AUX_CTRL_FULL_LINE_ZERO_MASK (1 << 0) +#define L310_AUX_CTRL_NS_LOCKDOWN_MASK (1 << 26) #define L310_AUX_CTRL_DATA_PREFETCH_MASK (1 << 28) #define L310_AUX_CTRL_INST_PREFETCH_MASK (1 << 29) +#define L310_AUX_CTRL_EARLY_BRESP_MASK (1 << 30)
struct pl310_regs { u32 pl310_cache_id; diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach -socfpga/misc.c index dd05e14..f67ab0b 100644 --- a/arch/arm/mach-socfpga/misc.c +++ b/arch/arm/mach-socfpga/misc.c @@ -53,6 +53,13 @@ void enable_caches(void)
void v7_outer_cache_enable(void) { + u32 acr; + + /* Read ACR */ + asm volatile ("mrc p15, 0, %0, c1, c0, 1" : "=r" (acr)); + acr |= (0x7 << 1); + v7_arch_cp15_set_acr(acr, 0, 0, 0, 0); + /* Disable the L2 cache */ clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN);
@@ -60,6 +67,9 @@ void v7_outer_cache_enable(void) setbits_le32(&pl310->pl310_aux_ctrl, L310_AUX_CTRL_DATA_PREFETCH_MASK | L310_AUX_CTRL_INST_PREFETCH_MASK | + L310_AUX_CTRL_EARLY_BRESP_MASK | + L310_AUX_CTRL_NS_LOCKDOWN_MASK | + L310_AUX_CTRL_FULL_LINE_ZERO_MASK | L310_SHARED_ATT_OVERRIDE_ENABLE);
/* Enable the L2 cache */