[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

[PATCH RFC u-boot-mvebu 1/6] arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant

[Pali Rohár]

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
-- 
2.20.1

[PATCH RFC u-boot-mvebu 2/6] arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant

[Pali Rohár]

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
-- 
2.20.1

[PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros

[Pali Rohár]

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
-- 
2.20.1

[PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros

[Pali Rohár]

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)
-- 
2.20.1

[PATCH RFC u-boot-mvebu 5/6] arm: mvebu: Define all BOOTROM_ERR_MODE_* macros

[Pali Rohár]

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.01-armada-18.06/tools/marvell/doimage_mv/soc_spec.h

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)
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 6/6] arm: mvebu: Define all options for AXP BOOT_FROM_* macros

[Pali Rohár]

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
-- 
2.20.1

Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros

[Pali Rohár]

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
> 

Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros

[Martin Rowe]

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

Re: [PATCH RFC u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros

[Martin Rowe]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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

Re: [PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Stefan Roese]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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?

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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?
> 
> 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
> > > > > > > >
> > > > > > > >
> > > > > >
> > >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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.

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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.

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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?
> >
> > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
>

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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?
> > >
> > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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?
> > > >
> > > > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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?
> > > > >
> > > > > 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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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 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?
> > > >
> > > > 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > >
>

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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 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?
> > > > >
> > > > > 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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > >
> >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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 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?
> > > > > >
> > > > > > 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
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > >
> > >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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 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?
> > > > > > >
> > > > > > > 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
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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 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?
> > > > > > > >
> > > > > > > > 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
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > >

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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.

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Tony Dinh]

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

Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Martin Rowe]

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>

Re: [PATCH RFC u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros

[Stefan Roese]

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) {
>>>   #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)

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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

[PATCH v2 u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[Pali Rohár]

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(-)

-- 
2.20.1

[PATCH v2 u-boot-mvebu 1/6] arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant

[Pali Rohár]

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
-- 
2.20.1

[PATCH v2 u-boot-mvebu 2/6] arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant

[Pali Rohár]

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
-- 
2.20.1

[PATCH v2 u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros

[Pali Rohár]

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
-- 
2.20.1

[PATCH v2 u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros

[Pali Rohár]

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)
-- 
2.20.1

[PATCH v2 u-boot-mvebu 5/6] arm: mvebu: Define all BOOTROM_ERR_MODE_* macros

[Pali Rohár]

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.01-armada-18.06/tools/marvell/doimage_mv/soc_spec.h

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)
 
-- 
2.20.1

[PATCH v2 u-boot-mvebu 6/6] arm: mvebu: Define all options for AXP BOOT_FROM_* macros

[Pali Rohár]

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
-- 
2.20.1

Re: [PATCH v2 u-boot-mvebu 1/6] arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant

[Stefan Roese]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH v2 u-boot-mvebu 2/6] arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant

[Stefan Roese]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH v2 u-boot-mvebu 3/6] arm: mvebu: Convert BOOT_FROM_* constants to function macros

[Stefan Roese]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH v2 u-boot-mvebu 4/6] arm: mvebu: Define all options for A38x BOOT_FROM_* macros

[Stefan Roese]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH v2 u-boot-mvebu 5/6] arm: mvebu: Define all BOOTROM_ERR_MODE_* macros

[Stefan Roese]

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.01-armada-18.06/tools/marvell/doimage_mv/soc_spec.h
> 
> 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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH v2 u-boot-mvebu 6/6] arm: mvebu: Define all options for AXP BOOT_FROM_* macros

[Stefan Roese]

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

-- 
DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH v2 u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

[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