[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
Also could you check if SATA booting is still working correctly?
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
A385 BootROM treats strapping configuration 0x3f as invalid. When booting fails (e.g. because of invalid configuration) then BootROM fallbacks to UART booting.
Detecting BootROM fallback to UART booting is implemented in U-Boot since commit 2fd4284051e3 ("ARM: mach-mvebu: handle fall-back to UART boot").
So there is no need to define BOOT_FROM_UART_ALT constant and special handling for it anymore, remove it.
This change effectively revers commit f3a88e2ca17a ("arm: mvebu: fix boot from UART on ClearFog Base").
Signed-off-by: Pali Rohár pali@kernel.org --- arch/arm/mach-mvebu/cpu.c | 3 --- arch/arm/mach-mvebu/include/mach/soc.h | 1 - 2 files changed, 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index 018a3614d4dd..c187bbede722 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -109,9 +109,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_MMC1; #endif case BOOT_FROM_UART: -#ifdef BOOT_FROM_UART_ALT - case BOOT_FROM_UART_ALT: -#endif return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA: diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 3b9618852c6d..e559d9f9791e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -164,7 +164,6 @@ #define BOOT_FROM_SATA 0x22 #define BOOT_FROM_UART 0x28 #define BOOT_FROM_SATA_ALT 0x2A -#define BOOT_FROM_UART_ALT 0x3f #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31
A385 BootROM treats strapping configuration 0x22 as SPI-NAND. So remove incorrect definition 0x22 as SATA. SATA on A385 has configuration 0x2A.
Signed-off-by: Pali Rohár pali@kernel.org --- arch/arm/mach-mvebu/cpu.c | 1 - arch/arm/mach-mvebu/include/mach/soc.h | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index c187bbede722..daa84c03fcdc 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -112,7 +112,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA: - case BOOT_FROM_SATA_ALT: return BOOT_DEVICE_SATA; #endif case BOOT_FROM_SPI: diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index e559d9f9791e..5fdce8fe4e7e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -161,9 +161,8 @@ #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x22 +#define BOOT_FROM_SATA 0x2A #define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SATA_ALT 0x2A #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants.
Signed-off-by: Pali Rohár pali@kernel.org --- arch/arm/mach-mvebu/cpu.c | 16 +++++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 25 ++++++++++++------------- 2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index daa84c03fcdc..cb3f3afad269 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -98,24 +98,26 @@ u32 get_boot_device(void) val = readl(CONFIG_SAR_REG); /* SAR - Sample At Reset */ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS; debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device); - switch (boot_device) { #ifdef BOOT_FROM_NAND - case BOOT_FROM_NAND: + if (BOOT_FROM_NAND(boot_device)) return BOOT_DEVICE_NAND; #endif #ifdef BOOT_FROM_MMC - case BOOT_FROM_MMC: - case BOOT_FROM_MMC_ALT: + if (BOOT_FROM_MMC(boot_device)) return BOOT_DEVICE_MMC1; #endif - case BOOT_FROM_UART: +#ifdef BOOT_FROM_UART + if (BOOT_FROM_UART(boot_device)) return BOOT_DEVICE_UART; +#endif #ifdef BOOT_FROM_SATA - case BOOT_FROM_SATA: + if (BOOT_FROM_SATA(boot_device)) return BOOT_DEVICE_SATA; #endif - case BOOT_FROM_SPI: +#ifdef BOOT_FROM_SPI + if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI; +#endif default: return BOOT_DEVICE_BOOTROM; }; diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 5fdce8fe4e7e..aa42db36a1ee 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -143,8 +143,8 @@ #define BOOT_DEV_SEL_OFFS 3 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30 -#define BOOT_FROM_SPI 0x38 +#define BOOT_FROM_UART(x) (x == 0x30) +#define BOOT_FROM_SPI(x) (x == 0x38)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(20)) ? \ 200000000 : 166000000) @@ -160,12 +160,11 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x2A -#define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SPI 0x32 -#define BOOT_FROM_MMC 0x30 -#define BOOT_FROM_MMC_ALT 0x31 +#define BOOT_FROM_NAND(x) (x == 0x0A) +#define BOOT_FROM_SATA(x) (x == 0x2A) +#define BOOT_FROM_UART(x) (x == 0x28) +#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) @@ -182,9 +181,9 @@ #define BOOT_DEV_SEL_OFFS 11 #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1 -#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_NAND(x) (x == 0x1) +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 200000000 /* 200MHz */ #elif defined(CONFIG_ARMADA_XP) @@ -204,8 +203,8 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 250000000 /* 250MHz */ #endif
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants.
Signed-off-by: Pali Rohár pali@kernel.org
arch/arm/mach-mvebu/cpu.c | 16 +++++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 25 ++++++++++++------------- 2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index daa84c03fcdc..cb3f3afad269 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -98,24 +98,26 @@ u32 get_boot_device(void) val = readl(CONFIG_SAR_REG); /* SAR - Sample At Reset */ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS; debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
switch (boot_device) {#ifdef BOOT_FROM_NAND
case BOOT_FROM_NAND:
if (BOOT_FROM_NAND(boot_device)) return BOOT_DEVICE_NAND;#endif #ifdef BOOT_FROM_MMC
case BOOT_FROM_MMC:case BOOT_FROM_MMC_ALT:
if (BOOT_FROM_MMC(boot_device)) return BOOT_DEVICE_MMC1;#endif
case BOOT_FROM_UART:+#ifdef BOOT_FROM_UART
if (BOOT_FROM_UART(boot_device)) return BOOT_DEVICE_UART;+#endif #ifdef BOOT_FROM_SATA
case BOOT_FROM_SATA:
if (BOOT_FROM_SATA(boot_device)) return BOOT_DEVICE_SATA;#endif
case BOOT_FROM_SPI:+#ifdef BOOT_FROM_SPI
if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI;+#endif default: return BOOT_DEVICE_BOOTROM; };
This doesn't compile for me: the switch has only partially been converted so I get: arch/arm/mach-mvebu/cpu.c: In function 'get_boot_device': arch/arm/mach-mvebu/cpu.c:118:9: error: 'default' label not within a switch statement 118 | default: | ^~~~~~~ arch/arm/mach-mvebu/cpu.c: At top level: arch/arm/mach-mvebu/cpu.c:121:1: error: expected identifier or '(' before '}' token 121 | } | ^
Maybe remove the default and closing bracket lines and just return BOOT_DEVICE_BOOTROM if nothing else worked? That worked for me.
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h index 5fdce8fe4e7e..aa42db36a1ee 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -143,8 +143,8 @@ #define BOOT_DEV_SEL_OFFS 3 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30 -#define BOOT_FROM_SPI 0x38 +#define BOOT_FROM_UART(x) (x == 0x30) +#define BOOT_FROM_SPI(x) (x == 0x38)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(20)) ? \ 200000000 : 166000000) @@ -160,12 +160,11 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x2A -#define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SPI 0x32 -#define BOOT_FROM_MMC 0x30 -#define BOOT_FROM_MMC_ALT 0x31 +#define BOOT_FROM_NAND(x) (x == 0x0A) +#define BOOT_FROM_SATA(x) (x == 0x2A) +#define BOOT_FROM_UART(x) (x == 0x28) +#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) @@ -182,9 +181,9 @@ #define BOOT_DEV_SEL_OFFS 11 #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1 -#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_NAND(x) (x == 0x1) +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 200000000 /* 200MHz */ #elif defined(CONFIG_ARMADA_XP) @@ -204,8 +203,8 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 250000000 /* 250MHz */
#endif
2.20.1
On Sunday 05 March 2023 03:11:20 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants.
Signed-off-by: Pali Rohár pali@kernel.org
arch/arm/mach-mvebu/cpu.c | 16 +++++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 25 ++++++++++++------------- 2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index daa84c03fcdc..cb3f3afad269 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -98,24 +98,26 @@ u32 get_boot_device(void) val = readl(CONFIG_SAR_REG); /* SAR - Sample At Reset */ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS; debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
switch (boot_device) {#ifdef BOOT_FROM_NAND
case BOOT_FROM_NAND:
if (BOOT_FROM_NAND(boot_device)) return BOOT_DEVICE_NAND;#endif #ifdef BOOT_FROM_MMC
case BOOT_FROM_MMC:case BOOT_FROM_MMC_ALT:
if (BOOT_FROM_MMC(boot_device)) return BOOT_DEVICE_MMC1;#endif
case BOOT_FROM_UART:+#ifdef BOOT_FROM_UART
if (BOOT_FROM_UART(boot_device)) return BOOT_DEVICE_UART;+#endif #ifdef BOOT_FROM_SATA
case BOOT_FROM_SATA:
if (BOOT_FROM_SATA(boot_device)) return BOOT_DEVICE_SATA;#endif
case BOOT_FROM_SPI:+#ifdef BOOT_FROM_SPI
if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI;+#endif default: return BOOT_DEVICE_BOOTROM; };
This doesn't compile for me: the switch has only partially been converted so I get: arch/arm/mach-mvebu/cpu.c: In function 'get_boot_device': arch/arm/mach-mvebu/cpu.c:118:9: error: 'default' label not within a switch statement 118 | default: | ^~~~~~~ arch/arm/mach-mvebu/cpu.c: At top level: arch/arm/mach-mvebu/cpu.c:121:1: error: expected identifier or '(' before '}' token 121 | } | ^
Maybe remove the default and closing bracket lines and just return BOOT_DEVICE_BOOTROM if nothing else worked? That worked for me.
Yea, broken merge on my side which results in the incorrect patch. Fixup for this patch is:
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index cb3f3afad269..4bff94394d41 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -118,9 +118,7 @@ u32 get_boot_device(void) if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI; #endif - default: - return BOOT_DEVICE_BOOTROM; - }; + return BOOT_DEVICE_BOOTROM; }
#if defined(CONFIG_DISPLAY_CPUINFO)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h index 5fdce8fe4e7e..aa42db36a1ee 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -143,8 +143,8 @@ #define BOOT_DEV_SEL_OFFS 3 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30 -#define BOOT_FROM_SPI 0x38 +#define BOOT_FROM_UART(x) (x == 0x30) +#define BOOT_FROM_SPI(x) (x == 0x38)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(20)) ? \ 200000000 : 166000000) @@ -160,12 +160,11 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x2A -#define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SPI 0x32 -#define BOOT_FROM_MMC 0x30 -#define BOOT_FROM_MMC_ALT 0x31 +#define BOOT_FROM_NAND(x) (x == 0x0A) +#define BOOT_FROM_SATA(x) (x == 0x2A) +#define BOOT_FROM_UART(x) (x == 0x28) +#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) @@ -182,9 +181,9 @@ #define BOOT_DEV_SEL_OFFS 11 #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1 -#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_NAND(x) (x == 0x1) +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 200000000 /* 200MHz */ #elif defined(CONFIG_ARMADA_XP) @@ -204,8 +203,8 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 250000000 /* 250MHz */
#endif
2.20.1
Hi Pali,
On 3/5/23 12:48, Pali Rohár wrote:
On Sunday 05 March 2023 03:11:20 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants.
Signed-off-by: Pali Rohár pali@kernel.org
arch/arm/mach-mvebu/cpu.c | 16 +++++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 25 ++++++++++++------------- 2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index daa84c03fcdc..cb3f3afad269 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -98,24 +98,26 @@ u32 get_boot_device(void) val = readl(CONFIG_SAR_REG); /* SAR - Sample At Reset */ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS; debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
switch (boot_device) {case BOOT_FROM_NAND:
if (BOOT_FROM_NAND(boot_device)) return BOOT_DEVICE_NAND;
case BOOT_FROM_MMC:case BOOT_FROM_MMC_ALT:
if (BOOT_FROM_MMC(boot_device)) return BOOT_DEVICE_MMC1;
case BOOT_FROM_UART:+#ifdef BOOT_FROM_UART
if (BOOT_FROM_UART(boot_device)) return BOOT_DEVICE_UART;+#endif #ifdef BOOT_FROM_SATA
case BOOT_FROM_SATA:
if (BOOT_FROM_SATA(boot_device)) return BOOT_DEVICE_SATA;
case BOOT_FROM_SPI:+#ifdef BOOT_FROM_SPI
if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI;+#endif default: return BOOT_DEVICE_BOOTROM; };
This doesn't compile for me: the switch has only partially been converted so I get: arch/arm/mach-mvebu/cpu.c: In function 'get_boot_device': arch/arm/mach-mvebu/cpu.c:118:9: error: 'default' label not within a switch statement 118 | default: | ^~~~~~~ arch/arm/mach-mvebu/cpu.c: At top level: arch/arm/mach-mvebu/cpu.c:121:1: error: expected identifier or '(' before '}' token 121 | } | ^
Maybe remove the default and closing bracket lines and just return BOOT_DEVICE_BOOTROM if nothing else worked? That worked for me.
Yea, broken merge on my side which results in the incorrect patch. Fixup for this patch is:
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index cb3f3afad269..4bff94394d41 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -118,9 +118,7 @@ u32 get_boot_device(void) if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI; #endif
- default:
return BOOT_DEVICE_BOOTROM;- };
return BOOT_DEVICE_BOOTROM; }
#if defined(CONFIG_DISPLAY_CPUINFO)
Applying this series to next does not work for me. Could you please re- send this patch series with all the RB and TB tags and this fix included?
Thanks, Stefan
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h index 5fdce8fe4e7e..aa42db36a1ee 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -143,8 +143,8 @@ #define BOOT_DEV_SEL_OFFS 3 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30 -#define BOOT_FROM_SPI 0x38 +#define BOOT_FROM_UART(x) (x == 0x30) +#define BOOT_FROM_SPI(x) (x == 0x38)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(20)) ? \ 200000000 : 166000000) @@ -160,12 +160,11 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x2A -#define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SPI 0x32 -#define BOOT_FROM_MMC 0x30 -#define BOOT_FROM_MMC_ALT 0x31 +#define BOOT_FROM_NAND(x) (x == 0x0A) +#define BOOT_FROM_SATA(x) (x == 0x2A) +#define BOOT_FROM_UART(x) (x == 0x28) +#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) @@ -182,9 +181,9 @@ #define BOOT_DEV_SEL_OFFS 11 #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1 -#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_NAND(x) (x == 0x1) +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 200000000 /* 200MHz */ #elif defined(CONFIG_ARMADA_XP) @@ -204,8 +203,8 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CONFIG_SYS_TCLK 250000000 /* 250MHz */
#endif
2.20.1
Viele Grüße, Stefan Roese
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are:
0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid
Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete.
Signed-off-by: Pali Rohár pali@kernel.org --- arch/arm/mach-mvebu/include/mach/soc.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index aa42db36a1ee..698b70339436 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) +#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 && x <= 0x25)) +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000)
On Saturday 04 March 2023 11:50:34 Pali Rohár wrote:
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are:
0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid
Clearfog has 5-bit DIP switch and seems that it is directly mapped to the Boot Device mode with most significant bit of boot mode pulled to high (sixth bit not present on the switch) and flipped second, third and fifth bits of the boot mode.
Based on documentation Clearfog DIP switch should be set to 11100 for SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, which is hex 0x2a --> matches A385 SATA boot mode.
Can somebody check if UART debug console boot mode works on Clearfog? It is boot mode when BootROM enters into simple debug console with few commands. Via kwboot it is possible to enter into this mode (it sends magic sequence) but from this information it looks like that it should be possible also without magic sequence, just by configuring boot mode.
Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete.
Signed-off-by: Pali Rohár pali@kernel.org
arch/arm/mach-mvebu/include/mach/soc.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index aa42db36a1ee..698b70339436 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) +#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 && x <= 0x25)) +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) -- 2.20.1
On Sat, 4 Mar 2023 at 11:20, Pali Rohár pali@kernel.org wrote:
On Saturday 04 March 2023 11:50:34 Pali Rohár wrote:
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are:
0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid
Clearfog has 5-bit DIP switch and seems that it is directly mapped to the Boot Device mode with most significant bit of boot mode pulled to high (sixth bit not present on the switch) and flipped second, third and fifth bits of the boot mode.
Based on documentation Clearfog DIP switch should be set to 11100 for SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, which is hex 0x2a --> matches A385 SATA boot mode.
The Clearfog schematics indicate the switch is internally pulled to 0x36 / 110110. 110110 XOR 11100 = 101010 = 0x2a. The math checks out and corresponds to the documented modes as well as the enumeration I did a few years ago: 00000 nothing [0x36] 00001 nothing [0x37] 00010 SPI [0x34] (documented SPI) 00011 SPI [0x35] 00100 SPI [0x32] 00101 SPI [0x33] 00110 MMC (Card did not respond to voltage select!) [0x30] 00111 MMC [0x31] (documented SD/eMMC) 01000 nothing [0x3e] 01001 UART [0x3f] (documented UART) 01010 NOR [0x3c] 01011 nothing [0x3d] 01100 NOR [0x3a] 01101 NOR [0x3b] 01110 nothing [0x38] 01111 nothing [0x39] 10000 nothing [0x26] 10001 nothing [0x27] 10010 NAND [0x24] 10011 NAND [0x25] 10100 NAND [0x22] 10101 NAND [0x23] 10110 NAND [0x20] 10111 NAND [0x21] 11000 NOR [0x2e] 11001 nothing [0x2f] 11010 PEX0 (00) [0x2c] 11011 PEX0 (1A) [0x2d] 11100 nothing [0x2a] (I don't think I had a SATA card attached, but this is documented SATA) 11101 nothing [0x2b] 11110 nothing [0x28] 11111 nothing [0x29] Where "nothing" indicates no BootROM output
Can somebody check if UART debug console boot mode works on Clearfog? It is boot mode when BootROM enters into simple debug console with few commands. Via kwboot it is possible to enter into this mode (it sends magic sequence) but from this information it looks like that it should be possible also without magic sequence, just by configuring boot mode.
I didn't know about this before. I tried with the magic sequence and it works (though it needs the A38x output workaround mentioned here [1]. The boot mode is the one set by 0x3d / 111101 or 0x3e / 111110, right? 0x3d: 111101 XOR 110110 = 01011 0x3e: 111110 XOR 110110 = 01000 Neither of those gives an interactive serial console, and even if the output workaround is entered there is never anything that appears in the console. It doesn't even echo the data I type in.
[1] https://manpages.debian.org/testing/u-boot-tools/kwboot.1.en.html
Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete.
Signed-off-by: Pali Rohár pali@kernel.org
arch/arm/mach-mvebu/include/mach/soc.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index aa42db36a1ee..698b70339436 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 ||
x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C))
+#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 &&
x <= 0x25))
+#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15))
? \
200000000 : 250000000)-- 2.20.1
On Sunday 05 March 2023 00:06:05 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 11:20, Pali Rohár pali@kernel.org wrote:
On Saturday 04 March 2023 11:50:34 Pali Rohár wrote:
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are:
0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid
Clearfog has 5-bit DIP switch and seems that it is directly mapped to the Boot Device mode with most significant bit of boot mode pulled to high (sixth bit not present on the switch) and flipped second, third and fifth bits of the boot mode.
Based on documentation Clearfog DIP switch should be set to 11100 for SATA booting, by flipping bits it is 01010, by adding MSB it is 101010, which is hex 0x2a --> matches A385 SATA boot mode.
The Clearfog schematics indicate the switch is internally pulled to 0x36 / 110110. 110110 XOR 11100 = 101010 = 0x2a. The math checks out and corresponds to the documented modes as well as the enumeration I did a few years ago: 00000 nothing [0x36] 00001 nothing [0x37] 00010 SPI [0x34] (documented SPI) 00011 SPI [0x35] 00100 SPI [0x32] 00101 SPI [0x33] 00110 MMC (Card did not respond to voltage select!) [0x30] 00111 MMC [0x31] (documented SD/eMMC) 01000 nothing [0x3e] 01001 UART [0x3f] (documented UART) 01010 NOR [0x3c] 01011 nothing [0x3d] 01100 NOR [0x3a] 01101 NOR [0x3b] 01110 nothing [0x38] 01111 nothing [0x39] 10000 nothing [0x26] 10001 nothing [0x27] 10010 NAND [0x24] 10011 NAND [0x25] 10100 NAND [0x22] 10101 NAND [0x23] 10110 NAND [0x20] 10111 NAND [0x21] 11000 NOR [0x2e] 11001 nothing [0x2f] 11010 PEX0 (00) [0x2c] 11011 PEX0 (1A) [0x2d] 11100 nothing [0x2a] (I don't think I had a SATA card attached, but this is documented SATA) 11101 nothing [0x2b] 11110 nothing [0x28] 11111 nothing [0x29] Where "nothing" indicates no BootROM output
Can somebody check if UART debug console boot mode works on Clearfog? It is boot mode when BootROM enters into simple debug console with few commands. Via kwboot it is possible to enter into this mode (it sends magic sequence) but from this information it looks like that it should be possible also without magic sequence, just by configuring boot mode.
I didn't know about this before. I tried with the magic sequence and it works (though it needs the A38x output workaround mentioned here [1]. The boot mode is the one set by 0x3d / 111101 or 0x3e / 111110, right? 0x3d: 111101 XOR 110110 = 01011 0x3e: 111110 XOR 110110 = 01000 Neither of those gives an interactive serial console, and even if the output workaround is entered there is never anything that appears in the console. It doesn't even echo the data I type in.
[1] https://manpages.debian.org/testing/u-boot-tools/kwboot.1.en.html
Different options for the same boot source use different configuration of the source. E.g. different MPP pins or different ECC NAND schema, ... It is hardcoded in the BootROM but figure it out is kind hard (executable code refers to the data blocks). 0x28 and 0x3d should use UART0, while 0x29 and 0x3e UART1.
This explains why 0x30 MMC does not work for you and 0x31 MMC works.
There is erratum Ref #: FE-482008 that boot option 0x27 is not supported and erratum Ref #: FE-9360355 that boot option 0x28 is non functional.
UART1 as boot source is completely undocumented and I suspect that because there is errata for 0x28 (UART0), UART in normal mode is somehow completely broken in BootROM.
You wrote that UART debug console mode does not work, so maybe it just proves brokenness and reason why it is undocumented.
I have not fully understood BootROM code, I was just able to decode tables and functions which read strapping pins and decide which boot code calls.
Magic sequence for putting into UART debug console is triggered independently of the strapping pins and (my) workaround with rewriting variable stored in L2/SRAM is always needed when on default location is stored valid image. Also sending magic sequence is not simple because if too many bytes are send then magic sequence cause buffer overflow in the BootROM and CPU reset occurs. So if magic sequence is working for you via kwboot then I'm happy as I when I wrote that kwboot code it was too fragile to stabilize it.
Anyway, I see that BootROM debug console has undocumented command 't' which listen for a short period for the UART magic pattern -- either xmodem or debug console. So maybe via this undocumented command it could be possible to enter into UART xmodem boot mode once UART debug console was activated. If it really works I can image that it could be useful for configuring higher UART speeds (via debug console 'w' commands) before starting xmodem transfer...
Note about 0x3F boot mode. I have not found any A385 documentation for it and BootROM maps this to unknown configuration (not even to UART), which always fails. I suspect that this is something unfinished or another out-of-bound array read and looks like a nice hack to jump to UART booting mode, via fallback mechanism (as the primary way is documented via errata as broken).
Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete.
Signed-off-by: Pali Rohár pali@kernel.org
arch/arm/mach-mvebu/include/mach/soc.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index aa42db36a1ee..698b70339436 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 ||
x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C))
+#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 &&
x <= 0x25))
+#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39)
#define CONFIG_SYS_TCLK ((readl(CONFIG_SAR_REG) & BIT(15))
? \
200000000 : 250000000)-- 2.20.1
A385 BootROM fills into bits [31:28] of register 0x182d0 tracing value, which represents in which state BootROM currently is. BootROM fills one of the possible values: 0x2 (CPU initialization), 0x3 (UART detection), 0x6 (UART booting), 0x8 (PCI Express booting), 0x9 (parallel or SPI NOR booting), 0xA (parallel or SPI NAND booting), 0xB (SATA booting) and 0xE (SD / eMMC booting).
Meaning of these values matches TRACE_* macros from Marvell soc_spec.h file: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013...
Signed-off-by: Pali Rohár pali@kernel.org --- arch/arm/mach-mvebu/include/mach/soc.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 698b70339436..75fe785932c2 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -128,7 +128,14 @@ #define BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0)) #define BOOTROM_ERR_MODE_OFFS 28 #define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS) +#define BOOTROM_ERR_MODE_MAIN 0x2 +#define BOOTROM_ERR_MODE_EXEC 0x3 #define BOOTROM_ERR_MODE_UART 0x6 +#define BOOTROM_ERR_MODE_PEX 0x8 +#define BOOTROM_ERR_MODE_NOR 0x9 +#define BOOTROM_ERR_MODE_NAND 0xA +#define BOOTROM_ERR_MODE_SATA 0xB +#define BOOTROM_ERR_MODE_MMC 0xE #define BOOTROM_ERR_CODE_OFFS 0 #define BOOTROM_ERR_CODE_MASK (0xf << BOOTROM_ERR_CODE_OFFS)
Definitions are according to the MV78460 Hardware Specifications.
Signed-off-by: Pali Rohár pali@kernel.org --- arch/arm/mach-mvebu/include/mach/soc.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 75fe785932c2..49b4c5c7b4d2 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -213,8 +213,12 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
+#define BOOT_FROM_NOR(x) (x == 0x0) +#define BOOT_FROM_NAND(x) (x == 0x1) #define BOOT_FROM_UART(x) (x == 0x2) #define BOOT_FROM_SPI(x) (x == 0x3) +#define BOOT_FROM_PEX(x) (x == 0x4) +#define BOOT_FROM_SATA(x) (x == 0x5)
#define CONFIG_SYS_TCLK 250000000 /* 250MHz */ #endif
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
Thanks, Tony
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote:
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Thanks, Tony
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote:
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
Thanks, Tony
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Hi Pali,
On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote:
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
> Improve code for checking strapping pins which specifies boot mode source. > > Martin, could you test if Clearfog can be still configured into UART > booting mode via HW switches and if it still works correctly? First > patch is reverting UART related commit for Clearfog which I think it not > needed anymore. >
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because of the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA defconfigs. I get the same result without this patch series applied, though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
> Also could you check if SATA booting is still working correctly? >
SATA works correctly.
Perfect!
> Tony, should address problems with SPI booting when it is configured to > different configuration. In fourth commit I added all possible boot mode > strapping pin configurations which are recognized by A385 bootrom (and > not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
I know it's no longer boot mode detection in my test. We knew that worked.
But I can't seem to get that SPI 1 booting to work, and hope you can see something in this log. The strapping pin is 0x34, but the SPI probe on bus 1 always fails. The envs loading on SPI 1 also fails. But the BootROM apparently *can* load the u-boot image from SPI. And after u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe command below).
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 1 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 1 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 62 devices, 22 uclasses, devicetree: separate MMC: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- soc simple_bus 1 [ + ] simple_bus | |-- internal-regs i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 serial 0 [ + ] ns16550_serial | | |-- serial@12000 pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 pinconfig 0 [ ] pinconfig | | | |-- ge-rgmii-pins-0 pinconfig 1 [ ] pinconfig | | | |-- ge-rgmii-pins-1 pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 pinconfig 3 [ ] pinconfig | | | |-- mdio-pins pinconfig 4 [ ] pinconfig | | | |-- ref-clk-pins-0 pinconfig 5 [ ] pinconfig | | | |-- ref-clk-pins-1 pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 pinconfig 8 [ ] pinconfig | | | |-- nand-pins pinconfig 9 [ ] pinconfig | | | |-- nand-rb pinconfig 10 [ ] pinconfig | | | |-- uart-pins-0 pinconfig 11 [ ] pinconfig | | | |-- uart-pins-1 pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins pinconfig 13 [ ] pinconfig | | | |-- sata-pins-0 pinconfig 14 [ ] pinconfig | | | |-- sata-pins-1 pinconfig 15 [ ] pinconfig | | | |-- sata-pins-2 pinconfig 16 [ ] pinconfig | | | |-- sata-pins-3 pinconfig 17 [ ] pinconfig | | | |-- pmx-power-button pinconfig 18 [ ] pinconfig | | | |-- pmx-copy-button pinconfig 19 [ ] pinconfig | | | |-- pmx-reset-button pinconfig 20 [ ] pinconfig | | | |-- pmx-sata1-white-led pinconfig 21 [ ] pinconfig | | | |-- pmx-sata1-red-led pinconfig 22 [ ] pinconfig | | | |-- pmx-sata2-white-led pinconfig 23 [ ] pinconfig | | | |-- pmx-sata2-red-led pinconfig 24 [ ] pinconfig | | | |-- pmx-sys-white-led pinconfig 25 [ ] pinconfig | | | |-- pmx-sys-red-led pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer pinconfig 27 [ ] pinconfig | | | |-- pmx-pwr-off pinconfig 28 [ ] pinconfig | | | |-- pmx-pwr-blue-led pinconfig 29 [ ] pinconfig | | | |-- pmx-pwr-red-led pinconfig 30 [ ] pinconfig | | | |-- pmx-usb-white-led pinconfig 31 [ ] pinconfig | | | `-- pmx-usb-red-led gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 reset 0 [ + ] mvebu-reset | | |-- system-controller@18200 timer 0 [ + ] orion_timer | | |-- timer@20300 ethernet 0 [ + ] mvneta | | |-- ethernet@70000 bootdev 0 [ ] eth_bootdev | | | `-- ethernet@70000.bootdev usb 0 [ ] ehci_mvebu | | |-- usb@58000 mdio 0 [ ] mvmdio | | |-- mdio@72004 rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 spi 0 [ ] mvebu_spi | |-- spi@10680 spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 misc 0 [ ] pcie_mvebu_base | `-- pcie pci 0 [ ] pcie_mvebu | |-- pcie0.0 pci 1 [ ] pcie_mvebu | `-- pcie1.0 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro |-- distro bootmeth 1 [ ] bootmeth_efi |-- efi bootmeth 2 [ ] bootmeth_pxe `-- pxe N2350 > sf probe 0:0 SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB N2350 > sf probe 1:0 Invalid bus 1 (err=-19) dev_get_uclass_priv: null device Failed to initialize SPI flash at 1:0 (error -19) <END LOG>
So I think there is probably some problem in SPL SPI. Note that for a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, spi 0 [ ] mvebu_spi | |-- spi@10680
index 0 is *not* bus 0, it is just the 1st device.
Meanwhile, the sf probe command is supposed to take bus:cs as argument, but it is taking the first device too. My thinking is DM SPI probably has never been tested with this scenario (spi1 is the only active SPI controller in the board).
Thanks, Tony
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
> > Stefan, do you have some AXP board with SATA boot source? Because I'm > adding it for completeness in the last sixth patch. > > Pali Rohár (6): > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > arm: mvebu: Convert BOOT_FROM_* constants to function macros > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > 2 files changed, 35 insertions(+), 26 deletions(-) > > -- > 2.20.1 > >
On Monday 06 March 2023 16:01:58 Tony Dinh wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote:
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote: > > > Improve code for checking strapping pins which specifies boot mode source. > > > > Martin, could you test if Clearfog can be still configured into UART > > booting mode via HW switches and if it still works correctly? First > > patch is reverting UART related commit for Clearfog which I think it not > > needed anymore. > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > you refactored in cpu.c/get_boot_device is all that gets processed. It > decides there is an error and returns BOOT_DEVICE_UART, probably because of > the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
> UART only works if I use the clearfog_spi_defconfig or if I select > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > defconfigs. I get the same result without this patch series applied, though. > > The failed cases have the same output (other than kwboot header patching > output) until after sending boot image data is complete. The output stops > after: > ================================ > 98 % [................................................................. > ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
> It looks like an unrelated issue with kwboot.c, which I was sure was > working after the last patches but I can no longer reproduce a successful > boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
For me it looks like that either mkimage generated incorrect image size for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
> > > Also could you check if SATA booting is still working correctly? > > > > SATA works correctly.
Perfect!
> > > Tony, should address problems with SPI booting when it is configured to > > different configuration. In fourth commit I added all possible boot mode > > strapping pin configurations which are recognized by A385 bootrom (and > > not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
I know it's no longer boot mode detection in my test. We knew that worked.
But I can't seem to get that SPI 1 booting to work, and hope you can see something in this log. The strapping pin is 0x34, but the SPI probe on bus 1 always fails. The envs loading on SPI 1 also fails. But the BootROM apparently *can* load the u-boot image from SPI. And after u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe command below).
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 1 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 1 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 62 devices, 22 uclasses, devicetree: separate MMC: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > dm tree Class Index Probed Driver Name
root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- soc simple_bus 1 [ + ] simple_bus | |-- internal-regs i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 serial 0 [ + ] ns16550_serial | | |-- serial@12000 pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 pinconfig 0 [ ] pinconfig | | | |-- ge-rgmii-pins-0 pinconfig 1 [ ] pinconfig | | | |-- ge-rgmii-pins-1 pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 pinconfig 3 [ ] pinconfig | | | |-- mdio-pins pinconfig 4 [ ] pinconfig | | | |-- ref-clk-pins-0 pinconfig 5 [ ] pinconfig | | | |-- ref-clk-pins-1 pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 pinconfig 8 [ ] pinconfig | | | |-- nand-pins pinconfig 9 [ ] pinconfig | | | |-- nand-rb pinconfig 10 [ ] pinconfig | | | |-- uart-pins-0 pinconfig 11 [ ] pinconfig | | | |-- uart-pins-1 pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins pinconfig 13 [ ] pinconfig | | | |-- sata-pins-0 pinconfig 14 [ ] pinconfig | | | |-- sata-pins-1 pinconfig 15 [ ] pinconfig | | | |-- sata-pins-2 pinconfig 16 [ ] pinconfig | | | |-- sata-pins-3 pinconfig 17 [ ] pinconfig | | | |-- pmx-power-button pinconfig 18 [ ] pinconfig | | | |-- pmx-copy-button pinconfig 19 [ ] pinconfig | | | |-- pmx-reset-button pinconfig 20 [ ] pinconfig | | | |-- pmx-sata1-white-led pinconfig 21 [ ] pinconfig | | | |-- pmx-sata1-red-led pinconfig 22 [ ] pinconfig | | | |-- pmx-sata2-white-led pinconfig 23 [ ] pinconfig | | | |-- pmx-sata2-red-led pinconfig 24 [ ] pinconfig | | | |-- pmx-sys-white-led pinconfig 25 [ ] pinconfig | | | |-- pmx-sys-red-led pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer pinconfig 27 [ ] pinconfig | | | |-- pmx-pwr-off pinconfig 28 [ ] pinconfig | | | |-- pmx-pwr-blue-led pinconfig 29 [ ] pinconfig | | | |-- pmx-pwr-red-led pinconfig 30 [ ] pinconfig | | | |-- pmx-usb-white-led pinconfig 31 [ ] pinconfig | | | `-- pmx-usb-red-led gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 reset 0 [ + ] mvebu-reset | | |-- system-controller@18200 timer 0 [ + ] orion_timer | | |-- timer@20300 ethernet 0 [ + ] mvneta | | |-- ethernet@70000 bootdev 0 [ ] eth_bootdev | | | `-- ethernet@70000.bootdev usb 0 [ ] ehci_mvebu | | |-- usb@58000 mdio 0 [ ] mvmdio | | |-- mdio@72004 rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 spi 0 [ ] mvebu_spi | |-- spi@10680 spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 misc 0 [ ] pcie_mvebu_base | `-- pcie pci 0 [ ] pcie_mvebu | |-- pcie0.0 pci 1 [ ] pcie_mvebu | `-- pcie1.0 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro |-- distro bootmeth 1 [ ] bootmeth_efi |-- efi bootmeth 2 [ ] bootmeth_pxe `-- pxe N2350 > sf probe 0:0 SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB N2350 > sf probe 1:0 Invalid bus 1 (err=-19) dev_get_uclass_priv: null device Failed to initialize SPI flash at 1:0 (error -19)
<END LOG>
So I think there is probably some problem in SPL SPI.
Yes, it clearly proves that problem is only in SPL. And also it proves that you have to use bus 0. So for sure rebuild u-boot and spl with bus number 0.
Note that for a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, spi 0 [ ] mvebu_spi | |-- spi@10680
index 0 is *not* bus 0, it is just the 1st device.
Yea, it looks like that.
Meanwhile, the sf probe command is supposed to take bus:cs as argument, but it is taking the first device too. My thinking is DM SPI probably has never been tested with this scenario (spi1 is the only active SPI controller in the board).
Can you try to trace probe function in u-boot and in spl? I think this should be the key here, why in u-boot it works and in spl not.
Thanks, Tony
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
> > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > adding it for completeness in the last sixth patch. > > > > Pali Rohár (6): > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > -- > > 2.20.1 > > > >
Hi Pali,
On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár pali@kernel.org wrote:
On Monday 06 March 2023 16:01:58 Tony Dinh wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote:
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote: > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote: > > > > > Improve code for checking strapping pins which specifies boot mode source. > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > booting mode via HW switches and if it still works correctly? First > > > patch is reverting UART related commit for Clearfog which I think it not > > > needed anymore. > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > decides there is an error and returns BOOT_DEVICE_UART, probably because of > > the invalid boot workaround for broken UART selection that you identified. > > Ok, so I figured out correctly how this invalid mode works. > > > UART only works if I use the clearfog_spi_defconfig or if I select > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > > defconfigs. I get the same result without this patch series applied, though. > > > > The failed cases have the same output (other than kwboot header patching > > output) until after sending boot image data is complete. The output stops > > after: > > ================================ > > 98 % [................................................................. > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > ================================ > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > instruct mkimage what to put into kwbimage header. > > If I'm looking at the output correctly then SPL was booted, it correctly > trained DDR RAM, returned back to bootrom, kwboot continued sending main > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > is complete. But then there is no output from main u-boot. > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > working after the last patches but I can no longer reproduce a successful > > boot. > > Can you check that you are using _both_ mkimage and kwboot from version > with applying _all_ my patches recently sent to ML? Because both mkimage > and kwboot have fixes for SATA and SDIO images. > > For me it looks like that either mkimage generated incorrect image size > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > from kwbimage header and sent smaller image. > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > SATA works correctly. > > Perfect! > > > > > > Tony, should address problems with SPI booting when it is configured to > > > different configuration. In fourth commit I added all possible boot mode > > > strapping pin configurations which are recognized by A385 bootrom (and > > > not the only one described in the HW spec, which is incomplete).
It works great! Here the strapping is SPI 1 (0x34), and the boot mode is set to "Trying to boot from SPI" correctly. I'm having a problem with SPL SPI probing the device. But I don't think it is not related to this boot mode patch. There is something in SPL SPI that either I don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
I know it's no longer boot mode detection in my test. We knew that worked.
But I can't seem to get that SPI 1 booting to work, and hope you can see something in this log. The strapping pin is 0x34, but the SPI probe on bus 1 always fails. The envs loading on SPI 1 also fails. But the BootROM apparently *can* load the u-boot image from SPI. And after u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe command below).
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 1 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 1 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 62 devices, 22 uclasses, devicetree: separate MMC: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > dm tree Class Index Probed Driver Name
root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- soc simple_bus 1 [ + ] simple_bus | |-- internal-regs i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 serial 0 [ + ] ns16550_serial | | |-- serial@12000 pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 pinconfig 0 [ ] pinconfig | | | |-- ge-rgmii-pins-0 pinconfig 1 [ ] pinconfig | | | |-- ge-rgmii-pins-1 pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 pinconfig 3 [ ] pinconfig | | | |-- mdio-pins pinconfig 4 [ ] pinconfig | | | |-- ref-clk-pins-0 pinconfig 5 [ ] pinconfig | | | |-- ref-clk-pins-1 pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 pinconfig 8 [ ] pinconfig | | | |-- nand-pins pinconfig 9 [ ] pinconfig | | | |-- nand-rb pinconfig 10 [ ] pinconfig | | | |-- uart-pins-0 pinconfig 11 [ ] pinconfig | | | |-- uart-pins-1 pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins pinconfig 13 [ ] pinconfig | | | |-- sata-pins-0 pinconfig 14 [ ] pinconfig | | | |-- sata-pins-1 pinconfig 15 [ ] pinconfig | | | |-- sata-pins-2 pinconfig 16 [ ] pinconfig | | | |-- sata-pins-3 pinconfig 17 [ ] pinconfig | | | |-- pmx-power-button pinconfig 18 [ ] pinconfig | | | |-- pmx-copy-button pinconfig 19 [ ] pinconfig | | | |-- pmx-reset-button pinconfig 20 [ ] pinconfig | | | |-- pmx-sata1-white-led pinconfig 21 [ ] pinconfig | | | |-- pmx-sata1-red-led pinconfig 22 [ ] pinconfig | | | |-- pmx-sata2-white-led pinconfig 23 [ ] pinconfig | | | |-- pmx-sata2-red-led pinconfig 24 [ ] pinconfig | | | |-- pmx-sys-white-led pinconfig 25 [ ] pinconfig | | | |-- pmx-sys-red-led pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer pinconfig 27 [ ] pinconfig | | | |-- pmx-pwr-off pinconfig 28 [ ] pinconfig | | | |-- pmx-pwr-blue-led pinconfig 29 [ ] pinconfig | | | |-- pmx-pwr-red-led pinconfig 30 [ ] pinconfig | | | |-- pmx-usb-white-led pinconfig 31 [ ] pinconfig | | | `-- pmx-usb-red-led gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 reset 0 [ + ] mvebu-reset | | |-- system-controller@18200 timer 0 [ + ] orion_timer | | |-- timer@20300 ethernet 0 [ + ] mvneta | | |-- ethernet@70000 bootdev 0 [ ] eth_bootdev | | | `-- ethernet@70000.bootdev usb 0 [ ] ehci_mvebu | | |-- usb@58000 mdio 0 [ ] mvmdio | | |-- mdio@72004 rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 spi 0 [ ] mvebu_spi | |-- spi@10680 spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 misc 0 [ ] pcie_mvebu_base | `-- pcie pci 0 [ ] pcie_mvebu | |-- pcie0.0 pci 1 [ ] pcie_mvebu | `-- pcie1.0 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro |-- distro bootmeth 1 [ ] bootmeth_efi |-- efi bootmeth 2 [ ] bootmeth_pxe `-- pxe N2350 > sf probe 0:0 SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB N2350 > sf probe 1:0 Invalid bus 1 (err=-19) dev_get_uclass_priv: null device Failed to initialize SPI flash at 1:0 (error -19)
<END LOG>
So I think there is probably some problem in SPL SPI.
Yes, it clearly proves that problem is only in SPL. And also it proves that you have to use bus 0. So for sure rebuild u-boot and spl with bus number 0.
Yes, indeed. Now it's working again after I removed all bus 1 configs and let all default to 0.
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe name=spi_flash busnum=0 cd=0
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) Thecus N2350 <END LOG>
So the one time that it did not work with bus=0 must have been a bad test. Now onto tracing why the DM SPI probe works in u-boot, even with bus=1.
Thanks, Tony
Note that for a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, spi 0 [ ] mvebu_spi | |-- spi@10680
index 0 is *not* bus 0, it is just the 1st device.
Yea, it looks like that.
Meanwhile, the sf probe command is supposed to take bus:cs as argument, but it is taking the first device too. My thinking is DM SPI probably has never been tested with this scenario (spi1 is the only active SPI controller in the board).
Can you try to trace probe function in u-boot and in spl? I think this should be the key here, why in u-boot it works and in spl not.
Thanks, Tony
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - 13:52:31 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 0 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
Thanks, Tony
> > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > adding it for completeness in the last sixth patch. > > > > > > Pali Rohár (6): > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > >
On Monday 06 March 2023 20:15:07 Tony Dinh wrote:
Hi Pali,
On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár pali@kernel.org wrote:
On Monday 06 March 2023 16:01:58 Tony Dinh wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote:
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote: > > Hi Pali, > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote: > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote: > > > > > > > Improve code for checking strapping pins which specifies boot mode source. > > > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > > booting mode via HW switches and if it still works correctly? First > > > > patch is reverting UART related commit for Clearfog which I think it not > > > > needed anymore. > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > decides there is an error and returns BOOT_DEVICE_UART, probably because of > > > the invalid boot workaround for broken UART selection that you identified. > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > > > defconfigs. I get the same result without this patch series applied, though. > > > > > > The failed cases have the same output (other than kwboot header patching > > > output) until after sending boot image data is complete. The output stops > > > after: > > > ================================ > > > 98 % [................................................................. > > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > ================================ > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > instruct mkimage what to put into kwbimage header. > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > trained DDR RAM, returned back to bootrom, kwboot continued sending main > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > is complete. But then there is no output from main u-boot. > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > > working after the last patches but I can no longer reproduce a successful > > > boot. > > > > Can you check that you are using _both_ mkimage and kwboot from version > > with applying _all_ my patches recently sent to ML? Because both mkimage > > and kwboot have fixes for SATA and SDIO images. > > > > For me it looks like that either mkimage generated incorrect image size > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > from kwbimage header and sent smaller image. > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > SATA works correctly. > > > > Perfect! > > > > > > > > > Tony, should address problems with SPI booting when it is configured to > > > > different configuration. In fourth commit I added all possible boot mode > > > > strapping pin configurations which are recognized by A385 bootrom (and > > > > not the only one described in the HW spec, which is incomplete). > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode > is set to "Trying to boot from SPI" correctly. I'm having a problem > with SPL SPI probing the device. But I don't think it is not related > to this boot mode patch. There is something in SPL SPI that either I > don't understand or it is a bug.
I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
I know it's no longer boot mode detection in my test. We knew that worked.
But I can't seem to get that SPI 1 booting to work, and hope you can see something in this log. The strapping pin is 0x34, but the SPI probe on bus 1 always fails. The envs loading on SPI 1 also fails. But the BootROM apparently *can* load the u-boot image from SPI. And after u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe command below).
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 1 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 1 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 62 devices, 22 uclasses, devicetree: separate MMC: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > dm tree Class Index Probed Driver Name
root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- soc simple_bus 1 [ + ] simple_bus | |-- internal-regs i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 serial 0 [ + ] ns16550_serial | | |-- serial@12000 pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 pinconfig 0 [ ] pinconfig | | | |-- ge-rgmii-pins-0 pinconfig 1 [ ] pinconfig | | | |-- ge-rgmii-pins-1 pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 pinconfig 3 [ ] pinconfig | | | |-- mdio-pins pinconfig 4 [ ] pinconfig | | | |-- ref-clk-pins-0 pinconfig 5 [ ] pinconfig | | | |-- ref-clk-pins-1 pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 pinconfig 8 [ ] pinconfig | | | |-- nand-pins pinconfig 9 [ ] pinconfig | | | |-- nand-rb pinconfig 10 [ ] pinconfig | | | |-- uart-pins-0 pinconfig 11 [ ] pinconfig | | | |-- uart-pins-1 pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins pinconfig 13 [ ] pinconfig | | | |-- sata-pins-0 pinconfig 14 [ ] pinconfig | | | |-- sata-pins-1 pinconfig 15 [ ] pinconfig | | | |-- sata-pins-2 pinconfig 16 [ ] pinconfig | | | |-- sata-pins-3 pinconfig 17 [ ] pinconfig | | | |-- pmx-power-button pinconfig 18 [ ] pinconfig | | | |-- pmx-copy-button pinconfig 19 [ ] pinconfig | | | |-- pmx-reset-button pinconfig 20 [ ] pinconfig | | | |-- pmx-sata1-white-led pinconfig 21 [ ] pinconfig | | | |-- pmx-sata1-red-led pinconfig 22 [ ] pinconfig | | | |-- pmx-sata2-white-led pinconfig 23 [ ] pinconfig | | | |-- pmx-sata2-red-led pinconfig 24 [ ] pinconfig | | | |-- pmx-sys-white-led pinconfig 25 [ ] pinconfig | | | |-- pmx-sys-red-led pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer pinconfig 27 [ ] pinconfig | | | |-- pmx-pwr-off pinconfig 28 [ ] pinconfig | | | |-- pmx-pwr-blue-led pinconfig 29 [ ] pinconfig | | | |-- pmx-pwr-red-led pinconfig 30 [ ] pinconfig | | | |-- pmx-usb-white-led pinconfig 31 [ ] pinconfig | | | `-- pmx-usb-red-led gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 reset 0 [ + ] mvebu-reset | | |-- system-controller@18200 timer 0 [ + ] orion_timer | | |-- timer@20300 ethernet 0 [ + ] mvneta | | |-- ethernet@70000 bootdev 0 [ ] eth_bootdev | | | `-- ethernet@70000.bootdev usb 0 [ ] ehci_mvebu | | |-- usb@58000 mdio 0 [ ] mvmdio | | |-- mdio@72004 rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 spi 0 [ ] mvebu_spi | |-- spi@10680 spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 misc 0 [ ] pcie_mvebu_base | `-- pcie pci 0 [ ] pcie_mvebu | |-- pcie0.0 pci 1 [ ] pcie_mvebu | `-- pcie1.0 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro |-- distro bootmeth 1 [ ] bootmeth_efi |-- efi bootmeth 2 [ ] bootmeth_pxe `-- pxe N2350 > sf probe 0:0 SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB N2350 > sf probe 1:0 Invalid bus 1 (err=-19) dev_get_uclass_priv: null device Failed to initialize SPI flash at 1:0 (error -19)
<END LOG>
So I think there is probably some problem in SPL SPI.
Yes, it clearly proves that problem is only in SPL. And also it proves that you have to use bus 0. So for sure rebuild u-boot and spl with bus number 0.
Yes, indeed. Now it's working again after I removed all bus 1 configs and let all default to 0.
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe name=spi_flash busnum=0 cd=0
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) Thecus N2350
<END LOG>
So the one time that it did not work with bus=0 must have been a bad test. Now onto tracing why the DM SPI probe works in u-boot, even with bus=1.
Look at your output with bus=1 properly, it does _not_ work as expected:
Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
bus 1 is _invalid_.
Thanks, Tony
Note that for a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, spi 0 [ ] mvebu_spi | |-- spi@10680
index 0 is *not* bus 0, it is just the 1st device.
Yea, it looks like that.
Meanwhile, the sf probe command is supposed to take bus:cs as argument, but it is taking the first device too. My thinking is DM SPI probably has never been tested with this scenario (spi1 is the only active SPI controller in the board).
Can you try to trace probe function in u-boot and in spl? I think this should be the key here, why in u-boot it works and in spl not.
Thanks, Tony
> > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - > 13:52:31 -0800) > High speed PHY - Version: 2.0 > Detected Device ID 6820 > board SerDes lanes topology details: > | Lane # | Speed | Type | > -------------------------------- > | 0 | 0 | SGMII0 | > | 1 | 3 | SATA0 | > | 2 | 3 | SATA1 | > | 4 | 5 | USB3 HOST0 | > | 5 | 5 | USB3 HOST1 | > -------------------------------- > High speed PHY - Ended Successfully > mv_ddr: 14.0.0 > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > mv_ddr: completed successfully > SAR_REG=0xcb00934c boot_device=0x34 > Trying to boot from SPI > spl_spi_load_image sf_bus = 0 sf_cs = 0 > spi_flash_probe spi_flash > Invalid bus 0 (err=-19) > SPI probe failed. > Trying to boot from BOOTROM > Returning to BootROM (return address 0xffff05c4)... > BootROM: Image checksum verification PASSED > > Thanks, > Tony > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > > adding it for completeness in the last sixth patch. > > > > > > > > Pali Rohár (6): > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > > > > > >
Hi Pali,
On Mon, Mar 6, 2023 at 11:56 PM Pali Rohár pali@kernel.org wrote:
On Monday 06 March 2023 20:15:07 Tony Dinh wrote:
Hi Pali,
On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár pali@kernel.org wrote:
On Monday 06 March 2023 16:01:58 Tony Dinh wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote: > > > > Hi Pali, > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote: > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote: > > > > > > > > > Improve code for checking strapping pins which specifies boot mode source. > > > > > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > > > booting mode via HW switches and if it still works correctly? First > > > > > patch is reverting UART related commit for Clearfog which I think it not > > > > > needed anymore. > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > > decides there is an error and returns BOOT_DEVICE_UART, probably because of > > > > the invalid boot workaround for broken UART selection that you identified. > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > > > > defconfigs. I get the same result without this patch series applied, though. > > > > > > > > The failed cases have the same output (other than kwboot header patching > > > > output) until after sending boot image data is complete. The output stops > > > > after: > > > > ================================ > > > > 98 % [................................................................. > > > > ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > ================================ > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > > instruct mkimage what to put into kwbimage header. > > > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > > trained DDR RAM, returned back to bootrom, kwboot continued sending main > > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > > is complete. But then there is no output from main u-boot. > > > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > > > working after the last patches but I can no longer reproduce a successful > > > > boot. > > > > > > Can you check that you are using _both_ mkimage and kwboot from version > > > with applying _all_ my patches recently sent to ML? Because both mkimage > > > and kwboot have fixes for SATA and SDIO images. > > > > > > For me it looks like that either mkimage generated incorrect image size > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > > > > SATA works correctly. > > > > > > Perfect! > > > > > > > > > > > > Tony, should address problems with SPI booting when it is configured to > > > > > different configuration. In fourth commit I added all possible boot mode > > > > > strapping pin configurations which are recognized by A385 bootrom (and > > > > > not the only one described in the HW spec, which is incomplete). > > > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode > > is set to "Trying to boot from SPI" correctly. I'm having a problem > > with SPL SPI probing the device. But I don't think it is not related > > to this boot mode patch. There is something in SPL SPI that either I > > don't understand or it is a bug. > > I meant "But I don't think it is related to this boot mode patch".
0x34 uses SPI controller 1. So maybe you need to adjust some config options? In your log is usage of bus 0, so maybe this could be the reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
I know it's no longer boot mode detection in my test. We knew that worked.
But I can't seem to get that SPI 1 booting to work, and hope you can see something in this log. The strapping pin is 0x34, but the SPI probe on bus 1 always fails. The envs loading on SPI 1 also fails. But the BootROM apparently *can* load the u-boot image from SPI. And after u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe command below).
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 1 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 1 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 62 devices, 22 uclasses, devicetree: separate MMC: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > dm tree Class Index Probed Driver Name
root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- soc simple_bus 1 [ + ] simple_bus | |-- internal-regs i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 serial 0 [ + ] ns16550_serial | | |-- serial@12000 pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 pinconfig 0 [ ] pinconfig | | | |-- ge-rgmii-pins-0 pinconfig 1 [ ] pinconfig | | | |-- ge-rgmii-pins-1 pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 pinconfig 3 [ ] pinconfig | | | |-- mdio-pins pinconfig 4 [ ] pinconfig | | | |-- ref-clk-pins-0 pinconfig 5 [ ] pinconfig | | | |-- ref-clk-pins-1 pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 pinconfig 8 [ ] pinconfig | | | |-- nand-pins pinconfig 9 [ ] pinconfig | | | |-- nand-rb pinconfig 10 [ ] pinconfig | | | |-- uart-pins-0 pinconfig 11 [ ] pinconfig | | | |-- uart-pins-1 pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins pinconfig 13 [ ] pinconfig | | | |-- sata-pins-0 pinconfig 14 [ ] pinconfig | | | |-- sata-pins-1 pinconfig 15 [ ] pinconfig | | | |-- sata-pins-2 pinconfig 16 [ ] pinconfig | | | |-- sata-pins-3 pinconfig 17 [ ] pinconfig | | | |-- pmx-power-button pinconfig 18 [ ] pinconfig | | | |-- pmx-copy-button pinconfig 19 [ ] pinconfig | | | |-- pmx-reset-button pinconfig 20 [ ] pinconfig | | | |-- pmx-sata1-white-led pinconfig 21 [ ] pinconfig | | | |-- pmx-sata1-red-led pinconfig 22 [ ] pinconfig | | | |-- pmx-sata2-white-led pinconfig 23 [ ] pinconfig | | | |-- pmx-sata2-red-led pinconfig 24 [ ] pinconfig | | | |-- pmx-sys-white-led pinconfig 25 [ ] pinconfig | | | |-- pmx-sys-red-led pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer pinconfig 27 [ ] pinconfig | | | |-- pmx-pwr-off pinconfig 28 [ ] pinconfig | | | |-- pmx-pwr-blue-led pinconfig 29 [ ] pinconfig | | | |-- pmx-pwr-red-led pinconfig 30 [ ] pinconfig | | | |-- pmx-usb-white-led pinconfig 31 [ ] pinconfig | | | `-- pmx-usb-red-led gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 reset 0 [ + ] mvebu-reset | | |-- system-controller@18200 timer 0 [ + ] orion_timer | | |-- timer@20300 ethernet 0 [ + ] mvneta | | |-- ethernet@70000 bootdev 0 [ ] eth_bootdev | | | `-- ethernet@70000.bootdev usb 0 [ ] ehci_mvebu | | |-- usb@58000 mdio 0 [ ] mvmdio | | |-- mdio@72004 rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 spi 0 [ ] mvebu_spi | |-- spi@10680 spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 misc 0 [ ] pcie_mvebu_base | `-- pcie pci 0 [ ] pcie_mvebu | |-- pcie0.0 pci 1 [ ] pcie_mvebu | `-- pcie1.0 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro |-- distro bootmeth 1 [ ] bootmeth_efi |-- efi bootmeth 2 [ ] bootmeth_pxe `-- pxe N2350 > sf probe 0:0 SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB N2350 > sf probe 1:0 Invalid bus 1 (err=-19) dev_get_uclass_priv: null device Failed to initialize SPI flash at 1:0 (error -19)
<END LOG>
So I think there is probably some problem in SPL SPI.
Yes, it clearly proves that problem is only in SPL. And also it proves that you have to use bus 0. So for sure rebuild u-boot and spl with bus number 0.
Yes, indeed. Now it's working again after I removed all bus 1 configs and let all default to 0.
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe name=spi_flash busnum=0 cd=0
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) Thecus N2350
<END LOG>
So the one time that it did not work with bus=0 must have been a bad test. Now onto tracing why the DM SPI probe works in u-boot, even with bus=1.
Look at your output with bus=1 properly, it does _not_ work as expected:
Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
bus 1 is _invalid_.
Indeed that environment probe did not work. I meant the part that is working is: in u-boot the spi1 was initialized by DM SPI and assigned the index 0, as shown in dm tree. And then we can do "sf probe 0:0".
Thanks, Tony
Note that for a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, spi 0 [ ] mvebu_spi | |-- spi@10680
index 0 is *not* bus 0, it is just the 1st device.
Yea, it looks like that.
Meanwhile, the sf probe command is supposed to take bus:cs as argument, but it is taking the first device too. My thinking is DM SPI probably has never been tested with this scenario (spi1 is the only active SPI controller in the board).
Can you try to trace probe function in u-boot and in spl? I think this should be the key here, why in u-boot it works and in spl not.
Thanks, Tony
> > > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - > > 13:52:31 -0800) > > High speed PHY - Version: 2.0 > > Detected Device ID 6820 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 0 | SGMII0 | > > | 1 | 3 | SATA0 | > > | 2 | 3 | SATA1 | > > | 4 | 5 | USB3 HOST0 | > > | 5 | 5 | USB3 HOST1 | > > -------------------------------- > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > SAR_REG=0xcb00934c boot_device=0x34 > > Trying to boot from SPI > > spl_spi_load_image sf_bus = 0 sf_cs = 0 > > spi_flash_probe spi_flash > > Invalid bus 0 (err=-19) > > SPI probe failed. > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > BootROM: Image checksum verification PASSED > > > > Thanks, > > Tony > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > Pali Rohár (6): > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > -- > > > > > 2.20.1 > > > > > > > > > >
On Tuesday 07 March 2023 12:53:45 Tony Dinh wrote:
Hi Pali,
On Mon, Mar 6, 2023 at 11:56 PM Pali Rohár pali@kernel.org wrote:
On Monday 06 March 2023 20:15:07 Tony Dinh wrote:
Hi Pali,
On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár pali@kernel.org wrote:
On Monday 06 March 2023 16:01:58 Tony Dinh wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár pali@kernel.org wrote: > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh mibodhi@gmail.com wrote: > > > > > > Hi Pali, > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár pali@kernel.org wrote: > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote: > > > > > > > > > > > Improve code for checking strapping pins which specifies boot mode source. > > > > > > > > > > > > Martin, could you test if Clearfog can be still configured into UART > > > > > > booting mode via HW switches and if it still works correctly? First > > > > > > patch is reverting UART related commit for Clearfog which I think it not > > > > > > needed anymore. > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that > > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > > > decides there is an error and returns BOOT_DEVICE_UART, probably because of > > > > > the invalid boot workaround for broken UART selection that you identified. > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I select > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA > > > > > defconfigs. I get the same result without this patch series applied, though. > > > > > > > > > > The failed cases have the same output (other than kwboot header patching > > > > > output) until after sending boot image data is complete. The output stops > > > > > after: > > > > > ================================ > > > > > 98 % [................................................................. > > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > ================================ > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > > > trained DDR RAM, returned back to bootrom, kwboot continued sending main > > > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was > > > > > working after the last patches but I can no longer reproduce a successful > > > > > boot. > > > > > > > > Can you check that you are using _both_ mkimage and kwboot from version > > > > with applying _all_ my patches recently sent to ML? Because both mkimage > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > For me it looks like that either mkimage generated incorrect image size > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > Perfect! > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it is configured to > > > > > > different configuration. In fourth commit I added all possible boot mode > > > > > > strapping pin configurations which are recognized by A385 bootrom (and > > > > > > not the only one described in the HW spec, which is incomplete). > > > > > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode > > > is set to "Trying to boot from SPI" correctly. I'm having a problem > > > with SPL SPI probing the device. But I don't think it is not related > > > to this boot mode patch. There is something in SPL SPI that either I > > > don't understand or it is a bug. > > > > I meant "But I don't think it is related to this boot mode patch". > > 0x34 uses SPI controller 1. So maybe you need to adjust some config > options? In your log is usage of bus 0, so maybe this could be the > reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works.
I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ?
I know it's no longer boot mode detection in my test. We knew that worked.
But I can't seem to get that SPI 1 booting to work, and hope you can see something in this log. The strapping pin is 0x34, but the SPI probe on bus 1 always fails. The envs loading on SPI 1 also fails. But the BootROM apparently *can* load the u-boot image from SPI. And after u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe command below).
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 1 sf_cs = 0 spi_flash_probe spi_flash Invalid bus 1 (err=-19) SPI probe failed. Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 -0800) Thecus N2350
SoC: MV88F6820-A0 at 1066 MHz DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) Core: 62 devices, 22 uclasses, devicetree: separate MMC: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
Model: Thecus N2350 Net: Warning: ethernet@70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65 eth0: ethernet@70000 Hit any key to stop autoboot: 0 N2350 > dm tree Class Index Probed Driver Name
root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- soc simple_bus 1 [ + ] simple_bus | |-- internal-regs i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 serial 0 [ + ] ns16550_serial | | |-- serial@12000 pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 pinconfig 0 [ ] pinconfig | | | |-- ge-rgmii-pins-0 pinconfig 1 [ ] pinconfig | | | |-- ge-rgmii-pins-1 pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 pinconfig 3 [ ] pinconfig | | | |-- mdio-pins pinconfig 4 [ ] pinconfig | | | |-- ref-clk-pins-0 pinconfig 5 [ ] pinconfig | | | |-- ref-clk-pins-1 pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 pinconfig 8 [ ] pinconfig | | | |-- nand-pins pinconfig 9 [ ] pinconfig | | | |-- nand-rb pinconfig 10 [ ] pinconfig | | | |-- uart-pins-0 pinconfig 11 [ ] pinconfig | | | |-- uart-pins-1 pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins pinconfig 13 [ ] pinconfig | | | |-- sata-pins-0 pinconfig 14 [ ] pinconfig | | | |-- sata-pins-1 pinconfig 15 [ ] pinconfig | | | |-- sata-pins-2 pinconfig 16 [ ] pinconfig | | | |-- sata-pins-3 pinconfig 17 [ ] pinconfig | | | |-- pmx-power-button pinconfig 18 [ ] pinconfig | | | |-- pmx-copy-button pinconfig 19 [ ] pinconfig | | | |-- pmx-reset-button pinconfig 20 [ ] pinconfig | | | |-- pmx-sata1-white-led pinconfig 21 [ ] pinconfig | | | |-- pmx-sata1-red-led pinconfig 22 [ ] pinconfig | | | |-- pmx-sata2-white-led pinconfig 23 [ ] pinconfig | | | |-- pmx-sata2-red-led pinconfig 24 [ ] pinconfig | | | |-- pmx-sys-white-led pinconfig 25 [ ] pinconfig | | | |-- pmx-sys-red-led pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer pinconfig 27 [ ] pinconfig | | | |-- pmx-pwr-off pinconfig 28 [ ] pinconfig | | | |-- pmx-pwr-blue-led pinconfig 29 [ ] pinconfig | | | |-- pmx-pwr-red-led pinconfig 30 [ ] pinconfig | | | |-- pmx-usb-white-led pinconfig 31 [ ] pinconfig | | | `-- pmx-usb-red-led gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 reset 0 [ + ] mvebu-reset | | |-- system-controller@18200 timer 0 [ + ] orion_timer | | |-- timer@20300 ethernet 0 [ + ] mvneta | | |-- ethernet@70000 bootdev 0 [ ] eth_bootdev | | | `-- ethernet@70000.bootdev usb 0 [ ] ehci_mvebu | | |-- usb@58000 mdio 0 [ ] mvmdio | | |-- mdio@72004 rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 spi 0 [ ] mvebu_spi | |-- spi@10680 spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 misc 0 [ ] pcie_mvebu_base | `-- pcie pci 0 [ ] pcie_mvebu | |-- pcie0.0 pci 1 [ ] pcie_mvebu | `-- pcie1.0 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro |-- distro bootmeth 1 [ ] bootmeth_efi |-- efi bootmeth 2 [ ] bootmeth_pxe `-- pxe N2350 > sf probe 0:0 SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB N2350 > sf probe 1:0 Invalid bus 1 (err=-19) dev_get_uclass_priv: null device Failed to initialize SPI flash at 1:0 (error -19)
<END LOG>
So I think there is probably some problem in SPL SPI.
Yes, it clearly proves that problem is only in SPL. And also it proves that you have to use bus 0. So for sure rebuild u-boot and spl with bus number 0.
Yes, indeed. Now it's working again after I removed all bus 1 configs and let all default to 0.
<BEGIN LOG> BootROM - 1.73 Booting from SPI flash
U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) High speed PHY - Version: 2.0 Detected Device ID 6820 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 0 | SGMII0 | | 1 | 3 | SATA0 | | 2 | 3 | SATA1 | | 4 | 5 | USB3 HOST0 | | 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR4 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully SAR_REG=0xcb00934c boot_device=0x34 Trying to boot from SPI spl_spi_load_image sf_bus = 0 sf_cs = 0 spi_flash_probe name=spi_flash busnum=0 cd=0
U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 -0800) Thecus N2350
<END LOG>
So the one time that it did not work with bus=0 must have been a bad test. Now onto tracing why the DM SPI probe works in u-boot, even with bus=1.
Look at your output with bus=1 properly, it does _not_ work as expected:
Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment
bus 1 is _invalid_.
Indeed that environment probe did not work. I meant the part that is working is: in u-boot the spi1 was initialized by DM SPI and assigned the index 0, as shown in dm tree. And then we can do "sf probe 0:0".
Yes, this is what I thought too.
Thanks, Tony
Note that for a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, spi 0 [ ] mvebu_spi | |-- spi@10680
index 0 is *not* bus 0, it is just the 1st device.
Yea, it looks like that.
Meanwhile, the sf probe command is supposed to take bus:cs as argument, but it is taking the first device too. My thinking is DM SPI probably has never been tested with this scenario (spi1 is the only active SPI controller in the board).
Can you try to trace probe function in u-boot and in spl? I think this should be the key here, why in u-boot it works and in spl not.
Thanks, Tony
> > > > > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 - > > > 13:52:31 -0800) > > > High speed PHY - Version: 2.0 > > > Detected Device ID 6820 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > -------------------------------- > > > | 0 | 0 | SGMII0 | > > > | 1 | 3 | SATA0 | > > > | 2 | 3 | SATA1 | > > > | 4 | 5 | USB3 HOST0 | > > > | 5 | 5 | USB3 HOST1 | > > > -------------------------------- > > > High speed PHY - Ended Successfully > > > mv_ddr: 14.0.0 > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > > > mv_ddr: completed successfully > > > SAR_REG=0xcb00934c boot_device=0x34 > > > Trying to boot from SPI > > > spl_spi_load_image sf_bus = 0 sf_cs = 0 > > > spi_flash_probe spi_flash > > > Invalid bus 0 (err=-19) > > > SPI probe failed. > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0xffff05c4)... > > > BootROM: Image checksum verification PASSED > > > > > > Thanks, > > > Tony > > > > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > Pali Rohár (6): > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.20.1 > > > > > > > > > > > >
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode
source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it
not
needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch
that
you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because
of
the invalid boot workaround for broken UART selection that you
identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or
SATA
defconfigs. I get the same result without this patch series applied,
though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
I tested using the latest next branch which has those changes in it. Steps: - Set UART boot mode on device - make clean - make clearfog_defconfig - make - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect image size
for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [......................................................................] <snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 % [......................................................................] <snip> 98 % [.................................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [......................................................................] <snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 | -------------------------------- High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 % [......................................................................] <snip> 98 % [................................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) </UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let me know if there's other data I can get to help with this one.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot
mode
strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode
source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it
not
needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch
that
you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because
of
the invalid boot workaround for broken UART selection that you
identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or
SATA
defconfigs. I get the same result without this patch series applied,
though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
I tested using the latest next branch which has those changes in it. Steps:
- Set UART boot mode on device
- make clean
- make clearfog_defconfig
- make
- ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect image size
for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [......................................................................] <snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 % [......................................................................]
<snip> 98 % [.................................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [......................................................................] <snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 % [......................................................................]
<snip> 98 % [................................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) </UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let me know if there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some aligning. It just proves what I wrote before "mkimage generated incorrect image size for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try it too. As mmc booting is working fine from mmc I have felling that bug is in kwboot code which parses mmc images.
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot
mode
strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot mode
source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it
not
needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch
that
you refactored in cpu.c/get_boot_device is all that gets processed. It decides there is an error and returns BOOT_DEVICE_UART, probably because
of
the invalid boot workaround for broken UART selection that you
identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or
SATA
defconfigs. I get the same result without this patch series applied,
though.
The failed cases have the same output (other than kwboot header patching output) until after sending boot image data is complete. The output stops after: ================================ 98 % [................................................................. ] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it correctly trained DDR RAM, returned back to bootrom, kwboot continued sending main u-boot and bootrom confirmed that transfer of both SPL and main u-boot is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure was working after the last patches but I can no longer reproduce a successful boot.
Can you check that you are using _both_ mkimage and kwboot from version with applying _all_ my patches recently sent to ML? Because both mkimage and kwboot have fixes for SATA and SDIO images.
I tested using the latest next branch which has those changes in it. Steps:
- Set UART boot mode on device
- make clean
- make clearfog_defconfig
- make
- ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect image size
for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [......................................................................] <snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 % [......................................................................]
<snip> 98 % [.................................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 % [......................................................................] <snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 % [......................................................................]
<snip> 98 % [................................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) </UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let me know if there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some aligning. It just proves what I wrote before "mkimage generated incorrect image size for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try it too. As mmc booting is working fine from mmc I have felling that bug is in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could you try these changes?
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 * count + 4;
+ /* + * For all images except UART, headersz stored in header itself should + * contains header size without padding. For UART image BootROM rounds + * down headersz to multiply of 128 bytes. Therefore align UART headersz + * to multiply of 128 bytes to ensure that remaining UART header bytes + * are not ignored by BootROM. + */ + if (image_get_bootfrom() == IBR_HDR_UART_ID) + headersz = ALIGN(headersz, 128); + return headersz; }
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size, sizeof(uint32_t)); + /* Update the 32-bit data checksum */ + *kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); }
if (!kwboot_img_has_ddr_init(img) && @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem block size\n"); kwboot_img_grow_hdr(img, size, grow); + + /* + * kwbimage v1 contains header size field and for UART type it + * must be set to the aligned xmodem header size because BootROM + * rounds header size down to xmodem block size. + */ + if (kwbimage_version(img) == 1) { + hdrsz += grow; + hdr->headersz_msb = hdrsz >> 16; + hdr->headersz_lsb = cpu_to_le16(hdrsz & 0xffff); + } }
hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot
mode
strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
Improve code for checking strapping pins which specifies boot
mode
source.
Martin, could you test if Clearfog can be still configured into
UART
booting mode via HW switches and if it still works correctly?
First
patch is reverting UART related commit for Clearfog which I
think it
not
needed anymore.
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the
switch
that
you refactored in cpu.c/get_boot_device is all that gets
processed. It
decides there is an error and returns BOOT_DEVICE_UART, probably
because
of
the invalid boot workaround for broken UART selection that you
identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC
or
SATA
defconfigs. I get the same result without this patch series
applied,
though.
The failed cases have the same output (other than kwboot header
patching
output) until after sending boot image data is complete. The
output stops
after:
98 %
[.................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it
correctly
trained DDR RAM, returned back to bootrom, kwboot continued sending
main
u-boot and bootrom confirmed that transfer of both SPL and main
u-boot
is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure
was
working after the last patches but I can no longer reproduce a
successful
boot.
Can you check that you are using _both_ mkimage and kwboot from
version
with applying _all_ my patches recently sent to ML? Because both
mkimage
and kwboot have fixes for SATA and SDIO images.
I tested using the latest next branch which has those changes in it.
Steps:
- Set UART boot mode on device
- make clean
- make clearfog_defconfig
- make
- ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect image size
for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 %
[......................................................................]
<snip> 98 %
[....................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 %
[......................................................................]
<snip> 98 %
[...................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) </UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let me
know if
there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some aligning. It just proves what I wrote before "mkimage generated incorrect image size for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try it too. As mmc booting is working fine from mmc I have felling that bug is in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could you try these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 * count
4;
/** For all images except UART, headersz stored in header itselfshould
* contains header size without padding. For UART image BootROMrounds
* down headersz to multiply of 128 bytes. Therefore align UARTheadersz
* to multiply of 128 bytes to ensure that remaining UART headerbytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); } if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem blocksize\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and for UARTtype it
* must be set to the aligned xmodem header size becauseBootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz & 0xffff);} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;Also could you check if SATA booting is still working correctly?
SATA works correctly.
Perfect!
Tony, should address problems with SPI booting when it is
configured to
different configuration. In fourth commit I added all possible
boot
mode
strapping pin configurations which are recognized by A385
bootrom (and
not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source?
Because I'm
adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41
++++++++++++++++----------
2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote:
> Improve code for checking strapping pins which specifies boot
mode
source.
> > Martin, could you test if Clearfog can be still configured into
UART
> booting mode via HW switches and if it still works correctly?
First
> patch is reverting UART related commit for Clearfog which I
think it
not
> needed anymore. >
On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the
switch
that
you refactored in cpu.c/get_boot_device is all that gets
processed. It
decides there is an error and returns BOOT_DEVICE_UART, probably
because
of
the invalid boot workaround for broken UART selection that you
identified.
Ok, so I figured out correctly how this invalid mode works.
UART only works if I use the clearfog_spi_defconfig or if I select CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC
or
SATA
defconfigs. I get the same result without this patch series
applied,
though.
The failed cases have the same output (other than kwboot header
patching
output) until after sending boot image data is complete. The
output stops
after:
98 %
[.................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit] ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it
correctly
trained DDR RAM, returned back to bootrom, kwboot continued sending
main
u-boot and bootrom confirmed that transfer of both SPL and main
u-boot
is complete. But then there is no output from main u-boot.
It looks like an unrelated issue with kwboot.c, which I was sure
was
working after the last patches but I can no longer reproduce a
successful
boot.
Can you check that you are using _both_ mkimage and kwboot from
version
with applying _all_ my patches recently sent to ML? Because both
mkimage
and kwboot have fixes for SATA and SDIO images.
I tested using the latest next branch which has those changes in it.
Steps:
- Set UART boot mode on device
- make clean
- make clearfog_defconfig
- make
- ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect image size
for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 %
[......................................................................]
<snip> 98 %
[....................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 %
[......................................................................]
<snip> 98 %
[...................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) </UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let me
know if
there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some aligning. It just proves what I wrote before "mkimage generated incorrect image size for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try it too. As mmc booting is working fine from mmc I have felling that bug is in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could you try these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
Meanwhile could you do following tests?
1) The one which you done with patched kwboot and kwbimage, but send output (sizes and aligning information from kwboot is useful there).
2) Use kwboot only for sending magic packet (-b without image) and then use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 * count
4;
/** For all images except UART, headersz stored in header itselfshould
* contains header size without padding. For UART image BootROMrounds
* down headersz to multiply of 128 bytes. Therefore align UARTheadersz
* to multiply of 128 bytes to ensure that remaining UART headerbytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); } if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem blocksize\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and for UARTtype it
* must be set to the aligned xmodem header size becauseBootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz & 0xffff);} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;> Also could you check if SATA booting is still working correctly? >
SATA works correctly.
Perfect!
> Tony, should address problems with SPI booting when it is
configured to
> different configuration. In fourth commit I added all possible
boot
mode
> strapping pin configurations which are recognized by A385
bootrom (and
> not the only one described in the HW spec, which is incomplete). > > Stefan, do you have some AXP board with SATA boot source?
Because I'm
> adding it for completeness in the last sixth patch. > > Pali Rohár (6): > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > arm: mvebu: Convert BOOT_FROM_* constants to function macros > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > arch/arm/mach-mvebu/include/mach/soc.h | 41
++++++++++++++++----------
> 2 files changed, 35 insertions(+), 26 deletions(-) > > -- > 2.20.1 > >
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org wrote: > > > Improve code for checking strapping pins which specifies boot
mode
source. > > > > Martin, could you test if Clearfog can be still configured into
UART
> > booting mode via HW switches and if it still works correctly?
First
> > patch is reverting UART related commit for Clearfog which I
think it
not > > needed anymore. > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the
switch
that > you refactored in cpu.c/get_boot_device is all that gets
processed. It
> decides there is an error and returns BOOT_DEVICE_UART, probably
because
of > the invalid boot workaround for broken UART selection that you identified.
Ok, so I figured out correctly how this invalid mode works.
> UART only works if I use the clearfog_spi_defconfig or if I select > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC
or
SATA > defconfigs. I get the same result without this patch series
applied,
though. > > The failed cases have the same output (other than kwboot header
patching
> output) until after sending boot image data is complete. The
output stops
> after: > ================================ > 98 %
[.................................................................
> ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > ================================
This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just instruct mkimage what to put into kwbimage header.
If I'm looking at the output correctly then SPL was booted, it
correctly
trained DDR RAM, returned back to bootrom, kwboot continued sending
main
u-boot and bootrom confirmed that transfer of both SPL and main
u-boot
is complete. But then there is no output from main u-boot.
> It looks like an unrelated issue with kwboot.c, which I was sure
was
> working after the last patches but I can no longer reproduce a
successful
> boot.
Can you check that you are using _both_ mkimage and kwboot from
version
with applying _all_ my patches recently sent to ML? Because both
mkimage
and kwboot have fixes for SATA and SDIO images.
I tested using the latest next branch which has those changes in it.
Steps:
- Set UART boot mode on device
- make clean
- make clearfog_defconfig
- make
- ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect image size
for SATA or SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 %
[......................................................................]
<snip> 98 %
[....................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog Pro. Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 %
[......................................................................]
<snip> 98 %
[...................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) </UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let me
know if
there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some aligning. It just proves what I wrote before "mkimage generated incorrect image size for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try it too. As mmc booting is working fine from mmc I have felling that bug is in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could you try these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/' ./arch/arm/mach-mvebu/kwbimage.cfg > kwbimage.uart.cfg ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option and check if you see early announce message on UART.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 * count
4;
/** For all images except UART, headersz stored in header itselfshould
* contains header size without padding. For UART image BootROMrounds
* down headersz to multiply of 128 bytes. Therefore align UARTheadersz
* to multiply of 128 bytes to ensure that remaining UART headerbytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); } if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem blocksize\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and for UARTtype it
* must be set to the aligned xmodem header size becauseBootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz & 0xffff);} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;> > Also could you check if SATA booting is still working correctly? > > > > SATA works correctly.
Perfect!
> > > Tony, should address problems with SPI booting when it is
configured to
> > different configuration. In fourth commit I added all possible
boot
mode > > strapping pin configurations which are recognized by A385
bootrom (and
> > not the only one described in the HW spec, which is incomplete). > > > > Stefan, do you have some AXP board with SATA boot source?
Because I'm
> > adding it for completeness in the last sixth patch. > > > > Pali Rohár (6): > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > arch/arm/mach-mvebu/include/mach/soc.h | 41
++++++++++++++++----------
> > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > -- > > 2.20.1 > > > >
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
> On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org
wrote:
> > > > > Improve code for checking strapping pins which specifies
boot
mode
> source. > > > > > > Martin, could you test if Clearfog can be still configured
into
UART
> > > booting mode via HW switches and if it still works
correctly?
First
> > > patch is reverting UART related commit for Clearfog which I
think it
> not > > > needed anymore. > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before
the
switch
> that > > you refactored in cpu.c/get_boot_device is all that gets
processed. It
> > decides there is an error and returns BOOT_DEVICE_UART,
probably
because
> of > > the invalid boot workaround for broken UART selection that
you
> identified. > > Ok, so I figured out correctly how this invalid mode works. > > > UART only works if I use the clearfog_spi_defconfig or if I
select
> > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with
the MMC
or
> SATA > > defconfigs. I get the same result without this patch series
applied,
> though. > > > > The failed cases have the same output (other than kwboot
header
patching
> > output) until after sending boot image data is complete. The
output stops
> > after: > > ================================ > > 98 %
[.................................................................
> > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > ================================ > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> instruct mkimage what to put into kwbimage header. > > If I'm looking at the output correctly then SPL was booted, it
correctly
> trained DDR RAM, returned back to bootrom, kwboot continued
sending
main
> u-boot and bootrom confirmed that transfer of both SPL and main
u-boot
> is complete. But then there is no output from main u-boot. > > > It looks like an unrelated issue with kwboot.c, which I was
sure
was
> > working after the last patches but I can no longer reproduce
a
successful
> > boot. > > Can you check that you are using _both_ mkimage and kwboot from
version
> with applying _all_ my patches recently sent to ML? Because
both
mkimage
> and kwboot have fixes for SATA and SDIO images. >
I tested using the latest next branch which has those changes in
it.
Steps:
- Set UART boot mode on device
- make clean
- make clearfog_defconfig
- make
- ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
For me it looks like that either mkimage generated incorrect
image size
> for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> from kwbimage header and sent smaller image. >
<MMC output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with SDIO boot signature Patching image boot signature to UART Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31
+1000)
High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog
Pro.
Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)... 0 %
[......................................................................]
<snip> 98 %
[....................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit] </MMC output>
<MMC sizes> du -b u-boot* 4996828 u-boot 474304 u-boot.bin 15155 u-boot.cfg 19496 u-boot.dtb 474304 u-boot-dtb.bin 474368 u-boot-dtb.img 474368 u-boot.img 1721 u-boot.lds 1069982 u-boot.map 454808 u-boot-nodtb.bin 1307712 u-boot.srec 198841 u-boot.sym 588288 u-boot-with-spl.kwb </MMC sizes>
If I make menuconfig and set the boot mode to UART before making
I get:
<UART output> ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00339-gcefd0449d6 Detected kwbimage v1 with UART boot signature Aligning image header to Xmodem block size Sending boot message. Please reboot the target...\ Sending boot image header (113408 bytes)... 0 %
[......................................................................]
<snip> 94 % [.............................................. ] Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
High speed PHY - Version: 2.0 EEPROM TLV detection failed: Using static config for Clearfog
Pro.
Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type |
| 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | PCIe2 | | 5 | 0 | SGMII2 |
High speed PHY - Ended Successfully mv_ddr: 14.0.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)... 0 %
[......................................................................]
<snip> 98 %
[...................................................................
] Done Finishing transfer [Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
</UART output>
<UART sizes> du -b u-boot* 4997204 u-boot 474400 u-boot.bin 15103 u-boot.cfg 19496 u-boot.dtb 474400 u-boot-dtb.bin 474464 u-boot-dtb.img 474464 u-boot.img 1721 u-boot.lds 1070068 u-boot.map 454904 u-boot-nodtb.bin 1307988 u-boot.srec 198886 u-boot.sym 587904 u-boot-with-spl.kwb </UART sizes>
The difference is very small somewhere if that is the cause. Let
me
know if
there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some
aligning. It
just proves what I wrote before "mkimage generated incorrect image
size
for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try
it
too. As mmc booting is working fine from mmc I have felling that
bug is
in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/' ./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work] That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 *
count
4;
/** For all images except UART, headersz stored in headeritself
should
* contains header size without padding. For UART imageBootROM
rounds
* down headersz to multiply of 128 bytes. Therefore alignUART
headersz
* to multiply of 128 bytes to ensure that remaining UARTheader
bytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); } if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem blocksize\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and forUART
type it
* must be set to the aligned xmodem header sizebecause
BootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz &0xffff);
} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;> > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > SATA works correctly. > > Perfect! > > > > > > Tony, should address problems with SPI booting when it is
configured to
> > > different configuration. In fourth commit I added all
possible
boot
> mode > > > strapping pin configurations which are recognized by A385
bootrom (and
> > > not the only one described in the HW spec, which is
incomplete).
> > > > > > Stefan, do you have some AXP board with SATA boot source?
Because I'm
> > > adding it for completeness in the last sixth patch. > > > > > > Pali Rohár (6): > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > arch/arm/mach-mvebu/include/mach/soc.h | 41
++++++++++++++++----------
> > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > > >
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote: > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org
wrote:
> > > > > > > Improve code for checking strapping pins which specifies
boot
mode
> > source. > > > > > > > > Martin, could you test if Clearfog can be still configured
into
UART
> > > > booting mode via HW switches and if it still works
correctly?
First
> > > > patch is reverting UART related commit for Clearfog which I
think it
> > not > > > > needed anymore. > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before
the
switch
> > that > > > you refactored in cpu.c/get_boot_device is all that gets
processed. It
> > > decides there is an error and returns BOOT_DEVICE_UART,
probably
because
> > of > > > the invalid boot workaround for broken UART selection that
you
> > identified. > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > UART only works if I use the clearfog_spi_defconfig or if I
select
> > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with
the MMC
or
> > SATA > > > defconfigs. I get the same result without this patch series
applied,
> > though. > > > > > > The failed cases have the same output (other than kwboot
header
patching
> > > output) until after sending boot image data is complete. The
output stops
> > > after: > > > ================================ > > > 98 %
[.................................................................
> > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > ================================ > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> > instruct mkimage what to put into kwbimage header. > > > > If I'm looking at the output correctly then SPL was booted, it
correctly
> > trained DDR RAM, returned back to bootrom, kwboot continued
sending
main
> > u-boot and bootrom confirmed that transfer of both SPL and main
u-boot
> > is complete. But then there is no output from main u-boot. > > > > > It looks like an unrelated issue with kwboot.c, which I was
sure
was
> > > working after the last patches but I can no longer reproduce
a
successful
> > > boot. > > > > Can you check that you are using _both_ mkimage and kwboot from
version
> > with applying _all_ my patches recently sent to ML? Because
both
mkimage
> > and kwboot have fixes for SATA and SDIO images. > > > > I tested using the latest next branch which has those changes in
it.
Steps:
> - Set UART boot mode on device > - make clean > - make clearfog_defconfig > - make > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > For me it looks like that either mkimage generated incorrect
image size
> > for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> > from kwbimage header and sent smaller image. > > > > <MMC output> > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > kwboot version 2023.04-rc4-00339-gcefd0449d6 > Detected kwbimage v1 with SDIO boot signature > Patching image boot signature to UART > Aligning image header to Xmodem block size > Sending boot message. Please reboot the target...\ > Sending boot image header (113408 bytes)... > 0 % >
[......................................................................]
> <snip> > 94 % [.............................................. > ] > Done > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31
+1000)
> High speed PHY - Version: 2.0 > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> Detected Device ID 6828 > board SerDes lanes topology details: > | Lane # | Speed | Type | > -------------------------------- > | 0 | 3 | SATA0 | > | 1 | 0 | SGMII1 | > | 2 | 5 | PCIe1 | > | 3 | 5 | USB3 HOST1 | > | 4 | 5 | PCIe2 | > | 5 | 0 | SGMII2 | > -------------------------------- > High speed PHY - Ended Successfully > mv_ddr: 14.0.0 > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > mv_ddr: completed successfully > Trying to boot from BOOTROM > Returning to BootROM (return address 0xffff05c4)... > > Sending boot image data (474564 bytes)... > 0 % >
[......................................................................]
> <snip> > 98 %
[....................................................................
> ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > </MMC output> > > <MMC sizes> > du -b u-boot* > 4996828 u-boot > 474304 u-boot.bin > 15155 u-boot.cfg > 19496 u-boot.dtb > 474304 u-boot-dtb.bin > 474368 u-boot-dtb.img > 474368 u-boot.img > 1721 u-boot.lds > 1069982 u-boot.map > 454808 u-boot-nodtb.bin > 1307712 u-boot.srec > 198841 u-boot.sym > 588288 u-boot-with-spl.kwb > </MMC sizes> > > If I make menuconfig and set the boot mode to UART before making
I get:
> > <UART output> > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > kwboot version 2023.04-rc4-00339-gcefd0449d6 > Detected kwbimage v1 with UART boot signature > Aligning image header to Xmodem block size > Sending boot message. Please reboot the target...\ > Sending boot image header (113408 bytes)... > 0 % >
[......................................................................]
> <snip> > 94 % [.............................................. > ] > Done > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> High speed PHY - Version: 2.0 > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> Detected Device ID 6828 > board SerDes lanes topology details: > | Lane # | Speed | Type | > -------------------------------- > | 0 | 3 | SATA0 | > | 1 | 0 | SGMII1 | > | 2 | 5 | PCIe1 | > | 3 | 5 | USB3 HOST1 | > | 4 | 5 | PCIe2 | > | 5 | 0 | SGMII2 | > -------------------------------- > High speed PHY - Ended Successfully > mv_ddr: 14.0.0 > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > mv_ddr: completed successfully > Trying to boot from BOOTROM > Returning to BootROM (return address 0xffff05c4)... > > Sending boot image data (474404 bytes)... > 0 % >
[......................................................................]
> <snip> > 98 %
[...................................................................
> ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> </UART output> > > <UART sizes> > du -b u-boot* > 4997204 u-boot > 474400 u-boot.bin > 15103 u-boot.cfg > 19496 u-boot.dtb > 474400 u-boot-dtb.bin > 474464 u-boot-dtb.img > 474464 u-boot.img > 1721 u-boot.lds > 1070068 u-boot.map > 454904 u-boot-nodtb.bin > 1307988 u-boot.srec > 198886 u-boot.sym > 587904 u-boot-with-spl.kwb > </UART sizes> > > The difference is very small somewhere if that is the cause. Let
me
know if
> there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some
aligning. It
just proves what I wrote before "mkimage generated incorrect image
size
for SDIO image. Or kwboot incorrectly parsed that image size from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try
it
too. As mmc booting is working fine from mmc I have felling that
bug is
in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/' ./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part. In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
diff --git a/tools/kwboot.c b/tools/kwboot.c index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
+ /* Remove the gap between header and data part by moving data part */ + if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) { + kwboot_printv("Removing gap between image header and data\n"); + memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr), le32_to_cpu(hdr->blocksize)); + hdr->srcaddr = cpu_to_le32(hdrsz); + } else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) { + fprintf(stderr, "Cannot align image with secure header\n"); + goto err; + } + hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
*size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);
That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 *
count
4;
/** For all images except UART, headersz stored in headeritself
should
* contains header size without padding. For UART imageBootROM
rounds
* down headersz to multiply of 128 bytes. Therefore alignUART
headersz
* to multiply of 128 bytes to ensure that remaining UARTheader
bytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); } if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem blocksize\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and forUART
type it
* must be set to the aligned xmodem header sizebecause
BootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz &0xffff);
} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;> > > > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > > > > SATA works correctly. > > > > Perfect! > > > > > > > > > Tony, should address problems with SPI booting when it is
configured to
> > > > different configuration. In fourth commit I added all
possible
boot
> > mode > > > > strapping pin configurations which are recognized by A385
bootrom (and
> > > > not the only one described in the HW spec, which is
incomplete).
> > > > > > > > Stefan, do you have some AXP board with SATA boot source?
Because I'm
> > > > adding it for completeness in the last sixth patch. > > > > > > > > Pali Rohár (6): > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41
++++++++++++++++----------
> > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > > > > > > > >
On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote: > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org
wrote:
> > > > > > > > > Improve code for checking strapping pins which specifies
boot
mode > > > source. > > > > > > > > > > Martin, could you test if Clearfog can be still configured
into
UART > > > > > booting mode via HW switches and if it still works
correctly?
First > > > > > patch is reverting UART related commit for Clearfog which I think it > > > not > > > > > needed anymore. > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before
the
switch > > > that > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > > decides there is an error and returns BOOT_DEVICE_UART,
probably
because > > > of > > > > the invalid boot workaround for broken UART selection that
you
> > > identified. > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I
select
> > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with
the MMC
or > > > SATA > > > > defconfigs. I get the same result without this patch series applied, > > > though. > > > > > > > > The failed cases have the same output (other than kwboot
header
patching > > > > output) until after sending boot image data is complete. The output stops > > > > after: > > > > ================================ > > > > 98 % [................................................................. > > > > ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > ================================ > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> > > instruct mkimage what to put into kwbimage header. > > > > > > If I'm looking at the output correctly then SPL was booted, it correctly > > > trained DDR RAM, returned back to bootrom, kwboot continued
sending
main > > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot > > > is complete. But then there is no output from main u-boot. > > > > > > > It looks like an unrelated issue with kwboot.c, which I was
sure
was > > > > working after the last patches but I can no longer reproduce
a
successful > > > > boot. > > > > > > Can you check that you are using _both_ mkimage and kwboot from version > > > with applying _all_ my patches recently sent to ML? Because
both
mkimage > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > I tested using the latest next branch which has those changes in
it.
Steps: > > - Set UART boot mode on device > > - make clean > > - make clearfog_defconfig > > - make > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > For me it looks like that either mkimage generated incorrect
image size
> > > for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> > > from kwbimage header and sent smaller image. > > > > > > > <MMC output> > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > Detected kwbimage v1 with SDIO boot signature > > Patching image boot signature to UART > > Aligning image header to Xmodem block size > > Sending boot message. Please reboot the target...\ > > Sending boot image header (113408 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 94 % [.............................................. > > ] > > Done > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31
+1000)
> > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 3 | SATA0 | > > | 1 | 0 | SGMII1 | > > | 2 | 5 | PCIe1 | > > | 3 | 5 | USB3 HOST1 | > > | 4 | 5 | PCIe2 | > > | 5 | 0 | SGMII2 | > > -------------------------------- > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > > > Sending boot image data (474564 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 98 % [.................................................................... > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > </MMC output> > > > > <MMC sizes> > > du -b u-boot* > > 4996828 u-boot > > 474304 u-boot.bin > > 15155 u-boot.cfg > > 19496 u-boot.dtb > > 474304 u-boot-dtb.bin > > 474368 u-boot-dtb.img > > 474368 u-boot.img > > 1721 u-boot.lds > > 1069982 u-boot.map > > 454808 u-boot-nodtb.bin > > 1307712 u-boot.srec > > 198841 u-boot.sym > > 588288 u-boot-with-spl.kwb > > </MMC sizes> > > > > If I make menuconfig and set the boot mode to UART before making
I get:
> > > > <UART output> > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > Detected kwbimage v1 with UART boot signature > > Aligning image header to Xmodem block size > > Sending boot message. Please reboot the target...\ > > Sending boot image header (113408 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 94 % [.............................................. > > ] > > Done > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 3 | SATA0 | > > | 1 | 0 | SGMII1 | > > | 2 | 5 | PCIe1 | > > | 3 | 5 | USB3 HOST1 | > > | 4 | 5 | PCIe2 | > > | 5 | 0 | SGMII2 | > > -------------------------------- > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > > > Sending boot image data (474404 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 98 % [................................................................... > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > </UART output> > > > > <UART sizes> > > du -b u-boot* > > 4997204 u-boot > > 474400 u-boot.bin > > 15103 u-boot.cfg > > 19496 u-boot.dtb > > 474400 u-boot-dtb.bin > > 474464 u-boot-dtb.img > > 474464 u-boot.img > > 1721 u-boot.lds > > 1070068 u-boot.map > > 454904 u-boot-nodtb.bin > > 1307988 u-boot.srec > > 198886 u-boot.sym > > 587904 u-boot-with-spl.kwb > > </UART sizes> > > > > The difference is very small somewhere if that is the cause. Let
me
know if > > there's other data I can get to help with this one. > > Difference should be only in the kwbimage header plus some
aligning. It
> just proves what I wrote before "mkimage generated incorrect image
size
> for SDIO image. Or kwboot incorrectly parsed that image size > from kwbimage header and sent smaller image.". > > I will try to find a bug in mkimage or kwboot tool. Or you can try
it
> too. As mmc booting is working fine from mmc I have felling that
bug is
> in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/' ./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part.
I looked at the disassembled bootrom code again and it does not ignore offset to the data part. But if my understanding is correct there is off-by-one error in bootrom code when processing a gap between header and data part. And Xth data byte is copied to the RAM[load_addr+X+1] offset.
Could you try prepending u-boot.bin binary by one byte and rebuild normal (mmc) kwb binary? If it starts booting over UART _without_ remove-gap patch which I sent in previous email then it confirms my above observation and remove-gap patch is needed.
In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
diff --git a/tools/kwboot.c b/tools/kwboot.c index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part */
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {
kwboot_printv("Removing gap between image header and data\n");memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr), le32_to_cpu(hdr->blocksize));hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {
fprintf(stderr, "Cannot align image with secure header\n");goto err;}
hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
*size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);
That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) if (count > 0) headersz += sizeof(struct register_set_hdr_v1) + 8 *
count
4;
/** For all images except UART, headersz stored in headeritself
should
* contains header size without padding. For UART imageBootROM
rounds
* down headersz to multiply of 128 bytes. Therefore alignUART
headersz
* to multiply of 128 bytes to ensure that remaining UARTheader
bytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) goto err; } kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); } if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem blocksize\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and forUART
type it
* must be set to the aligned xmodem header sizebecause
BootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz &0xffff);
} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;> > > > > > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > > > > > > > SATA works correctly. > > > > > > Perfect! > > > > > > > > > > > > Tony, should address problems with SPI booting when it is configured to > > > > > different configuration. In fourth commit I added all
possible
boot > > > mode > > > > > strapping pin configurations which are recognized by A385 bootrom (and > > > > > not the only one described in the HW spec, which is
incomplete).
> > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > Pali Rohár (6): > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > -- > > > > > 2.20.1 > > > > > > > > > > > > >
On Tuesday 21 March 2023 20:56:02 Pali Rohár wrote:
On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
> On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote: > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org
wrote:
> > > > > > > > > > > Improve code for checking strapping pins which specifies
boot
> mode > > > > source. > > > > > > > > > > > > Martin, could you test if Clearfog can be still configured
into
> UART > > > > > > booting mode via HW switches and if it still works
correctly?
> First > > > > > > patch is reverting UART related commit for Clearfog which I > think it > > > > not > > > > > > needed anymore. > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before
the
> switch > > > > that > > > > > you refactored in cpu.c/get_boot_device is all that gets > processed. It > > > > > decides there is an error and returns BOOT_DEVICE_UART,
probably
> because > > > > of > > > > > the invalid boot workaround for broken UART selection that
you
> > > > identified. > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I
select
> > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with
the MMC
> or > > > > SATA > > > > > defconfigs. I get the same result without this patch series > applied, > > > > though. > > > > > > > > > > The failed cases have the same output (other than kwboot
header
> patching > > > > > output) until after sending boot image data is complete. The > output stops > > > > > after: > > > > > ================================ > > > > > 98 % > [................................................................. > > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > ================================ > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> > > > instruct mkimage what to put into kwbimage header. > > > > > > > > If I'm looking at the output correctly then SPL was booted, it > correctly > > > > trained DDR RAM, returned back to bootrom, kwboot continued
sending
> main > > > > u-boot and bootrom confirmed that transfer of both SPL and main > u-boot > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I was
sure
> was > > > > > working after the last patches but I can no longer reproduce
a
> successful > > > > > boot. > > > > > > > > Can you check that you are using _both_ mkimage and kwboot from > version > > > > with applying _all_ my patches recently sent to ML? Because
both
> mkimage > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > I tested using the latest next branch which has those changes in
it.
> Steps: > > > - Set UART boot mode on device > > > - make clean > > > - make clearfog_defconfig > > > - make > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > For me it looks like that either mkimage generated incorrect
image size
> > > > for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> > > > from kwbimage header and sent smaller image. > > > > > > > > > > <MMC output> > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > Detected kwbimage v1 with SDIO boot signature > > > Patching image boot signature to UART > > > Aligning image header to Xmodem block size > > > Sending boot message. Please reboot the target...\ > > > Sending boot image header (113408 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 94 % [.............................................. > > > ] > > > Done > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31
+1000)
> > > High speed PHY - Version: 2.0 > > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > > Detected Device ID 6828 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > -------------------------------- > > > | 0 | 3 | SATA0 | > > > | 1 | 0 | SGMII1 | > > > | 2 | 5 | PCIe1 | > > > | 3 | 5 | USB3 HOST1 | > > > | 4 | 5 | PCIe2 | > > > | 5 | 0 | SGMII2 | > > > -------------------------------- > > > High speed PHY - Ended Successfully > > > mv_ddr: 14.0.0 > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > mv_ddr: completed successfully > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > Sending boot image data (474564 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 98 % > [.................................................................... > > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > </MMC output> > > > > > > <MMC sizes> > > > du -b u-boot* > > > 4996828 u-boot > > > 474304 u-boot.bin > > > 15155 u-boot.cfg > > > 19496 u-boot.dtb > > > 474304 u-boot-dtb.bin > > > 474368 u-boot-dtb.img > > > 474368 u-boot.img > > > 1721 u-boot.lds > > > 1069982 u-boot.map > > > 454808 u-boot-nodtb.bin > > > 1307712 u-boot.srec > > > 198841 u-boot.sym > > > 588288 u-boot-with-spl.kwb > > > </MMC sizes> > > > > > > If I make menuconfig and set the boot mode to UART before making
I get:
> > > > > > <UART output> > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > Detected kwbimage v1 with UART boot signature > > > Aligning image header to Xmodem block size > > > Sending boot message. Please reboot the target...\ > > > Sending boot image header (113408 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 94 % [.............................................. > > > ] > > > Done > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > > High speed PHY - Version: 2.0 > > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > > Detected Device ID 6828 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > -------------------------------- > > > | 0 | 3 | SATA0 | > > > | 1 | 0 | SGMII1 | > > > | 2 | 5 | PCIe1 | > > > | 3 | 5 | USB3 HOST1 | > > > | 4 | 5 | PCIe2 | > > > | 5 | 0 | SGMII2 | > > > -------------------------------- > > > High speed PHY - Ended Successfully > > > mv_ddr: 14.0.0 > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > mv_ddr: completed successfully > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > Sending boot image data (474404 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 98 % > [................................................................... > > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > > </UART output> > > > > > > <UART sizes> > > > du -b u-boot* > > > 4997204 u-boot > > > 474400 u-boot.bin > > > 15103 u-boot.cfg > > > 19496 u-boot.dtb > > > 474400 u-boot-dtb.bin > > > 474464 u-boot-dtb.img > > > 474464 u-boot.img > > > 1721 u-boot.lds > > > 1070068 u-boot.map > > > 454904 u-boot-nodtb.bin > > > 1307988 u-boot.srec > > > 198886 u-boot.sym > > > 587904 u-boot-with-spl.kwb > > > </UART sizes> > > > > > > The difference is very small somewhere if that is the cause. Let
me
> know if > > > there's other data I can get to help with this one. > > > > Difference should be only in the kwbimage header plus some
aligning. It
> > just proves what I wrote before "mkimage generated incorrect image
size
> > for SDIO image. Or kwboot incorrectly parsed that image size > > from kwbimage header and sent smaller image.". > > > > I will try to find a bug in mkimage or kwboot tool. Or you can try
it
> > too. As mmc booting is working fine from mmc I have felling that
bug is
> > in kwboot code which parses mmc images. > > Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
> these changes? >
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/' ./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part.
I looked at the disassembled bootrom code again and it does not ignore offset to the data part. But if my understanding is correct there is off-by-one error in bootrom code when processing a gap between header and data part. And Xth data byte is copied to the RAM[load_addr+X+1] offset.
Could you try prepending u-boot.bin binary by one byte and rebuild normal (mmc) kwb binary?
Hm... no, this does not help as off-by-one is in opposite direction. You need to cut the first byte from the u-boot.bin binary, build kwb image and then put this first byte into the kwb image just before data part (by replacing that one zero byte filler).
If it starts booting over UART _without_ remove-gap patch which I sent in previous email then it confirms my above observation and remove-gap patch is needed.
In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
diff --git a/tools/kwboot.c b/tools/kwboot.c index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part */
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {
kwboot_printv("Removing gap between image header and data\n");memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr), le32_to_cpu(hdr->blocksize));hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {
fprintf(stderr, "Cannot align image with secure header\n");goto err;}
hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
*size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);
That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
> diff --git a/tools/kwbimage.c b/tools/kwbimage.c > index 309657a5637b..177084adf825 100644 > --- a/tools/kwbimage.c > +++ b/tools/kwbimage.c > @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext) > if (count > 0) > headersz += sizeof(struct register_set_hdr_v1) + 8 *
count
> + 4; > > + /* > + * For all images except UART, headersz stored in header
itself
> should > + * contains header size without padding. For UART image
BootROM
> rounds > + * down headersz to multiply of 128 bytes. Therefore align
UART
> headersz > + * to multiply of 128 bytes to ensure that remaining UART
header
> bytes > + * are not ignored by BootROM. > + */ > + if (image_get_bootfrom() == IBR_HDR_UART_ID) > + headersz = ALIGN(headersz, 128); > + > return headersz; > } > > diff --git a/tools/kwboot.c b/tools/kwboot.c > index 1844d7291fe0..b40800c108fc 100644 > --- a/tools/kwboot.c > +++ b/tools/kwboot.c > @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int > baudrate) > goto err; > } > kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
> + /* Update the 32-bit data checksum */ > + *kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img); > } > > if (!kwboot_img_has_ddr_init(img) && > @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int > baudrate) > > kwboot_printv("Aligning image header to Xmodem block > size\n"); > kwboot_img_grow_hdr(img, size, grow); > + > + /* > + * kwbimage v1 contains header size field and for
UART
> type it > + * must be set to the aligned xmodem header size
because
> BootROM > + * rounds header size down to xmodem block size. > + */ > + if (kwbimage_version(img) == 1) { > + hdrsz += grow; > + hdr->headersz_msb = hdrsz >> 16; > + hdr->headersz_lsb = cpu_to_le16(hdrsz &
0xffff);
> + } > } > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > > > > > > > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > Perfect! > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it is > configured to > > > > > > different configuration. In fourth commit I added all
possible
> boot > > > > mode > > > > > > strapping pin configurations which are recognized by A385 > bootrom (and > > > > > > not the only one described in the HW spec, which is
incomplete).
> > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? > Because I'm > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > Pali Rohár (6): > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > ++++++++++++++++---------- > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.20.1 > > > > > > > > > > > > > > > > >
On Tue, 21 Mar 2023 at 17:26, Pali Rohár pali@kernel.org wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org
wrote:
> > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali@kernel.org
wrote:
> > > > > > > > > Improve code for checking strapping pins which
specifies
boot
mode > > > source. > > > > > > > > > > Martin, could you test if Clearfog can be still
configured
into
UART > > > > > booting mode via HW switches and if it still works
correctly?
First > > > > > patch is reverting UART related commit for Clearfog
which I
think it > > > not > > > > > needed anymore. > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef
before
the
switch > > > that > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It > > > > decides there is an error and returns BOOT_DEVICE_UART,
probably
because > > > of > > > > the invalid boot workaround for broken UART selection
that
you
> > > identified. > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > UART only works if I use the clearfog_spi_defconfig or
if I
select
> > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work
with
the MMC
or > > > SATA > > > > defconfigs. I get the same result without this patch
series
applied, > > > though. > > > > > > > > The failed cases have the same output (other than kwboot
header
patching > > > > output) until after sending boot image data is complete.
The
output stops > > > > after: > > > > ================================ > > > > 98 %
[.................................................................
> > > > ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > ================================ > > > > > > This is very strange because
CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> > > instruct mkimage what to put into kwbimage header. > > > > > > If I'm looking at the output correctly then SPL was
booted, it
correctly > > > trained DDR RAM, returned back to bootrom, kwboot continued
sending
main > > > u-boot and bootrom confirmed that transfer of both SPL and
main
u-boot > > > is complete. But then there is no output from main u-boot. > > > > > > > It looks like an unrelated issue with kwboot.c, which I
was
sure
was > > > > working after the last patches but I can no longer
reproduce
a
successful > > > > boot. > > > > > > Can you check that you are using _both_ mkimage and kwboot
from
version > > > with applying _all_ my patches recently sent to ML? Because
both
mkimage > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > I tested using the latest next branch which has those
changes in
it.
Steps: > > - Set UART boot mode on device > > - make clean > > - make clearfog_defconfig > > - make > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > For me it looks like that either mkimage generated incorrect
image size
> > > for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> > > from kwbimage header and sent smaller image. > > > > > > > <MMC output> > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > Detected kwbimage v1 with SDIO boot signature > > Patching image boot signature to UART > > Aligning image header to Xmodem block size > > Sending boot message. Please reboot the target...\ > > Sending boot image header (113408 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 94 % [.............................................. > > ] > > Done > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
12:57:31
+1000)
> > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 3 | SATA0 | > > | 1 | 0 | SGMII1 | > > | 2 | 5 | PCIe1 | > > | 3 | 5 | USB3 HOST1 | > > | 4 | 5 | PCIe2 | > > | 5 | 0 | SGMII2 | > > -------------------------------- > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > mv_ddr: completed successfully > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > > > Sending boot image data (474564 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 98 %
[....................................................................
> > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > </MMC output> > > > > <MMC sizes> > > du -b u-boot* > > 4996828 u-boot > > 474304 u-boot.bin > > 15155 u-boot.cfg > > 19496 u-boot.dtb > > 474304 u-boot-dtb.bin > > 474368 u-boot-dtb.img > > 474368 u-boot.img > > 1721 u-boot.lds > > 1069982 u-boot.map > > 454808 u-boot-nodtb.bin > > 1307712 u-boot.srec > > 198841 u-boot.sym > > 588288 u-boot-with-spl.kwb > > </MMC sizes> > > > > If I make menuconfig and set the boot mode to UART before
making
I get:
> > > > <UART output> > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > Detected kwbimage v1 with UART boot signature > > Aligning image header to Xmodem block size > > Sending boot message. Please reboot the target...\ > > Sending boot image header (113408 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 94 % [.............................................. > > ] > > Done > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
13:20:48
+1000)
> > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 3 | SATA0 | > > | 1 | 0 | SGMII1 | > > | 2 | 5 | PCIe1 | > > | 3 | 5 | USB3 HOST1 | > > | 4 | 5 | PCIe2 | > > | 5 | 0 | SGMII2 | > > -------------------------------- > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > mv_ddr: completed successfully > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > > > Sending boot image data (474404 bytes)... > > 0 % > >
[......................................................................]
> > <snip> > > 98 %
[...................................................................
> > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > </UART output> > > > > <UART sizes> > > du -b u-boot* > > 4997204 u-boot > > 474400 u-boot.bin > > 15103 u-boot.cfg > > 19496 u-boot.dtb > > 474400 u-boot-dtb.bin > > 474464 u-boot-dtb.img > > 474464 u-boot.img > > 1721 u-boot.lds > > 1070068 u-boot.map > > 454904 u-boot-nodtb.bin > > 1307988 u-boot.srec > > 198886 u-boot.sym > > 587904 u-boot-with-spl.kwb > > </UART sizes> > > > > The difference is very small somewhere if that is the cause.
Let
me
know if > > there's other data I can get to help with this one. > > Difference should be only in the kwbimage header plus some
aligning. It
> just proves what I wrote before "mkimage generated incorrect
image
size
> for SDIO image. Or kwboot incorrectly parsed that image size > from kwbimage header and sent smaller image.". > > I will try to find a bug in mkimage or kwboot tool. Or you can
try
it
> too. As mmc booting is working fine from mmc I have felling
that
bug is
> in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
these changes?
Dedicated UART still works, patching an MMC for UART with kwboot
still
hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code
again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/'
./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part. In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
Success! I tested kwboot patching of MMC, SATA and SPI images and all boot successfully with all 4 patches applied.
UART images work with all 4 patches applied as well, but also work with just the two patches at the end of kwboot.c kwboot_img_patch applied.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part*/
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {kwboot_printv("Removing gap between image header anddata\n");
memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr),le32_to_cpu(hdr->blocksize));
hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {fprintf(stderr, "Cannot align image with secure header\n");goto err;}hdr->checksum = kwboot_hdr_csum8(hdr) - csum; *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE
option
and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and
then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 309657a5637b..177084adf825 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int
*hasext)
if (count > 0) headersz += sizeof(struct register_set_hdr_v1) +8 *
count
4;
/** For all images except UART, headersz stored in headeritself
should
* contains header size without padding. For UART imageBootROM
rounds
* down headersz to multiply of 128 bytes. Thereforealign
UART
headersz
* to multiply of 128 bytes to ensure that remaining UARTheader
bytes
* are not ignored by BootROM.*/if (image_get_bootfrom() == IBR_HDR_UART_ID)headersz = ALIGN(headersz, 128);return headersz;}
diff --git a/tools/kwboot.c b/tools/kwboot.c index 1844d7291fe0..b40800c108fc 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size,
int
baudrate) goto err; } kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
/* Update the 32-bit data checksum */*kwboot_img_csum32_ptr(img) =kwboot_img_csum32(img);
} if (!kwboot_img_has_ddr_init(img) &&@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size,
int
baudrate)
kwboot_printv("Aligning image header to Xmodemblock
size\n"); kwboot_img_grow_hdr(img, size, grow);
/** kwbimage v1 contains header size field and forUART
type it
* must be set to the aligned xmodem header sizebecause
BootROM
* rounds header size down to xmodem block size.*/if (kwbimage_version(img) == 1) {hdrsz += grow;hdr->headersz_msb = hdrsz >> 16;hdr->headersz_lsb = cpu_to_le16(hdrsz &0xffff);
} } hdr->checksum = kwboot_hdr_csum8(hdr) - csum;> > > > > > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > > > > > > > SATA works correctly. > > > > > > Perfect! > > > > > > > > > > > > Tony, should address problems with SPI booting when it
is
configured to > > > > > different configuration. In fourth commit I added all
possible
boot > > > mode > > > > > strapping pin configurations which are recognized by
A385
bootrom (and > > > > > not the only one described in the HW spec, which is
incomplete).
> > > > > > > > > > Stefan, do you have some AXP board with SATA boot
source?
Because I'm > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > Pali Rohár (6): > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f
constant
> > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_*
macros
> > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20
++++++-------
> > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > -- > > > > > 2.20.1 > > > > > > > > > > > > >
On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote:
On Tue, 21 Mar 2023 at 17:26, Pali Rohár pali@kernel.org wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
> On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org
wrote:
> > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali@kernel.org
wrote:
> > > > > > > > > > > Improve code for checking strapping pins which
specifies
boot
> mode > > > > source. > > > > > > > > > > > > Martin, could you test if Clearfog can be still
configured
into
> UART > > > > > > booting mode via HW switches and if it still works
correctly?
> First > > > > > > patch is reverting UART related commit for Clearfog
which I
> think it > > > > not > > > > > > needed anymore. > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef
before
the
> switch > > > > that > > > > > you refactored in cpu.c/get_boot_device is all that gets > processed. It > > > > > decides there is an error and returns BOOT_DEVICE_UART,
probably
> because > > > > of > > > > > the invalid boot workaround for broken UART selection
that
you
> > > > identified. > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or
if I
select
> > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work
with
the MMC
> or > > > > SATA > > > > > defconfigs. I get the same result without this patch
series
> applied, > > > > though. > > > > > > > > > > The failed cases have the same output (other than kwboot
header
> patching > > > > > output) until after sending boot image data is complete.
The
> output stops > > > > > after: > > > > > ================================ > > > > > 98 % >
[.................................................................
> > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > ================================ > > > > > > > > This is very strange because
CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> > > > instruct mkimage what to put into kwbimage header. > > > > > > > > If I'm looking at the output correctly then SPL was
booted, it
> correctly > > > > trained DDR RAM, returned back to bootrom, kwboot continued
sending
> main > > > > u-boot and bootrom confirmed that transfer of both SPL and
main
> u-boot > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I
was
sure
> was > > > > > working after the last patches but I can no longer
reproduce
a
> successful > > > > > boot. > > > > > > > > Can you check that you are using _both_ mkimage and kwboot
from
> version > > > > with applying _all_ my patches recently sent to ML? Because
both
> mkimage > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > I tested using the latest next branch which has those
changes in
it.
> Steps: > > > - Set UART boot mode on device > > > - make clean > > > - make clearfog_defconfig > > > - make > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > For me it looks like that either mkimage generated incorrect
image size
> > > > for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> > > > from kwbimage header and sent smaller image. > > > > > > > > > > <MMC output> > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > Detected kwbimage v1 with SDIO boot signature > > > Patching image boot signature to UART > > > Aligning image header to Xmodem block size > > > Sending boot message. Please reboot the target...\ > > > Sending boot image header (113408 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 94 % [.............................................. > > > ] > > > Done > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
12:57:31
+1000)
> > > High speed PHY - Version: 2.0 > > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > > Detected Device ID 6828 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > -------------------------------- > > > | 0 | 3 | SATA0 | > > > | 1 | 0 | SGMII1 | > > > | 2 | 5 | PCIe1 | > > > | 3 | 5 | USB3 HOST1 | > > > | 4 | 5 | PCIe2 | > > > | 5 | 0 | SGMII2 | > > > -------------------------------- > > > High speed PHY - Ended Successfully > > > mv_ddr: 14.0.0 > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > mv_ddr: completed successfully > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > Sending boot image data (474564 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 98 % >
[....................................................................
> > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > </MMC output> > > > > > > <MMC sizes> > > > du -b u-boot* > > > 4996828 u-boot > > > 474304 u-boot.bin > > > 15155 u-boot.cfg > > > 19496 u-boot.dtb > > > 474304 u-boot-dtb.bin > > > 474368 u-boot-dtb.img > > > 474368 u-boot.img > > > 1721 u-boot.lds > > > 1069982 u-boot.map > > > 454808 u-boot-nodtb.bin > > > 1307712 u-boot.srec > > > 198841 u-boot.sym > > > 588288 u-boot-with-spl.kwb > > > </MMC sizes> > > > > > > If I make menuconfig and set the boot mode to UART before
making
I get:
> > > > > > <UART output> > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > Detected kwbimage v1 with UART boot signature > > > Aligning image header to Xmodem block size > > > Sending boot message. Please reboot the target...\ > > > Sending boot image header (113408 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 94 % [.............................................. > > > ] > > > Done > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
13:20:48
+1000)
> > > High speed PHY - Version: 2.0 > > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > > Detected Device ID 6828 > > > board SerDes lanes topology details: > > > | Lane # | Speed | Type | > > > -------------------------------- > > > | 0 | 3 | SATA0 | > > > | 1 | 0 | SGMII1 | > > > | 2 | 5 | PCIe1 | > > > | 3 | 5 | USB3 HOST1 | > > > | 4 | 5 | PCIe2 | > > > | 5 | 0 | SGMII2 | > > > -------------------------------- > > > High speed PHY - Ended Successfully > > > mv_ddr: 14.0.0 > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > mv_ddr: completed successfully > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > Sending boot image data (474404 bytes)... > > > 0 % > > > >
[......................................................................]
> > > <snip> > > > 98 % >
[...................................................................
> > > ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > > </UART output> > > > > > > <UART sizes> > > > du -b u-boot* > > > 4997204 u-boot > > > 474400 u-boot.bin > > > 15103 u-boot.cfg > > > 19496 u-boot.dtb > > > 474400 u-boot-dtb.bin > > > 474464 u-boot-dtb.img > > > 474464 u-boot.img > > > 1721 u-boot.lds > > > 1070068 u-boot.map > > > 454904 u-boot-nodtb.bin > > > 1307988 u-boot.srec > > > 198886 u-boot.sym > > > 587904 u-boot-with-spl.kwb > > > </UART sizes> > > > > > > The difference is very small somewhere if that is the cause.
Let
me
> know if > > > there's other data I can get to help with this one. > > > > Difference should be only in the kwbimage header plus some
aligning. It
> > just proves what I wrote before "mkimage generated incorrect
image
size
> > for SDIO image. Or kwboot incorrectly parsed that image size > > from kwbimage header and sent smaller image.". > > > > I will try to find a bug in mkimage or kwboot tool. Or you can
try
it
> > too. As mmc booting is working fine from mmc I have felling
that
bug is
> > in kwboot code which parses mmc images. > > Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
> these changes? >
Dedicated UART still works, patching an MMC for UART with kwboot
still
hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code
again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/'
./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part. In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
Success! I tested kwboot patching of MMC, SATA and SPI images and all boot successfully with all 4 patches applied.
Perfect! Could you also try to send without kwboot patch image with that off-by-one offset which I described in other? It would be nice to have some proof that this is really the issue here.
I will prepare another kwboot and kwbimage patches which finally should solve these issues.
UART images work with all 4 patches applied as well, but also work with just the two patches at the end of kwboot.c kwboot_img_patch applied.
Could you try to send UART image also via "sx" utility? Just to be sure that UART images generated by mkimage are valid for xmodem transfer without need to do any kwboot on-the-fly patching.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part*/
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {kwboot_printv("Removing gap between image header anddata\n");
memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr),le32_to_cpu(hdr->blocksize));
hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {fprintf(stderr, "Cannot align image with secure header\n");goto err;}hdr->checksum = kwboot_hdr_csum8(hdr) - csum; *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE
option
and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and
then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
> diff --git a/tools/kwbimage.c b/tools/kwbimage.c > index 309657a5637b..177084adf825 100644 > --- a/tools/kwbimage.c > +++ b/tools/kwbimage.c > @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int
*hasext)
> if (count > 0) > headersz += sizeof(struct register_set_hdr_v1) +
8 *
count
> + 4; > > + /* > + * For all images except UART, headersz stored in header
itself
> should > + * contains header size without padding. For UART image
BootROM
> rounds > + * down headersz to multiply of 128 bytes. Therefore
align
UART
> headersz > + * to multiply of 128 bytes to ensure that remaining UART
header
> bytes > + * are not ignored by BootROM. > + */ > + if (image_get_bootfrom() == IBR_HDR_UART_ID) > + headersz = ALIGN(headersz, 128); > + > return headersz; > } > > diff --git a/tools/kwboot.c b/tools/kwboot.c > index 1844d7291fe0..b40800c108fc 100644 > --- a/tools/kwboot.c > +++ b/tools/kwboot.c > @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size,
int
> baudrate) > goto err; > } > kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
> + /* Update the 32-bit data checksum */ > + *kwboot_img_csum32_ptr(img) =
kwboot_img_csum32(img);
> } > > if (!kwboot_img_has_ddr_init(img) && > @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size,
int
> baudrate) > > kwboot_printv("Aligning image header to Xmodem
block
> size\n"); > kwboot_img_grow_hdr(img, size, grow); > + > + /* > + * kwbimage v1 contains header size field and for
UART
> type it > + * must be set to the aligned xmodem header size
because
> BootROM > + * rounds header size down to xmodem block size. > + */ > + if (kwbimage_version(img) == 1) { > + hdrsz += grow; > + hdr->headersz_msb = hdrsz >> 16; > + hdr->headersz_lsb = cpu_to_le16(hdrsz &
0xffff);
> + } > } > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > > > > > > > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > Perfect! > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it
is
> configured to > > > > > > different configuration. In fourth commit I added all
possible
> boot > > > > mode > > > > > > strapping pin configurations which are recognized by
A385
> bootrom (and > > > > > > not the only one described in the HW spec, which is
incomplete).
> > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot
source?
> Because I'm > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > Pali Rohár (6): > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f
constant
> > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_*
macros
> > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20
++++++-------
> > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > ++++++++++++++++---------- > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.20.1 > > > > > > > > > > > > > > > > >
On Wed, 22 Mar 2023 at 18:09, Pali Rohár pali@kernel.org wrote:
On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote:
On Tue, 21 Mar 2023 at 17:26, Pali Rohár pali@kernel.org wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote: > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org
wrote:
> > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali@kernel.org
wrote:
> > > > > > > > > > > > > Improve code for checking strapping pins which
specifies
boot
> > mode > > > > > source. > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still
configured
into
> > UART > > > > > > > booting mode via HW switches and if it still works
correctly?
> > First > > > > > > > patch is reverting UART related commit for Clearfog
which I
> > think it > > > > > not > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef
before
the
> > switch > > > > > that > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > processed. It > > > > > > decides there is an error and returns BOOT_DEVICE_UART,
probably
> > because > > > > > of > > > > > > the invalid boot workaround for broken UART selection
that
you
> > > > > identified. > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or
if I
select
> > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work
with
the MMC
> > or > > > > > SATA > > > > > > defconfigs. I get the same result without this patch
series
> > applied, > > > > > though. > > > > > > > > > > > > The failed cases have the same output (other than kwboot
header
> > patching > > > > > > output) until after sending boot image data is complete.
The
> > output stops > > > > > > after: > > > > > > ================================ > > > > > > 98 % > >
[.................................................................
> > > > > > ] > > > > > > Done > > > > > > Finishing transfer > > > > > > [Type Ctrl-\ + c to quit] > > > > > > ================================ > > > > > > > > > > This is very strange because
CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
> > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > If I'm looking at the output correctly then SPL was
booted, it
> > correctly > > > > > trained DDR RAM, returned back to bootrom, kwboot continued
sending
> > main > > > > > u-boot and bootrom confirmed that transfer of both SPL and
main
> > u-boot > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I
was
sure
> > was > > > > > > working after the last patches but I can no longer
reproduce
a
> > successful > > > > > > boot. > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot
from
> > version > > > > > with applying _all_ my patches recently sent to ML? Because
both
> > mkimage > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > I tested using the latest next branch which has those
changes in
it.
> > Steps: > > > > - Set UART boot mode on device > > > > - make clean > > > > - make clearfog_defconfig > > > > - make > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > For me it looks like that either mkimage generated incorrect
image size
> > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
> > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > <MMC output> > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > Detected kwbimage v1 with SDIO boot signature > > > > Patching image boot signature to UART > > > > Aligning image header to Xmodem block size > > > > Sending boot message. Please reboot the target...\ > > > > Sending boot image header (113408 bytes)... > > > > 0 % > > > > > >
[......................................................................]
> > > > <snip> > > > > 94 % [.............................................. > > > > ] > > > > Done > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
12:57:31
+1000)
> > > > High speed PHY - Version: 2.0 > > > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > > > Detected Device ID 6828 > > > > board SerDes lanes topology details: > > > > | Lane # | Speed | Type | > > > > -------------------------------- > > > > | 0 | 3 | SATA0 | > > > > | 1 | 0 | SGMII1 | > > > > | 2 | 5 | PCIe1 | > > > > | 3 | 5 | USB3 HOST1 | > > > > | 4 | 5 | PCIe2 | > > > > | 5 | 0 | SGMII2 | > > > > -------------------------------- > > > > High speed PHY - Ended Successfully > > > > mv_ddr: 14.0.0 > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > > mv_ddr: completed successfully > > > > Trying to boot from BOOTROM > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > Sending boot image data (474564 bytes)... > > > > 0 % > > > > > >
[......................................................................]
> > > > <snip> > > > > 98 % > >
[....................................................................
> > > > ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > </MMC output> > > > > > > > > <MMC sizes> > > > > du -b u-boot* > > > > 4996828 u-boot > > > > 474304 u-boot.bin > > > > 15155 u-boot.cfg > > > > 19496 u-boot.dtb > > > > 474304 u-boot-dtb.bin > > > > 474368 u-boot-dtb.img > > > > 474368 u-boot.img > > > > 1721 u-boot.lds > > > > 1069982 u-boot.map > > > > 454808 u-boot-nodtb.bin > > > > 1307712 u-boot.srec > > > > 198841 u-boot.sym > > > > 588288 u-boot-with-spl.kwb > > > > </MMC sizes> > > > > > > > > If I make menuconfig and set the boot mode to UART before
making
I get:
> > > > > > > > <UART output> > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > Detected kwbimage v1 with UART boot signature > > > > Aligning image header to Xmodem block size > > > > Sending boot message. Please reboot the target...\ > > > > Sending boot image header (113408 bytes)... > > > > 0 % > > > > > >
[......................................................................]
> > > > <snip> > > > > 94 % [.............................................. > > > > ] > > > > Done > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
13:20:48
+1000)
> > > > High speed PHY - Version: 2.0 > > > > EEPROM TLV detection failed: Using static config for Clearfog
Pro.
> > > > Detected Device ID 6828 > > > > board SerDes lanes topology details: > > > > | Lane # | Speed | Type | > > > > -------------------------------- > > > > | 0 | 3 | SATA0 | > > > > | 1 | 0 | SGMII1 | > > > > | 2 | 5 | PCIe1 | > > > > | 3 | 5 | USB3 HOST1 | > > > > | 4 | 5 | PCIe2 | > > > > | 5 | 0 | SGMII2 | > > > > -------------------------------- > > > > High speed PHY - Ended Successfully > > > > mv_ddr: 14.0.0 > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > > mv_ddr: completed successfully > > > > Trying to boot from BOOTROM > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > Sending boot image data (474404 bytes)... > > > > 0 % > > > > > >
[......................................................................]
> > > > <snip> > > > > 98 % > >
[...................................................................
> > > > ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
> > > > </UART output> > > > > > > > > <UART sizes> > > > > du -b u-boot* > > > > 4997204 u-boot > > > > 474400 u-boot.bin > > > > 15103 u-boot.cfg > > > > 19496 u-boot.dtb > > > > 474400 u-boot-dtb.bin > > > > 474464 u-boot-dtb.img > > > > 474464 u-boot.img > > > > 1721 u-boot.lds > > > > 1070068 u-boot.map > > > > 454904 u-boot-nodtb.bin > > > > 1307988 u-boot.srec > > > > 198886 u-boot.sym > > > > 587904 u-boot-with-spl.kwb > > > > </UART sizes> > > > > > > > > The difference is very small somewhere if that is the cause.
Let
me
> > know if > > > > there's other data I can get to help with this one. > > > > > > Difference should be only in the kwbimage header plus some
aligning. It
> > > just proves what I wrote before "mkimage generated incorrect
image
size
> > > for SDIO image. Or kwboot incorrectly parsed that image size > > > from kwbimage header and sent smaller image.". > > > > > > I will try to find a bug in mkimage or kwboot tool. Or you can
try
it
> > > too. As mmc booting is working fine from mmc I have felling
that
bug is
> > > in kwboot code which parses mmc images. > > > > Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
> > these changes? > > > > Dedicated UART still works, patching an MMC for UART with kwboot
still
> hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code
again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/'
./arch/arm/mach-mvebu/kwbimage.cfg
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part. In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
Success! I tested kwboot patching of MMC, SATA and SPI images and all boot successfully with all 4 patches applied.
Perfect! Could you also try to send without kwboot patch image with that off-by-one offset which I described in other? It would be nice to have some proof that this is really the issue here.
One byte in either direction without the patch to remove the gap does not boot, just hangs after "Finishing transfer". The patch moves the data by 256 bytes with the same files, so it seems like there's another effect involved.
I will prepare another kwboot and kwbimage patches which finally should solve these issues.
UART images work with all 4 patches applied as well, but also work with just the two patches at the end of kwboot.c kwboot_img_patch applied.
Could you try to send UART image also via "sx" utility? Just to be sure that UART images generated by mkimage are valid for xmodem transfer without need to do any kwboot on-the-fly patching.
./tools/kwboot -b /dev/ttyUSB0 sx -b u-boot-with-spl.kwb < /dev/ttyUSB0 > /dev/ttyUSB0 Sending u-boot-with-spl.kwb, 4626 blocks: Give your local XMODEM receive command now. Xmodem sectors/kbytes sent: 898/112kRetry 0: Got 0d for sector ACK Retry 0: NAK on sector Retry 0: Got 6c for sector ACK Retry 0: NAK on sector Retry 0: Got 49 for sector ACK Retry 0: NAK on sector Retry 0: Got 49 for sector ACK Retry 0: NAK on sector Bytes Sent: 592128 BPS:7679
Transfer complete ./tools/kwboot -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00342-g7e562609bb-dirty [Type Ctrl-\ + c to quit]
...and nothing; no u-boot prompt, system doesn't boot, it just hangs like when kwboot fails.
I added a write function after kwboot.c kwboot_img_patch gets called and compared the output. The files are identical until the very end where kwboot trims some zeros. I tried sending both the patched and unpatched file and got the same hanging with both. Given the patched file works with kwboot, I suspect the remaining magic is happening in the kwboot_xmodem function.
I've never seen sx work on clearfog. I assumed the SPL serial output corrupted the transfer, so I've always used kwboot. Maybe it's a quirk of this board, but either way I don't think the result of this test is meaningful.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part*/
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {kwboot_printv("Removing gap between image header anddata\n");
memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr),le32_to_cpu(hdr->blocksize));
hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {fprintf(stderr, "Cannot align image with secure header\n");goto err;}hdr->checksum = kwboot_hdr_csum8(hdr) - csum; *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE
option
and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
Meanwhile could you do following tests?
- The one which you done with patched kwboot and kwbimage, but send
output (sizes and aligning information from kwboot is useful there).
- Use kwboot only for sending magic packet (-b without image) and
then
use "sx" program for transferring kwb image over UART (instead of kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
> > > diff --git a/tools/kwbimage.c b/tools/kwbimage.c > > index 309657a5637b..177084adf825 100644 > > --- a/tools/kwbimage.c > > +++ b/tools/kwbimage.c > > @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int
*hasext)
> > if (count > 0) > > headersz += sizeof(struct register_set_hdr_v1) +
8 *
count
> > + 4; > > > > + /* > > + * For all images except UART, headersz stored in header
itself
> > should > > + * contains header size without padding. For UART image
BootROM
> > rounds > > + * down headersz to multiply of 128 bytes. Therefore
align
UART
> > headersz > > + * to multiply of 128 bytes to ensure that remaining UART
header
> > bytes > > + * are not ignored by BootROM. > > + */ > > + if (image_get_bootfrom() == IBR_HDR_UART_ID) > > + headersz = ALIGN(headersz, 128); > > + > > return headersz; > > } > > > > diff --git a/tools/kwboot.c b/tools/kwboot.c > > index 1844d7291fe0..b40800c108fc 100644 > > --- a/tools/kwboot.c > > +++ b/tools/kwboot.c > > @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size,
int
> > baudrate) > > goto err; > > } > > kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
> > + /* Update the 32-bit data checksum */ > > + *kwboot_img_csum32_ptr(img) =
kwboot_img_csum32(img);
> > } > > > > if (!kwboot_img_has_ddr_init(img) && > > @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size,
int
> > baudrate) > > > > kwboot_printv("Aligning image header to Xmodem
block
> > size\n"); > > kwboot_img_grow_hdr(img, size, grow); > > + > > + /* > > + * kwbimage v1 contains header size field and for
UART
> > type it > > + * must be set to the aligned xmodem header size
because
> > BootROM > > + * rounds header size down to xmodem block size. > > + */ > > + if (kwbimage_version(img) == 1) { > > + hdrsz += grow; > > + hdr->headersz_msb = hdrsz >> 16; > > + hdr->headersz_lsb = cpu_to_le16(hdrsz &
0xffff);
> > + } > > } > > > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > > > > > > > > > > > > > Also could you check if SATA booting is still working
correctly?
> > > > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > > > Perfect! > > > > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it
is
> > configured to > > > > > > > different configuration. In fourth commit I added all
possible
> > boot > > > > > mode > > > > > > > strapping pin configurations which are recognized by
A385
> > bootrom (and > > > > > > > not the only one described in the HW spec, which is
incomplete).
> > > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot
source?
> > Because I'm > > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > > > Pali Rohár (6): > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f
constant
> > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function
macros
> > > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
> > > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_*
macros
> > > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20
++++++-------
> > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > > ++++++++++++++++---------- > > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > > > -- > > > > > > > 2.20.1 > > > > > > > > > > > > > > > > > > > > >
On Thursday 23 March 2023 11:01:22 Martin Rowe wrote:
On Wed, 22 Mar 2023 at 18:09, Pali Rohár pali@kernel.org wrote:
On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote:
On Tue, 21 Mar 2023 at 17:26, Pali Rohár pali@kernel.org wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote: > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org
wrote:
> > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali@kernel.org
wrote: > > > > > > > > > > > > > > > Improve code for checking strapping pins which
specifies
boot > > > mode > > > > > > source. > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still
configured
into > > > UART > > > > > > > > booting mode via HW switches and if it still works correctly? > > > First > > > > > > > > patch is reverting UART related commit for Clearfog
which I
> > > think it > > > > > > not > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef
before
the > > > switch > > > > > > that > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > processed. It > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, probably > > > because > > > > > > of > > > > > > > the invalid boot workaround for broken UART selection
that
you > > > > > > identified. > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or
if I
select > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work
with
the MMC > > > or > > > > > > SATA > > > > > > > defconfigs. I get the same result without this patch
series
> > > applied, > > > > > > though. > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot header > > > patching > > > > > > > output) until after sending boot image data is complete.
The
> > > output stops > > > > > > > after: > > > > > > > ================================ > > > > > > > 98 % > > >
[.................................................................
> > > > > > > ] > > > > > > > Done > > > > > > > Finishing transfer > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > ================================ > > > > > > > > > > > > This is very strange because
CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > If I'm looking at the output correctly then SPL was
booted, it
> > > correctly > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued sending > > > main > > > > > > u-boot and bootrom confirmed that transfer of both SPL and
main
> > > u-boot > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I
was
sure > > > was > > > > > > > working after the last patches but I can no longer
reproduce
a > > > successful > > > > > > > boot. > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot
from
> > > version > > > > > > with applying _all_ my patches recently sent to ML? Because both > > > mkimage > > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > > > > I tested using the latest next branch which has those
changes in
it. > > > Steps: > > > > > - Set UART boot mode on device > > > > > - make clean > > > > > - make clearfog_defconfig > > > > > - make > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > For me it looks like that either mkimage generated incorrect image size > > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size > > > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > > <MMC output> > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > Patching image boot signature to UART > > > > > Aligning image header to Xmodem block size > > > > > Sending boot message. Please reboot the target...\ > > > > > Sending boot image header (113408 bytes)... > > > > > 0 % > > > > > > > >
[......................................................................]
> > > > > <snip> > > > > > 94 % [.............................................. > > > > > ] > > > > > Done > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
12:57:31
+1000) > > > > > High speed PHY - Version: 2.0 > > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > > > > Detected Device ID 6828 > > > > > board SerDes lanes topology details: > > > > > | Lane # | Speed | Type | > > > > > -------------------------------- > > > > > | 0 | 3 | SATA0 | > > > > > | 1 | 0 | SGMII1 | > > > > > | 2 | 5 | PCIe1 | > > > > > | 3 | 5 | USB3 HOST1 | > > > > > | 4 | 5 | PCIe2 | > > > > > | 5 | 0 | SGMII2 | > > > > > -------------------------------- > > > > > High speed PHY - Ended Successfully > > > > > mv_ddr: 14.0.0 > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > > > mv_ddr: completed successfully > > > > > Trying to boot from BOOTROM > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > > > Sending boot image data (474564 bytes)... > > > > > 0 % > > > > > > > >
[......................................................................]
> > > > > <snip> > > > > > 98 % > > >
[....................................................................
> > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > </MMC output> > > > > > > > > > > <MMC sizes> > > > > > du -b u-boot* > > > > > 4996828 u-boot > > > > > 474304 u-boot.bin > > > > > 15155 u-boot.cfg > > > > > 19496 u-boot.dtb > > > > > 474304 u-boot-dtb.bin > > > > > 474368 u-boot-dtb.img > > > > > 474368 u-boot.img > > > > > 1721 u-boot.lds > > > > > 1069982 u-boot.map > > > > > 454808 u-boot-nodtb.bin > > > > > 1307712 u-boot.srec > > > > > 198841 u-boot.sym > > > > > 588288 u-boot-with-spl.kwb > > > > > </MMC sizes> > > > > > > > > > > If I make menuconfig and set the boot mode to UART before
making
I get: > > > > > > > > > > <UART output> > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > Detected kwbimage v1 with UART boot signature > > > > > Aligning image header to Xmodem block size > > > > > Sending boot message. Please reboot the target...\ > > > > > Sending boot image header (113408 bytes)... > > > > > 0 % > > > > > > > >
[......................................................................]
> > > > > <snip> > > > > > 94 % [.............................................. > > > > > ] > > > > > Done > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
13:20:48
+1000) > > > > > High speed PHY - Version: 2.0 > > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > > > > Detected Device ID 6828 > > > > > board SerDes lanes topology details: > > > > > | Lane # | Speed | Type | > > > > > -------------------------------- > > > > > | 0 | 3 | SATA0 | > > > > > | 1 | 0 | SGMII1 | > > > > > | 2 | 5 | PCIe1 | > > > > > | 3 | 5 | USB3 HOST1 | > > > > > | 4 | 5 | PCIe2 | > > > > > | 5 | 0 | SGMII2 | > > > > > -------------------------------- > > > > > High speed PHY - Ended Successfully > > > > > mv_ddr: 14.0.0 > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > > > mv_ddr: completed successfully > > > > > Trying to boot from BOOTROM > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > > > Sending boot image data (474404 bytes)... > > > > > 0 % > > > > > > > >
[......................................................................]
> > > > > <snip> > > > > > 98 % > > >
[...................................................................
> > > > > ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000) > > > > > </UART output> > > > > > > > > > > <UART sizes> > > > > > du -b u-boot* > > > > > 4997204 u-boot > > > > > 474400 u-boot.bin > > > > > 15103 u-boot.cfg > > > > > 19496 u-boot.dtb > > > > > 474400 u-boot-dtb.bin > > > > > 474464 u-boot-dtb.img > > > > > 474464 u-boot.img > > > > > 1721 u-boot.lds > > > > > 1070068 u-boot.map > > > > > 454904 u-boot-nodtb.bin > > > > > 1307988 u-boot.srec > > > > > 198886 u-boot.sym > > > > > 587904 u-boot-with-spl.kwb > > > > > </UART sizes> > > > > > > > > > > The difference is very small somewhere if that is the cause.
Let
me > > > know if > > > > > there's other data I can get to help with this one. > > > > > > > > Difference should be only in the kwbimage header plus some aligning. It > > > > just proves what I wrote before "mkimage generated incorrect
image
size > > > > for SDIO image. Or kwboot incorrectly parsed that image size > > > > from kwbimage header and sent smaller image.". > > > > > > > > I will try to find a bug in mkimage or kwboot tool. Or you can
try
it > > > > too. As mmc booting is working fine from mmc I have felling
that
bug is > > > > in kwboot code which parses mmc images. > > > > > > Ok, I think I found 3 bugs, all are UART related (not mmc). Could you try > > > these changes? > > > > > > > Dedicated UART still works, patching an MMC for UART with kwboot
still
> > hangs after finishing transfer; no change. > > Bah :-( So there is still another bug. I will look at the code
again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/'
./arch/arm/mach-mvebu/kwbimage.cfg
> kwbimage.uart.cfg ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part. In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
Success! I tested kwboot patching of MMC, SATA and SPI images and all boot successfully with all 4 patches applied.
Perfect! Could you also try to send without kwboot patch image with that off-by-one offset which I described in other? It would be nice to have some proof that this is really the issue here.
One byte in either direction without the patch to remove the gap does not boot, just hangs after "Finishing transfer".
Ok, then probably I did not fully understood that disassembled code.
The patch moves the data by 256 bytes with the same files, so it seems like there's another effect involved.
This movement is correct. It is changing alignment from 512 bytes to just 128 bytes. So if in the last 512 byte long block are only 200 bytes then then 200 bytes in 128 byte long alignment needs only 256 bytes and so gap between 256th byte and 512th byte needs to be removed.
I will prepare another kwboot and kwbimage patches which finally should solve these issues.
UART images work with all 4 patches applied as well, but also work with just the two patches at the end of kwboot.c kwboot_img_patch applied.
Could you try to send UART image also via "sx" utility? Just to be sure that UART images generated by mkimage are valid for xmodem transfer without need to do any kwboot on-the-fly patching.
./tools/kwboot -b /dev/ttyUSB0 sx -b u-boot-with-spl.kwb < /dev/ttyUSB0 > /dev/ttyUSB0 Sending u-boot-with-spl.kwb, 4626 blocks: Give your local XMODEM receive command now. Xmodem sectors/kbytes sent: 898/112kRetry 0: Got 0d for sector ACK Retry 0: NAK on sector Retry 0: Got 6c for sector ACK Retry 0: NAK on sector Retry 0: Got 49 for sector ACK Retry 0: NAK on sector Retry 0: Got 49 for sector ACK Retry 0: NAK on sector Bytes Sent: 592128 BPS:7679
Transfer complete ./tools/kwboot -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00342-g7e562609bb-dirty [Type Ctrl-\ + c to quit]
...and nothing; no u-boot prompt, system doesn't boot, it just hangs like when kwboot fails.
Ah... I guess sx is too smart is trying to resubmit xmodem block when it receives unknown reply (which is the SPL output). If you look into kwboot.c source code you can find description of A38x BootROM bug which cause that resubmit/retry is broken and must not be used _after_ sending header.
Could you try instead to use kwboot from U-Boot v2021.07 for booting UART kwbimage? I just want to be sure that UART image is correctly generated by mkimage and I hope that this old kwboot is not smart enough for on-the-fly "patching".
Anyway, I think everything. I will prepare patches and send them to ML.
I added a write function after kwboot.c kwboot_img_patch gets called and compared the output. The files are identical until the very end where kwboot trims some zeros. I tried sending both the patched and unpatched file and got the same hanging with both. Given the patched file works with kwboot, I suspect the remaining magic is happening in the kwboot_xmodem function.
Ok.
I've never seen sx work on clearfog. I assumed the SPL serial output corrupted the transfer, so I've always used kwboot. Maybe it's a quirk of this board, but either way I don't think the result of this test is meaningful.
I thought that I saw sx working on A385 in the past. But maybe too long SPL output makes it broken.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part*/
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {kwboot_printv("Removing gap between image header anddata\n");
memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr),le32_to_cpu(hdr->blocksize));
hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {fprintf(stderr, "Cannot align image with secure header\n");goto err;}hdr->checksum = kwboot_hdr_csum8(hdr) - csum; *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE
option
and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
> Meanwhile could you do following tests? > > 1) The one which you done with patched kwboot and kwbimage, but send > output (sizes and aligning information from kwboot is useful there). > > 2) Use kwboot only for sending magic packet (-b without image) and
then
> use "sx" program for transferring kwb image over UART (instead of > kwboot). "sx" should work only with dedicated UART image type. > > These commands would do it (replace ttyX by correct UART device) > > $ ./tools/kwboot -b /dev/ttyX > $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb' > > > > > > diff --git a/tools/kwbimage.c b/tools/kwbimage.c > > > index 309657a5637b..177084adf825 100644 > > > --- a/tools/kwbimage.c > > > +++ b/tools/kwbimage.c > > > @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int
*hasext)
> > > if (count > 0) > > > headersz += sizeof(struct register_set_hdr_v1) +
8 *
count > > > + 4; > > > > > > + /* > > > + * For all images except UART, headersz stored in header itself > > > should > > > + * contains header size without padding. For UART image BootROM > > > rounds > > > + * down headersz to multiply of 128 bytes. Therefore
align
UART > > > headersz > > > + * to multiply of 128 bytes to ensure that remaining UART header > > > bytes > > > + * are not ignored by BootROM. > > > + */ > > > + if (image_get_bootfrom() == IBR_HDR_UART_ID) > > > + headersz = ALIGN(headersz, 128); > > > + > > > return headersz; > > > } > > > > > > diff --git a/tools/kwboot.c b/tools/kwboot.c > > > index 1844d7291fe0..b40800c108fc 100644 > > > --- a/tools/kwboot.c > > > +++ b/tools/kwboot.c > > > @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size,
int
> > > baudrate) > > > goto err; > > > } > > > kwboot_img_grow_data_right(img, size, sizeof(uint32_t)); > > > + /* Update the 32-bit data checksum */ > > > + *kwboot_img_csum32_ptr(img) =
kwboot_img_csum32(img);
> > > } > > > > > > if (!kwboot_img_has_ddr_init(img) && > > > @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size,
int
> > > baudrate) > > > > > > kwboot_printv("Aligning image header to Xmodem
block
> > > size\n"); > > > kwboot_img_grow_hdr(img, size, grow); > > > + > > > + /* > > > + * kwbimage v1 contains header size field and for UART > > > type it > > > + * must be set to the aligned xmodem header size because > > > BootROM > > > + * rounds header size down to xmodem block size. > > > + */ > > > + if (kwbimage_version(img) == 1) { > > > + hdrsz += grow; > > > + hdr->headersz_msb = hdrsz >> 16; > > > + hdr->headersz_lsb = cpu_to_le16(hdrsz & 0xffff); > > > + } > > > } > > > > > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > > > > > > > > > > > > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > > > > > Perfect! > > > > > > > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it
is
> > > configured to > > > > > > > > different configuration. In fourth commit I added all possible > > > boot > > > > > > mode > > > > > > > > strapping pin configurations which are recognized by
A385
> > > bootrom (and > > > > > > > > not the only one described in the HW spec, which is incomplete). > > > > > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot
source?
> > > Because I'm > > > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > > > > > Pali Rohár (6): > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f
constant
> > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros > > > > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_*
macros
> > > > > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20
++++++-------
> > > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > > > ++++++++++++++++---------- > > > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > > > > > -- > > > > > > > > 2.20.1 > > > > > > > > > > > > > > > > > > > > > > > > >
On Thursday 23 March 2023 19:33:27 Pali Rohár wrote:
On Thursday 23 March 2023 11:01:22 Martin Rowe wrote:
On Wed, 22 Mar 2023 at 18:09, Pali Rohár pali@kernel.org wrote:
On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote:
On Tue, 21 Mar 2023 at 17:26, Pali Rohár pali@kernel.org wrote:
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
> On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote: > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org
wrote:
> > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali@kernel.org
> wrote: > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which
specifies
> boot > > > > mode > > > > > > > source. > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still
configured
> into > > > > UART > > > > > > > > > booting mode via HW switches and if it still works > correctly? > > > > First > > > > > > > > > patch is reverting UART related commit for Clearfog
which I
> > > > think it > > > > > > > not > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef
before
> the > > > > switch > > > > > > > that > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > processed. It > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > probably > > > > because > > > > > > > of > > > > > > > > the invalid boot workaround for broken UART selection
that
> you > > > > > > > identified. > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or
if I
> select > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work
with
> the MMC > > > > or > > > > > > > SATA > > > > > > > > defconfigs. I get the same result without this patch
series
> > > > applied, > > > > > > > though. > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > header > > > > patching > > > > > > > > output) until after sending boot image data is complete.
The
> > > > output stops > > > > > > > > after: > > > > > > > > ================================ > > > > > > > > 98 % > > > >
[.................................................................
> > > > > > > > ] > > > > > > > > Done > > > > > > > > Finishing transfer > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > ================================ > > > > > > > > > > > > > > This is very strange because
CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
> just > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was
booted, it
> > > > correctly > > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued > sending > > > > main > > > > > > > u-boot and bootrom confirmed that transfer of both SPL and
main
> > > > u-boot > > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I
was
> sure > > > > was > > > > > > > > working after the last patches but I can no longer
reproduce
> a > > > > successful > > > > > > > > boot. > > > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot
from
> > > > version > > > > > > > with applying _all_ my patches recently sent to ML? Because > both > > > > mkimage > > > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those
changes in
> it. > > > > Steps: > > > > > > - Set UART boot mode on device > > > > > > - make clean > > > > > > - make clearfog_defconfig > > > > > > - make > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > For me it looks like that either mkimage generated incorrect > image size > > > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that > image size > > > > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > > > > > <MMC output> > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > > Patching image boot signature to UART > > > > > > Aligning image header to Xmodem block size > > > > > > Sending boot message. Please reboot the target...\ > > > > > > Sending boot image header (113408 bytes)... > > > > > > 0 % > > > > > > > > > > >
[......................................................................]
> > > > > > <snip> > > > > > > 94 % [.............................................. > > > > > > ] > > > > > > Done > > > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
12:57:31
> +1000) > > > > > > High speed PHY - Version: 2.0 > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > Pro. > > > > > > Detected Device ID 6828 > > > > > > board SerDes lanes topology details: > > > > > > | Lane # | Speed | Type | > > > > > > -------------------------------- > > > > > > | 0 | 3 | SATA0 | > > > > > > | 1 | 0 | SGMII1 | > > > > > > | 2 | 5 | PCIe1 | > > > > > > | 3 | 5 | USB3 HOST1 | > > > > > > | 4 | 5 | PCIe2 | > > > > > > | 5 | 0 | SGMII2 | > > > > > > -------------------------------- > > > > > > High speed PHY - Ended Successfully > > > > > > mv_ddr: 14.0.0 > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > > > > mv_ddr: completed successfully > > > > > > Trying to boot from BOOTROM > > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > > > > > Sending boot image data (474564 bytes)... > > > > > > 0 % > > > > > > > > > > >
[......................................................................]
> > > > > > <snip> > > > > > > 98 % > > > >
[....................................................................
> > > > > > ] > > > > > > Done > > > > > > Finishing transfer > > > > > > [Type Ctrl-\ + c to quit] > > > > > > </MMC output> > > > > > > > > > > > > <MMC sizes> > > > > > > du -b u-boot* > > > > > > 4996828 u-boot > > > > > > 474304 u-boot.bin > > > > > > 15155 u-boot.cfg > > > > > > 19496 u-boot.dtb > > > > > > 474304 u-boot-dtb.bin > > > > > > 474368 u-boot-dtb.img > > > > > > 474368 u-boot.img > > > > > > 1721 u-boot.lds > > > > > > 1069982 u-boot.map > > > > > > 454808 u-boot-nodtb.bin > > > > > > 1307712 u-boot.srec > > > > > > 198841 u-boot.sym > > > > > > 588288 u-boot-with-spl.kwb > > > > > > </MMC sizes> > > > > > > > > > > > > If I make menuconfig and set the boot mode to UART before
making
> I get: > > > > > > > > > > > > <UART output> > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > Detected kwbimage v1 with UART boot signature > > > > > > Aligning image header to Xmodem block size > > > > > > Sending boot message. Please reboot the target...\ > > > > > > Sending boot image header (113408 bytes)... > > > > > > 0 % > > > > > > > > > > >
[......................................................................]
> > > > > > <snip> > > > > > > 94 % [.............................................. > > > > > > ] > > > > > > Done > > > > > > > > > > > > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 -
13:20:48
> +1000) > > > > > > High speed PHY - Version: 2.0 > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > Pro. > > > > > > Detected Device ID 6828 > > > > > > board SerDes lanes topology details: > > > > > > | Lane # | Speed | Type | > > > > > > -------------------------------- > > > > > > | 0 | 3 | SATA0 | > > > > > > | 1 | 0 | SGMII1 | > > > > > > | 2 | 5 | PCIe1 | > > > > > > | 3 | 5 | USB3 HOST1 | > > > > > > | 4 | 5 | PCIe2 | > > > > > > | 5 | 0 | SGMII2 | > > > > > > -------------------------------- > > > > > > High speed PHY - Ended Successfully > > > > > > mv_ddr: 14.0.0 > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath
Window
> > > > > > mv_ddr: completed successfully > > > > > > Trying to boot from BOOTROM > > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > > > > > > Sending boot image data (474404 bytes)... > > > > > > 0 % > > > > > > > > > > >
[......................................................................]
> > > > > > <snip> > > > > > > 98 % > > > >
[...................................................................
> > > > > > ] > > > > > > Done > > > > > > Finishing transfer > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > > > > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 > +1000) > > > > > > </UART output> > > > > > > > > > > > > <UART sizes> > > > > > > du -b u-boot* > > > > > > 4997204 u-boot > > > > > > 474400 u-boot.bin > > > > > > 15103 u-boot.cfg > > > > > > 19496 u-boot.dtb > > > > > > 474400 u-boot-dtb.bin > > > > > > 474464 u-boot-dtb.img > > > > > > 474464 u-boot.img > > > > > > 1721 u-boot.lds > > > > > > 1070068 u-boot.map > > > > > > 454904 u-boot-nodtb.bin > > > > > > 1307988 u-boot.srec > > > > > > 198886 u-boot.sym > > > > > > 587904 u-boot-with-spl.kwb > > > > > > </UART sizes> > > > > > > > > > > > > The difference is very small somewhere if that is the cause.
Let
> me > > > > know if > > > > > > there's other data I can get to help with this one. > > > > > > > > > > Difference should be only in the kwbimage header plus some > aligning. It > > > > > just proves what I wrote before "mkimage generated incorrect
image
> size > > > > > for SDIO image. Or kwboot incorrectly parsed that image size > > > > > from kwbimage header and sent smaller image.". > > > > > > > > > > I will try to find a bug in mkimage or kwboot tool. Or you can
try
> it > > > > > too. As mmc booting is working fine from mmc I have felling
that
> bug is > > > > > in kwboot code which parses mmc images. > > > > > > > > Ok, I think I found 3 bugs, all are UART related (not mmc). Could > you try > > > > these changes? > > > > > > > > > > Dedicated UART still works, patching an MMC for UART with kwboot
still
> > > hangs after finishing transfer; no change. > > > > Bah :-( So there is still another bug. I will look at the code
again...
> > I do not see anything wrong there :-( > > Could you try to normally build mmc image and then run following > commands to manually generate uart image u-boot-with-spl.uart.kwb? > > sed 's/^BOOT_FROM.*/BOOT_FROM uart/'
./arch/arm/mach-mvebu/kwbimage.cfg
> > kwbimage.uart.cfg > ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e > 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb > > I would like to know if this UART image is bootable or not. >
It is bootable. Here is the output from the normal mkimage: ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.kwb Image Type: MVEBU Boot from sdio Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113664 Bytes = 111.00 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Here is the output from your custom command: ./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e 0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb Image Type: MVEBU Boot from uart Image Image version:1 BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB Data Size: 475072 Bytes = 463.94 KiB = 0.45 MiB Data Offset: 113536 Bytes = 110.88 KiB = 0.11 MiB Load Address: 00800000 Entry Point: 00800000
Obviously I have this output as I compiled it many times. There is nothing suspicious. Data offset is different just be cause mmc image is aligned to 512 byte long sector size and uart image is aligned to 128 byte log xmodem block size. Hence data offset needs to be multiply of 128 or 512 based on the image type
The difference is 128 bytes for the data offset. When I run kwboot I get: Sending boot image data (475204 bytes)... [for the normal mkimage which doesn't work] Sending boot image data (475076 bytes)... [for the custom mkimage which does work]
But this is suspicious. Data image size printed by kwboot is data size printed by mkimage plus 4 bytes (which is checksum). It is correct for custom uart image, but not for mmc image converted to uart image by kwboot.
And now I see where can be an issue. In kwbimage v1 header is stored length of the header itself (it can be variable length) and also offset where the data part of the image starts. As I pointed in one of the patch chunk sent previously, bootrom reads kwbimage header by loading number of xmodem blocks equals to header size divided by 128 (xmodem block size) rounded down. So patch chunk manually increased header size to the next multiply of 128 bytes. And after bootrom read kwbimage header it immediately starts reading data part of the image - and completely ignores the fact that in header is stored offset to the data part. In case we have different alignment, it is possible that between header and data part is a gap, which is multiply of the 128 bytes. E.g. original header size was 300 bytes, alignment was 512 bytes; new alignment is 128 bytes, which effectively decrease size of the header from 512 bytes to just 384 bytes; with creating a gap of 128 bytes between header and data part.
Could you try following change if it fixes?
Success! I tested kwboot patching of MMC, SATA and SPI images and all boot successfully with all 4 patches applied.
Perfect! Could you also try to send without kwboot patch image with that off-by-one offset which I described in other? It would be nice to have some proof that this is really the issue here.
One byte in either direction without the patch to remove the gap does not boot, just hangs after "Finishing transfer".
Ok, then probably I did not fully understood that disassembled code.
Hm.. have you recalculated also header checksum? If not then failure is expected. Because the first byte of the data image is moved to the position of the last byte of the header (where is the filler) and so it breaks header checksum. If you send me working mmc kwbimage I can try to convert it into "shifted off-by-one" uart kwbimage.
The patch moves the data by 256 bytes with the same files, so it seems like there's another effect involved.
This movement is correct. It is changing alignment from 512 bytes to just 128 bytes. So if in the last 512 byte long block are only 200 bytes then then 200 bytes in 128 byte long alignment needs only 256 bytes and so gap between 256th byte and 512th byte needs to be removed.
I will prepare another kwboot and kwbimage patches which finally should solve these issues.
UART images work with all 4 patches applied as well, but also work with just the two patches at the end of kwboot.c kwboot_img_patch applied.
Could you try to send UART image also via "sx" utility? Just to be sure that UART images generated by mkimage are valid for xmodem transfer without need to do any kwboot on-the-fly patching.
./tools/kwboot -b /dev/ttyUSB0 sx -b u-boot-with-spl.kwb < /dev/ttyUSB0 > /dev/ttyUSB0 Sending u-boot-with-spl.kwb, 4626 blocks: Give your local XMODEM receive command now. Xmodem sectors/kbytes sent: 898/112kRetry 0: Got 0d for sector ACK Retry 0: NAK on sector Retry 0: Got 6c for sector ACK Retry 0: NAK on sector Retry 0: Got 49 for sector ACK Retry 0: NAK on sector Retry 0: Got 49 for sector ACK Retry 0: NAK on sector Bytes Sent: 592128 BPS:7679
Transfer complete ./tools/kwboot -t /dev/ttyUSB0 kwboot version 2023.04-rc4-00342-g7e562609bb-dirty [Type Ctrl-\ + c to quit]
...and nothing; no u-boot prompt, system doesn't boot, it just hangs like when kwboot fails.
Ah... I guess sx is too smart is trying to resubmit xmodem block when it receives unknown reply (which is the SPL output). If you look into kwboot.c source code you can find description of A38x BootROM bug which cause that resubmit/retry is broken and must not be used _after_ sending header.
Could you try instead to use kwboot from U-Boot v2021.07 for booting UART kwbimage? I just want to be sure that UART image is correctly generated by mkimage and I hope that this old kwboot is not smart enough for on-the-fly "patching".
Anyway, I think everything. I will prepare patches and send them to ML.
I added a write function after kwboot.c kwboot_img_patch gets called and compared the output. The files are identical until the very end where kwboot trims some zeros. I tried sending both the patched and unpatched file and got the same hanging with both. Given the patched file works with kwboot, I suspect the remaining magic is happening in the kwboot_xmodem function.
Ok.
I've never seen sx work on clearfog. I assumed the SPL serial output corrupted the transfer, so I've always used kwboot. Maybe it's a quirk of this board, but either way I don't think the result of this test is meaningful.
I thought that I saw sx working on A385 in the past. But maybe too long SPL output makes it broken.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index a118a26d282c..272128db3946 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -2181,6 +2181,16 @@ kwboot_img_patch(void *img, size_t *size, int baudrate) } }
/* Remove the gap between header and data part by moving data part*/
if (!is_secure && hdrsz != le32_to_cpu(hdr->srcaddr)) {kwboot_printv("Removing gap between image header anddata\n");
memmove(img + hdrsz, img + le32_to_cpu(hdr->srcaddr),le32_to_cpu(hdr->blocksize));
hdr->srcaddr = cpu_to_le32(hdrsz);} else if (le32_to_cpu(hdr->srcaddr) % KWBOOT_XM_BLKSZ) {fprintf(stderr, "Cannot align image with secure header\n");goto err;}hdr->checksum = kwboot_hdr_csum8(hdr) - csum; *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);That 128 extra carries across. I'll poke around a bit more, but it seems like a good lead so I wanted to share.
> Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE
option
> and check if you see early announce message on UART. >
That's enabled for all the clearfog builds already.
> > Meanwhile could you do following tests? > > > > 1) The one which you done with patched kwboot and kwbimage, but send > > output (sizes and aligning information from kwboot is useful there). > > > > 2) Use kwboot only for sending magic packet (-b without image) and
then
> > use "sx" program for transferring kwb image over UART (instead of > > kwboot). "sx" should work only with dedicated UART image type. > > > > These commands would do it (replace ttyX by correct UART device) > > > > $ ./tools/kwboot -b /dev/ttyX > > $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb' > > > > > > > > > diff --git a/tools/kwbimage.c b/tools/kwbimage.c > > > > index 309657a5637b..177084adf825 100644 > > > > --- a/tools/kwbimage.c > > > > +++ b/tools/kwbimage.c > > > > @@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int
*hasext)
> > > > if (count > 0) > > > > headersz += sizeof(struct register_set_hdr_v1) +
8 *
> count > > > > + 4; > > > > > > > > + /* > > > > + * For all images except UART, headersz stored in header > itself > > > > should > > > > + * contains header size without padding. For UART image > BootROM > > > > rounds > > > > + * down headersz to multiply of 128 bytes. Therefore
align
> UART > > > > headersz > > > > + * to multiply of 128 bytes to ensure that remaining UART > header > > > > bytes > > > > + * are not ignored by BootROM. > > > > + */ > > > > + if (image_get_bootfrom() == IBR_HDR_UART_ID) > > > > + headersz = ALIGN(headersz, 128); > > > > + > > > > return headersz; > > > > } > > > > > > > > diff --git a/tools/kwboot.c b/tools/kwboot.c > > > > index 1844d7291fe0..b40800c108fc 100644 > > > > --- a/tools/kwboot.c > > > > +++ b/tools/kwboot.c > > > > @@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size,
int
> > > > baudrate) > > > > goto err; > > > > } > > > > kwboot_img_grow_data_right(img, size, > sizeof(uint32_t)); > > > > + /* Update the 32-bit data checksum */ > > > > + *kwboot_img_csum32_ptr(img) =
kwboot_img_csum32(img);
> > > > } > > > > > > > > if (!kwboot_img_has_ddr_init(img) && > > > > @@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size,
int
> > > > baudrate) > > > > > > > > kwboot_printv("Aligning image header to Xmodem
block
> > > > size\n"); > > > > kwboot_img_grow_hdr(img, size, grow); > > > > + > > > > + /* > > > > + * kwbimage v1 contains header size field and for > UART > > > > type it > > > > + * must be set to the aligned xmodem header size > because > > > > BootROM > > > > + * rounds header size down to xmodem block size. > > > > + */ > > > > + if (kwbimage_version(img) == 1) { > > > > + hdrsz += grow; > > > > + hdr->headersz_msb = hdrsz >> 16; > > > > + hdr->headersz_lsb = cpu_to_le16(hdrsz & > 0xffff); > > > > + } > > > > } > > > > > > > > hdr->checksum = kwboot_hdr_csum8(hdr) - csum; > > > > > > > > > > > > > > > > > > > > > > > > Also could you check if SATA booting is still working > correctly? > > > > > > > > > > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > > > > > > > Perfect! > > > > > > > > > > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it
is
> > > > configured to > > > > > > > > > different configuration. In fourth commit I added all > possible > > > > boot > > > > > > > mode > > > > > > > > > strapping pin configurations which are recognized by
A385
> > > > bootrom (and > > > > > > > > > not the only one described in the HW spec, which is > incomplete). > > > > > > > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot
source?
> > > > Because I'm > > > > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > > > > > > > Pali Rohár (6): > > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f
constant
> > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function > macros > > > > > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* > macros > > > > > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_*
macros
> > > > > > > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20
++++++-------
> > > > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > > > > ++++++++++++++++---------- > > > > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > > > > > > > -- > > > > > > > > > 2.20.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
One more question. Did you set boot mode HW switches to UART position? Or are they in MMC position and magic boot pattern from kwboot triggers UART boot?
On Mon, 20 Mar 2023 at 19:42, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
One more question. Did you set boot mode HW switches to UART position? Or are they in MMC position and magic boot pattern from kwboot triggers UART boot?
HW switches to UART position.
On Tuesday 21 March 2023 08:03:45 Martin Rowe wrote:
On Mon, 20 Mar 2023 at 19:42, Pali Rohár pali@kernel.org wrote:
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
Dedicated UART still works, patching an MMC for UART with kwboot still hangs after finishing transfer; no change.
One more question. Did you set boot mode HW switches to UART position? Or are they in MMC position and magic boot pattern from kwboot triggers UART boot?
HW switches to UART position.
Could you try also the second option. Put it into mmc position and use kwboot with magic pattern for booting? Just to ensure that if some HW reset occurs we will see boot log of mmc u-boot.
Hi Pali,
On 3/4/23 11:50, Pali Rohár wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
Also could you check if SATA booting is still working correctly?
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
No, theadorable only boots from SPI NOR.
Thanks, Stefan
On Saturday 04 March 2023 11:50:30 Pali Rohár wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
Also could you check if SATA booting is still working correctly?
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Is something else needed to do with this patch series?
Because the discussion in this patch thread just pointed to different issues, not related this this patch series.
Hi Pali,
On Sat, Mar 25, 2023 at 6:30 AM Pali Rohár pali@kernel.org wrote:
On Saturday 04 March 2023 11:50:30 Pali Rohár wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
Also could you check if SATA booting is still working correctly?
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Is something else needed to do with this patch series?
Because the discussion in this patch thread just pointed to different issues, not related this this patch series.
For my part I'm OK. The boot mode detection works properly when the strapping pin is set to spi1. The issue comes after that. The spi0 versus spi1 in SPL is a different issue that I will need to investigate further. At the moment it falls back to BootROM, which is also very fast booting anyway.
Thanks, Tony
On Sat, Mar 25, 2023 at 12:27 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Pali,
On Sat, Mar 25, 2023 at 6:30 AM Pali Rohár pali@kernel.org wrote:
On Saturday 04 March 2023 11:50:30 Pali Rohár wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
Also could you check if SATA booting is still working correctly?
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Is something else needed to do with this patch series?
Because the discussion in this patch thread just pointed to different issues, not related this this patch series.
For my part I'm OK. The boot mode detection works properly when the strapping pin is set to spi1. The issue comes after that. The spi0 versus spi1 in SPL is a different issue that I will need to investigate further. At the moment it falls back to BootROM, which is also very fast booting anyway.
Tested-by: Tony Dinh mibodhi@gmail.com
Thanks, Tony
On Sat, 25 Mar 2023 at 13:30, Pali Rohár pali@kernel.org wrote:
On Saturday 04 March 2023 11:50:30 Pali Rohár wrote:
Improve code for checking strapping pins which specifies boot mode source.
Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore.
Also could you check if SATA booting is still working correctly?
Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete).
Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 20 ++++++------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 35 insertions(+), 26 deletions(-)
-- 2.20.1
Is something else needed to do with this patch series?
Because the discussion in this patch thread just pointed to different issues, not related this this patch series.
Tested this patch with everything that just went into next, plus the switch fix, and all boot successfully: - MMC - eMMC - SD card - UART via kwboot - SATA (including UART via kwboot) - SPI (including UART via kwboot) - UART
Tested-by: Martin Rowe martin.p.rowe@gmail.com
Improve code for checking strapping pins which specifies boot mode source.
v2 is same as v1 with compile fix and rebased on top of next branch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 24 +++++++-------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 36 insertions(+), 29 deletions(-)
A385 BootROM treats strapping configuration 0x3f as invalid. When booting fails (e.g. because of invalid configuration) then BootROM fallbacks to UART booting.
Detecting BootROM fallback to UART booting is implemented in U-Boot since commit 2fd4284051e3 ("ARM: mach-mvebu: handle fall-back to UART boot").
So there is no need to define BOOT_FROM_UART_ALT constant and special handling for it anymore, remove it.
This change effectively revers commit f3a88e2ca17a ("arm: mvebu: fix boot from UART on ClearFog Base").
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com --- arch/arm/mach-mvebu/cpu.c | 3 --- arch/arm/mach-mvebu/include/mach/soc.h | 1 - 2 files changed, 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index 8b91e174c4c1..b72037d45b1c 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -111,9 +111,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_MMC1; #endif case BOOT_FROM_UART: -#ifdef BOOT_FROM_UART_ALT - case BOOT_FROM_UART_ALT: -#endif return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA: diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 6edd2e2d79c7..4a9463292fcb 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -164,7 +164,6 @@ #define BOOT_FROM_SATA 0x22 #define BOOT_FROM_UART 0x28 #define BOOT_FROM_SATA_ALT 0x2A -#define BOOT_FROM_UART_ALT 0x3f #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31
On 3/29/23 21:03, Pali Rohár wrote:
A385 BootROM treats strapping configuration 0x3f as invalid. When booting fails (e.g. because of invalid configuration) then BootROM fallbacks to UART booting.
Detecting BootROM fallback to UART booting is implemented in U-Boot since commit 2fd4284051e3 ("ARM: mach-mvebu: handle fall-back to UART boot").
So there is no need to define BOOT_FROM_UART_ALT constant and special handling for it anymore, remove it.
This change effectively revers commit f3a88e2ca17a ("arm: mvebu: fix boot from UART on ClearFog Base").
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
arch/arm/mach-mvebu/cpu.c | 3 --- arch/arm/mach-mvebu/include/mach/soc.h | 1 - 2 files changed, 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index 8b91e174c4c1..b72037d45b1c 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -111,9 +111,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_MMC1; #endif case BOOT_FROM_UART: -#ifdef BOOT_FROM_UART_ALT
- case BOOT_FROM_UART_ALT:
-#endif return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA: diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 6edd2e2d79c7..4a9463292fcb 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -164,7 +164,6 @@ #define BOOT_FROM_SATA 0x22 #define BOOT_FROM_UART 0x28 #define BOOT_FROM_SATA_ALT 0x2A -#define BOOT_FROM_UART_ALT 0x3f #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31
Viele Grüße, Stefan Roese
A385 BootROM treats strapping configuration 0x22 as SPI-NAND. So remove incorrect definition 0x22 as SATA. SATA on A385 has configuration 0x2A.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com --- arch/arm/mach-mvebu/cpu.c | 1 - arch/arm/mach-mvebu/include/mach/soc.h | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index b72037d45b1c..0fcd520c1dbc 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -114,7 +114,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA: - case BOOT_FROM_SATA_ALT: return BOOT_DEVICE_SATA; #endif case BOOT_FROM_SPI: diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 4a9463292fcb..3266749836a7 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -161,9 +161,8 @@ #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x22 +#define BOOT_FROM_SATA 0x2A #define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SATA_ALT 0x2A #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31
On 3/29/23 21:03, Pali Rohár wrote:
A385 BootROM treats strapping configuration 0x22 as SPI-NAND. So remove incorrect definition 0x22 as SATA. SATA on A385 has configuration 0x2A.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
arch/arm/mach-mvebu/cpu.c | 1 - arch/arm/mach-mvebu/include/mach/soc.h | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index b72037d45b1c..0fcd520c1dbc 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -114,7 +114,6 @@ u32 get_boot_device(void) return BOOT_DEVICE_UART; #ifdef BOOT_FROM_SATA case BOOT_FROM_SATA:
- case BOOT_FROM_SATA_ALT: return BOOT_DEVICE_SATA; #endif case BOOT_FROM_SPI:
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 4a9463292fcb..3266749836a7 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -161,9 +161,8 @@ #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x22 +#define BOOT_FROM_SATA 0x2A #define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SATA_ALT 0x2A #define BOOT_FROM_SPI 0x32 #define BOOT_FROM_MMC 0x30 #define BOOT_FROM_MMC_ALT 0x31
Viele Grüße, Stefan Roese
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com --- arch/arm/mach-mvebu/cpu.c | 20 ++++++++++---------- arch/arm/mach-mvebu/include/mach/soc.h | 25 ++++++++++++------------- 2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index 0fcd520c1dbc..1676032682b5 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -100,27 +100,27 @@ u32 get_boot_device(void) val = readl(CFG_SAR_REG); /* SAR - Sample At Reset */ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS; debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device); - switch (boot_device) { #ifdef BOOT_FROM_NAND - case BOOT_FROM_NAND: + if (BOOT_FROM_NAND(boot_device)) return BOOT_DEVICE_NAND; #endif #ifdef BOOT_FROM_MMC - case BOOT_FROM_MMC: - case BOOT_FROM_MMC_ALT: + if (BOOT_FROM_MMC(boot_device)) return BOOT_DEVICE_MMC1; #endif - case BOOT_FROM_UART: +#ifdef BOOT_FROM_UART + if (BOOT_FROM_UART(boot_device)) return BOOT_DEVICE_UART; +#endif #ifdef BOOT_FROM_SATA - case BOOT_FROM_SATA: + if (BOOT_FROM_SATA(boot_device)) return BOOT_DEVICE_SATA; #endif - case BOOT_FROM_SPI: +#ifdef BOOT_FROM_SPI + if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI; - default: - return BOOT_DEVICE_BOOTROM; - }; +#endif + return BOOT_DEVICE_BOOTROM; }
#if defined(CONFIG_DISPLAY_CPUINFO) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 3266749836a7..82a98cf9ff57 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -143,8 +143,8 @@ #define BOOT_DEV_SEL_OFFS 3 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30 -#define BOOT_FROM_SPI 0x38 +#define BOOT_FROM_UART(x) (x == 0x30) +#define BOOT_FROM_SPI(x) (x == 0x38)
#define CFG_SYS_TCLK ((readl(CFG_SAR_REG) & BIT(20)) ? \ 200000000 : 166000000) @@ -160,12 +160,11 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x2A -#define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SPI 0x32 -#define BOOT_FROM_MMC 0x30 -#define BOOT_FROM_MMC_ALT 0x31 +#define BOOT_FROM_NAND(x) (x == 0x0A) +#define BOOT_FROM_SATA(x) (x == 0x2A) +#define BOOT_FROM_UART(x) (x == 0x28) +#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CFG_SYS_TCLK ((readl(CFG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) @@ -182,9 +181,9 @@ #define BOOT_DEV_SEL_OFFS 11 #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1 -#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_NAND(x) (x == 0x1) +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CFG_SYS_TCLK 200000000 /* 200MHz */ #elif defined(CONFIG_ARMADA_XP) @@ -204,8 +203,8 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CFG_SYS_TCLK 250000000 /* 250MHz */ #endif
On 3/29/23 21:03, Pali Rohár wrote:
This allows to merge BOOT_FROM_MMC and BOOT_FROM_MMC_ALT constants to one macro. And also allows to extend other BOOT_FROM_* macros for other variants.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
arch/arm/mach-mvebu/cpu.c | 20 ++++++++++---------- arch/arm/mach-mvebu/include/mach/soc.h | 25 ++++++++++++------------- 2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c index 0fcd520c1dbc..1676032682b5 100644 --- a/arch/arm/mach-mvebu/cpu.c +++ b/arch/arm/mach-mvebu/cpu.c @@ -100,27 +100,27 @@ u32 get_boot_device(void) val = readl(CFG_SAR_REG); /* SAR - Sample At Reset */ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS; debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
- switch (boot_device) { #ifdef BOOT_FROM_NAND
- case BOOT_FROM_NAND:
- if (BOOT_FROM_NAND(boot_device)) return BOOT_DEVICE_NAND; #endif #ifdef BOOT_FROM_MMC
- case BOOT_FROM_MMC:
- case BOOT_FROM_MMC_ALT:
- if (BOOT_FROM_MMC(boot_device)) return BOOT_DEVICE_MMC1; #endif
- case BOOT_FROM_UART:
+#ifdef BOOT_FROM_UART
- if (BOOT_FROM_UART(boot_device)) return BOOT_DEVICE_UART;
+#endif #ifdef BOOT_FROM_SATA
- case BOOT_FROM_SATA:
- if (BOOT_FROM_SATA(boot_device)) return BOOT_DEVICE_SATA; #endif
- case BOOT_FROM_SPI:
+#ifdef BOOT_FROM_SPI
- if (BOOT_FROM_SPI(boot_device)) return BOOT_DEVICE_SPI;
- default:
return BOOT_DEVICE_BOOTROM;- };
+#endif
return BOOT_DEVICE_BOOTROM; }
#if defined(CONFIG_DISPLAY_CPUINFO)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 3266749836a7..82a98cf9ff57 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -143,8 +143,8 @@ #define BOOT_DEV_SEL_OFFS 3 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x30 -#define BOOT_FROM_SPI 0x38 +#define BOOT_FROM_UART(x) (x == 0x30) +#define BOOT_FROM_SPI(x) (x == 0x38)
#define CFG_SYS_TCLK ((readl(CFG_SAR_REG) & BIT(20)) ? \ 200000000 : 166000000) @@ -160,12 +160,11 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x0A -#define BOOT_FROM_SATA 0x2A -#define BOOT_FROM_UART 0x28 -#define BOOT_FROM_SPI 0x32 -#define BOOT_FROM_MMC 0x30 -#define BOOT_FROM_MMC_ALT 0x31 +#define BOOT_FROM_NAND(x) (x == 0x0A) +#define BOOT_FROM_SATA(x) (x == 0x2A) +#define BOOT_FROM_UART(x) (x == 0x28) +#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31)
#define CFG_SYS_TCLK ((readl(CFG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000) @@ -182,9 +181,9 @@ #define BOOT_DEV_SEL_OFFS 11 #define BOOT_DEV_SEL_MASK (0x7 << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND 0x1 -#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_NAND(x) (x == 0x1) +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CFG_SYS_TCLK 200000000 /* 200MHz */ #elif defined(CONFIG_ARMADA_XP) @@ -204,8 +203,8 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_UART 0x2 -#define BOOT_FROM_SPI 0x3 +#define BOOT_FROM_UART(x) (x == 0x2) +#define BOOT_FROM_SPI(x) (x == 0x3)
#define CFG_SYS_TCLK 250000000 /* 250MHz */ #endif
Viele Grüße, Stefan Roese
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are:
0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid
Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com --- arch/arm/mach-mvebu/include/mach/soc.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 82a98cf9ff57..b02e30552276 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) +#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 && x <= 0x25)) +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39)
#define CFG_SYS_TCLK ((readl(CFG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000)
On 3/29/23 21:03, Pali Rohár wrote:
Disassembling A385 BootROM binary reveal how BootROM interprets strapping pins for Boot Device Mode. All possible options are:
0x00..0x07 -> Parallel NOR 0x08..0x15 -> Parallel NAND 0x16..0x17 -> Parallel NOR 0x18..0x25 -> Parallel NAND 0x26..0x27 -> SPI NAND 0x28..0x29 -> UART xmodem 0x2a..0x2b -> SATA 0x2c..0x2d -> PCI Express 0x2e..0x2f -> Parallel NOR 0x30..0x31 -> SD / eMMC 0x32..0x39 -> SPI NOR 0x3a..0x3c -> Parallel NOR 0x3d..0x3e -> UART debug console 0x3f -> Invalid
Note that Boot Device Mode Options in A38x Hardware Specifications is incomplete.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
arch/arm/mach-mvebu/include/mach/soc.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 82a98cf9ff57..b02e30552276 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -160,11 +160,14 @@ #define BOOT_DEV_SEL_OFFS 4 #define BOOT_DEV_SEL_MASK (0x3f << BOOT_DEV_SEL_OFFS)
-#define BOOT_FROM_NAND(x) (x == 0x0A) -#define BOOT_FROM_SATA(x) (x == 0x2A) -#define BOOT_FROM_UART(x) (x == 0x28) -#define BOOT_FROM_SPI(x) (x == 0x32) +#define BOOT_FROM_NOR(x) ((x >= 0x00 && x <= 0x07) || x == 0x16 || x == 0x17 || x == 0x2E || x == 0x2F || (x >= 0x3A && x <= 0x3C)) +#define BOOT_FROM_NAND(x) ((x >= 0x08 && x <= 0x15) || (x >= 0x18 && x <= 0x25)) +#define BOOT_FROM_SPINAND(x) (x == 0x26 || x == 0x27) +#define BOOT_FROM_UART(x) (x == 0x28 || x == 0x29) +#define BOOT_FROM_SATA(x) (x == 0x2A || x == 0x2B) +#define BOOT_FROM_PEX(x) (x == 0x2C || x == 0x2D) #define BOOT_FROM_MMC(x) (x == 0x30 || x == 0x31) +#define BOOT_FROM_SPI(x) (x >= 0x32 && x <= 0x39)
#define CFG_SYS_TCLK ((readl(CFG_SAR_REG) & BIT(15)) ? \ 200000000 : 250000000)
Viele Grüße, Stefan Roese
A385 BootROM fills into bits [31:28] of register 0x182d0 tracing value, which represents in which state BootROM currently is. BootROM fills one of the possible values: 0x2 (CPU initialization), 0x3 (UART detection), 0x6 (UART booting), 0x8 (PCI Express booting), 0x9 (parallel or SPI NOR booting), 0xA (parallel or SPI NAND booting), 0xB (SATA booting) and 0xE (SD / eMMC booting).
Meaning of these values matches TRACE_* macros from Marvell soc_spec.h file: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013...
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com --- arch/arm/mach-mvebu/include/mach/soc.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index b02e30552276..c04fa339c31e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -128,7 +128,14 @@ #define BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0)) #define BOOTROM_ERR_MODE_OFFS 28 #define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS) +#define BOOTROM_ERR_MODE_MAIN 0x2 +#define BOOTROM_ERR_MODE_EXEC 0x3 #define BOOTROM_ERR_MODE_UART 0x6 +#define BOOTROM_ERR_MODE_PEX 0x8 +#define BOOTROM_ERR_MODE_NOR 0x9 +#define BOOTROM_ERR_MODE_NAND 0xA +#define BOOTROM_ERR_MODE_SATA 0xB +#define BOOTROM_ERR_MODE_MMC 0xE #define BOOTROM_ERR_CODE_OFFS 0 #define BOOTROM_ERR_CODE_MASK (0xf << BOOTROM_ERR_CODE_OFFS)
On 3/29/23 21:03, Pali Rohár wrote:
A385 BootROM fills into bits [31:28] of register 0x182d0 tracing value, which represents in which state BootROM currently is. BootROM fills one of the possible values: 0x2 (CPU initialization), 0x3 (UART detection), 0x6 (UART booting), 0x8 (PCI Express booting), 0x9 (parallel or SPI NOR booting), 0xA (parallel or SPI NAND booting), 0xB (SATA booting) and 0xE (SD / eMMC booting).
Meaning of these values matches TRACE_* macros from Marvell soc_spec.h file: https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013...
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
arch/arm/mach-mvebu/include/mach/soc.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index b02e30552276..c04fa339c31e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -128,7 +128,14 @@ #define BOOTROM_ERR_REG (MVEBU_REGISTER(0x182d0)) #define BOOTROM_ERR_MODE_OFFS 28 #define BOOTROM_ERR_MODE_MASK (0xf << BOOTROM_ERR_MODE_OFFS) +#define BOOTROM_ERR_MODE_MAIN 0x2 +#define BOOTROM_ERR_MODE_EXEC 0x3 #define BOOTROM_ERR_MODE_UART 0x6 +#define BOOTROM_ERR_MODE_PEX 0x8 +#define BOOTROM_ERR_MODE_NOR 0x9 +#define BOOTROM_ERR_MODE_NAND 0xA +#define BOOTROM_ERR_MODE_SATA 0xB +#define BOOTROM_ERR_MODE_MMC 0xE #define BOOTROM_ERR_CODE_OFFS 0 #define BOOTROM_ERR_CODE_MASK (0xf << BOOTROM_ERR_CODE_OFFS)
Viele Grüße, Stefan Roese
Definitions are according to the MV78460 Hardware Specifications.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com --- arch/arm/mach-mvebu/include/mach/soc.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index c04fa339c31e..dc68d406f99e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -213,8 +213,12 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
+#define BOOT_FROM_NOR(x) (x == 0x0) +#define BOOT_FROM_NAND(x) (x == 0x1) #define BOOT_FROM_UART(x) (x == 0x2) #define BOOT_FROM_SPI(x) (x == 0x3) +#define BOOT_FROM_PEX(x) (x == 0x4) +#define BOOT_FROM_SATA(x) (x == 0x5)
#define CFG_SYS_TCLK 250000000 /* 250MHz */ #endif
On 3/29/23 21:03, Pali Rohár wrote:
Definitions are according to the MV78460 Hardware Specifications.
Signed-off-by: Pali Rohár pali@kernel.org Tested-by: Tony Dinh mibodhi@gmail.com Tested-by: Martin Rowe martin.p.rowe@gmail.com
Reviewed-by: Stefan Roese sr@denx.de
Thanks, Stefan
arch/arm/mach-mvebu/include/mach/soc.h | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index c04fa339c31e..dc68d406f99e 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -213,8 +213,12 @@ #define BOOT_DEV_SEL_OFFS 5 #define BOOT_DEV_SEL_MASK (0xf << BOOT_DEV_SEL_OFFS)
+#define BOOT_FROM_NOR(x) (x == 0x0) +#define BOOT_FROM_NAND(x) (x == 0x1) #define BOOT_FROM_UART(x) (x == 0x2) #define BOOT_FROM_SPI(x) (x == 0x3) +#define BOOT_FROM_PEX(x) (x == 0x4) +#define BOOT_FROM_SATA(x) (x == 0x5)
#define CFG_SYS_TCLK 250000000 /* 250MHz */ #endif
Viele Grüße, Stefan Roese
On 3/29/23 21:03, Pali Rohár wrote:
Improve code for checking strapping pins which specifies boot mode source.
v2 is same as v1 with compile fix and rebased on top of next branch.
Pali Rohár (6): arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant arm: mvebu: Convert BOOT_FROM_* constants to function macros arm: mvebu: Define all options for A38x BOOT_FROM_* macros arm: mvebu: Define all BOOTROM_ERR_MODE_* macros arm: mvebu: Define all options for AXP BOOT_FROM_* macros
arch/arm/mach-mvebu/cpu.c | 24 +++++++-------- arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++---------- 2 files changed, 36 insertions(+), 29 deletions(-)
Applied to u-boot-marvell/next
Thanks, Stefan
participants (4)
-
Martin Rowe -
Pali Rohár -
Stefan Roese -
Tony Dinh