mx6: invalidate D-cache only when booting from USB

PATCH New Vincent Stehlé 4 participants 6 messages May 22, 2015 – May 26, 2015 Arm (32-bit)

lore

Share & tools

lore

Vincent Stehlé

author

2015-05-22 14:52 UTC #0 lore raw

PATCH 1/1 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? <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc Frank Li <[email protected]>

Cc Nitin Garg <[email protected]>

---
 arch/arm/cpu/armv7/mx6/soc.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

arch/arm/cpu/armv7/mx6/soc.c +14 -1

index 21ef9d0..774f078 100644
@@ -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();

Signature · 1 line

2.1.4

Vincent Stehlé

author

2015-05-22 15:37 UTC #2 lore raw

PATCH 1/1 mx6: invalidate D-cache only when booting from USB

On 05/22/2015 05:15 PM, Li Frank-B20596 wrote:
..

Quoted 1 line

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,

Stefano Babic

2015-05-24 07:24 UTC #3 lore raw

PATCH 1/1 mx6: invalidate D-cache only when booting from USB

In reply to Vincent Stehlé

Hi Vincent,

Quoted 9 lines · Vincent Stehl?

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 ?

Quoted 19 lines

Signed-off-by Vincent Stehl? <[email protected]>
Cc Stefano Babic <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Frank Li <[email protected]>
Cc Nitin Garg <[email protected]>
---
 arch/arm/cpu/armv7/mx6/soc.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)
arch/arm/cpu/armv7/mx6/soc.c +1 -0
index 21ef9d0..774f078 100644
@@ -350,6 +350,18 @@ int board_postclk_init(void)
 	return 0;
 }
 
+/*

arch/arm/cpu/armv7/mx6/soc.c int board_postclk_init(void) · line 363

Quoted 10 lines

arch/arm/cpu/armv7/mx6/soc.c +10 -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 ?

arch/arm/cpu/armv7/mx6/soc.c void enable_caches(void) · line 376

Quoted 11 lines

arch/arm/cpu/armv7/mx6/soc.c +3 -1

+
 #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

Signature · 5 lines

=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

Vincent

2015-05-26 15:16 UTC #4 lore raw

PATCH 1/1 mx6: invalidate D-cache only when booting from USB

Quoted 3 lines · Stefano

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)

Quoted 4 lines

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)

Quoted 4 lines

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,

Stefano Babic

2015-05-26 17:08 UTC #5 lore raw

PATCH 1/1 mx6: invalidate D-cache only when booting from USB

Hi Vincent,

Quoted 11 lines · Vincent

Quoted 3 lines · Stefano
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.

Quoted 6 lines

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.

ok, understood what you are doing.

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 10 lines

(boot from USB detection code)
Quoted 4 lines
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.

Quoted 8 lines

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)

Quoted 8 lines

Quoted 4 lines
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.

Quoted 9 lines

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

Signature · 5 lines

=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================