[U-Boot] [PATCH] mx6: invalidate D-cache only when booting from USB
Add a detection at runtime of the boot from USB on i.MX6, and invalidate the D-cache only in that case.
The USB boot detection method is taken from Freescale u-boot commit 1309b1ed78b3 ("ENGR00315499-8 Auto check if boot from usb").
This repairs u-boot when it is built with CONFIG_SKIP_LOWLEVEL_INIT defined, and is booted from another u-boot, which booted from SD card, for example.
Signed-off-by: Vincent Stehlé vincent.stehle@freescale.com Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com Cc: Frank Li Frank.li@freescale.com Cc: Nitin Garg nitin.garg@freescale.com --- arch/arm/cpu/armv7/mx6/soc.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c index 21ef9d0..774f078 100644 --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -350,6 +350,18 @@ int board_postclk_init(void) return 0; }
+/* + * Determine if we booted from USB. + * + * We look at the USBPH0_PWD0.RXPWDRX register to determine if the USB + * PHY is powered on or off. If the USB PHY is turned on, we assume that + * the ROM booted us from USB. + */ +static bool is_boot_from_usb(void) +{ + return !(readl(USB_PHY0_BASE_ADDR) & (1<<20)); +} + #ifndef CONFIG_SYS_DCACHE_OFF void enable_caches(void) { @@ -360,7 +372,8 @@ void enable_caches(void) #endif
/* Avoid random hang when download by usb */ - invalidate_dcache_all(); + if (is_boot_from_usb()) + invalidate_dcache_all();
/* Enable D-cache. I-cache is already enabled in start.S */ dcache_enable();
From: Vincent Stehlé [mailto:vincent.stehle@freescale.com] Sent: Friday, May 22, 2015 9:53 AM To: u-boot@lists.denx.de Cc: Stehle Vincent-B46079; Stefano Babic; Estevam Fabio-R49496; Li Frank- B20596; Garg Nitin-B37173 Subject: [PATCH] mx6: invalidate D-cache only when booting from USB
Add a detection at runtime of the boot from USB on i.MX6, and invalidate the D-cache only in that case.
The USB boot detection method is taken from Freescale u-boot commit 1309b1ed78b3 ("ENGR00315499-8 Auto check if boot from usb").
This repairs u-boot when it is built with CONFIG_SKIP_LOWLEVEL_INIT defined, and is booted from another u-boot, which booted from SD card, for example.
Signed-off-by: Vincent Stehlé vincent.stehle@freescale.com Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com Cc: Frank Li Frank.li@freescale.com Cc: Nitin Garg nitin.garg@freescale.com
arch/arm/cpu/armv7/mx6/soc.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c index 21ef9d0..774f078 100644 --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -350,6 +350,18 @@ int board_postclk_init(void) return 0; }
+/*
- Determine if we booted from USB.
- We look at the USBPH0_PWD0.RXPWDRX register to determine if the
USB
- PHY is powered on or off. If the USB PHY is turned on, we assume
+that
- the ROM booted us from USB.
- */
+static bool is_boot_from_usb(void) +{
- return !(readl(USB_PHY0_BASE_ADDR) & (1<<20)); }
#ifndef CONFIG_SYS_DCACHE_OFF void enable_caches(void) { @@ -360,7 +372,8 @@ void enable_caches(void) #endif
/* Avoid random hang when download by usb */
- invalidate_dcache_all();
- if (is_boot_from_usb())
invalidate_dcache_all();
How about second uboot save in usb mass storage device?
Best regards Frank Li
/* Enable D-cache. I-cache is already enabled in start.S */ dcache_enable(); -- 2.1.4
On 05/22/2015 05:15 PM, Li Frank-B20596 wrote: ..
How about second uboot save in usb mass storage device?
Hi Frank,
I cannot test but I guess this will behave the same as without the patch, which means that it will probably not boot.
Granted, the detection method in is_boot_from_usb() is an approximation, but it repairs one case already and should not break anything.
Best regards,
V.
Hi Vincent,
On 22/05/2015 16:52, Vincent Stehlé wrote:
Add a detection at runtime of the boot from USB on i.MX6, and invalidate the D-cache only in that case.
The USB boot detection method is taken from Freescale u-boot commit 1309b1ed78b3 ("ENGR00315499-8 Auto check if boot from usb").
This repairs u-boot when it is built with CONFIG_SKIP_LOWLEVEL_INIT defined, and is booted from another u-boot, which booted from SD card, for example.
Please help me to find the use case. I searched in all i.MX6 boards in mainline, but none of them is setting CONFIG_SKIP_LOWLEVEL_INIT. Can you tell me on which board there is this issue ?
Signed-off-by: Vincent Stehlé vincent.stehle@freescale.com Cc: Stefano Babic sbabic@denx.de Cc: Fabio Estevam fabio.estevam@freescale.com Cc: Frank Li Frank.li@freescale.com Cc: Nitin Garg nitin.garg@freescale.com
arch/arm/cpu/armv7/mx6/soc.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c index 21ef9d0..774f078 100644 --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -350,6 +350,18 @@ int board_postclk_init(void) return 0; }
+/*
- Determine if we booted from USB.
- We look at the USBPH0_PWD0.RXPWDRX register to determine if the USB
- PHY is powered on or off. If the USB PHY is turned on, we assume that
- the ROM booted us from USB.
- */
+static bool is_boot_from_usb(void) +{
- return !(readl(USB_PHY0_BASE_ADDR) & (1<<20));
+}
This looks like a hack. I understand this can work in your case, but can we set as general case ? You check power for PHY0, but what about if a board is using PHY1 ?
Anyway, is it not possible to get the boot storage from the SRC ?
#ifndef CONFIG_SYS_DCACHE_OFF void enable_caches(void) { @@ -360,7 +372,8 @@ void enable_caches(void) #endif
/* Avoid random hang when download by usb */
- invalidate_dcache_all();
- if (is_boot_from_usb())
invalidate_dcache_all();
I cannot understand well this. The correct implementation seems correct to me. And if you have issues booting with USB, why are you changing the behavior in all other cases *except* booting from USB, where you rely on the current implementation invalidating the cache ?
Best regards, Stefano Babic
Stefano wrote:
Please help me to find the use case. I searched in all i.MX6 boards in mainline, but none of them is setting CONFIG_SKIP_LOWLEVEL_INIT. Can you tell me on which board there is this issue ?
Hi Stefano,
Thank you for taking the time to look at this proposed patch.
You are right, this is a "non standard" use case. What I am trying to do is to boot u-boot with u-boot on i.MX6Q Sabre SD :)
Here are more details on what I would like to do:
1. Boot "old" u-boot from SD card. 2. "old" u-boot loads "new" u-boot from network with 'dhcp' command. 3. "old" u-boot boots "new" u-boot with 'go' command.
This is not so easy to achieve, it seems. I learned that in this peculiar use case it is necessary to set CONFIG_SKIP_LOWLEVEL_INIT when building the "new" u-boot, as hinted by the README.
Also I found out that the call to invalidate_dcache_all() would prevent the boot for the aforementioned use case. "protecting" the call (as done in Freescale u-boot) "repairs" my use case, and I verified that it does not alter the boot through USB.
(boot from USB detection code)
This looks like a hack. I understand this can work in your case, but can we set as general case ? You check power for PHY0, but what about if a board is using PHY1 ? Anyway, is it not possible to get the boot storage from the SRC ?
You are right, the detection code is not perfect. This is the one I borrowed from Freescale u-boot, though, so it is reasonably tested "in the field".
About the phy0/phy1 distinction, I think we can boot only from OTG PHY0 so no worry.
About the SRC; I am not sure you can get the desired information from there, as booting from USB is a ROM "fallback".
(adding a condition to cache invalidation)
I cannot understand well this. The correct implementation seems correct to me. And if you have issues booting with USB, why are you changing the behavior in all other cases *except* booting from USB, where you rely on the current implementation invalidating the cache ?
In my case, it is NOT booting with USB rather, it is booting from another u-boot. I discovered that invalidating the caches in this case breaks the boot.
The current implementation invalidates the cache in all cases for i.MX6, as it believes it is always booting from the ROM.
As the comments hint that invalidating the caches is necessary only when booting from USB (from ROM), I tried to restrict a bit more the invalidation to this "boot from USB" case. The detection is not perfect, but it is enough to repair my use case, at least.
Best regards,
V.
Hi Vincent,
On 26/05/2015 17:16, Vincent wrote:
Stefano wrote:
Please help me to find the use case. I searched in all i.MX6 boards in mainline, but none of them is setting CONFIG_SKIP_LOWLEVEL_INIT. Can you tell me on which board there is this issue ?
Hi Stefano,
Thank you for taking the time to look at this proposed patch.
You are right, this is a "non standard" use case. What I am trying to do is to boot u-boot with u-boot on i.MX6Q Sabre SD :)
ok - so there is a chain of u-boot, and the last one loads and starts the kernel.
Here are more details on what I would like to do:
- Boot "old" u-boot from SD card.
- "old" u-boot loads "new" u-boot from network with 'dhcp' command.
- "old" u-boot boots "new" u-boot with 'go' command.
ok, understood what you are doing.
This is not so easy to achieve, it seems. I learned that in this peculiar use case it is necessary to set CONFIG_SKIP_LOWLEVEL_INIT when building the "new" u-boot, as hinted by the README.
This use case can happen and I had in the past, but I confess with other SOCs. It can be requested if U-Boot in field is outdated and a new U-Boot is required, but updating U-Boot is dangerous, and a chain of multiple (two) U-Boot is chosen.
Anyway, to reach the goal, you have to check the initialization routines. CONFIG_SKIP_LOWLEVEL_INIT should ensure that the DDR controller is not initialized twice. On imx, I guess you will have a u-boot.imx on the board, while the "new" u-boot is in "bin" format. In fact, you do not nned the DCD table that is parsed and applied only by the SOC's Boot ROM.
Also I found out that the call to invalidate_dcache_all() would prevent the boot for the aforementioned use case. "protecting" the call (as done in Freescale u-boot) "repairs" my use case, and I verified that it does not alter the boot through USB.
Before booting the kernel, U-Boot calls "cleanup_before_linux()" to let the SOC in a well knon state. Cache are disable at this point, and this let the kernel doing evething with the hardware. However, when you load U-Boot as different image, this cleanup is not called at all. Maybe it works in your case if cleanup is called even by loading your second u-boot and not only by starting Linux.
(boot from USB detection code)
This looks like a hack. I understand this can work in your case, but can we set as general case ? You check power for PHY0, but what about if a board is using PHY1 ? Anyway, is it not possible to get the boot storage from the SRC ?
You are right, the detection code is not perfect. This is the one I borrowed from Freescale u-boot, though, so it is reasonably tested "in the field".
This cannot be generalized - maybe it does not work on all boards, even if in your case it does the job.
About the phy0/phy1 distinction, I think we can boot only from OTG PHY0 so no worry.
About the SRC; I am not sure you can get the desired information from there, as booting from USB is a ROM "fallback".
(adding a condition to cache invalidation)
I cannot understand well this. The correct implementation seems correct to me. And if you have issues booting with USB, why are you changing the behavior in all other cases *except* booting from USB, where you rely on the current implementation invalidating the cache ?
In my case, it is NOT booting with USB rather, it is booting from another u-boot. I discovered that invalidating the caches in this case breaks the boot.
It should not be. And the second U-Boot should not be started with enabled cache, as it is done now.
The current implementation invalidates the cache in all cases for i.MX6, as it believes it is always booting from the ROM.
As the comments hint that invalidating the caches is necessary only when booting from USB (from ROM), I tried to restrict a bit more the invalidation to this "boot from USB" case. The detection is not perfect, but it is enough to repair my use case, at least.
Best regards, Stefano Babic
participants (4)
-
Li Frank -
Stefano Babic -
Vincent -
Vincent Stehlé