arm: socfpga: Fix cache configuration
PATCH 1/1 arm: socfpga: Fix cache configuration
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/sWith 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/sA performance improvement of factor ~3.
--- include/configs/socfpga_common.h | 1 - 1 file changed, 1 deletion(-)
include/configs/socfpga_common.h +0 -1
@@ -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
Signature · 1 line
2.5.2
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 32 lines · 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/sWith 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
Quoted 7 lines
A performance improvement of factor ~3.
Signed-off-by Stefan Roese <[email protected]>Cc Dinh Nguyen <[email protected]>Cc Chin Liang See <[email protected]>Cc Pavel Machek <[email protected]>Cc Marek Vasut <[email protected]>
OUCH! This actually came from the original Altera sources, darn :-(
Best regards,
Marek Vasut
PATCH 1/1 arm: socfpga: Fix cache configuration
In reply to Stefan RoeseQuoted 26 lines · 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/sWith 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: #################################################################
Quoted 7 lines
################################################################# ################################################################# ################################################################# ########################## 7.6 MiB/sA 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
Quoted 12 lines
include/configs/socfpga_common.h +0
-1@@ -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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
PATCH 1/1 arm: socfpga: Fix cache configuration
Hi Pavel,
Quoted 33 lines · Pavel Machek
Quoted 32 lines · 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/sWith 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
Quoted 3 lines
Quoted 1 line
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.
Quoted 3 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
Hi!
Quoted 18 lines
Quoted 14 lines
Quoted 14 lines
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/sQuoted 3 lines
Quoted 1 line
A performance improvement of factor ~3.
Ok, so you turn on write-back cache and it is faster.
Quoted 7 lines
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.
Quoted 7 lines
Quoted 3 lines
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);}
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 28 lines · Pavel Machek
Hi!
Quoted 18 lines
Quoted 14 lines
Quoted 14 lines
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/sQuoted 3 lines
Quoted 1 line
A performance improvement of factor ~3.
Ok, so you turn on write-back cache and it is faster.
Quoted 7 lines
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.
Quoted 2 lines
Yes, so we were running with dcache disabled, which can mask _many_ programming errors.
Of course.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
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?
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
In reply to Stefan RoeseOn Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:
Hi!
Quoted 48 lines
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/sWith 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/sA performance improvement of factor ~3.
Signed-off-by Stefan Roese <[email protected]>Cc Dinh Nguyen <[email protected]>Cc Chin Liang See <[email protected]>Cc Pavel Machek <[email protected]>Cc Marek Vasut <[email protected]>--- include/configs/socfpga_common.h | 1 - 1 file changed, 1 deletion(-)(quoted diff) +0
-0
b/include/configs/socfpga_common.hindex 38ae763..a2811ba 100644
include/configs/socfpga_common.h line 78
Quoted 7 lines
include/configs/socfpga_common.h +0
-1@@ -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 0usb_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
PATCH 1/1 arm: socfpga: Fix cache configuration
Hi Marek,
Quoted 47 lines · Marek Vasut
On Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:
Hi!
Quoted 43 lines
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/sWith 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/sA performance improvement of factor ~3.
Signed-off-by Stefan Roese <[email protected]>Cc Dinh Nguyen <[email protected]>Cc Chin Liang See <[email protected]>Cc Pavel Machek <[email protected]>Cc Marek Vasut <[email protected]>--- include/configs/socfpga_common.h | 1 - 1 file changed, 1 deletion(-)
Quoted 14 lines
include/configs/socfpga_common.h line 78
Quoted 12 lines
(quoted diff) +0
-0
b/include/configs/socfpga_common.hindex 38ae763..a2811ba 100644include/configs/socfpga_common.h +0
-1@@ -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_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 17 lines
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 0usb_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
Quoted 8 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 107 lines · Stefan Roese
Hi Marek,
Quoted 67 lines · Marek Vasut
On Thursday, September 17, 2015 at 05:30:29 PM, Stefan Roese wrote:
Hi!
Quoted 63 lines
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/sWith 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/sA performance improvement of factor ~3.
Signed-off-by Stefan Roese <[email protected]>Cc Dinh Nguyen <[email protected]>Cc Chin Liang See <[email protected]>Cc Pavel Machek <[email protected]>Cc Marek Vasut <[email protected]>---
include/configs/socfpga_common.h | 1 - 1 file changed, 1 deletion(-)(quoted diff) +0
-0
b/include/configs/socfpga_common.hindex 38ae763..a2811ba 100644include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* * Cache */ Quoted 7 lines
Quoted 5 lines
include/configs/socfpga_common.h +0
-1-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 27 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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.
Quoted 5 lines
Quoted 1 line
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
PATCH 1/1 arm: socfpga: Fix cache configuration
Hi Marek,
On 09.11.2015 14:49, Marek Vasut wrote:
<snip>
Quoted 48 lines
Quoted 48 lines
Quoted 9 lines
Quoted 9 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* * Cache */ Quoted 7 lines
Quoted 5 lines
include/configs/socfpga_common.h +0
-1-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 28 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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 ?
Quoted 7 lines
Quoted 3 lines
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 afterinvalidate_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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 1 line · Stefan Roese
Hi Marek,
Hi!
Quoted 60 lines · Marek Vasut
<snip>
Quoted 48 lines
Quoted 48 lines
Quoted 9 lines
Quoted 9 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* * Cache */ Quoted 7 lines
Quoted 5 lines
include/configs/socfpga_common.h +0
-1-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 28 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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 ?
Quoted 7 lines
Quoted 3 lines
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 afterinvalidate_dcache_range()in the driver), it still fails.
Quoted 7 lines
Did you check if this problem is perhaps also related to Dinh's L2 cache patch:
8d8e13e1arm: socfpga: enable data/inst prefetch and shared override in the L2?
Yes I did, but reverting this patch had no impact.
Quoted 6 lines
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_ctrlregister setup again?
I guess we should pester Dinh now :-)
PATCH 1/1 arm: socfpga: Fix cache configuration
Hi Marek,
Quoted 75 lines · Marek Vasut
Quoted 1 line · Stefan Roese
Hi Marek,
Hi!
Quoted 60 lines · Marek Vasut
<snip>
Quoted 48 lines
Quoted 48 lines
Quoted 9 lines
Quoted 9 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* * Cache */ Quoted 7 lines
Quoted 5 lines
include/configs/socfpga_common.h +0
-1-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 28 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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 ?
Quoted 7 lines
Quoted 3 lines
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 afterinvalidate_dcache_range()in the driver), it still fails.Quoted 7 lines
Did you check if this problem is perhaps also related to Dinh's L2 cache patch:
8d8e13e1arm: socfpga: enable data/inst prefetch and shared override in the L2?
Yes I did, but reverting this patch had no impact.
Quoted 8 lines
Quoted 6 lines
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_ctrlregister 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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 136 lines · Chin Liang See
Hi Marek,
Quoted 78 lines · Marek Vasut
Quoted 1 line · Stefan Roese
Hi Marek,
Hi!
Quoted 63 lines · Marek Vasut
<snip>
Quoted 50 lines
Quoted 50 lines
Quoted 9 lines
Quoted 9 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* * Cache */ Quoted 7 lines
Quoted 5 lines
include/configs/socfpga_common.h +0
-1-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 30 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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 ?
Quoted 8 lines
Quoted 3 lines
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 afterinvalidate_dcache_range()in the driver), it still fails.Quoted 7 lines
Did you check if this problem is perhaps also related to Dinh's L2 cache patch:
8d8e13e1arm: socfpga: enable data/inst prefetch and shared override in the L2?
Yes I did, but reverting this patch had no impact.
Quoted 8 lines
Quoted 6 lines
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_ctrlregister 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 commita55f28624e97e1e43ac?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 KitNet:
Error: ethernet atff702000address 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:0x0000Product0x0000Version 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
Quoted 12 lines
2: Mass Storage, USB Revision 2.0
- SanDisk SDDR-113 000000009412
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x0781Product0xa7c1Version 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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 150 lines · Marek Vasut
Quoted 136 lines · Chin Liang See
Hi Marek,
Quoted 78 lines · Marek Vasut
Quoted 1 line · Stefan Roese
Hi Marek,
Hi!
Quoted 63 lines · Marek Vasut
<snip>
Quoted 50 lines
Quoted 50 lines
Quoted 9 lines
Quoted 9 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* * Cache */ Quoted 7 lines
Quoted 5 lines
include/configs/socfpga_common.h +0
-1-#define CONFIG_SYS_ARM_CACHE_WRITEALLOC #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESSI hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 30 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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 ?
Quoted 8 lines
Quoted 3 lines
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 afterinvalidate_dcache_range()in the driver), it still fails.Quoted 7 lines
Did you check if this problem is perhaps also related to Dinh's L2 cache patch:
8d8e13e1arm: socfpga: enable data/inst prefetch and shared override in the L2?
Yes I did, but reverting this patch had no impact.
Quoted 8 lines
Quoted 6 lines
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_ctrlregister 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 commita55f28624e97e1e43ac?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 KitNet:
Error: ethernet atff702000address 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:0x0000Product0x0000Version 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 255msQuoted 12 lines
2: Mass Storage, USB Revision 2.0
- SanDisk SDDR-113 000000009412
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x0781Product0xa7c1Version 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
Quoted 7 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
On Thursday, November 12, 2015 at 03:33:42 AM, Chin Liang See wrote:
[...]
Quoted 78 lines
Quoted 78 lines
Quoted 77 lines
Quoted 8 lines
Quoted 6 lines
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_ctrlregister 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 commita55f28624e97e1e43ac?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 KitNet:
Error: ethernet atff702000address 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) foundscanning 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:0x0000Product0x0000Version 0.0Configuration: 1
- Interfaces: 1 Self Powered 0mAInterface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms2: Mass Storage, USB Revision 2.0
- SanDisk SDDR-113 000000009412
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x0781Product0xa7c1Version 148.18Configuration: 1
- Interfaces: 1 Bus Powered 500mAInterface: 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
Quoted 7 lines
Quoted 7 lines
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!
Quoted 1 line
It takes some amount of time for digging out a USB 2.0 stick :)
Well sorry about living in a developing country ;-)
Quoted 4 lines
But it still work for me as below.
Let me check out the code and see any clue.
Quoted 12 lines
2: Mass Storage, USB Revision 2.0
- USB DISK 2.0 0781076602A6
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x13feProduct0x1e00Version 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
PATCH 1/1 arm: socfpga: Fix cache configuration
In reply to Chin Liang SeeQuoted 20 lines · Chin Liang See
Quoted 19 lines · Marek Vasut
Quoted 18 lines · Chin Liang See
Hi Marek,
Quoted 15 lines · Marek Vasut
Quoted 1 line · Stefan Roese
Hi Marek,
Hi!
Quoted 10 lines · Marek Vasut
<snip>
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/*
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
include/configs/socfpga_common.h +0
-1* 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
Quoted 150 lines
Quoted 137 lines
Quoted 128 lines
Quoted 59 lines
Quoted 49 lines
Quoted 44 lines
Quoted 37 lines
Quoted 3 lines
I hate to say it, but I am running into issues with this patch :-(
I'm sorry to hear this.
Quoted 31 lines
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 0usb_new_device: Cannot read configuration, skipping device 058f:6387 1 USB Device(s) foundscanning 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) foundscanning 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.
Quoted 6 lines
Quoted 1 line
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.
Quoted 4 lines
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 afterinvalidate_dcache_range()in the driver), it still fails.Quoted 7 lines
Did you check if this problem is perhaps also related to Dinh's L2 cache patch:
8d8e13e1arm: socfpga: enable data/inst prefetch and shared override in the L2?
Yes I did, but reverting this patch had no impact.
Quoted 8 lines
Quoted 6 lines
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_ctrlregister 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 commita55f28624e97e1e43ac?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 KitNet:
Error: ethernet atff702000address 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) foundscanning 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:0x0000Product0x0000Version 0.0Configuration: 1
- Interfaces: 1 Self Powered 0mAInterface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms2: Mass Storage, USB Revision 2.0
- SanDisk SDDR-113 000000009412
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x0781Product0xa7c1Version 148.18Quoted 8 lines
Configuration: 1
- Interfaces: 1 Bus Powered 500mAInterface: 0
- Alternate Setting 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512Quoted 7 lines
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=1255723475It 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.
Quoted 12 lines
2: Mass Storage, USB Revision 2.0
- USB DISK 2.0 0781076602A6
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x13feProduct0x1e00Version 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.
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 221 lines · Marek Vasut
Quoted 22 lines · Chin Liang See
Quoted 21 lines · Marek Vasut
Quoted 19 lines · Chin Liang See
Hi Marek,
Quoted 16 lines · Marek Vasut
Quoted 1 line · Stefan Roese
Hi Marek,
Hi!
Quoted 10 lines · Marek Vasut
<snip>
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
include/configs/socfpga_common.h +0
-0@@ -73,7 +73,6 @@/* Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
include/configs/socfpga_common.h +0
-1* 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_ADDRESSQuoted 176 lines
Quoted 164 lines
Quoted 150 lines
Quoted 83 lines
Quoted 66 lines
Quoted 58 lines
Quoted 50 lines
Quoted 4 lines
I hate to say it, but I am running into issues with this patch
:-(I'm sorry to hear this.
Quoted 41 lines
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 0usb_new_device: Cannot read configuration, skipping device
058f:6387 1 USB Device(s) foundscanning 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) foundscanning usb for storage devices... 1
Storage
Device(s) foundIf 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.Quoted 1 line
Any ideas please ?
Quoted 7 lines
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.Quoted 7 lines
I doubt that's not the case. If I disable cache just around the
hcdma bit in the driver (disable before theflush_dcache_range()
and enable afterinvalidate_dcache_range()in the driver), it
still fails.Quoted 8 lines
Did you check if this problem is perhaps also related to Dinh's L2
cache patch:
8d8e13e1arm: socfpga: enable data/inst prefetch and shared override in the L2?
Yes I did, but reverting this patch had no impact.
Quoted 6 lines
I just noticed, that here the L2 cache gets disabled and is not
enabled again in functionv7_outer_cache_enable(). This looks a
bit suspicious.Quoted 5 lines
Quoted 3 lines
Dinh, did you perhaps miss to re-enable the L2 cache after the
aux_ctrlregister 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 commita55f28624e97e1e43ac?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 KitNet:
Error: ethernet atff702000address 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) foundscanning 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:0x0000Product0x0000Version 0.0Configuration: 1
- Interfaces: 1 Self Powered 0mAInterface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms2: Mass Storage, USB Revision 2.0
- SanDisk SDDR-113 000000009412
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x0781Product0xa7c1Version 148.18Quoted 8 lines
Configuration: 1
- Interfaces: 1 Bus Powered 500mAInterface: 0
- Alternate Setting 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- Endpoint 1 In Bulk MaxPacket 512
- Endpoint 2 Out Bulk MaxPacket 512Yeah, 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.Quoted 6 lines
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
75It 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.Quoted 12 lines
2: Mass Storage, USB Revision 2.0
- USB DISK 2.0 0781076602A6
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor:0x13feProduct0x1e00Version 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
Quoted 3 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:
[...]
Quoted 67 lines
Quoted 3 lines
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
=> mtdpartsdevice 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 0active partition: nor0,0 - (u-boot)
0x00100000@0x00000000defaults:
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 @0x0Erased: 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 volumeUsage:
ubifsmount <volume-name>
- mount 'volume-name' volume
=> ubifsmount ubi0:testvol
Error reading superblock on volume 'ubi0:testvol' errno=-22! ubifsmount - mount UBIFS volume
Quoted 8 lines
Usage:
ubifsmount <volume-name>
- mount 'volume-name' volumeIn 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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 100 lines · Marek Vasut
On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:
[...]
Quoted 77 lines
Quoted 4 lines
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
=> mtdpartsdevice 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 0active partition: nor0,0 - (u-boot)
0x00100000@0x00000000defaults:
mtdids : nor0=ff705000.spi
mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot(quoted diff) +0
-2-env),16m(rootfs), -(UBI)=> sf erase u-boot 100000
SF: 1048576 bytes @0x0Erased: 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 volumeUsage:
ubifsmount <volume-name>
- mount 'volume-name' volume
=> ubifsmount ubi0:testvol
Error reading superblock on volume 'ubi0:testvol' errno=-22! ubifsmount - mount UBIFS volumeUsage:
ubifsmount <volume-name>
- mount 'volume-name' volumeQuoted 5 lines
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"
Quoted 8 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 119 lines · Chin Liang See
Quoted 102 lines · Marek Vasut
On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:
[...]
Quoted 77 lines
Quoted 4 lines
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
=> mtdpartsdevice 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 0active partition: nor0,0 - (u-boot)
0x00100000@0x00000000defaults:
mtdids : nor0=ff705000.spi
mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot(quoted diff) +0
-2-env),16m(rootfs), -(UBI)=> sf erase u-boot 100000
SF: 1048576 bytes @0x0Erased: 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 volumeUsage:
ubifsmount <volume-name>- mount 'volume-name' volume
=> ubifsmount ubi0:testvol
Error reading superblock on volume 'ubi0:testvol' errno=-22! ubifsmount - mount UBIFS volumeUsage:
ubifsmount <volume-name>Quoted 7 lines
- 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"Quoted 8 lines
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=autoresizeThanks 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.
Quoted 4 lines
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.
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 141 lines · Marek Vasut
Quoted 132 lines · Chin Liang See
Quoted 113 lines · Marek Vasut
On Thursday, December 03, 2015 at 05:11:23 PM, Chin Liang See wrote:
[...]
Quoted 83 lines
Quoted 4 lines
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
=> mtdpartsdevice nor0 <ff705000.spi>, # parts = 4
#: name size offset
mask_flags0: u-boot 0x00100000 0x00000000 0 1: uboot-env 0x00010000 0x00100000 0 2: rootfs 0x01000000 0x00110000 0 3: UBI 0x02ef0000 0x01110000 0active partition: nor0,0 - (u-boot)
0x00100000@0x00000000defaults:
mtdids : nor0=ff705000.spi
mtdparts: mtdparts=ff705000.spi:1m(u-boot),64k(uboot(quoted diff) +0
-2-env),16m(rootfs), -(UBI)=> sf erase u-boot 100000
SF: 1048576 bytes @0x0Erased: 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 volumeUsage:
ubifsmount <volume-name>- mount 'volume-name' volume
=> ubifsmount ubi0:testvol
Error reading superblock on volume 'ubi0:testvol' errno=-22! ubifsmount - mount UBIFS volumeUsage:
ubifsmount <volume-name>Quoted 8 lines
- 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"Quoted 8 lines
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=autoresizeThanks 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.Quoted 7 lines
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 :)
Quoted 2 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
In reply to Marek VasutQuoted 40 lines
Quoted 40 lines
Quoted 24 lines
Quoted 10 lines
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"Quoted 8 lines
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=autoresizeThanks 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.
Quoted 7 lines
Quoted 4 lines
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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 45 lines · Pavel Machek
Quoted 45 lines
Quoted 44 lines
Quoted 24 lines
Quoted 10 lines
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"Quoted 8 lines
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=autoresizeThanks 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 :)
Quoted 5 lines
Quoted 2 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 46 lines · Stefan Roese
Quoted 45 lines · Pavel Machek
Quoted 45 lines
Quoted 44 lines
Quoted 24 lines
Quoted 10 lines
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"Quoted 8 lines
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=autoresizeThanks 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 :)
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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 ;-)
Quoted 2 lines
Sorry for the inconvenience. But I didn't notice any problems with it until now.
You were just lucky ;-)
Best regards,
Marek Vasut
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 69 lines · Marek Vasut
Quoted 62 lines · Stefan Roese
Quoted 61 lines · Pavel Machek
Quoted 60 lines
Quoted 49 lines
Quoted 30 lines
Quoted 11 lines
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"Quoted 8 lines
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=autoresizeThanks 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.Quoted 7 lines
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.Quoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
Me, already done, see the other email ;-)
Quoted 2 lines
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
Quoted 3 lines
Best regards,
Marek Vasut
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 75 lines · Chin Liang See
Quoted 74 lines · Marek Vasut
Quoted 62 lines · Stefan Roese
Quoted 61 lines · Pavel Machek
Quoted 60 lines
Quoted 49 lines
Quoted 30 lines
Quoted 11 lines
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"Quoted 8 lines
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=autoresizeThanks 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.Quoted 7 lines
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.Quoted 5 lines
Quoted 2 lines
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 ;-)
Quoted 2 lines
Sorry for the inconvenience. But I didn't notice any problems with it until now.
Quoted 6 lines
Quoted 1 line
You were just lucky ;-)
With the mentioned bug, the value that will be programmed to ttbr0 is the
tlb_addressitself. The value I have (through bdinfo command) is0x3fff0000. 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.
PATCH 1/1 arm: socfpga: Fix cache configuration
In reply to Pavel MachekOn Tuesday, December 08, 2015 at 12:13:23 PM, Pavel Machek wrote:
[...]
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
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 :)
Quoted 5 lines
Quoted 2 lines
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
PATCH 1/1 arm: socfpga: Fix cache configuration
Quoted 26 lines · Marek Vasut
On Tuesday, December 08, 2015 at 12:13:23 PM, Pavel Machek wrote:
[...]
Quoted 22 lines
Quoted 21 lines
Quoted 10 lines
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.Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
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!
Quoted 12 lines
Look at
arch/arm/lib/cache-cp15.c, the file checks forCONFIG_ARMV7and only
ifdefCONFIG_ARMV7, then it configures TTBR0. IfCONFIG_ARMV7is not set, it
configures nothing. But, I cannot find any place for any ARMV7 machine which
would actually set theCONFIG_ARMV7option.I verified this on SoCFPGA and indeed,
CONFIG_ARMV7is not set, so this piece
of code is never executed and thus my cache misbehaves.
Quoted 8 lines
I guess the right way to fix this would be to replace #ifdef
CONFIG_ARMV7withCONFIG_CPU_V7? Or shall we add new symbol,CONFIG_ARMV7and makeCONFIG_CPU_V7
selectCONFIG_ARMV7to avoid changing thesystem.hheader, which is most likely
taken from Linux ?
I would opt for CONFIG_CPU_V7 as its specific to ARMV7 cache feature.
Thanks
Chin Liang
Quoted 2 lines
Best regards,
Marek Vasut