[U-Boot] SoCFPGA cache / S-bit problem - was Re: Newbie SPL question for socfpga_sockit

[Stefan Roese <sr@denx.de>]

Hi Chin,

On 23.03.2016 16:00, Chin Liang See wrote:
> On Mon, 2016-03-21 at 23:45 +0800, Chin Liang See wrote:
>> On Mon, 2016-03-21 at 22:05 +0800, Chin Liang See wrote:
>>> On Fri, 2016-03-04 at 20:03 +0100, Marek Vasut wrote:
>>>> On 03/04/2016 05:06 PM, Dinh Nguyen wrote:
>>>>> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>
> [..]
>
>>>>>> Well, that's our usual USB/QSPI cache issue that's tormenting
>>>>>> your soul.
>>>>>> CCing Chin ;-)
>>>>>>
>>>>>> Does the issue by any chance magically disappear if you apply
>>>>>> this patch:
>>>>>>
>>>>>> diff --git a/arch/arm/include/asm/system.h
>>>>>> b/arch/arm/include/asm/system.h
>>>>>> index 026e7ef..06802c6 100644
>>>>>> --- a/arch/arm/include/asm/system.h
>>>>>> +++ b/arch/arm/include/asm/system.h
>>>>>> @@ -274,7 +274,7 @@ static inline void set_dacr(unsigned int
>>>>>> val)
>>>>>>
>>>>>>   /* options available for data cache on each page */
>>>>>>   enum dcache_option {
>>>>>> -       DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK |
>>>>>> TTB_SECT,
>>>>>> +       DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
>>>>>> TTB_SECT_XN_MASK | TTB_SECT,
>>>>>>          DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
>>>>>>          DCACHE_WRITEBACK = DCACHE_WRITETHROUGH |
>>>>>> TTB_SECT_B_MASK,
>>>>>>          DCACHE_WRITEALLOC = DCACHE_WRITEBACK |
>>>>>> TTB_SECT_TEX(1),
>>>>>>
>>>>>
>>>>> Yes, this patch fixes USB with dcache left on.
>>>>
>>>> Except that it doesn't fix anything, it just makes the system
>>>> slower
>>>> by
>>>> setting the S bit :-/ So this is not a fix :-(
>>>
>>> Sorry for away for a while as busy with some critical issues.
>>>
>>> Finally relooking back on this. I notice that with SanDisk Cruzer
>>> Blade
>>> pendrive, U-Boot 2013.01.01 can detect it while latest cannot. The
>>> dcache disablement at latest U-Boot doesn't help.
>>>
>>> With that, I compared a bunch of registers from clocks, sysmgr,
>>> SCTLR,
>>> ATCLR and USB1 too. I noticed they are similar except the
>>> usb1.globgrp.gusbcfg.ulpiextvbusdrv. The latest U-Boot is
>>> indicating
>>> external supply (address 0xffb4000c return value 0x00101710) while
>>> working 2013.01.01 indicating internal charge pump (return value
>>> 0x00001710)
>>>
>>> Wonder you guys are seeing the same too? Will dig more about this.
>>> FYI,
>>> I tried to add lot of delay within dwc2.c but doesn't help at all.
>>>
>>
>> While modifying the USB power control of the code, I noticed the
>> patch
>> made by Dinh is not there. Just realize the git clone through http
>> from
>> main git doesn't work. I was able to clone but getting older version.
>>
>> With getting the latest code, all my pendrive now can works with
>> dcache
>> off. Its easier now as I can get consistent behaviour compared
>> previously. With that, dcache investigation for tomorrow then
>>
>> Thanks
>> Chin Liang
>>
>
> Spent more time on the dcache + USB issue today. Narrow down to below
> patch which can make all my USB pendrives work with dcache enabled. But
> still need to understand further as not in depth familiar with dwc2.
> Probably this might ring a bell to you guys?
>
>
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index b2f4bc6..b11d8d7 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -776,6 +776,7 @@ static int transfer_chunk(struct dwc2_hc_regs
> *hc_regs, void *aligned_buffer,
>                 (num_packets << DWC2_HCTSIZ_PKTCNT_OFFSET) |
>                 (*pid << DWC2_HCTSIZ_PID_OFFSET),
>                 &hc_regs->hctsiz);
> +       udelay(2);
>
>          if (!in && xfer_len) {
>                  memcpy(aligned_buffer, buffer, xfer_len);

I can't really comment on the USB problem, as I've only seen this
d-cache / S-bit problem with SPI NOR flash. This is because I've never
really used USB on this platform intensively. But I'm nearly 100%
sure, that all changes that add some delays (or debug printfs)
resulting in a "working solution", either in the USB case or the SPI
NOR case, are just papering over the real problem.

Thanks,
Stefan