[U-Boot] [PATCH] 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/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
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
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
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
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); }
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
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
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
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/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 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) 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.
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
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) 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.
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
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) 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.
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 :-)
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) 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.
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@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
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) 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.
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@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
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@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
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 enabledI2C: 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@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
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 enabledI2C: 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@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.
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 enabledI2C: 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@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
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
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
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' 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
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.
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' 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
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
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
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
On 08.12.2015 12:13, Pavel Machek wrote:
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
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
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' 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
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
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
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.
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
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
participants (4)
-
Chin Liang See -
Marek Vasut -
Pavel Machek -
Stefan Roese