[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese]

By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
policy is selected. This leads to much better performance on the SoCFPGA.
A quick network test shows this:

Without this patch:
=> tftp 100000 big-40mb
Speed: 1000, full duplex
Using dwmac.ff702000 device
TFTP from server 192.168.1.54; our IP address is 192.168.1.252
Filename 'big-40mb'.
Load address: 0x100000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################
         2.5 MiB/s

With this patch:
=> tftp 100000 big-40mb
Speed: 1000, full duplex
Using dwmac.ff702000 device
TFTP from server 192.168.1.54; our IP address is 192.168.1.252
Filename 'big-40mb'.
Load address: 0x100000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################
         7.6 MiB/s

A performance improvement of factor ~3.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Marek Vasut <marex@denx.de>
---
 include/configs/socfpga_common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 38ae763..a2811ba 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -73,7 +73,6 @@
 /*
  * Cache
  */
-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
 #define CONFIG_SYS_CACHELINE_SIZE 32
 #define CONFIG_SYS_L2_PL310
 #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
-- 
2.5.2

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:
> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
> policy is selected. This leads to much better performance on the SoCFPGA.
> A quick network test shows this:
> 
> Without this patch:
> => tftp 100000 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################
>          2.5 MiB/s
> 
> With this patch:
> => tftp 100000 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################
>          7.6 MiB/s
> 
> A performance improvement of factor ~3.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> Cc: Chin Liang See <clsee@altera.com>
> Cc: Pavel Machek <pavel@denx.de>
> Cc: Marek Vasut <marex@denx.de>

OUCH! This actually came from the original Altera sources, darn :-(

Acked-by: Marek Vasut <marex@denx.de>

Best regards,
Marek Vasut

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Pavel Machek]

On Thu 2015-09-17 17:30:29, Stefan Roese wrote:
> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
> policy is selected. This leads to much better performance on the SoCFPGA.
> A quick network test shows this:
> 
> Without this patch:
> => tftp 100000 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################
>          2.5 MiB/s
> 
> With this patch:
> => tftp 100000 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################
>          7.6 MiB/s
> 
> A performance improvement of factor ~3.

Ok, so you turn on write-back cache and it is faster.

Now... do you have an explanation why this is safe to do? Are there
cache flushes that need to be added to the code now that we turned on
write-back?

Best regards,
									Pavel

> diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
> index 38ae763..a2811ba 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -73,7 +73,6 @@
>  /*
>   * Cache
>   */
> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
>  #define CONFIG_SYS_CACHELINE_SIZE 32
>  #define CONFIG_SYS_L2_PL310
>  #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese]

Hi Pavel,

On 18.09.2015 08:16, Pavel Machek wrote:
> On Thu 2015-09-17 17:30:29, Stefan Roese wrote:
>> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
>> policy is selected. This leads to much better performance on the SoCFPGA.
>> A quick network test shows this:
>>
>> Without this patch:
>> => tftp 100000 big-40mb
>> Speed: 1000, full duplex
>> Using dwmac.ff702000 device
>> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
>> Filename 'big-40mb'.
>> Load address: 0x100000
>> Loading: #################################################################
>>           #################################################################
>>           #################################################################
>>           #################################################################
>>           ##########################
>>           2.5 MiB/s
>>
>> With this patch:
>> => tftp 100000 big-40mb
>> Speed: 1000, full duplex
>> Using dwmac.ff702000 device
>> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
>> Filename 'big-40mb'.
>> Load address: 0x100000
>> Loading: #################################################################
>>           #################################################################
>>           #################################################################
>>           #################################################################
>>           ##########################
>>           7.6 MiB/s
>>
>> A performance improvement of factor ~3.
>
> Ok, so you turn on write-back cache and it is faster.

Its not only faster. My tests have shown, that the current 
implementation (WRITEALLOC) does not enable the dcache at all. No 
performance difference with dcache enable or disabled. I also tested 
this by removing the dcache flush and invalidate calls from the ethernet 
driver. And tftp still worked without any problems (same slow speed of 
course) with dcache enabled. On platforms with a really enabled dcache, 
such a change leads to a non-working network interface.

The only conclusion I can draw from this is, that in the current 
configuration (WRITEALLOC) the dcache is not enabled at all. With this 
patch now I'm seeing network speeds that are similar to other platforms.

> Now... do you have an explanation why this is safe to do? Are there
> cache flushes that need to be added to the code now that we turned on
> write-back?

I have not found any issues yet with this patch added. The cache 
handling calls (flush, invalidate) are already included in the code 
using it (e.g. USB, ethernet, MMC).

Thanks,
Stefan

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Pavel Machek]

Hi!

> >>With this patch:
> >>=> tftp 100000 big-40mb
> >>Speed: 1000, full duplex
> >>Using dwmac.ff702000 device
> >>TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> >>Filename 'big-40mb'.
> >>Load address: 0x100000
> >>Loading: #################################################################
> >>          #################################################################
> >>          #################################################################
> >>          #################################################################
> >>          ##########################
> >>          7.6 MiB/s
> >>
> >>A performance improvement of factor ~3.
> >
> >Ok, so you turn on write-back cache and it is faster.
> 
> Its not only faster. My tests have shown, that the current implementation
> (WRITEALLOC) does not enable the dcache at all. No performance difference
> with dcache enable or disabled. I also tested this by removing the dcache
> flush and invalidate calls from the ethernet driver. And tftp still worked
> without any problems (same slow speed of course) with dcache enabled. On
> platforms with a really enabled dcache, such a change leads to a non-working
> network interface.

Yes, so we were running with dcache disabled, which can mask _many_
programming errors.

> >Now... do you have an explanation why this is safe to do? Are there
> >cache flushes that need to be added to the code now that we turned on
> >write-back?
> 
> I have not found any issues yet with this patch added. The cache handling
> calls (flush, invalidate) are already included in the code using it (e.g.
> USB, ethernet, MMC).

For generic code, you are right.

What about socfpga-specific code? Will this still do the right thing
with cache enabled? Do we have hardware registers mapped uncacheable?

Ok, I guess we should enable the cache and fix any bugs currently
hidden.

Best regards,
								Pavel

/* Toggle reset signal to watchdog (WDT is disabled after this
operation!) */
void socfpga_watchdog_reset(void)
{
        /* assert reset for watchdog */
	setbits_le32(&reset_manager_base->per_mod_reset,
		                     1 << RSTMGR_PERMODRST_L4WD0_LSB);

        /* deassert watchdog from reset (watchdog in not running
        state) */
	clrbits_le32(&reset_manager_base->per_mod_reset,
		                     1 << RSTMGR_PERMODRST_L4WD0_LSB);
 }
				     				     

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese]

On 18.09.2015 08:34, Pavel Machek wrote:
> Hi!
>
>>>> With this patch:
>>>> => tftp 100000 big-40mb
>>>> Speed: 1000, full duplex
>>>> Using dwmac.ff702000 device
>>>> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
>>>> Filename 'big-40mb'.
>>>> Load address: 0x100000
>>>> Loading: #################################################################
>>>>           #################################################################
>>>>           #################################################################
>>>>           #################################################################
>>>>           ##########################
>>>>           7.6 MiB/s
>>>>
>>>> A performance improvement of factor ~3.
>>>
>>> Ok, so you turn on write-back cache and it is faster.
>>
>> Its not only faster. My tests have shown, that the current implementation
>> (WRITEALLOC) does not enable the dcache at all. No performance difference
>> with dcache enable or disabled. I also tested this by removing the dcache
>> flush and invalidate calls from the ethernet driver. And tftp still worked
>> without any problems (same slow speed of course) with dcache enabled. On
>> platforms with a really enabled dcache, such a change leads to a non-working
>> network interface.
>
> Yes, so we were running with dcache disabled, which can mask _many_
> programming errors.

Of course.

>>> Now... do you have an explanation why this is safe to do? Are there
>>> cache flushes that need to be added to the code now that we turned on
>>> write-back?
>>
>> I have not found any issues yet with this patch added. The cache handling
>> calls (flush, invalidate) are already included in the code using it (e.g.
>> USB, ethernet, MMC).
>
> For generic code, you are right.
>
> What about socfpga-specific code? Will this still do the right thing
> with cache enabled? Do we have hardware registers mapped uncacheable?

Yes. Thats how it should be done for all platforms. Only for SDRAM 
dcache should be enabled. Otherwise we would run in many problems.

> Ok, I guess we should enable the cache and fix any bugs currently
> hidden.

This is also my feeling. Such problems should show pretty quickly.

Thanks,
Stefan

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:

Hi!

> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
> policy is selected. This leads to much better performance on the SoCFPGA.
> A quick network test shows this:
> 
> Without this patch:
> => tftp 100000 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################
>          2.5 MiB/s
> 
> With this patch:
> => tftp 100000 big-40mb
> Speed: 1000, full duplex
> Using dwmac.ff702000 device
> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> Filename 'big-40mb'.
> Load address: 0x100000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          ##########################
>          7.6 MiB/s
> 
> A performance improvement of factor ~3.
> 
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> Cc: Chin Liang See <clsee@altera.com>
> Cc: Pavel Machek <pavel@denx.de>
> Cc: Marek Vasut <marex@denx.de>
> ---
>  include/configs/socfpga_common.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h index 38ae763..a2811ba 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -73,7 +73,6 @@
>  /*
>   * Cache
>   */
> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
>  #define CONFIG_SYS_CACHELINE_SIZE 32
>  #define CONFIG_SYS_L2_PL310
>  #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS

I hate to say it, but I am running into issues with this patch :-(

I use a standard USB stick here and with this patch, I am getting the following
failure (with enabled and disabled cache):

=> usb reset
resetting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... unable to get descriptor, error 0
usb_new_device: Cannot read configuration, skipping device 058f:6387
1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
=> dcache off
=> usb reset 
resetting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

If I revert this patch, my USB stick works as well.

I am also aware that Stefan mentions that without this patch, cache is not 
enabled at all. On the other hand, I cannot find any obviously faulty behavior
in the dwc2 driver, it does flush_dcache_range()/invalidate_dcache_range() in
the right places.

Any ideas please ?

Best regards,
Marek Vasut

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese]

Hi Marek,

On 09.11.2015 01:10, Marek Vasut wrote:
> On Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:
>
> Hi!
>
>> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
>> policy is selected. This leads to much better performance on the SoCFPGA.
>> A quick network test shows this:
>>
>> Without this patch:
>> => tftp 100000 big-40mb
>> Speed: 1000, full duplex
>> Using dwmac.ff702000 device
>> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
>> Filename 'big-40mb'.
>> Load address: 0x100000
>> Loading: #################################################################
>>           #################################################################
>>           #################################################################
>>           #################################################################
>>           ##########################
>>           2.5 MiB/s
>>
>> With this patch:
>> => tftp 100000 big-40mb
>> Speed: 1000, full duplex
>> Using dwmac.ff702000 device
>> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
>> Filename 'big-40mb'.
>> Load address: 0x100000
>> Loading: #################################################################
>>           #################################################################
>>           #################################################################
>>           #################################################################
>>           ##########################
>>           7.6 MiB/s
>>
>> A performance improvement of factor ~3.
>>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
>> Cc: Chin Liang See <clsee@altera.com>
>> Cc: Pavel Machek <pavel@denx.de>
>> Cc: Marek Vasut <marex@denx.de>
>> ---
>>   include/configs/socfpga_common.h | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/include/configs/socfpga_common.h
>> b/include/configs/socfpga_common.h index 38ae763..a2811ba 100644
>> --- a/include/configs/socfpga_common.h
>> +++ b/include/configs/socfpga_common.h
>> @@ -73,7 +73,6 @@
>>   /*
>>    * Cache
>>    */
>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
>>   #define CONFIG_SYS_CACHELINE_SIZE 32
>>   #define CONFIG_SYS_L2_PL310
>>   #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
>
> I hate to say it, but I am running into issues with this patch :-(

I'm sorry to hear this.

> I use a standard USB stick here and with this patch, I am getting the following
> failure (with enabled and disabled cache):
>
> => usb reset
> resetting USB...
> USB0:   Core Release: 2.93a
> scanning bus 0 for devices... unable to get descriptor, error 0
> usb_new_device: Cannot read configuration, skipping device 058f:6387
> 1 USB Device(s) found
>         scanning usb for storage devices... 0 Storage Device(s) found
> => dcache off
> => usb reset
> resetting USB...
> USB0:   Core Release: 2.93a
> scanning bus 0 for devices... 2 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
>
> If I revert this patch, my USB stick works as well.
>
> I am also aware that Stefan mentions that without this patch, cache is not
> enabled at all. On the other hand, I cannot find any obviously faulty behavior
> in the dwc2 driver, it does flush_dcache_range()/invalidate_dcache_range() in
> the right places.
>
> Any ideas please ?

Perhaps its a timing related issue? As the code is executed faster
with cache enabled. Just an idea - perhaps there is still some ugly
code that doesn't do proper timer based loops / delays.

HTP.

Thanks,
Stefan

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Monday, November 09, 2015 at 12:42:24 PM, Stefan Roese wrote:
> Hi Marek,
> 
> On 09.11.2015 01:10, Marek Vasut wrote:
> > On Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:
> > 
> > Hi!
> > 
> >> By not defining CONFIG_SYS_ARM_CACHE_WRITEALLOC, the WRITEBACK cache
> >> policy is selected. This leads to much better performance on the
> >> SoCFPGA. A quick network test shows this:
> >> 
> >> Without this patch:
> >> => tftp 100000 big-40mb
> >> Speed: 1000, full duplex
> >> Using dwmac.ff702000 device
> >> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> >> Filename 'big-40mb'.
> >> Load address: 0x100000
> >> Loading:
> >> #################################################################
> >> 
> >>           ##############################################################
> >>           ###
> >>           #############################################################
> >>           ####
> >>           #############################################################
> >>           #### ##########################
> >>           2.5 MiB/s
> >> 
> >> With this patch:
> >> => tftp 100000 big-40mb
> >> Speed: 1000, full duplex
> >> Using dwmac.ff702000 device
> >> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
> >> Filename 'big-40mb'.
> >> Load address: 0x100000
> >> Loading:
> >> #################################################################
> >> 
> >>           ##############################################################
> >>           ###
> >>           #############################################################
> >>           ####
> >>           #############################################################
> >>           #### ##########################
> >>           7.6 MiB/s
> >> 
> >> A performance improvement of factor ~3.
> >> 
> >> Signed-off-by: Stefan Roese <sr@denx.de>
> >> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> >> Cc: Chin Liang See <clsee@altera.com>
> >> Cc: Pavel Machek <pavel@denx.de>
> >> Cc: Marek Vasut <marex@denx.de>
> >> ---
> >> 
> >>   include/configs/socfpga_common.h | 1 -
> >>   1 file changed, 1 deletion(-)
> >> 
> >> diff --git a/include/configs/socfpga_common.h
> >> b/include/configs/socfpga_common.h index 38ae763..a2811ba 100644
> >> --- a/include/configs/socfpga_common.h
> >> +++ b/include/configs/socfpga_common.h
> >> @@ -73,7 +73,6 @@
> >> 
> >>   /*
> >>   
> >>    * Cache
> >>    */
> >> 
> >> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> >> 
> >>   #define CONFIG_SYS_CACHELINE_SIZE 32
> >>   #define CONFIG_SYS_L2_PL310
> >>   #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
> > 
> > I hate to say it, but I am running into issues with this patch :-(
> 
> I'm sorry to hear this.
> 
> > I use a standard USB stick here and with this patch, I am getting the
> > following failure (with enabled and disabled cache):
> > 
> > => usb reset
> > resetting USB...
> > USB0:   Core Release: 2.93a
> > scanning bus 0 for devices... unable to get descriptor, error 0
> > usb_new_device: Cannot read configuration, skipping device 058f:6387
> > 1 USB Device(s) found
> > 
> >         scanning usb for storage devices... 0 Storage Device(s) found
> > 
> > => dcache off
> > => usb reset
> > resetting USB...
> > USB0:   Core Release: 2.93a
> > scanning bus 0 for devices... 2 USB Device(s) found
> > 
> >         scanning usb for storage devices... 1 Storage Device(s) found
> > 
> > If I revert this patch, my USB stick works as well.
> > 
> > I am also aware that Stefan mentions that without this patch, cache is
> > not enabled at all. On the other hand, I cannot find any obviously
> > faulty behavior in the dwc2 driver, it does
> > flush_dcache_range()/invalidate_dcache_range() in the right places.
> > 
> > Any ideas please ?
> 
> Perhaps its a timing related issue? As the code is executed faster
> with cache enabled. Just an idea - perhaps there is still some ugly
> code that doesn't do proper timer based loops / delays.

I doubt that's not the case. If I disable cache just around the hcdma bit
in the driver (disable before the flush_dcache_range() and enable after 
invalidate_dcache_range() in the driver), it still fails.

Best regards,
Marek Vasut

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese]

Hi Marek,

On 09.11.2015 14:49, Marek Vasut wrote:

<snip>

>>>> --- a/include/configs/socfpga_common.h
>>>> +++ b/include/configs/socfpga_common.h
>>>> @@ -73,7 +73,6 @@
>>>>
>>>>    /*
>>>>    
>>>>     * Cache
>>>>     */
>>>>
>>>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
>>>>
>>>>    #define CONFIG_SYS_CACHELINE_SIZE 32
>>>>    #define CONFIG_SYS_L2_PL310
>>>>    #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
>>>
>>> I hate to say it, but I am running into issues with this patch :-(
>>
>> I'm sorry to hear this.
>>
>>> I use a standard USB stick here and with this patch, I am getting the
>>> following failure (with enabled and disabled cache):
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0:   Core Release: 2.93a
>>> scanning bus 0 for devices... unable to get descriptor, error 0
>>> usb_new_device: Cannot read configuration, skipping device 058f:6387
>>> 1 USB Device(s) found
>>>
>>>          scanning usb for storage devices... 0 Storage Device(s) found
>>>
>>> => dcache off
>>> => usb reset
>>> resetting USB...
>>> USB0:   Core Release: 2.93a
>>> scanning bus 0 for devices... 2 USB Device(s) found
>>>
>>>          scanning usb for storage devices... 1 Storage Device(s) found
>>>
>>> If I revert this patch, my USB stick works as well.
>>>
>>> I am also aware that Stefan mentions that without this patch, cache is
>>> not enabled at all. On the other hand, I cannot find any obviously
>>> faulty behavior in the dwc2 driver, it does
>>> flush_dcache_range()/invalidate_dcache_range() in the right places.
>>>
>>> Any ideas please ?
>>
>> Perhaps its a timing related issue? As the code is executed faster
>> with cache enabled. Just an idea - perhaps there is still some ugly
>> code that doesn't do proper timer based loops / delays.
> 
> I doubt that's not the case. If I disable cache just around the hcdma bit
> in the driver (disable before the flush_dcache_range() and enable after
> invalidate_dcache_range() in the driver), it still fails.

Did you check if this problem is perhaps also related to Dinh's L2
cache patch:

8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in the L2

?

I just noticed, that here the L2 cache gets disabled and is not
enabled again in function v7_outer_cache_enable(). This looks a
bit suspicious.

Dinh, did you perhaps miss to re-enable the L2 cache after the
aux_ctrl register setup again?

Thanks,
Stefan

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> Hi Marek,

Hi!

> On 09.11.2015 14:49, Marek Vasut wrote:
> 
> <snip>
> 
> >>>> --- a/include/configs/socfpga_common.h
> >>>> +++ b/include/configs/socfpga_common.h
> >>>> @@ -73,7 +73,6 @@
> >>>> 
> >>>>    /*
> >>>>    
> >>>>     * Cache
> >>>>     */
> >>>> 
> >>>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> >>>> 
> >>>>    #define CONFIG_SYS_CACHELINE_SIZE 32
> >>>>    #define CONFIG_SYS_L2_PL310
> >>>>    #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
> >>> 
> >>> I hate to say it, but I am running into issues with this patch :-(
> >> 
> >> I'm sorry to hear this.
> >> 
> >>> I use a standard USB stick here and with this patch, I am getting the
> >>> following failure (with enabled and disabled cache):
> >>> 
> >>> => usb reset
> >>> resetting USB...
> >>> USB0:   Core Release: 2.93a
> >>> scanning bus 0 for devices... unable to get descriptor, error 0
> >>> usb_new_device: Cannot read configuration, skipping device 058f:6387
> >>> 1 USB Device(s) found
> >>> 
> >>>          scanning usb for storage devices... 0 Storage Device(s) found
> >>> 
> >>> => dcache off
> >>> => usb reset
> >>> resetting USB...
> >>> USB0:   Core Release: 2.93a
> >>> scanning bus 0 for devices... 2 USB Device(s) found
> >>> 
> >>>          scanning usb for storage devices... 1 Storage Device(s) found
> >>> 
> >>> If I revert this patch, my USB stick works as well.
> >>> 
> >>> I am also aware that Stefan mentions that without this patch, cache is
> >>> not enabled at all. On the other hand, I cannot find any obviously
> >>> faulty behavior in the dwc2 driver, it does
> >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> >>> 
> >>> Any ideas please ?
> >> 
> >> Perhaps its a timing related issue? As the code is executed faster
> >> with cache enabled. Just an idea - perhaps there is still some ugly
> >> code that doesn't do proper timer based loops / delays.
> > 
> > I doubt that's not the case. If I disable cache just around the hcdma bit
> > in the driver (disable before the flush_dcache_range() and enable after
> > invalidate_dcache_range() in the driver), it still fails.
> 
> Did you check if this problem is perhaps also related to Dinh's L2
> cache patch:
> 
> 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in the
> L2
> 
> ?

Yes I did, but reverting this patch had no impact.

> I just noticed, that here the L2 cache gets disabled and is not
> enabled again in function v7_outer_cache_enable(). This looks a
> bit suspicious.
> 
> Dinh, did you perhaps miss to re-enable the L2 cache after the
> aux_ctrl register setup again?

I guess we should pester Dinh now :-)

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

Hi Marek,

On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > Hi Marek,
> 
> Hi!
> 
> > On 09.11.2015 14:49, Marek Vasut wrote:
> > 
> > <snip>
> > 
> > >>>> --- a/include/configs/socfpga_common.h
> > >>>> +++ b/include/configs/socfpga_common.h
> > >>>> @@ -73,7 +73,6 @@
> > >>>> 
> > >>>>    /*
> > >>>>    
> > >>>>     * Cache
> > >>>>     */
> > >>>> 
> > >>>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > >>>> 
> > >>>>    #define CONFIG_SYS_CACHELINE_SIZE 32
> > >>>>    #define CONFIG_SYS_L2_PL310
> > >>>>    #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
> > >>> 
> > >>> I hate to say it, but I am running into issues with this patch :-(
> > >> 
> > >> I'm sorry to hear this.
> > >> 
> > >>> I use a standard USB stick here and with this patch, I am getting the
> > >>> following failure (with enabled and disabled cache):
> > >>> 
> > >>> => usb reset
> > >>> resetting USB...
> > >>> USB0:   Core Release: 2.93a
> > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > >>> usb_new_device: Cannot read configuration, skipping device 058f:6387
> > >>> 1 USB Device(s) found
> > >>> 
> > >>>          scanning usb for storage devices... 0 Storage Device(s) found
> > >>> 
> > >>> => dcache off
> > >>> => usb reset
> > >>> resetting USB...
> > >>> USB0:   Core Release: 2.93a
> > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > >>> 
> > >>>          scanning usb for storage devices... 1 Storage Device(s) found
> > >>> 
> > >>> If I revert this patch, my USB stick works as well.
> > >>> 
> > >>> I am also aware that Stefan mentions that without this patch, cache is
> > >>> not enabled at all. On the other hand, I cannot find any obviously
> > >>> faulty behavior in the dwc2 driver, it does
> > >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> > >>> 
> > >>> Any ideas please ?
> > >> 
> > >> Perhaps its a timing related issue? As the code is executed faster
> > >> with cache enabled. Just an idea - perhaps there is still some ugly
> > >> code that doesn't do proper timer based loops / delays.
> > > 
> > > I doubt that's not the case. If I disable cache just around the hcdma bit
> > > in the driver (disable before the flush_dcache_range() and enable after
> > > invalidate_dcache_range() in the driver), it still fails.
> > 
> > Did you check if this problem is perhaps also related to Dinh's L2
> > cache patch:
> > 
> > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in the
> > L2
> > 
> > ?
> 
> Yes I did, but reverting this patch had no impact.
> 
> > I just noticed, that here the L2 cache gets disabled and is not
> > enabled again in function v7_outer_cache_enable(). This looks a
> > bit suspicious.
> > 
> > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > aux_ctrl register setup again?
> 
> I guess we should pester Dinh now :-)


I recompiled the latest source and it works for me.
Here is the printout message.
Wonder any modification against commit a55f28624e97e1e43ac?


U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)

CPU:   Altera SoCFPGA Platform
FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT:  SD/MMC External Transceiver (1.8V)
       Watchdog enabled
I2C:   ready
DRAM:  1 GiB
MMC:   SOCFPGA DWMMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Altera SOCFPGA Cyclone V SoC Development Kit
Net:
Error: ethernet at ff702000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0
=> dcache
Data (writethrough) Cache is ON
=> icache
Instruction Cache is ON
=> usb start
starting USB...
USB0:   Core Release: 2.93a
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub,  USB Revision 1.10
 -  U-Boot Root Hub
 - Class: Hub
 - PacketSize: 8  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 0.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms

2: Mass Storage,  USB Revision 2.0
 - SanDisk  SDDR-113 000000009412
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0781  Product 0xa7c1 Version 148.18
   Configuration: 1
   - Interfaces: 1 Bus Powered 500mA
     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

=> fatls usb 0
            nfs/
  5099520   rootfs.tar
   119858   pcie-altera.ko
            gen3/
            gen2/
   173733   altera_rpde.ko
   173214   altera_epde.ko
    12196   dmaxfer
  4091760   zimage,ok
     2961   0002-nios2-add-max10-defconfig.patch
     6963   0001-nios2-add-max10-device-tree.patch
    59026   iperf-arm
  7268512   uimage
   139681   endpoint.ko
  3501880   zimage
    25278   socfpga_arria10_socdk.dtb.good
    25302   socfpga_arria10_socdk.dtb
            125mhz gen2 x8 stp/
   344480   ghrd_10as066n2.periph.rbf
 14684880   ghrd_10as066n2.core.rbf

16 file(s), 4 dir(s)

=>

Thanks
Chin Liang

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See wrote:
> Hi Marek,
> 
> On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > > Hi Marek,
> > 
> > Hi!
> > 
> > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > 
> > > <snip>
> > > 
> > > >>>> --- a/include/configs/socfpga_common.h
> > > >>>> +++ b/include/configs/socfpga_common.h
> > > >>>> @@ -73,7 +73,6 @@
> > > >>>> 
> > > >>>>    /*
> > > >>>>    
> > > >>>>     * Cache
> > > >>>>     */
> > > >>>> 
> > > >>>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > > >>>> 
> > > >>>>    #define CONFIG_SYS_CACHELINE_SIZE 32
> > > >>>>    #define CONFIG_SYS_L2_PL310
> > > >>>>    #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
> > > >>> 
> > > >>> I hate to say it, but I am running into issues with this patch :-(
> > > >> 
> > > >> I'm sorry to hear this.
> > > >> 
> > > >>> I use a standard USB stick here and with this patch, I am getting
> > > >>> the following failure (with enabled and disabled cache):
> > > >>> 
> > > >>> => usb reset
> > > >>> resetting USB...
> > > >>> USB0:   Core Release: 2.93a
> > > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > > >>> usb_new_device: Cannot read configuration, skipping device
> > > >>> 058f:6387 1 USB Device(s) found
> > > >>> 
> > > >>>          scanning usb for storage devices... 0 Storage Device(s)
> > > >>>          found
> > > >>> 
> > > >>> => dcache off
> > > >>> => usb reset
> > > >>> resetting USB...
> > > >>> USB0:   Core Release: 2.93a
> > > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > > >>> 
> > > >>>          scanning usb for storage devices... 1 Storage Device(s)
> > > >>>          found
> > > >>> 
> > > >>> If I revert this patch, my USB stick works as well.
> > > >>> 
> > > >>> I am also aware that Stefan mentions that without this patch, cache
> > > >>> is not enabled at all. On the other hand, I cannot find any
> > > >>> obviously faulty behavior in the dwc2 driver, it does
> > > >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> > > >>> 
> > > >>> Any ideas please ?
> > > >> 
> > > >> Perhaps its a timing related issue? As the code is executed faster
> > > >> with cache enabled. Just an idea - perhaps there is still some ugly
> > > >> code that doesn't do proper timer based loops / delays.
> > > > 
> > > > I doubt that's not the case. If I disable cache just around the hcdma
> > > > bit in the driver (disable before the flush_dcache_range() and
> > > > enable after invalidate_dcache_range() in the driver), it still
> > > > fails.
> > > 
> > > Did you check if this problem is perhaps also related to Dinh's L2
> > > cache patch:
> > > 
> > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in
> > > the L2
> > > 
> > > ?
> > 
> > Yes I did, but reverting this patch had no impact.
> > 
> > > I just noticed, that here the L2 cache gets disabled and is not
> > > enabled again in function v7_outer_cache_enable(). This looks a
> > > bit suspicious.
> > > 
> > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > aux_ctrl register setup again?
> > 
> > I guess we should pester Dinh now :-)
> 
> I recompiled the latest source and it works for me.
> Here is the printout message.
> Wonder any modification against commit a55f28624e97e1e43ac?
> 
> 
> U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> 
> CPU:   Altera SoCFPGA Platform
> FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> BOOT:  SD/MMC External Transceiver (1.8V)
>        Watchdog enabled
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SOCFPGA DWMMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Model: Altera SOCFPGA Cyclone V SoC Development Kit
> Net:
> Error: ethernet at ff702000 address not set.
> No ethernet found.
> Hit any key to stop autoboot:  0
> => dcache
> Data (writethrough) Cache is ON
> => icache
> Instruction Cache is ON
> => usb start
> starting USB...
> USB0:   Core Release: 2.93a
> scanning bus 0 for devices... 2 USB Device(s) found
>        scanning usb for storage devices... 1 Storage Device(s) found
> => usb info
> 1: Hub,  USB Revision 1.10
>  -  U-Boot Root Hub
>  - Class: Hub
>  - PacketSize: 8  Configurations: 1
>  - Vendor: 0x0000  Product 0x0000 Version 0.0
>    Configuration: 1
>    - Interfaces: 1 Self Powered 0mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> 
> 2: Mass Storage,  USB Revision 2.0
>  - SanDisk  SDDR-113 000000009412
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
>    Configuration: 1
>    - Interfaces: 1 Bus Powered 500mA
>      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

Yeah, that's because you're using high-quality USB sticks which leave skid marks 
on the USB port. Now try with some dirt cheap USB 2.0 stick.

058f:6387 Alcor Micro Corp. Flash Drive

The thing above is my absolute fav when it comes to testing corner cases:
http://www.intenso.de/produkte.php?kategorie=23&&produkt=1255723475

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Thu, 2015-11-12 at 01:53 +0100, Marek Vasut wrote:
> On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See wrote:
> > Hi Marek,
> > 
> > On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > > > Hi Marek,
> > > 
> > > Hi!
> > > 
> > > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > > 
> > > > <snip>
> > > > 
> > > > >>>> --- a/include/configs/socfpga_common.h
> > > > >>>> +++ b/include/configs/socfpga_common.h
> > > > >>>> @@ -73,7 +73,6 @@
> > > > >>>> 
> > > > >>>>    /*
> > > > >>>>    
> > > > >>>>     * Cache
> > > > >>>>     */
> > > > >>>> 
> > > > >>>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > > > >>>> 
> > > > >>>>    #define CONFIG_SYS_CACHELINE_SIZE 32
> > > > >>>>    #define CONFIG_SYS_L2_PL310
> > > > >>>>    #define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
> > > > >>> 
> > > > >>> I hate to say it, but I am running into issues with this patch :-(
> > > > >> 
> > > > >> I'm sorry to hear this.
> > > > >> 
> > > > >>> I use a standard USB stick here and with this patch, I am getting
> > > > >>> the following failure (with enabled and disabled cache):
> > > > >>> 
> > > > >>> => usb reset
> > > > >>> resetting USB...
> > > > >>> USB0:   Core Release: 2.93a
> > > > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > > > >>> usb_new_device: Cannot read configuration, skipping device
> > > > >>> 058f:6387 1 USB Device(s) found
> > > > >>> 
> > > > >>>          scanning usb for storage devices... 0 Storage Device(s)
> > > > >>>          found
> > > > >>> 
> > > > >>> => dcache off
> > > > >>> => usb reset
> > > > >>> resetting USB...
> > > > >>> USB0:   Core Release: 2.93a
> > > > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > > > >>> 
> > > > >>>          scanning usb for storage devices... 1 Storage Device(s)
> > > > >>>          found
> > > > >>> 
> > > > >>> If I revert this patch, my USB stick works as well.
> > > > >>> 
> > > > >>> I am also aware that Stefan mentions that without this patch, cache
> > > > >>> is not enabled at all. On the other hand, I cannot find any
> > > > >>> obviously faulty behavior in the dwc2 driver, it does
> > > > >>> flush_dcache_range()/invalidate_dcache_range() in the right places.
> > > > >>> 
> > > > >>> Any ideas please ?
> > > > >> 
> > > > >> Perhaps its a timing related issue? As the code is executed faster
> > > > >> with cache enabled. Just an idea - perhaps there is still some ugly
> > > > >> code that doesn't do proper timer based loops / delays.
> > > > > 
> > > > > I doubt that's not the case. If I disable cache just around the hcdma
> > > > > bit in the driver (disable before the flush_dcache_range() and
> > > > > enable after invalidate_dcache_range() in the driver), it still
> > > > > fails.
> > > > 
> > > > Did you check if this problem is perhaps also related to Dinh's L2
> > > > cache patch:
> > > > 
> > > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared override in
> > > > the L2
> > > > 
> > > > ?
> > > 
> > > Yes I did, but reverting this patch had no impact.
> > > 
> > > > I just noticed, that here the L2 cache gets disabled and is not
> > > > enabled again in function v7_outer_cache_enable(). This looks a
> > > > bit suspicious.
> > > > 
> > > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > > aux_ctrl register setup again?
> > > 
> > > I guess we should pester Dinh now :-)
> > 
> > I recompiled the latest source and it works for me.
> > Here is the printout message.
> > Wonder any modification against commit a55f28624e97e1e43ac?
> > 
> > 
> > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > 
> > CPU:   Altera SoCFPGA Platform
> > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > BOOT:  SD/MMC External Transceiver (1.8V)
> >        Watchdog enabled
> > I2C:   ready
> > DRAM:  1 GiB
> > MMC:   SOCFPGA DWMMC: 0
> > *** Warning - bad CRC, using default environment
> > 
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Model: Altera SOCFPGA Cyclone V SoC Development Kit
> > Net:
> > Error: ethernet at ff702000 address not set.
> > No ethernet found.
> > Hit any key to stop autoboot:  0
> > => dcache
> > Data (writethrough) Cache is ON
> > => icache
> > Instruction Cache is ON
> > => usb start
> > starting USB...
> > USB0:   Core Release: 2.93a
> > scanning bus 0 for devices... 2 USB Device(s) found
> >        scanning usb for storage devices... 1 Storage Device(s) found
> > => usb info
> > 1: Hub,  USB Revision 1.10
> >  -  U-Boot Root Hub
> >  - Class: Hub
> >  - PacketSize: 8  Configurations: 1
> >  - Vendor: 0x0000  Product 0x0000 Version 0.0
> >    Configuration: 1
> >    - Interfaces: 1 Self Powered 0mA
> >      Interface: 0
> >      - Alternate Setting 0, Endpoints: 1
> >      - Class Hub
> >      - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> > 
> > 2: Mass Storage,  USB Revision 2.0
> >  - SanDisk  SDDR-113 000000009412
> >  - Class: (from Interface) Mass Storage
> >  - PacketSize: 64  Configurations: 1
> >  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
> >    Configuration: 1
> >    - Interfaces: 1 Bus Powered 500mA
> >      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
> 
> Yeah, that's because you're using high-quality USB sticks which leave skid marks 
> on the USB port. Now try with some dirt cheap USB 2.0 stick.
> 
> 058f:6387 Alcor Micro Corp. Flash Drive
> 
> The thing above is my absolute fav when it comes to testing corner cases:
> http://www.intenso.de/produkte.php?kategorie=23&&produkt=1255723475


It takes some amount of time for digging out a USB 2.0 stick :)
But it still work for me as below.
Let me check out the code and see any clue.


2: Mass Storage,  USB Revision 2.0
 -          USB DISK 2.0     0781076602A6
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x13fe  Product 0x1e00 Version 1.16
   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


Thanks
Chin Liang

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, November 12, 2015 at 03:33:42 AM, Chin Liang See wrote:

[...]

> > > > > I just noticed, that here the L2 cache gets disabled and is not
> > > > > enabled again in function v7_outer_cache_enable(). This looks a
> > > > > bit suspicious.
> > > > > 
> > > > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > > > aux_ctrl register setup again?
> > > > 
> > > > I guess we should pester Dinh now :-)
> > > 
> > > I recompiled the latest source and it works for me.
> > > Here is the printout message.
> > > Wonder any modification against commit a55f28624e97e1e43ac?
> > > 
> > > 
> > > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > > 
> > > CPU:   Altera SoCFPGA Platform
> > > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > > BOOT:  SD/MMC External Transceiver (1.8V)
> > > 
> > >        Watchdog enabled
> > > 
> > > I2C:   ready
> > > DRAM:  1 GiB
> > > MMC:   SOCFPGA DWMMC: 0
> > > *** Warning - bad CRC, using default environment
> > > 
> > > In:    serial
> > > Out:   serial
> > > Err:   serial
> > > Model: Altera SOCFPGA Cyclone V SoC Development Kit
> > > Net:
> > > Error: ethernet at ff702000 address not set.
> > > No ethernet found.
> > > Hit any key to stop autoboot:  0
> > > => dcache
> > > Data (writethrough) Cache is ON
> > > => icache
> > > Instruction Cache is ON
> > > => usb start
> > > starting USB...
> > > USB0:   Core Release: 2.93a
> > > scanning bus 0 for devices... 2 USB Device(s) found
> > > 
> > >        scanning usb for storage devices... 1 Storage Device(s) found
> > > 
> > > => usb info
> > > 1: Hub,  USB Revision 1.10
> > > 
> > >  -  U-Boot Root Hub
> > >  - Class: Hub
> > >  - PacketSize: 8  Configurations: 1
> > >  - Vendor: 0x0000  Product 0x0000 Version 0.0
> > >  
> > >    Configuration: 1
> > >    - Interfaces: 1 Self Powered 0mA
> > >    
> > >      Interface: 0
> > >      - Alternate Setting 0, Endpoints: 1
> > >      - Class Hub
> > >      - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> > > 
> > > 2: Mass Storage,  USB Revision 2.0
> > > 
> > >  - SanDisk  SDDR-113 000000009412
> > >  - Class: (from Interface) Mass Storage
> > >  - PacketSize: 64  Configurations: 1
> > >  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
> > >  
> > >    Configuration: 1
> > >    - Interfaces: 1 Bus Powered 500mA
> > >    
> > >      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
> > 
> > Yeah, that's because you're using high-quality USB sticks which leave
> > skid marks on the USB port. Now try with some dirt cheap USB 2.0 stick.
> > 
> > 058f:6387 Alcor Micro Corp. Flash Drive
> > 
> > The thing above is my absolute fav when it comes to testing corner cases:
> > http://www.intenso.de/produkte.php?kategorie=23&&produkt=1255723475

Hi!

> It takes some amount of time for digging out a USB 2.0 stick :)

Well sorry about living in a developing country ;-)

> But it still work for me as below.
> Let me check out the code and see any clue.
> 
> 
> 2: Mass Storage,  USB Revision 2.0
>  -          USB DISK 2.0     0781076602A6
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x13fe  Product 0x1e00 Version 1.16
>    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

Fascinating. Could it be that it's only these really crappy USB sticks which
trigger some odd condition in the controller ? I will dig out the trusty SoCDK
and check it there this week.

btw. these Alcor sticks work for me in Linux 3.18.x, but seems like that's not 
always the case:
http://comments.gmane.org/gmane.linux.usb.general/86117

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, November 12, 2015 at 03:33:42 AM, Chin Liang See wrote:
> On Thu, 2015-11-12 at 01:53 +0100, Marek Vasut wrote:
> > On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See wrote:
> > > Hi Marek,
> > > 
> > > On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > > > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese wrote:
> > > > > Hi Marek,
> > > > 
> > > > Hi!
> > > > 
> > > > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > > > 
> > > > > <snip>
> > > > > 
> > > > > >>>> --- a/include/configs/socfpga_common.h
> > > > > >>>> +++ b/include/configs/socfpga_common.h
> > > > > >>>> @@ -73,7 +73,6 @@
> > > > > >>>> 
> > > > > >>>>    /*
> > > > > >>>>    
> > > > > >>>>     * Cache
> > > > > >>>>     */
> > > > > >>>> 
> > > > > >>>> -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > > > > >>>> 
> > > > > >>>>    #define CONFIG_SYS_CACHELINE_SIZE 32
> > > > > >>>>    #define CONFIG_SYS_L2_PL310
> > > > > >>>>    #define CONFIG_SYS_PL310_BASE		
SOCFPGA_MPUL2_ADDRESS
> > > > > >>> 
> > > > > >>> I hate to say it, but I am running into issues with this patch
> > > > > >>> :-(
> > > > > >> 
> > > > > >> I'm sorry to hear this.
> > > > > >> 
> > > > > >>> I use a standard USB stick here and with this patch, I am
> > > > > >>> getting the following failure (with enabled and disabled
> > > > > >>> cache):
> > > > > >>> 
> > > > > >>> => usb reset
> > > > > >>> resetting USB...
> > > > > >>> USB0:   Core Release: 2.93a
> > > > > >>> scanning bus 0 for devices... unable to get descriptor, error 0
> > > > > >>> usb_new_device: Cannot read configuration, skipping device
> > > > > >>> 058f:6387 1 USB Device(s) found
> > > > > >>> 
> > > > > >>>          scanning usb for storage devices... 0 Storage
> > > > > >>>          Device(s) found
> > > > > >>> 
> > > > > >>> => dcache off
> > > > > >>> => usb reset
> > > > > >>> resetting USB...
> > > > > >>> USB0:   Core Release: 2.93a
> > > > > >>> scanning bus 0 for devices... 2 USB Device(s) found
> > > > > >>> 
> > > > > >>>          scanning usb for storage devices... 1 Storage
> > > > > >>>          Device(s) found
> > > > > >>> 
> > > > > >>> If I revert this patch, my USB stick works as well.
> > > > > >>> 
> > > > > >>> I am also aware that Stefan mentions that without this patch,
> > > > > >>> cache is not enabled at all. On the other hand, I cannot find
> > > > > >>> any obviously faulty behavior in the dwc2 driver, it does
> > > > > >>> flush_dcache_range()/invalidate_dcache_range() in the right
> > > > > >>> places.
> > > > > >>> 
> > > > > >>> Any ideas please ?
> > > > > >> 
> > > > > >> Perhaps its a timing related issue? As the code is executed
> > > > > >> faster with cache enabled. Just an idea - perhaps there is
> > > > > >> still some ugly code that doesn't do proper timer based loops /
> > > > > >> delays.
> > > > > > 
> > > > > > I doubt that's not the case. If I disable cache just around the
> > > > > > hcdma bit in the driver (disable before the flush_dcache_range()
> > > > > > and enable after invalidate_dcache_range() in the driver), it
> > > > > > still fails.
> > > > > 
> > > > > Did you check if this problem is perhaps also related to Dinh's L2
> > > > > cache patch:
> > > > > 
> > > > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared
> > > > > override in the L2
> > > > > 
> > > > > ?
> > > > 
> > > > Yes I did, but reverting this patch had no impact.
> > > > 
> > > > > I just noticed, that here the L2 cache gets disabled and is not
> > > > > enabled again in function v7_outer_cache_enable(). This looks a
> > > > > bit suspicious.
> > > > > 
> > > > > Dinh, did you perhaps miss to re-enable the L2 cache after the
> > > > > aux_ctrl register setup again?
> > > > 
> > > > I guess we should pester Dinh now :-)
> > > 
> > > I recompiled the latest source and it works for me.
> > > Here is the printout message.
> > > Wonder any modification against commit a55f28624e97e1e43ac?
> > > 
> > > 
> > > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > > 
> > > CPU:   Altera SoCFPGA Platform
> > > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > > BOOT:  SD/MMC External Transceiver (1.8V)
> > > 
> > >        Watchdog enabled
> > > 
> > > I2C:   ready
> > > DRAM:  1 GiB
> > > MMC:   SOCFPGA DWMMC: 0
> > > *** Warning - bad CRC, using default environment
> > > 
> > > In:    serial
> > > Out:   serial
> > > Err:   serial
> > > Model: Altera SOCFPGA Cyclone V SoC Development Kit
> > > Net:
> > > Error: ethernet at ff702000 address not set.
> > > No ethernet found.
> > > Hit any key to stop autoboot:  0
> > > => dcache
> > > Data (writethrough) Cache is ON
> > > => icache
> > > Instruction Cache is ON
> > > => usb start
> > > starting USB...
> > > USB0:   Core Release: 2.93a
> > > scanning bus 0 for devices... 2 USB Device(s) found
> > > 
> > >        scanning usb for storage devices... 1 Storage Device(s) found
> > > 
> > > => usb info
> > > 1: Hub,  USB Revision 1.10
> > > 
> > >  -  U-Boot Root Hub
> > >  - Class: Hub
> > >  - PacketSize: 8  Configurations: 1
> > >  - Vendor: 0x0000  Product 0x0000 Version 0.0
> > >  
> > >    Configuration: 1
> > >    - Interfaces: 1 Self Powered 0mA
> > >    
> > >      Interface: 0
> > >      - Alternate Setting 0, Endpoints: 1
> > >      - Class Hub
> > >      - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> > > 
> > > 2: Mass Storage,  USB Revision 2.0
> > > 
> > >  - SanDisk  SDDR-113 000000009412
> > >  - Class: (from Interface) Mass Storage
> > >  - PacketSize: 64  Configurations: 1
> > >  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
> > >  
> > >    Configuration: 1
> > >    - Interfaces: 1 Bus Powered 500mA
> > >    
> > >      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
> > 
> > Yeah, that's because you're using high-quality USB sticks which leave
> > skid marks on the USB port. Now try with some dirt cheap USB 2.0 stick.
> > 
> > 058f:6387 Alcor Micro Corp. Flash Drive
> > 
> > The thing above is my absolute fav when it comes to testing corner cases:
> > http://www.intenso.de/produkte.php?kategorie=23&&produkt=1255723475
> 
> It takes some amount of time for digging out a USB 2.0 stick :)
> But it still work for me as below.
> Let me check out the code and see any clue.
> 
> 
> 2: Mass Storage,  USB Revision 2.0
>  -          USB DISK 2.0     0781076602A6
>  - Class: (from Interface) Mass Storage
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x13fe  Product 0x1e00 Version 1.16
>    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

I have another board where I cannot use UBI on QSPI NOR and reverting this
patch magically fixes things.

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Thu, 2015-12-03 at 01:10 +0100, Marek Vasut wrote:
> On Thursday, November 12, 2015 at 03:33:42 AM, Chin Liang See wrote:
> > On Thu, 2015-11-12 at 01:53 +0100, Marek Vasut wrote:
> > > On Thursday, November 12, 2015 at 01:49:09 AM, Chin Liang See
> > > wrote:
> > > > Hi Marek,
> > > > 
> > > > On Mon, 2015-11-09 at 17:02 +0100, Marek Vasut wrote:
> > > > > On Monday, November 09, 2015 at 04:46:54 PM, Stefan Roese
> > > > > wrote:
> > > > > > Hi Marek,
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > > On 09.11.2015 14:49, Marek Vasut wrote:
> > > > > > 
> > > > > > <snip>
> > > > > > 
> > > > > > > > > > --- a/include/configs/socfpga_common.h
> > > > > > > > > > +++ b/include/configs/socfpga_common.h
> > > > > > > > > > @@ -73,7 +73,6 @@
> > > > > > > > > > 
> > > > > > > > > >    /*
> > > > > > > > > >    
> > > > > > > > > >     * Cache
> > > > > > > > > >     */
> > > > > > > > > > 
> > > > > > > > > > -#define CONFIG_SYS_ARM_CACHE_WRITEALLOC
> > > > > > > > > > 
> > > > > > > > > >    #define CONFIG_SYS_CACHELINE_SIZE 32
> > > > > > > > > >    #define CONFIG_SYS_L2_PL310
> > > > > > > > > >    #define CONFIG_SYS_PL310_BASE		
> SOCFPGA_MPUL2_ADDRESS
> > > > > > > > > 
> > > > > > > > > I hate to say it, but I am running into issues with
> > > > > > > > > this patch
> > > > > > > > > :-(
> > > > > > > > 
> > > > > > > > I'm sorry to hear this.
> > > > > > > > 
> > > > > > > > > I use a standard USB stick here and with this patch,
> > > > > > > > > I am
> > > > > > > > > getting the following failure (with enabled and
> > > > > > > > > disabled
> > > > > > > > > cache):
> > > > > > > > > 
> > > > > > > > > => usb reset
> > > > > > > > > resetting USB...
> > > > > > > > > USB0:   Core Release: 2.93a
> > > > > > > > > scanning bus 0 for devices... unable to get
> > > > > > > > > descriptor, error 0
> > > > > > > > > usb_new_device: Cannot read configuration, skipping
> > > > > > > > > device
> > > > > > > > > 058f:6387 1 USB Device(s) found
> > > > > > > > > 
> > > > > > > > >          scanning usb for storage devices... 0
> > > > > > > > > Storage
> > > > > > > > >          Device(s) found
> > > > > > > > > 
> > > > > > > > > => dcache off
> > > > > > > > > => usb reset
> > > > > > > > > resetting USB...
> > > > > > > > > USB0:   Core Release: 2.93a
> > > > > > > > > scanning bus 0 for devices... 2 USB Device(s) found
> > > > > > > > > 
> > > > > > > > >          scanning usb for storage devices... 1
> > > > > > > > > Storage
> > > > > > > > >          Device(s) found
> > > > > > > > > 
> > > > > > > > > If I revert this patch, my USB stick works as well.
> > > > > > > > > 
> > > > > > > > > I am also aware that Stefan mentions that without
> > > > > > > > > this patch,
> > > > > > > > > cache is not enabled at all. On the other hand, I
> > > > > > > > > cannot find
> > > > > > > > > any obviously faulty behavior in the dwc2 driver, it
> > > > > > > > > does
> > > > > > > > > flush_dcache_range()/invalidate_dcache_range() in the
> > > > > > > > > right
> > > > > > > > > places.
> > > > > > > > > 
> > > > > > > > > Any ideas please ?
> > > > > > > > 
> > > > > > > > Perhaps its a timing related issue? As the code is
> > > > > > > > executed
> > > > > > > > faster with cache enabled. Just an idea - perhaps there
> > > > > > > > is
> > > > > > > > still some ugly code that doesn't do proper timer based
> > > > > > > > loops /
> > > > > > > > delays.
> > > > > > > 
> > > > > > > I doubt that's not the case. If I disable cache just
> > > > > > > around the
> > > > > > > hcdma bit in the driver (disable before the
> > > > > > > flush_dcache_range()
> > > > > > > and enable after invalidate_dcache_range() in the
> > > > > > > driver), it
> > > > > > > still fails.
> > > > > > 
> > > > > > Did you check if this problem is perhaps also related to
> > > > > > Dinh's L2
> > > > > > cache patch:
> > > > > > 
> > > > > > 8d8e13e1 arm: socfpga: enable data/inst prefetch and shared
> > > > > > override in the L2
> > > > > > 
> > > > > > ?
> > > > > 
> > > > > Yes I did, but reverting this patch had no impact.
> > > > > 
> > > > > > I just noticed, that here the L2 cache gets disabled and is
> > > > > > not
> > > > > > enabled again in function v7_outer_cache_enable(). This
> > > > > > looks a
> > > > > > bit suspicious.
> > > > > > 
> > > > > > Dinh, did you perhaps miss to re-enable the L2 cache after
> > > > > > the
> > > > > > aux_ctrl register setup again?
> > > > > 
> > > > > I guess we should pester Dinh now :-)
> > > > 
> > > > I recompiled the latest source and it works for me.
> > > > Here is the printout message.
> > > > Wonder any modification against commit a55f28624e97e1e43ac?
> > > > 
> > > > 
> > > > U-Boot 2015.10-08073-ga55f286 (Nov 11 2015 - 23:19:06 +0800)
> > > > 
> > > > CPU:   Altera SoCFPGA Platform
> > > > FPGA:  Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
> > > > BOOT:  SD/MMC External Transceiver (1.8V)
> > > > 
> > > >        Watchdog enabled
> > > > 
> > > > I2C:   ready
> > > > DRAM:  1 GiB
> > > > MMC:   SOCFPGA DWMMC: 0
> > > > *** Warning - bad CRC, using default environment
> > > > 
> > > > In:    serial
> > > > Out:   serial
> > > > Err:   serial
> > > > Model: Altera SOCFPGA Cyclone V SoC Development Kit
> > > > Net:
> > > > Error: ethernet at ff702000 address not set.
> > > > No ethernet found.
> > > > Hit any key to stop autoboot:  0
> > > > => dcache
> > > > Data (writethrough) Cache is ON
> > > > => icache
> > > > Instruction Cache is ON
> > > > => usb start
> > > > starting USB...
> > > > USB0:   Core Release: 2.93a
> > > > scanning bus 0 for devices... 2 USB Device(s) found
> > > > 
> > > >        scanning usb for storage devices... 1 Storage Device(s)
> > > > found
> > > > 
> > > > => usb info
> > > > 1: Hub,  USB Revision 1.10
> > > > 
> > > >  -  U-Boot Root Hub
> > > >  - Class: Hub
> > > >  - PacketSize: 8  Configurations: 1
> > > >  - Vendor: 0x0000  Product 0x0000 Version 0.0
> > > >  
> > > >    Configuration: 1
> > > >    - Interfaces: 1 Self Powered 0mA
> > > >    
> > > >      Interface: 0
> > > >      - Alternate Setting 0, Endpoints: 1
> > > >      - Class Hub
> > > >      - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms
> > > > 
> > > > 2: Mass Storage,  USB Revision 2.0
> > > > 
> > > >  - SanDisk  SDDR-113 000000009412
> > > >  - Class: (from Interface) Mass Storage
> > > >  - PacketSize: 64  Configurations: 1
> > > >  - Vendor: 0x0781  Product 0xa7c1 Version 148.18
> > > >  
> > > >    Configuration: 1
> > > >    - Interfaces: 1 Bus Powered 500mA
> > > >    
> > > >      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
> > > 
> > > Yeah, that's because you're using high-quality USB sticks which
> > > leave
> > > skid marks on the USB port. Now try with some dirt cheap USB 2.0
> > > stick.
> > > 
> > > 058f:6387 Alcor Micro Corp. Flash Drive
> > > 
> > > The thing above is my absolute fav when it comes to testing
> > > corner cases:
> > > http://www.intenso.de/produkte.php?kategorie=23&&produkt=12557234
> > > 75
> > 
> > It takes some amount of time for digging out a USB 2.0 stick :)
> > But it still work for me as below.
> > Let me check out the code and see any clue.
> > 
> > 
> > 2: Mass Storage,  USB Revision 2.0
> >  -          USB DISK 2.0     0781076602A6
> >  - Class: (from Interface) Mass Storage
> >  - PacketSize: 64  Configurations: 1
> >  - Vendor: 0x13fe  Product 0x1e00 Version 1.16
> >    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
> 
> I have another board where I cannot use UBI on QSPI NOR and reverting
> this
> patch magically fixes things.


I was testing this too as enabling the UBIFS on NOR and here are my
output. Wonder how to simulate your errors as I can help to take a
look?


=> icache
Instruction Cache is ON
=> dcache
Data (writethrough) Cache is ON
=> sf probe
SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
64 MiB
=> mtdparts default
=> mtdparts
 
device nor0 <ff705000.spi>, # parts = 4
#: name                size            offset          mask_flags
0: u-boot              0x00100000      0x00000000      0
1: uboot-env           0x00010000      0x00100000      0
2: rootfs              0x01000000      0x00110000      0
3: UBI                 0x02ef0000      0x01110000      0
 
active partition: nor0,0 - (u-boot) 0x00100000 @ 0x00000000
 
defaults:
mtdids  : nor0=ff705000.spi
mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot-env),16m(rootfs),
-(UBI)
=> sf erase u-boot 100000
SF: 1048576 bytes @ 0x0 Erased: OK
=> ubi part u-boot
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: empty MTD device detected
ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
ubi0: VID header offset: 64 (aligned 64), data offset: 128
ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence
number: 0
ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs reserved for
bad PEB handling: 0
=> ubi createvol testvol c0000
Creating dynamic volume testvol of size 786432
=> ubi write 0 testvol 100
256 bytes written to volume testvol
=> ubi read 200 testvol 100
Read 256 bytes from volume testvol to 200
=> cmp.b 0 200 100
Total of 256 byte(s) were the same
=> ubifsmount testvol
Error reading superblock on volume 'testvol' errno=-22!
ubifsmount - mount UBIFS volume
 
Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume
=> ubifsmount ubi0:testvol
Error reading superblock on volume 'ubi0:testvol' errno=-22!
ubifsmount - mount UBIFS volume
 
Usage:
ubifsmount <volume-name>
    - mount 'volume-name' volume


In the mean time, I was not able to get ubifsmount works. Appreciate
for any quick advise? Else will look into the code tomorrow as my bed
is calling me :)

Thanks
Chin Liang

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:

[...]

> > I have another board where I cannot use UBI on QSPI NOR and reverting
> > this
> > patch magically fixes things.
> 
> I was testing this too as enabling the UBIFS on NOR and here are my
> output. Wonder how to simulate your errors as I can help to take a
> look?
> 
> 
> => icache
> Instruction Cache is ON
> => dcache
> Data (writethrough) Cache is ON
> => sf probe
> SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB, total
> 64 MiB
> => mtdparts default
> => mtdparts
> 
> device nor0 <ff705000.spi>, # parts = 4
> #: name                size            offset          mask_flags
> 0: u-boot              0x00100000      0x00000000      0
> 1: uboot-env           0x00010000      0x00100000      0
> 2: rootfs              0x01000000      0x00110000      0
> 3: UBI                 0x02ef0000      0x01110000      0
> 
> active partition: nor0,0 - (u-boot) 0x00100000 @ 0x00000000
> 
> defaults:
> mtdids  : nor0=ff705000.spi
> mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot-env),16m(rootfs),
> -(UBI)
> => sf erase u-boot 100000
> SF: 1048576 bytes @ 0x0 Erased: OK
> => ubi part u-boot
> ubi0: attaching mtd1
> ubi0: scanning is finished
> ubi0: empty MTD device detected
> ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
> ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
> ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
> ubi0: VID header offset: 64 (aligned 64), data offset: 128
> ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
> ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23
> ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence
> number: 0
> ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs reserved for
> bad PEB handling: 0
> => ubi createvol testvol c0000
> Creating dynamic volume testvol of size 786432
> => ubi write 0 testvol 100
> 256 bytes written to volume testvol
> => ubi read 200 testvol 100
> Read 256 bytes from volume testvol to 200
> => cmp.b 0 200 100
> Total of 256 byte(s) were the same
> => ubifsmount testvol
> Error reading superblock on volume 'testvol' errno=-22!
> ubifsmount - mount UBIFS volume
> 
> Usage:
> ubifsmount <volume-name>
>     - mount 'volume-name' volume
> => ubifsmount ubi0:testvol
> Error reading superblock on volume 'ubi0:testvol' errno=-22!
> ubifsmount - mount UBIFS volume
> 
> Usage:
> ubifsmount <volume-name>
>     - mount 'volume-name' volume
> 
> 
> In the mean time, I was not able to get ubifsmount works. Appreciate
> for any quick advise? Else will look into the code tomorrow as my bed
> is calling me :)

I usually write ubinized image into the "rootfs" partition (sf erase and
then sf write) and then do 'ubi part rootfs' , which fails with error 22
unless I revert this patch. If I dump the SPI NOR area after writing the
data, I see that the last 2 bytes of some pages are corrupted.

I am using these parameters to generate my ~11MiB large ubinized image:
MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
UBINIZE_OPTS="-m 1 -p 64KiB -s 1"

Here is the content of my ubinize.cfg:
[rootfs]
mode=ubi
image=root.ubifs
vol_id=0
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Thu, 2015-12-03 at 17:22 +0100, Marek Vasut wrote:
> On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:
> 
> [...]
> 
> > > I have another board where I cannot use UBI on QSPI NOR and
> > > reverting
> > > this
> > > patch magically fixes things.
> > 
> > I was testing this too as enabling the UBIFS on NOR and here are my
> > output. Wonder how to simulate your errors as I can help to take a
> > look?
> > 
> > 
> > => icache
> > Instruction Cache is ON
> > => dcache
> > Data (writethrough) Cache is ON
> > => sf probe
> > SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB,
> > total
> > 64 MiB
> > => mtdparts default
> > => mtdparts
> > 
> > device nor0 <ff705000.spi>, # parts = 4
> > #: name                size            offset          mask_flags
> > 0: u-boot              0x00100000      0x00000000      0
> > 1: uboot-env           0x00010000      0x00100000      0
> > 2: rootfs              0x01000000      0x00110000      0
> > 3: UBI                 0x02ef0000      0x01110000      0
> > 
> > active partition: nor0,0 - (u-boot) 0x00100000 @ 0x00000000
> > 
> > defaults:
> > mtdids  : nor0=ff705000.spi
> > mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot
> > -env),16m(rootfs),
> > -(UBI)
> > => sf erase u-boot 100000
> > SF: 1048576 bytes @ 0x0 Erased: OK
> > => ubi part u-boot
> > ubi0: attaching mtd1
> > ubi0: scanning is finished
> > ubi0: empty MTD device detected
> > ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
> > ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
> > ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
> > ubi0: VID header offset: 64 (aligned 64), data offset: 128
> > ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
> > ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23
> > ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image
> > sequence
> > number: 0
> > ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs reserved
> > for
> > bad PEB handling: 0
> > => ubi createvol testvol c0000
> > Creating dynamic volume testvol of size 786432
> > => ubi write 0 testvol 100
> > 256 bytes written to volume testvol
> > => ubi read 200 testvol 100
> > Read 256 bytes from volume testvol to 200
> > => cmp.b 0 200 100
> > Total of 256 byte(s) were the same
> > => ubifsmount testvol
> > Error reading superblock on volume 'testvol' errno=-22!
> > ubifsmount - mount UBIFS volume
> > 
> > Usage:
> > ubifsmount <volume-name>
> >     - mount 'volume-name' volume
> > => ubifsmount ubi0:testvol
> > Error reading superblock on volume 'ubi0:testvol' errno=-22!
> > ubifsmount - mount UBIFS volume
> > 
> > Usage:
> > ubifsmount <volume-name>
> >     - mount 'volume-name' volume
> > 
> > 
> > In the mean time, I was not able to get ubifsmount works.
> > Appreciate
> > for any quick advise? Else will look into the code tomorrow as my
> > bed
> > is calling me :)
> 
> I usually write ubinized image into the "rootfs" partition (sf erase
> and
> then sf write) and then do 'ubi part rootfs' , which fails with error
> 22
> unless I revert this patch. If I dump the SPI NOR area after writing
> the
> data, I see that the last 2 bytes of some pages are corrupted.
> 
> I am using these parameters to generate my ~11MiB large ubinized
> image:
> MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> 
> Here is the content of my ubinize.cfg:
> [rootfs]
> mode=ubi
> image=root.ubifs
> vol_id=0
> vol_type=dynamic
> vol_name=rootfs
> vol_flags=autoresize

Thanks for the pointers. 

I checked the source and enabled the debug message. Noticed my failure
is due to small LEB and PEB size. It was set to 4k which is the sub
-sector erase size of NOR flash. I suspect you didn't hit this as you
generate ubinized image which is 64kB erase size.

I will continue to dig more. Need to ensure it works when user create
UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
erase size). Hopefully existing U-Boot already have source taking care
this :)

Thanks
Chin Liang

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Monday, December 07, 2015 at 03:37:17 PM, Chin Liang See wrote:
> On Thu, 2015-12-03 at 17:22 +0100, Marek Vasut wrote:
> > On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:
> > 
> > [...]
> > 
> > > > I have another board where I cannot use UBI on QSPI NOR and
> > > > reverting
> > > > this
> > > > patch magically fixes things.
> > > 
> > > I was testing this too as enabling the UBIFS on NOR and here are my
> > > output. Wonder how to simulate your errors as I can help to take a
> > > look?
> > > 
> > > 
> > > => icache
> > > Instruction Cache is ON
> > > => dcache
> > > Data (writethrough) Cache is ON
> > > => sf probe
> > > SF: Detected N25Q512 with page size 256 Bytes, erase size 4 KiB,
> > > total
> > > 64 MiB
> > > => mtdparts default
> > > => mtdparts
> > > 
> > > device nor0 <ff705000.spi>, # parts = 4
> > > #: name                size            offset          mask_flags
> > > 0: u-boot              0x00100000      0x00000000      0
> > > 1: uboot-env           0x00010000      0x00100000      0
> > > 2: rootfs              0x01000000      0x00110000      0
> > > 3: UBI                 0x02ef0000      0x01110000      0
> > > 
> > > active partition: nor0,0 - (u-boot) 0x00100000 @ 0x00000000
> > > 
> > > defaults:
> > > mtdids  : nor0=ff705000.spi
> > > mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot
> > > -env),16m(rootfs),
> > > -(UBI)
> > > => sf erase u-boot 100000
> > > SF: 1048576 bytes @ 0x0 Erased: OK
> > > => ubi part u-boot
> > > ubi0: attaching mtd1
> > > ubi0: scanning is finished
> > > ubi0: empty MTD device detected
> > > ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
> > > ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
> > > ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
> > > ubi0: VID header offset: 64 (aligned 64), data offset: 128
> > > ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
> > > ubi0: user volume: 0, internal volumes: 1, max. volumes count: 23
> > > ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image
> > > sequence
> > > number: 0
> > > ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs reserved
> > > for
> > > bad PEB handling: 0
> > > => ubi createvol testvol c0000
> > > Creating dynamic volume testvol of size 786432
> > > => ubi write 0 testvol 100
> > > 256 bytes written to volume testvol
> > > => ubi read 200 testvol 100
> > > Read 256 bytes from volume testvol to 200
> > > => cmp.b 0 200 100
> > > Total of 256 byte(s) were the same
> > > => ubifsmount testvol
> > > Error reading superblock on volume 'testvol' errno=-22!
> > > ubifsmount - mount UBIFS volume
> > > 
> > > Usage:
> > > ubifsmount <volume-name>
> > > 
> > >     - mount 'volume-name' volume
> > > 
> > > => ubifsmount ubi0:testvol
> > > Error reading superblock on volume 'ubi0:testvol' errno=-22!
> > > ubifsmount - mount UBIFS volume
> > > 
> > > Usage:
> > > ubifsmount <volume-name>
> > > 
> > >     - mount 'volume-name' volume
> > > 
> > > In the mean time, I was not able to get ubifsmount works.
> > > Appreciate
> > > for any quick advise? Else will look into the code tomorrow as my
> > > bed
> > > is calling me :)
> > 
> > I usually write ubinized image into the "rootfs" partition (sf erase
> > and
> > then sf write) and then do 'ubi part rootfs' , which fails with error
> > 22
> > unless I revert this patch. If I dump the SPI NOR area after writing
> > the
> > data, I see that the last 2 bytes of some pages are corrupted.
> > 
> > I am using these parameters to generate my ~11MiB large ubinized
> > image:
> > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > 
> > Here is the content of my ubinize.cfg:
> > [rootfs]
> > mode=ubi
> > image=root.ubifs
> > vol_id=0
> > vol_type=dynamic
> > vol_name=rootfs
> > vol_flags=autoresize
> 
> Thanks for the pointers.
> 
> I checked the source and enabled the debug message. Noticed my failure
> is due to small LEB and PEB size. It was set to 4k which is the sub
> -sector erase size of NOR flash. I suspect you didn't hit this as you
> generate ubinized image which is 64kB erase size.
> 
> I will continue to dig more. Need to ensure it works when user create
> UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
> erase size). Hopefully existing U-Boot already have source taking care
> this :)

I am tempted to revert this patch, since it breaks USB and UBI for me
on two different boards though.

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Mon, 2015-12-07 at 15:44 +0100, Marek Vasut wrote:
> On Monday, December 07, 2015 at 03:37:17 PM, Chin Liang See wrote:
> > On Thu, 2015-12-03 at 17:22 +0100, Marek Vasut wrote:
> > > On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See
> > > wrote:
> > > 
> > > [...]
> > > 
> > > > > I have another board where I cannot use UBI on QSPI NOR and
> > > > > reverting
> > > > > this
> > > > > patch magically fixes things.
> > > > 
> > > > I was testing this too as enabling the UBIFS on NOR and here
> > > > are my
> > > > output. Wonder how to simulate your errors as I can help to
> > > > take a
> > > > look?
> > > > 
> > > > 
> > > > => icache
> > > > Instruction Cache is ON
> > > > => dcache
> > > > Data (writethrough) Cache is ON
> > > > => sf probe
> > > > SF: Detected N25Q512 with page size 256 Bytes, erase size 4
> > > > KiB,
> > > > total
> > > > 64 MiB
> > > > => mtdparts default
> > > > => mtdparts
> > > > 
> > > > device nor0 <ff705000.spi>, # parts = 4
> > > > #: name                size            offset         
> > > >  mask_flags
> > > > 0: u-boot              0x00100000      0x00000000      0
> > > > 1: uboot-env           0x00010000      0x00100000      0
> > > > 2: rootfs              0x01000000      0x00110000      0
> > > > 3: UBI                 0x02ef0000      0x01110000      0
> > > > 
> > > > active partition: nor0,0 - (u-boot) 0x00100000 @ 0x00000000
> > > > 
> > > > defaults:
> > > > mtdids  : nor0=ff705000.spi
> > > > mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot
> > > > -env),16m(rootfs),
> > > > -(UBI)
> > > > => sf erase u-boot 100000
> > > > SF: 1048576 bytes @ 0x0 Erased: OK
> > > > => ubi part u-boot
> > > > ubi0: attaching mtd1
> > > > ubi0: scanning is finished
> > > > ubi0: empty MTD device detected
> > > > ubi0: attached mtd1 (name "mtd=0", size 1 MiB)
> > > > ubi0: PEB size: 4096 bytes (4 KiB), LEB size: 3968 bytes
> > > > ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1
> > > > ubi0: VID header offset: 64 (aligned 64), data offset: 128
> > > > ubi0: good PEBs: 256, bad PEBs: 0, corrupted PEBs: 0
> > > > ubi0: user volume: 0, internal volumes: 1, max. volumes count:
> > > > 23
> > > > ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image
> > > > sequence
> > > > number: 0
> > > > ubi0: available PEBs: 252, total reserved PEBs: 4, PEBs
> > > > reserved
> > > > for
> > > > bad PEB handling: 0
> > > > => ubi createvol testvol c0000
> > > > Creating dynamic volume testvol of size 786432
> > > > => ubi write 0 testvol 100
> > > > 256 bytes written to volume testvol
> > > > => ubi read 200 testvol 100
> > > > Read 256 bytes from volume testvol to 200
> > > > => cmp.b 0 200 100
> > > > Total of 256 byte(s) were the same
> > > > => ubifsmount testvol
> > > > Error reading superblock on volume 'testvol' errno=-22!
> > > > ubifsmount - mount UBIFS volume
> > > > 
> > > > Usage:
> > > > ubifsmount <volume-name>
> > > > 
> > > >     - mount 'volume-name' volume
> > > > 
> > > > => ubifsmount ubi0:testvol
> > > > Error reading superblock on volume 'ubi0:testvol' errno=-22!
> > > > ubifsmount - mount UBIFS volume
> > > > 
> > > > Usage:
> > > > ubifsmount <volume-name>
> > > > 
> > > >     - mount 'volume-name' volume
> > > > 
> > > > In the mean time, I was not able to get ubifsmount works.
> > > > Appreciate
> > > > for any quick advise? Else will look into the code tomorrow as
> > > > my
> > > > bed
> > > > is calling me :)
> > > 
> > > I usually write ubinized image into the "rootfs" partition (sf
> > > erase
> > > and
> > > then sf write) and then do 'ubi part rootfs' , which fails with
> > > error
> > > 22
> > > unless I revert this patch. If I dump the SPI NOR area after
> > > writing
> > > the
> > > data, I see that the last 2 bytes of some pages are corrupted.
> > > 
> > > I am using these parameters to generate my ~11MiB large ubinized
> > > image:
> > > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > > 
> > > Here is the content of my ubinize.cfg:
> > > [rootfs]
> > > mode=ubi
> > > image=root.ubifs
> > > vol_id=0
> > > vol_type=dynamic
> > > vol_name=rootfs
> > > vol_flags=autoresize
> > 
> > Thanks for the pointers.
> > 
> > I checked the source and enabled the debug message. Noticed my
> > failure
> > is due to small LEB and PEB size. It was set to 4k which is the sub
> > -sector erase size of NOR flash. I suspect you didn't hit this as
> > you
> > generate ubinized image which is 64kB erase size.
> > 
> > I will continue to dig more. Need to ensure it works when user
> > create
> > UBI part in U-Boot on top of serial NOR flash (which is commonly
> > 4kB
> > erase size). Hopefully existing U-Boot already have source taking
> > care
> > this :)
> 
> I am tempted to revert this patch, since it breaks USB and UBI for me
> on two different boards though.


I believe good to go ahead then as functionality is critical then
performance. The next patch for this would need to get your help to
test it as I have challenge to reproduce this. Need to understand the
reason through the cache drivers.

Thanks
Chin Liang

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Pavel Machek]

> > > > Usage:
> > > > ubifsmount <volume-name>
> > > > 
> > > >     - mount 'volume-name' volume
> > > > 
> > > > In the mean time, I was not able to get ubifsmount works.
> > > > Appreciate
> > > > for any quick advise? Else will look into the code tomorrow as my
> > > > bed
> > > > is calling me :)
> > > 
> > > I usually write ubinized image into the "rootfs" partition (sf erase
> > > and
> > > then sf write) and then do 'ubi part rootfs' , which fails with error
> > > 22
> > > unless I revert this patch. If I dump the SPI NOR area after writing
> > > the
> > > data, I see that the last 2 bytes of some pages are corrupted.
> > > 
> > > I am using these parameters to generate my ~11MiB large ubinized
> > > image:
> > > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > > 
> > > Here is the content of my ubinize.cfg:
> > > [rootfs]
> > > mode=ubi
> > > image=root.ubifs
> > > vol_id=0
> > > vol_type=dynamic
> > > vol_name=rootfs
> > > vol_flags=autoresize
> > 
> > Thanks for the pointers.
> > 
> > I checked the source and enabled the debug message. Noticed my failure
> > is due to small LEB and PEB size. It was set to 4k which is the sub
> > -sector erase size of NOR flash. I suspect you didn't hit this as you
> > generate ubinized image which is 64kB erase size.
> > 
> > I will continue to dig more. Need to ensure it works when user create
> > UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
> > erase size). Hopefully existing U-Boot already have source taking care
> > this :)
> 
> I am tempted to revert this patch, since it breaks USB and UBI for me
> on two different boards though.

It caused regressions it was not supposed to change. That means
revert...

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese]

On 08.12.2015 12:13, Pavel Machek wrote:
>>>>> Usage:
>>>>> ubifsmount <volume-name>
>>>>>
>>>>>      - mount 'volume-name' volume
>>>>>
>>>>> In the mean time, I was not able to get ubifsmount works.
>>>>> Appreciate
>>>>> for any quick advise? Else will look into the code tomorrow as my
>>>>> bed
>>>>> is calling me :)
>>>>
>>>> I usually write ubinized image into the "rootfs" partition (sf erase
>>>> and
>>>> then sf write) and then do 'ubi part rootfs' , which fails with error
>>>> 22
>>>> unless I revert this patch. If I dump the SPI NOR area after writing
>>>> the
>>>> data, I see that the last 2 bytes of some pages are corrupted.
>>>>
>>>> I am using these parameters to generate my ~11MiB large ubinized
>>>> image:
>>>> MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
>>>> UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
>>>>
>>>> Here is the content of my ubinize.cfg:
>>>> [rootfs]
>>>> mode=ubi
>>>> image=root.ubifs
>>>> vol_id=0
>>>> vol_type=dynamic
>>>> vol_name=rootfs
>>>> vol_flags=autoresize
>>>
>>> Thanks for the pointers.
>>>
>>> I checked the source and enabled the debug message. Noticed my failure
>>> is due to small LEB and PEB size. It was set to 4k which is the sub
>>> -sector erase size of NOR flash. I suspect you didn't hit this as you
>>> generate ubinized image which is 64kB erase size.
>>>
>>> I will continue to dig more. Need to ensure it works when user create
>>> UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
>>> erase size). Hopefully existing U-Boot already have source taking care
>>> this :)
>>
>> I am tempted to revert this patch, since it breaks USB and UBI for me
>> on two different boards though.
>
> It caused regressions it was not supposed to change. That means
> revert...

Yes, please revert and hopefully someone will find the time
to find and fix the problem with this dcache at some time.

Sorry for the inconvenience. But I didn't notice any problems
with it until now.

Thanks,
Stefan

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Tuesday, December 08, 2015 at 01:04:29 PM, Stefan Roese wrote:
> On 08.12.2015 12:13, Pavel Machek wrote:
> >>>>> Usage:
> >>>>> ubifsmount <volume-name>
> >>>>> 
> >>>>>      - mount 'volume-name' volume
> >>>>> 
> >>>>> In the mean time, I was not able to get ubifsmount works.
> >>>>> Appreciate
> >>>>> for any quick advise? Else will look into the code tomorrow as my
> >>>>> bed
> >>>>> is calling me :)
> >>>> 
> >>>> I usually write ubinized image into the "rootfs" partition (sf erase
> >>>> and
> >>>> then sf write) and then do 'ubi part rootfs' , which fails with error
> >>>> 22
> >>>> unless I revert this patch. If I dump the SPI NOR area after writing
> >>>> the
> >>>> data, I see that the last 2 bytes of some pages are corrupted.
> >>>> 
> >>>> I am using these parameters to generate my ~11MiB large ubinized
> >>>> image:
> >>>> MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> >>>> UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> >>>> 
> >>>> Here is the content of my ubinize.cfg:
> >>>> [rootfs]
> >>>> mode=ubi
> >>>> image=root.ubifs
> >>>> vol_id=0
> >>>> vol_type=dynamic
> >>>> vol_name=rootfs
> >>>> vol_flags=autoresize
> >>> 
> >>> Thanks for the pointers.
> >>> 
> >>> I checked the source and enabled the debug message. Noticed my failure
> >>> is due to small LEB and PEB size. It was set to 4k which is the sub
> >>> -sector erase size of NOR flash. I suspect you didn't hit this as you
> >>> generate ubinized image which is 64kB erase size.
> >>> 
> >>> I will continue to dig more. Need to ensure it works when user create
> >>> UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
> >>> erase size). Hopefully existing U-Boot already have source taking care
> >>> this :)
> >> 
> >> I am tempted to revert this patch, since it breaks USB and UBI for me
> >> on two different boards though.
> > 
> > It caused regressions it was not supposed to change. That means
> > revert...
> 
> Yes, please revert and hopefully someone will find the time
> to find and fix the problem with this dcache at some time.

Me, already done, see the other email ;-)

> Sorry for the inconvenience. But I didn't notice any problems
> with it until now.

You were just lucky ;-)

Best regards,
Marek Vasut

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Tue, 2015-12-08 at 13:54 +0100, Marek Vasut wrote:
> On Tuesday, December 08, 2015 at 01:04:29 PM, Stefan Roese wrote:
> > On 08.12.2015 12:13, Pavel Machek wrote:
> > > > > > > Usage:
> > > > > > > ubifsmount <volume-name>
> > > > > > > 
> > > > > > >      - mount 'volume-name' volume
> > > > > > > 
> > > > > > > In the mean time, I was not able to get ubifsmount works.
> > > > > > > Appreciate
> > > > > > > for any quick advise? Else will look into the code
> > > > > > > tomorrow as my
> > > > > > > bed
> > > > > > > is calling me :)
> > > > > > 
> > > > > > I usually write ubinized image into the "rootfs" partition
> > > > > > (sf erase
> > > > > > and
> > > > > > then sf write) and then do 'ubi part rootfs' , which fails
> > > > > > with error
> > > > > > 22
> > > > > > unless I revert this patch. If I dump the SPI NOR area
> > > > > > after writing
> > > > > > the
> > > > > > data, I see that the last 2 bytes of some pages are
> > > > > > corrupted.
> > > > > > 
> > > > > > I am using these parameters to generate my ~11MiB large
> > > > > > ubinized
> > > > > > image:
> > > > > > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > > > > > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > > > > > 
> > > > > > Here is the content of my ubinize.cfg:
> > > > > > [rootfs]
> > > > > > mode=ubi
> > > > > > image=root.ubifs
> > > > > > vol_id=0
> > > > > > vol_type=dynamic
> > > > > > vol_name=rootfs
> > > > > > vol_flags=autoresize
> > > > > 
> > > > > Thanks for the pointers.
> > > > > 
> > > > > I checked the source and enabled the debug message. Noticed
> > > > > my failure
> > > > > is due to small LEB and PEB size. It was set to 4k which is
> > > > > the sub
> > > > > -sector erase size of NOR flash. I suspect you didn't hit
> > > > > this as you
> > > > > generate ubinized image which is 64kB erase size.
> > > > > 
> > > > > I will continue to dig more. Need to ensure it works when
> > > > > user create
> > > > > UBI part in U-Boot on top of serial NOR flash (which is
> > > > > commonly 4kB
> > > > > erase size). Hopefully existing U-Boot already have source
> > > > > taking care
> > > > > this :)
> > > > 
> > > > I am tempted to revert this patch, since it breaks USB and UBI
> > > > for me
> > > > on two different boards though.
> > > 
> > > It caused regressions it was not supposed to change. That means
> > > revert...
> > 
> > Yes, please revert and hopefully someone will find the time
> > to find and fix the problem with this dcache at some time.
> 
> Me, already done, see the other email ;-)
> 
> > Sorry for the inconvenience. But I didn't notice any problems
> > with it until now.
> 
> You were just lucky ;-)


With the mentioned bug, the value that will be programmed to ttbr0 is
the tlb_address itself. The value I have (through bdinfo command) is
0x3fff0000. Wonder what is the value when the issue happen? Just try to
understand more.

Thanks
Chin Liang



> 
> Best regards,
> Marek Vasut

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Wednesday, December 09, 2015 at 02:48:49 PM, Chin Liang See wrote:
> On Tue, 2015-12-08 at 13:54 +0100, Marek Vasut wrote:
> > On Tuesday, December 08, 2015 at 01:04:29 PM, Stefan Roese wrote:
> > > On 08.12.2015 12:13, Pavel Machek wrote:
> > > > > > > > Usage:
> > > > > > > > ubifsmount <volume-name>
> > > > > > > > 
> > > > > > > >      - mount 'volume-name' volume
> > > > > > > > 
> > > > > > > > In the mean time, I was not able to get ubifsmount works.
> > > > > > > > Appreciate
> > > > > > > > for any quick advise? Else will look into the code
> > > > > > > > tomorrow as my
> > > > > > > > bed
> > > > > > > > is calling me :)
> > > > > > > 
> > > > > > > I usually write ubinized image into the "rootfs" partition
> > > > > > > (sf erase
> > > > > > > and
> > > > > > > then sf write) and then do 'ubi part rootfs' , which fails
> > > > > > > with error
> > > > > > > 22
> > > > > > > unless I revert this patch. If I dump the SPI NOR area
> > > > > > > after writing
> > > > > > > the
> > > > > > > data, I see that the last 2 bytes of some pages are
> > > > > > > corrupted.
> > > > > > > 
> > > > > > > I am using these parameters to generate my ~11MiB large
> > > > > > > ubinized
> > > > > > > image:
> > > > > > > MKFS_UBIFS_OPTS="-m 1 -e 65408 -c 200"
> > > > > > > UBINIZE_OPTS="-m 1 -p 64KiB -s 1"
> > > > > > > 
> > > > > > > Here is the content of my ubinize.cfg:
> > > > > > > [rootfs]
> > > > > > > mode=ubi
> > > > > > > image=root.ubifs
> > > > > > > vol_id=0
> > > > > > > vol_type=dynamic
> > > > > > > vol_name=rootfs
> > > > > > > vol_flags=autoresize
> > > > > > 
> > > > > > Thanks for the pointers.
> > > > > > 
> > > > > > I checked the source and enabled the debug message. Noticed
> > > > > > my failure
> > > > > > is due to small LEB and PEB size. It was set to 4k which is
> > > > > > the sub
> > > > > > -sector erase size of NOR flash. I suspect you didn't hit
> > > > > > this as you
> > > > > > generate ubinized image which is 64kB erase size.
> > > > > > 
> > > > > > I will continue to dig more. Need to ensure it works when
> > > > > > user create
> > > > > > UBI part in U-Boot on top of serial NOR flash (which is
> > > > > > commonly 4kB
> > > > > > erase size). Hopefully existing U-Boot already have source
> > > > > > taking care
> > > > > > this :)
> > > > > 
> > > > > I am tempted to revert this patch, since it breaks USB and UBI
> > > > > for me
> > > > > on two different boards though.
> > > > 
> > > > It caused regressions it was not supposed to change. That means
> > > > revert...
> > > 
> > > Yes, please revert and hopefully someone will find the time
> > > to find and fix the problem with this dcache at some time.
> > 
> > Me, already done, see the other email ;-)
> > 
> > > Sorry for the inconvenience. But I didn't notice any problems
> > > with it until now.
> > 
> > You were just lucky ;-)
> 
> With the mentioned bug, the value that will be programmed to ttbr0 is
> the tlb_address itself. The value I have (through bdinfo command) is
> 0x3fff0000. Wonder what is the value when the issue happen? Just try to
> understand more.

Check this patch:

[PATCH] arm: Replace test for CONFIG_ARMV7 with CONFIG_CPU_V7

Me and Albert isolated things to S bit in the page tables, which fixes
things, but causes slowness on the socfpga.

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Marek Vasut]

On Tuesday, December 08, 2015 at 12:13:23 PM, Pavel Machek wrote:

[...]

> > > Thanks for the pointers.
> > > 
> > > I checked the source and enabled the debug message. Noticed my failure
> > > is due to small LEB and PEB size. It was set to 4k which is the sub
> > > -sector erase size of NOR flash. I suspect you didn't hit this as you
> > > generate ubinized image which is 64kB erase size.
> > > 
> > > I will continue to dig more. Need to ensure it works when user create
> > > UBI part in U-Boot on top of serial NOR flash (which is commonly 4kB
> > > erase size). Hopefully existing U-Boot already have source taking care
> > > this :)
> > 
> > I am tempted to revert this patch, since it breaks USB and UBI for me
> > on two different boards though.
> 
> It caused regressions it was not supposed to change. That means
> revert...

I found the bug, it's not a bug in this patch, but it's even broader issue.

Look at arch/arm/lib/cache-cp15.c , the file checks for CONFIG_ARMV7 and only
ifdef CONFIG_ARMV7, then it configures TTBR0. If CONFIG_ARMV7 is not set, it 
configures nothing. But, I cannot find any place for any ARMV7 machine which 
would actually set the CONFIG_ARMV7 option.

I verified this on SoCFPGA and indeed, CONFIG_ARMV7 is not set, so this piece
of code is never executed and thus my cache misbehaves.

I guess the right way to fix this would be to replace #ifdef CONFIG_ARMV7 with
CONFIG_CPU_V7 ? Or shall we add new symbol, CONFIG_ARMV7 and make CONFIG_CPU_V7
select CONFIG_ARMV7 to avoid changing the system.h header, which is most likely
taken from Linux ?

Best regards,
Marek Vasut

[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Chin Liang See]

On Tue, 2015-12-08 at 13:53 +0100, Marek Vasut wrote:
> On Tuesday, December 08, 2015 at 12:13:23 PM, Pavel Machek wrote:
> 
> [...]
> 
> > > > Thanks for the pointers.
> > > > 
> > > > I checked the source and enabled the debug message. Noticed my
> > > > failure
> > > > is due to small LEB and PEB size. It was set to 4k which is the
> > > > sub
> > > > -sector erase size of NOR flash. I suspect you didn't hit this
> > > > as you
> > > > generate ubinized image which is 64kB erase size.
> > > > 
> > > > I will continue to dig more. Need to ensure it works when user
> > > > create
> > > > UBI part in U-Boot on top of serial NOR flash (which is
> > > > commonly 4kB
> > > > erase size). Hopefully existing U-Boot already have source
> > > > taking care
> > > > this :)
> > > 
> > > I am tempted to revert this patch, since it breaks USB and UBI
> > > for me
> > > on two different boards though.
> > 
> > It caused regressions it was not supposed to change. That means
> > revert...
> 
> I found the bug, it's not a bug in this patch, but it's even broader
> issue.
> 

Nice!

> Look at arch/arm/lib/cache-cp15.c , the file checks for CONFIG_ARMV7
> and only
> ifdef CONFIG_ARMV7, then it configures TTBR0. If CONFIG_ARMV7 is not
> set, it 
> configures nothing. But, I cannot find any place for any ARMV7
> machine which 
> would actually set the CONFIG_ARMV7 option.
> 
> I verified this on SoCFPGA and indeed, CONFIG_ARMV7 is not set, so
> this piece
> of code is never executed and thus my cache misbehaves.
> 
> I guess the right way to fix this would be to replace #ifdef
> CONFIG_ARMV7 with
> CONFIG_CPU_V7 ? Or shall we add new symbol, CONFIG_ARMV7 and make
> CONFIG_CPU_V7
> select CONFIG_ARMV7 to avoid changing the system.h header, which is
> most likely
> taken from Linux ?
> 

I would opt for CONFIG_CPU_V7 as its specific to ARMV7 cache feature.

Thanks
Chin Liang

> Best regards,
> Marek Vasut