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 <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 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 */
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
