[PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

This patch series contains various improvements and fixes for existing
logical errors. Boot phase was adjusted to match behavior of Armada 385
BootROM by inspecting and disassembling of BootROM binary dump itself.
Important information are included in documentation patch for kwboot.
Most of the changes are untested, hence this patch series is just RFC.
So please test changes before applying, idealy on SPI, SATA and SD/MMC.
Nevertheless all patches on github passed CI testing in this PR:
https://github.com/u-boot/u-boot/pull/275

Pali Rohár (59):
  tools: kwbimage: Fix generating, verifying and extracting SDIO
    kwbimage
  tools: kwboot: Fix parsing SDIO kwbimage
  arm: mvebu: spl: Fix parsing SDIO kwbimage
  cmd: mvebu/bubt: Fix parsing SDIO kwbimage
  tools: kwbimage: Fix generating, verifying and extracting SATA
    kwbimage
  tools: kwboot: Fix parsing SATA kwbimage
  arm: mvebu: spl: Fix parsing SATA kwbimage
  cmd: mvebu/bubt: Fix parsing SATA kwbimage
  arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
    BOOT_DEVICE_MMC2_2
  arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
  spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
  arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
  tools: kwboot: Add more documentation references
  tools: kwboot: Add image type documentation
  tools: kwboot: Fix parsing UART image without data checksum
  tools: kwboot: Validate optional kwbimage v1 headers
  tools: kwboot: Add check that kwbimage contains DDR init code
  tools: kwboot: Fix patching of SPI/NOR XIP images
  tools: kwboot: Show image type and error parsing reasons
  cmd: mvebu/bubt: Add support for selecting eMMC HW partition
  cmd: mvebu/bubt: Add support for writing image to SATA disk
  cmd: mvebu/bubt: Add support for reading image from the SATA disk
    partition
  cmd: mvebu/bubt: Rename variable image_size to hdr_size
  cmd: mvebu/bubt: Mark all local symbols as static
  cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
  cmd: mvebu/bubt: Check also A8K boot image checksum
  cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
  cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
  cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
    'fuse_read_u64' defined but not used
  cmd: mvebu/bubt: Enable command by default
  tools: kwbimage: Fix dumping register set / DATA commands
  tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
  tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
  tools: kwbimage: Fix dumping NAND_BLKSZ
  tools: kwbimage: Fix generating of kwbimage v0 header checksum
  tools: kwbimage: Fix endianity when printing kwbimage header
  tools: kwbimage: Reject mkimage -F option
  tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
  tools: kwbimage: Print binary image offset as size
  tools: kwbimage: Print image data offset when printing kwbimage header
  tools: kwbimage: Simplify add_secure_header_v1()
  tools: kwbimage: Rename imagesz to dataoff
  tools: kwbimage: Fix generating secure boot data image signature
  tools: kwbimage: Fix invalid secure boot header signature
  tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
  tools: kwbimage: Add support for XIP SPI/NOR images
  tools: mkimage: Print human readable error when -d is not specified
  tools: mkimage: Do not try to open datafile when it is skipped
  tools: kwbimage: Add support for creating an image with no data
  arm: mvebu: Add support for generating NAND kwbimage
  arm: mvebu: Add support for generating PEX kwbimage
  arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
  arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
  arm: mvebu: clearfog: Add defconfig for SATA booting
  arm: mvebu: Remove A39x relicts
  arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
  arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
  arm: mvebu: Define SPL memory maps
  doc/kwboot.1: Update example description

 arch/arm/mach-mvebu/Kconfig                   |  23 +-
 arch/arm/mach-mvebu/Makefile                  |  13 +
 arch/arm/mach-mvebu/cpu.c                     |  11 +-
 arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
 arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
 .../serdes/a38x/high_speed_env_spec.c         |   4 +-
 .../serdes/a38x/high_speed_env_spec.h         |   4 +-
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
 arch/arm/mach-mvebu/spl.c                     |  84 +++--
 cmd/mvebu/Kconfig                             |  18 ++
 cmd/mvebu/bubt.c                              | 253 ++++++++++++---
 common/spl/Kconfig                            |   9 +
 common/spl/spl_mmc.c                          |  12 +-
 ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
 ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
 doc/kwboot.1                                  |   3 +-
 doc/mvebu/cmd/bubt.txt                        |  25 +-
 drivers/mtd/nand/raw/Kconfig                  |   4 +-
 tools/kwbimage.c                              | 297 +++++++++++-------
 tools/kwboot.c                                | 200 +++++++++++-
 tools/mkimage.c                               |  11 +-
 22 files changed, 768 insertions(+), 281 deletions(-)
 copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
 copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)

-- 
2.20.1

[PATCH RFC u-boot-mvebu 01/59] tools: kwbimage: Fix generating, verifying and extracting SDIO kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SDIO image as offset in number of sectors (like for SATA
image), but as offset in bytes (like for all other images except SATA).

To generate SDIO kwbimage compatible with Marvell BootROM, it is needed to
have srcaddr in bytes. This change fixes SDIO images for Armada 38x SoCs.

Fixes: 501a54a29cc2 ("tools: kwbimage: Fix generation of SATA, SDIO and PCIe images")
Fixes: 5c61710c9880 ("tools: kwbimage: Properly set srcaddr in kwbimage v0")
Fixes: e0c243c398a7 ("tools: kwbimage: Validate data checksum of v1 images")
Fixes: aa6943ca3122 ("kwbimage: Add support for extracting images via dumpimage tool")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 29 -----------------------------
 1 file changed, 29 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 6abb9f2d5c01..09d52d47652f 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1021,15 +1021,6 @@ static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
 	if (main_hdr->blockid == IBR_HDR_SATA_ID)
 		main_hdr->srcaddr = cpu_to_le32(headersz / 512 + 1);
 
-	/*
-	 * For SDIO srcaddr is specified in number of sectors starting from
-	 * sector 0. The main header is stored at sector number 0.
-	 * This expects sector size to be 512 bytes.
-	 * Header size is already aligned.
-	 */
-	if (main_hdr->blockid == IBR_HDR_SDIO_ID)
-		main_hdr->srcaddr = cpu_to_le32(headersz / 512);
-
 	/* For PCIe srcaddr is not used and must be set to 0xFFFFFFFF. */
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
 		main_hdr->srcaddr = cpu_to_le32(0xFFFFFFFF);
@@ -1478,15 +1469,6 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
 	if (main_hdr->blockid == IBR_HDR_SATA_ID)
 		main_hdr->srcaddr = cpu_to_le32(headersz / 512 + 1);
 
-	/*
-	 * For SDIO srcaddr is specified in number of sectors starting from
-	 * sector 0. The main header is stored at sector number 0.
-	 * This expects sector size to be 512 bytes.
-	 * Header size is already aligned.
-	 */
-	if (main_hdr->blockid == IBR_HDR_SDIO_ID)
-		main_hdr->srcaddr = cpu_to_le32(headersz / 512);
-
 	/* For PCIe srcaddr is not used and must be set to 0xFFFFFFFF. */
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
 		main_hdr->srcaddr = cpu_to_le32(0xFFFFFFFF);
@@ -2039,14 +2021,6 @@ static int kwbimage_verify_header(unsigned char *ptr, int image_size,
 		offset *= 512;
 	}
 
-	/*
-	 * For SDIO srcaddr is specified in number of sectors.
-	 * This expects that sector size is 512 bytes and recalculates
-	 * data offset to bytes.
-	 */
-	if (blockid == IBR_HDR_SDIO_ID)
-		offset *= 512;
-
 	/*
 	 * For PCIe srcaddr is always set to 0xFFFFFFFF.
 	 * This expects that data starts after all headers.
@@ -2408,9 +2382,6 @@ static int kwbimage_extract_subimage(void *ptr, struct image_tool_params *params
 			offset *= 512;
 		}
 
-		if (mhdr->blockid == IBR_HDR_SDIO_ID)
-			offset *= 512;
-
 		if (mhdr->blockid == IBR_HDR_PEX_ID && offset == 0xFFFFFFFF)
 			offset = header_size;
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 02/59] tools: kwboot: Fix parsing SDIO kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SDIO image as offset in number of sectors (like for SATA
image), but as offset in bytes (like for all other images except SATA).

To parse SDIO kwbimage in the same way as Marvell BootROM, it is needed to
interpret srcaddr in bytes. This change fixes loading of SDIO images via
kwboot over UART.

Fixes: 792e42355083 ("tools: kwboot: Patch source address in image header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index da4fe32da226..188f944263fa 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1894,10 +1894,6 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 		hdr->srcaddr = cpu_to_le32((srcaddr - 1) * 512);
 		break;
 
-	case IBR_HDR_SDIO_ID:
-		hdr->srcaddr = cpu_to_le32(srcaddr * 512);
-		break;
-
 	case IBR_HDR_PEX_ID:
 		if (srcaddr == 0xFFFFFFFF)
 			hdr->srcaddr = cpu_to_le32(hdrsz);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 03/59] arm: mvebu: spl: Fix parsing SDIO kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SDIO image as offset in number of sectors (like for SATA
image), but as offset in bytes (like for all other images except SATA).

To process SDIO kwbimage and load U-Boot proper from it in the same way as
Marvell BootROM, it is needed to interpret srcaddr in bytes. This change
fixes booting of U-Boot proper from SPL code stored in SDIO image.

Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/spl.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 424599286e5e..b238ba2f5d99 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -196,14 +196,6 @@ int spl_parse_board_header(struct spl_image_info *spl_image,
 		spl_image->offset *= 512;
 	}
 
-	/*
-	 * For SDIO (eMMC) srcaddr is specified in number of sectors.
-	 * This expects that sector size is 512 bytes and recalculates
-	 * data offset to bytes.
-	 */
-	if (IS_ENABLED(CONFIG_SPL_MMC) && mhdr->blockid == IBR_HDR_SDIO_ID)
-		spl_image->offset *= 512;
-
 	if (spl_image->offset % 4 != 0) {
 		printf("ERROR: Wrong srcaddr (0x%08x) in kwbimage\n",
 		       spl_image->offset);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 04/59] cmd: mvebu/bubt: Fix parsing SDIO kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SDIO image as offset in number of sectors (like for SATA
image), but as offset in bytes (like for all other images except SATA).

To ensure that we do not store invalid SDIO image to the boot location
(read by the Marvell BootROM), we need to check that image is valid
and srcaddr is intepreted in bytes, in the same way as it is done by
Marvell BootROM.

This fixes rejecting valid and accepting invalid SDIO images by bubt command.

Fixes: 5a0653493307 ("cmd: mvebu/bubt: Check for A38x image data checksum")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 1efbe2e607ca..6bb84da03ed6 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -747,9 +747,6 @@ static int check_image_header(void)
 		offset *= 512;
 	}
 
-	if (hdr->blockid == 0xAE) /* SDIO id */
-		offset *= 512;
-
 	if (offset % 4 != 0 || size < 4 || size % 4 != 0) {
 		printf("Error: Bad A38x image blocksize.\n");
 		return -ENOEXEC;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 05/59] tools: kwbimage: Fix generating, verifying and extracting SATA kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SATA image as number of sectors the beginning of the hard
drive, but as number of sectors relative to the main header.

The main header is stored at absolute sector number 1. So do not add or
subtract it when calculating with relative offsets to the main header.

Fixes: 501a54a29cc2 ("tools: kwbimage: Fix generation of SATA, SDIO and PCIe images")
Fixes: 5c61710c9880 ("tools: kwbimage: Properly set srcaddr in kwbimage v0")
Fixes: e0c243c398a7 ("tools: kwbimage: Validate data checksum of v1 images")
Fixes: aa6943ca3122 ("kwbimage: Add support for extracting images via dumpimage tool")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 24 +++++++-----------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 09d52d47652f..67b45503e466 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1013,13 +1013,12 @@ static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
 					     sizeof(struct main_hdr_v0));
 
 	/*
-	 * For SATA srcaddr is specified in number of sectors starting from
-	 * sector 0. The main header is stored at sector number 1.
+	 * For SATA srcaddr is specified in number of sectors.
 	 * This expects the sector size to be 512 bytes.
 	 * Header size is already aligned.
 	 */
 	if (main_hdr->blockid == IBR_HDR_SATA_ID)
-		main_hdr->srcaddr = cpu_to_le32(headersz / 512 + 1);
+		main_hdr->srcaddr = cpu_to_le32(headersz / 512);
 
 	/* For PCIe srcaddr is not used and must be set to 0xFFFFFFFF. */
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
@@ -1461,13 +1460,12 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
 		main_hdr->flags = e->debug ? 0x1 : 0;
 
 	/*
-	 * For SATA srcaddr is specified in number of sectors starting from
-	 * sector 0. The main header is stored at sector number 1.
+	 * For SATA srcaddr is specified in number of sectors.
 	 * This expects the sector size to be 512 bytes.
 	 * Header size is already aligned.
 	 */
 	if (main_hdr->blockid == IBR_HDR_SATA_ID)
-		main_hdr->srcaddr = cpu_to_le32(headersz / 512 + 1);
+		main_hdr->srcaddr = cpu_to_le32(headersz / 512);
 
 	/* For PCIe srcaddr is not used and must be set to 0xFFFFFFFF. */
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
@@ -2010,16 +2008,10 @@ static int kwbimage_verify_header(unsigned char *ptr, int image_size,
 
 	/*
 	 * For SATA srcaddr is specified in number of sectors.
-	 * The main header is must be stored at sector number 1.
-	 * This expects that sector size is 512 bytes and recalculates
-	 * data offset to bytes relative to the main header.
+	 * This expects that sector size is 512 bytes.
 	 */
-	if (blockid == IBR_HDR_SATA_ID) {
-		if (offset < 1)
-			return -FDT_ERR_BADSTRUCTURE;
-		offset -= 1;
+	if (blockid == IBR_HDR_SATA_ID)
 		offset *= 512;
-	}
 
 	/*
 	 * For PCIe srcaddr is always set to 0xFFFFFFFF.
@@ -2377,10 +2369,8 @@ static int kwbimage_extract_subimage(void *ptr, struct image_tool_params *params
 		/* Extract data image when -p is not specified or when '-p 0' is specified */
 		offset = le32_to_cpu(mhdr->srcaddr);
 
-		if (mhdr->blockid == IBR_HDR_SATA_ID) {
-			offset -= 1;
+		if (mhdr->blockid == IBR_HDR_SATA_ID)
 			offset *= 512;
-		}
 
 		if (mhdr->blockid == IBR_HDR_PEX_ID && offset == 0xFFFFFFFF)
 			offset = header_size;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 06/59] tools: kwboot: Fix parsing SATA kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SATA image as number of sectors the beginning of the hard
drive, but as number of sectors relative to the main header.

To parse SATA kwbimage in the same way as Marvell BootROM, it is needed to
interpret srcaddr as relative offset to the main header. This change fixes
loading of SATA images via kwboot over UART.

Fixes: 792e42355083 ("tools: kwboot: Patch source address in image header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 188f944263fa..bf410520de63 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1888,10 +1888,7 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 
 	switch (hdr->blockid) {
 	case IBR_HDR_SATA_ID:
-		if (srcaddr < 1)
-			goto err;
-
-		hdr->srcaddr = cpu_to_le32((srcaddr - 1) * 512);
+		hdr->srcaddr = cpu_to_le32(srcaddr * 512);
 		break;
 
 	case IBR_HDR_PEX_ID:
-- 
2.20.1

[PATCH RFC u-boot-mvebu 07/59] arm: mvebu: spl: Fix parsing SATA kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SATA image as number of sectors the beginning of the hard
drive, but as number of sectors relative to the main header.

To process SATA kwbimage and load U-Boot proper from it in the same way as
Marvell BootROM, it is needed to interpret srcaddr as relative offset to
the main header. This change fixes booting of U-Boot proper from SPL code
in SATA image.

Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/spl.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index b238ba2f5d99..6a398612628e 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -182,19 +182,10 @@ int spl_parse_board_header(struct spl_image_info *spl_image,
 
 	/*
 	 * For SATA srcaddr is specified in number of sectors.
-	 * The main header is must be stored at sector number 1.
-	 * This expects that sector size is 512 bytes and recalculates
-	 * data offset to bytes relative to the main header.
+	 * This expects that sector size is 512 bytes.
 	 */
-	if (IS_ENABLED(CONFIG_SPL_SATA) && mhdr->blockid == IBR_HDR_SATA_ID) {
-		if (spl_image->offset < 1) {
-			printf("ERROR: Wrong srcaddr (0x%08x) in SATA kwbimage\n",
-			       spl_image->offset);
-			return -EINVAL;
-		}
-		spl_image->offset -= 1;
+	if (IS_ENABLED(CONFIG_SPL_SATA) && mhdr->blockid == IBR_HDR_SATA_ID)
 		spl_image->offset *= 512;
-	}
 
 	if (spl_image->offset % 4 != 0) {
 		printf("ERROR: Wrong srcaddr (0x%08x) in kwbimage\n",
-- 
2.20.1

[PATCH RFC u-boot-mvebu 08/59] cmd: mvebu/bubt: Fix parsing SATA kwbimage

[Pali Rohár]

Despite the official specification, Marvell BootROM does not interpret
srcaddr from SATA image as number of sectors the beginning of the hard
drive, but as number of sectors relative to the main header.

Reject invalid and accept valid SATA images.

Fixes: 5a0653493307 ("cmd: mvebu/bubt: Check for A38x image data checksum")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 6bb84da03ed6..2bcdf145f64a 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -738,14 +738,8 @@ static int check_image_header(void)
 	offset = le32_to_cpu(hdr->srcaddr);
 	size = le32_to_cpu(hdr->blocksize);
 
-	if (hdr->blockid == 0x78) { /* SATA id */
-		if (offset < 1) {
-			printf("Error: Bad A38x image srcaddr.\n");
-			return -ENOEXEC;
-		}
-		offset -= 1;
+	if (hdr->blockid == 0x78) /* SATA id */
 		offset *= 512;
-	}
 
 	if (offset % 4 != 0 || size < 4 || size % 4 != 0) {
 		printf("Error: Bad A38x image blocksize.\n");
-- 
2.20.1

[PATCH RFC u-boot-mvebu 09/59] arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2

[Pali Rohár]

BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2 are representing mmc dev 1 but all
Armada SoCs have only one mmc controller. So remove references to
non-existent second mmc controller.

Fixes: f830703f4284 ("arm: mvebu: Check that kwbimage blockid matches boot mode")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/spl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 6a398612628e..e14c7a9c6cf2 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -169,9 +169,7 @@ int spl_parse_board_header(struct spl_image_info *spl_image,
 	}
 
 	if (IS_ENABLED(CONFIG_SPL_MMC) &&
-	    (bootdev->boot_device == BOOT_DEVICE_MMC1 ||
-	     bootdev->boot_device == BOOT_DEVICE_MMC2 ||
-	     bootdev->boot_device == BOOT_DEVICE_MMC2_2) &&
+	    (bootdev->boot_device == BOOT_DEVICE_MMC1) &&
 	    mhdr->blockid != IBR_HDR_SDIO_ID) {
 		printf("ERROR: Wrong blockid (0x%x) in SDIO kwbimage\n",
 		       mhdr->blockid);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 10/59] arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition

[Pali Rohár]

When eMMC boot is selected then BootROM loads kwbimage header (U-Boot SPL)
from the selected eMMC boot partition. So for eMMC boot ensure that U-Boot
SPL loads U-Boot proper (from kwbimage) also from the same selected eMMC
boot partition.

Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 arch/arm/mach-mvebu/spl.c   | 8 +++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 594e9a03d901..5303b1cbb965 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -330,6 +330,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
 	imply SPL_GPIO
 	imply SPL_LIBDISK_SUPPORT
 	imply SPL_MMC
+	select SUPPORT_EMMC_BOOT if SPL_MMC
 	select SPL_BOOTROM_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_SATA
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index e14c7a9c6cf2..0a809e91349c 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -41,6 +41,12 @@
  * kwbimage main header.
  */
 #ifdef CONFIG_SPL_MMC
+#ifdef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
+#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG is unsupported
+#endif
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
+#error CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION is unsupported
+#endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 #error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
 #endif
@@ -98,7 +104,7 @@ struct kwbimage_main_hdr_v1 {
 #ifdef CONFIG_SPL_MMC
 u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
 {
-	return MMCSD_MODE_RAW;
+	return MMCSD_MODE_EMMCBOOT;
 }
 #endif
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 11/59] spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION

[Pali Rohár]

On some platforms is SYS_MMCSD_FS_BOOT_PARTITION unsupported. So allow to
completely disable MMC FS Boot support via new option SYS_MMCSD_FS_BOOT.

By default MMC FS Boot support is enabled (like it was before) except for
ARCH_MVEBU where MMC FS Boot supported is unsupported due to Marvell
BootROM limitations.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 common/spl/Kconfig   |  9 +++++++++
 common/spl/spl_mmc.c | 12 +++---------
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index d774c930a80b..fdee0bd06936 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -815,8 +815,17 @@ config SPL_MMC
 	  this option to build the drivers in drivers/mmc as part of an SPL
 	  build.
 
+config SYS_MMCSD_FS_BOOT
+	bool "MMC FS Boot mode"
+	depends on SPL_MMC
+	default y if !ARCH_MVEBU
+	help
+	  Enable MMC FS Boot mode. Partition is selected by option
+	  SYS_MMCSD_FS_BOOT_PARTITION.
+
 config SYS_MMCSD_FS_BOOT_PARTITION
 	int "MMC Boot Partition"
+	depends on SYS_MMCSD_FS_BOOT
 	default 1
 	help
 	  Partition on the MMC to load U-Boot from when the MMC is being
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e4135b204875..bd5e6adf1ea6 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -272,7 +272,7 @@ int spl_start_uboot(void)
 }
 #endif
 
-#ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT
 static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image,
 			      struct spl_boot_device *bootdev,
 			      struct mmc *mmc,
@@ -341,14 +341,6 @@ static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image,
 
 	return err;
 }
-#else
-static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image,
-			      struct spl_boot_device *bootdev,
-			      struct mmc *mmc,
-			      const char *filename)
-{
-	return -ENOSYS;
-}
 #endif
 
 u32 __weak spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
@@ -481,6 +473,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
 			return err;
 #endif
 		/* If RAW mode fails, try FS mode. */
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT
 	case MMCSD_MODE_FS:
 		debug("spl: mmc boot mode: fs\n");
 
@@ -489,6 +482,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
 			return err;
 
 		break;
+#endif
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
 	default:
 		puts("spl: mmc: wrong boot mode\n");
-- 
2.20.1

[PATCH RFC u-boot-mvebu 12/59] arm: mvebu: spl: Fix support for loading U-Boot proper from SD card

[Pali Rohár]

Marvell BootROM loads MMC image from sector 0 (HW boot or data partition)
and SD image from sector 1.

So for SD card booting it is needed to not use constant CONFIG MMC options
and instead of them it is needed to define functions spl_mmc_boot_mode()
spl_mmc_get_uboot_raw_sector() which determinate offsets at SPL runtime
based on MMC or SD card.

Calculation of SD card sector expects following values:
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0

Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/Kconfig |  1 +
 arch/arm/mach-mvebu/spl.c   | 40 ++++++++++++++++++++++++++++---------
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5303b1cbb965..2863babefbe3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -331,6 +331,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
 	imply SPL_LIBDISK_SUPPORT
 	imply SPL_MMC
 	select SUPPORT_EMMC_BOOT if SPL_MMC
+	select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC
 	select SPL_BOOTROM_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_SATA
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 0a809e91349c..02528e025d8c 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -33,14 +33,27 @@
 #endif
 
 /*
- * When loading U-Boot via SPL from eMMC (in Marvell terminology SDIO), the
- * kwbimage main header is stored at sector 0. U-Boot SPL needs to parse this
- * header and figure out at which sector the U-Boot proper binary is stored.
- * Partition booting is therefore not supported and CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
- * and CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET need to point to the
- * kwbimage main header.
+ * When loading U-Boot via SPL from eMMC, the kwbimage main header is stored at
+ * sector 0 and either on HW boot partition or on data partition. Choice of HW
+ * partition depends on what is configured in eMMC EXT_CSC register.
+ * When loading U-Boot via SPL from SD card, the kwbimage main header is stored
+ * at sector 1.
+ * Therefore MBR/GPT partition booting, fixed sector number and fixed eMMC HW
+ * partition number are unsupported due to limitation of Marvell BootROM.
+ * Correct sector number must be determined as runtime in mvebu SPL code based
+ * on the detected boot source. Otherwise U-Boot SPL would not be able to load
+ * U-Boot proper.
+ * Runtime mvebu SPL sector calculation code expects:
+ * - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0
+ * - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0
  */
 #ifdef CONFIG_SPL_MMC
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT
+#error CONFIG_SYS_MMCSD_FS_BOOT is unsupported
+#endif
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
+#error CONFIG_SYS_MMCSD_FS_BOOT_PARTITION is unsupported
+#endif
 #ifdef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
 #error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG is unsupported
 #endif
@@ -50,10 +63,14 @@
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 #error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
 #endif
-#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) && CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR != 0
+#ifndef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR must be enabled for SD/eMMC boot support
+#endif
+#if !defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) || \
+    CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR != 0
 #error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR must be set to 0
 #endif
-#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET) && \
+#if !defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET) || \
     CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET != 0
 #error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET must be set to 0
 #endif
@@ -104,7 +121,12 @@ struct kwbimage_main_hdr_v1 {
 #ifdef CONFIG_SPL_MMC
 u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
 {
-	return MMCSD_MODE_EMMCBOOT;
+	return IS_SD(mmc) ? MMCSD_MODE_RAW : MMCSD_MODE_EMMCBOOT;
+}
+unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
+					   unsigned long raw_sect)
+{
+	return IS_SD(mmc) ? 1 : 0;
 }
 #endif
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 13/59] tools: kwboot: Add more documentation references

[Pali Rohár]

Add reference to Avanta Boot Flow documentation, BobCat2, AlleyCat3 and
PONCat3 BootROM Firmware documentation and links to public Marvell tools:
hdrparser.c and doimage.c

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index bf410520de63..aae7393aeef6 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -15,6 +15,12 @@
  *   Processor, and High-Definition Video Decoder: Functional Specifications"
  *   August 3, 2011. Chapter 5 "BootROM Firmware"
  *   https://web.archive.org/web/20120130172443/https://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
+ * - "88F6665, 88F6660, 88F6658, 88F6655, 88F6655F, 88F6650, 88F6650F, 88F6610,
+ *   and 88F6610F Avanta LP Family Integrated Single/Dual CPU Ecosystem for
+ *   Gateway (GW), Home Gateway Unit (HGU), and Single Family Unit (SFU)
+ *   Functional Specifications" Doc. No. MV-S108952-00, Rev. A. November 7, 2013.
+ *   Chapter 7 "Boot Flow"
+ *   CONFIDENTIAL, no public documentation available
  * - "88F6710, 88F6707, and 88F6W11: ARMADA(R) 370 SoC: Functional Specifications"
  *   May 26, 2014. Chapter 6 "BootROM Firmware".
  *   https://web.archive.org/web/20140617183701/https://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
@@ -22,6 +28,15 @@
  *   Multi-Core ARMv7 Based SoC Processors: Functional Specifications"
  *   May 29, 2014. Chapter 6 "BootROM Firmware".
  *   https://web.archive.org/web/20180829171131/https://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
+ * - "BobCat2 Control and Management Subsystem Functional Specifications"
+ *   Doc. No. MV-S109400-00, Rev. A. December 4, 2014.
+ *   Chapter 1.6 BootROM Firmware
+ *   CONFIDENTIAL, no public documentation available
+ * - "AlleyCat3 and PONCat3 Highly Integrated 1/10 Gigabit Ethernet Switch
+ *   Control and Management Subsystem: Functional Specifications"
+ *   Doc. No. MV-S109693-00, Rev. A. May 20, 2014.
+ *   Chapter 1.6 BootROM Firmware
+ *   CONFIDENTIAL, no public documentation available
  * - "ARMADA(R) 375 Value-Performance Dual Core CPU System on Chip: Functional
  *   Specifications" Doc. No. MV-S109377-00, Rev. A. September 18, 2013.
  *   Chapter 7 "Boot Sequence"
@@ -35,6 +50,10 @@
  *   System on Chip Functional Specifications" Doc. No. MV-S109896-00, Rev. B.
  *   December 22, 2015. Chapter 7 "Boot Flow"
  *   CONFIDENTIAL, no public documentation available
+ * - "Marvell boot image parser", Marvell U-Boot 2013.01, version 18.06. September 17, 2015.
+ *   https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/hdrparser.c
+ * - "Marvell doimage Tool", Marvell U-Boot 2013.01, version 18.06. August 30, 2015.
+ *   https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/doimage.c
  */
 
 #include "kwbimage.h"
-- 
2.20.1

[PATCH RFC u-boot-mvebu 14/59] tools: kwboot: Add image type documentation

[Pali Rohár]

Add information of all available image types and where they should be
stored. Storage location offsets where documented from the disassembly of
the A385 BootROM image dump.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index aae7393aeef6..7a7dd5bf3d7b 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -54,6 +54,68 @@
  *   https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/hdrparser.c
  * - "Marvell doimage Tool", Marvell U-Boot 2013.01, version 18.06. August 30, 2015.
  *   https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/doimage.c
+ *
+ * Storage location / offset of different image types:
+ * - IBR_HDR_SPI_ID (0x5A):
+ *   SPI image can be stored at any 2 MB aligned offset in the first 16 MB of
+ *   SPI-NOR or parallel-NOR. Despite the type name it really can be stored on
+ *   parallel-NOR and cannot be stored on other SPI devices, like SPI-NAND.
+ *   So it should have been named NOR image, not SPI image. This image type
+ *   supports XIP - Execute In Place directly from NOR memory.
+ *
+ * - IBR_HDR_NAND_ID (0x8B):
+ *   NAND image can be stored either at any 2 MB aligned offset in the first
+ *   16 MB of SPI-NAND or at any blocksize aligned offset in the first 64 MB
+ *   of parallel-NAND.
+ *
+ * - IBR_HDR_PEX_ID (0x9C):
+ *   PEX image is used for booting from PCI Express device. Source address
+ *   stored in image is ignored by BootROM. It is not the BootROM who parses
+ *   or loads data part of the PEX image. BootROM just configures SoC to the
+ *   PCIe endpoint mode and let the PCIe device on the other end of the PCIe
+ *   link (which must be in Root Complex mode) to load kwbimage into SoC's
+ *   memory and tell BootROM physical address.
+ *
+ * - IBR_HDR_UART_ID (0x69):
+ *   UART image can be transfered via xmodem protocol over first UART.
+ *
+ * - IBR_HDR_I2C_ID (0x4D):
+ *   It is unknown for what kind of storage is used this image. It is not
+ *   specified in any document from References section.
+ *
+ * - IBR_HDR_SATA_ID (0x78):
+ *   SATA image can be stored at sector 1 (after the MBR table), sector 34
+ *   (after the GPT table) or at any next sector which is aligned to 2 MB and
+ *   is in the first 16 MB of SATA disk. Note that source address in SATA image
+ *   is stored in sector unit and not in bytes like for any other images.
+ *   Unfortunately sector size is disk specific, in most cases it is 512 bytes
+ *   but there are also Native 4K SATA disks which have 4096 bytes long sectors.
+ *
+ * - IBR_HDR_SDIO_ID (0xAE):
+ *   SDIO image can be stored on different medias:
+ *   - SD(SC) card
+ *   - SDHC/SDXC card
+ *   - eMMC HW boot partition
+ *   - eMMC user data partition / MMC card
+ *   It cannot be stored on SDIO card despite the image name.
+ *
+ *   For SD(SC)/SDHC/SDXC cards, image can be stored at the same locations as
+ *   the SATA image (sector 1, sector 34 or any 2 MB aligned sector) but within
+ *   the first 64 MB. SDHC and SDXC cards have fixed 512 bytes long sector size.
+ *   Old SD(SC) cards unfortunately can have also different sector sizes, mostly
+ *   1024 bytes long sector sizes and also can be changed at runtime.
+ *
+ *   For MMC-compatible devices, image can be stored at offset 0 or at offset
+ *   2 MB. If MMC device supports HW boot partitions then image must be stored
+ *   on the HW partition as is configured in the EXT_CSC register (it can be
+ *   either boot or user data).
+ *
+ *   Note that source address for SDIO image is stored in byte unit, like for
+ *   any other images (except SATA). Marvell Functional Specifications for
+ *   A38x and A39x SoCs say that source address is in sector units, but this
+ *   is purely incorrect information. A385 BootROM really expects source address
+ *   for SDIO images in bytes and also Marvell tools generate SDIO image with
+ *   source address in byte units.
  */
 
 #include "kwbimage.h"
-- 
2.20.1

[PATCH RFC u-boot-mvebu 15/59] tools: kwboot: Fix parsing UART image without data checksum

[Pali Rohár]

The 32-bit data checksum in UART image is not checked by the BootROM and
also Marvell tools do not generate it.

So if data checksum stored in UART image does not match calculated checksum
from the image then treat those checksum bytes as part of the executable
image code (and not as the checksum) and for compatibility with the rest of
the code manually insert data checksum into the in-memory image after the
executable code, without overwriting it.

This should allow to boot UART images generated by Marvell tools.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7a7dd5bf3d7b..da840864b565 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1990,8 +1990,18 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 	    *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
 		goto err;
 
-	if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img))
-		goto err;
+	/*
+	 * The 32-bit data checksum is optional for UART image. If it is not
+	 * present (checksum detected as invalid) then grow data part of the
+	 * image for the checksum, so it can be inserted there.
+	 */
+	if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img)) {
+		if (hdr->blockid != IBR_HDR_UART_ID) {
+			fprintf(stderr, "Image has invalid data checksum\n");
+			goto err;
+		}
+		kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
+	}
 
 	is_secure = kwboot_img_is_secure(img);
 
@@ -2256,6 +2266,7 @@ main(int argc, char **argv)
 				 KWBOOT_XM_BLKSZ +
 				 sizeof(kwboot_baud_code) +
 				 sizeof(kwboot_baud_code_data_jump) +
+				 sizeof(uint32_t) +
 				 KWBOOT_XM_BLKSZ;
 
 	if (imgpath) {
-- 
2.20.1

[PATCH RFC u-boot-mvebu 16/59] tools: kwboot: Validate optional kwbimage v1 headers

[Pali Rohár]

Before starting parsing of kwbimage, first validate that all optional v1
headers and correct. This prevents kwboot crashes on invalid input.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index da840864b565..c8c7a8d24658 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1939,6 +1939,7 @@ static int
 kwboot_img_patch(void *img, size_t *size, int baudrate)
 {
 	struct main_hdr_v1 *hdr;
+	struct opt_hdr_v1 *ohdr;
 	uint32_t srcaddr;
 	uint8_t csum;
 	size_t hdrsz;
@@ -1990,6 +1991,13 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 	    *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
 		goto err;
 
+	for_each_opt_hdr_v1 (ohdr, hdr) {
+		if (!opt_hdr_v1_valid_size(ohdr, (const uint8_t *)hdr + hdrsz)) {
+			fprintf(stderr, "Invalid optional image header\n");
+			goto err;
+		}
+	}
+
 	/*
 	 * The 32-bit data checksum is optional for UART image. If it is not
 	 * present (checksum detected as invalid) then grow data part of the
-- 
2.20.1

[PATCH RFC u-boot-mvebu 17/59] tools: kwboot: Add check that kwbimage contains DDR init code

[Pali Rohár]

Some NOR images may be execute-in-place and do not contain DDR init code in
its kwbimage header. Such images cannot be booted over UART as BootROM
loads them to RAM. Add check that kwbimage contains DDR init code in its
header (either as binary code header or as the simple register-value set).

In some cases it is possible to load very small image into L2SRAM and when
DDR init code is not required. So check for L2SRAM load address and skip
DDR init code check in this case.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index c8c7a8d24658..f624edc7798f 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1780,6 +1780,47 @@ kwboot_img_is_secure(void *img)
 	return 0;
 }
 
+static int
+kwboot_img_has_ddr_init(void *img)
+{
+	const struct register_set_hdr_v1 *rhdr;
+	const struct main_hdr_v0 *hdr0;
+	struct opt_hdr_v1 *ohdr;
+	u32 ohdrsz;
+	int last;
+
+	/*
+	 * kwbimage v0 image headers contain DDR init code either in
+	 * extension header or in binary code header.
+	 */
+	if (kwbimage_version(img) == 0) {
+		hdr0 = img;
+		return hdr0->ext || hdr0->bin;
+	}
+
+	/*
+	 * kwbimage v1 image headers contain DDR init code either in binary
+	 * code header or in a register set list header with SDRAM_SETUP.
+	 */
+	for_each_opt_hdr_v1 (ohdr, img) {
+		if (ohdr->headertype == OPT_HDR_V1_BINARY_TYPE)
+			return 1;
+		if (ohdr->headertype == OPT_HDR_V1_REGISTER_TYPE) {
+			rhdr = (const struct register_set_hdr_v1 *)ohdr;
+			ohdrsz = opt_hdr_v1_size(ohdr);
+			if (ohdrsz >= sizeof(*ohdr) + sizeof(rhdr->data[0].last_entry)) {
+				ohdrsz -= sizeof(*ohdr) + sizeof(rhdr->data[0].last_entry);
+				last = ohdrsz / sizeof(rhdr->data[0].entry);
+				if (rhdr->data[last].last_entry.delay ==
+				    REGISTER_SET_HDR_OPT_DELAY_SDRAM_SETUP)
+					return 1;
+			}
+		}
+	}
+
+	return 0;
+}
+
 static void *
 kwboot_img_grow_data_right(void *img, size_t *size, size_t grow)
 {
@@ -2011,6 +2052,13 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 		kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
 	}
 
+	if (!kwboot_img_has_ddr_init(img) &&
+	    (le32_to_cpu(hdr->destaddr) < 0x40000000 ||
+	     le32_to_cpu(hdr->destaddr) + le32_to_cpu(hdr->blocksize) > 0x40034000)) {
+		fprintf(stderr, "Image does not contain DDR init code needed for UART booting\n");
+		goto err;
+	}
+
 	is_secure = kwboot_img_is_secure(img);
 
 	if (hdr->blockid != IBR_HDR_UART_ID) {
-- 
2.20.1

[PATCH RFC u-boot-mvebu 18/59] tools: kwboot: Fix patching of SPI/NOR XIP images

[Pali Rohár]

Marvell BootROM interprets execaddr of SPI/NOR XIP images as relative byte
offset from the from the beginning of the flash device. So if data image
offset and execute offset are not same then it is needed to adjust them
also in DDR RAM.

Fixes: f2c644e0b8bc ("tools: kwboot: Patch destination address to DDR area for SPI image")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index f624edc7798f..cb31d5b858ce 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2022,8 +2022,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 	case IBR_HDR_SPI_ID:
 		if (hdr->destaddr == cpu_to_le32(0xFFFFFFFF)) {
 			kwboot_printv("Patching destination and execution addresses from SPI/NOR XIP area to DDR area 0x00800000\n");
-			hdr->destaddr = cpu_to_le32(0x00800000);
-			hdr->execaddr = cpu_to_le32(0x00800000);
+			hdr->destaddr = cpu_to_le32(0x00800000 + le32_to_cpu(hdr->srcaddr));
+			hdr->execaddr = cpu_to_le32(0x00800000 + le32_to_cpu(hdr->execaddr));
 		}
 		break;
 	}
-- 
2.20.1

[PATCH RFC u-boot-mvebu 19/59] tools: kwboot: Show image type and error parsing reasons

[Pali Rohár]

Show image type and version during parsing of kwbimage.
And show reasons in error messages when parsing failed.
This can help to debug issues with invalid images.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 39 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index cb31d5b858ce..7c666486f31f 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1976,6 +1976,21 @@ _inject_baudrate_change_code(void *img, size_t *size, int for_data,
 	}
 }
 
+static const char *
+kwboot_img_type(uint8_t blockid)
+{
+	switch (blockid) {
+	case IBR_HDR_I2C_ID: return "I2C";
+	case IBR_HDR_SPI_ID: return "SPI";
+	case IBR_HDR_NAND_ID: return "NAND";
+	case IBR_HDR_SATA_ID: return "SATA";
+	case IBR_HDR_PEX_ID: return "PEX";
+	case IBR_HDR_UART_ID: return "UART";
+	case IBR_HDR_SDIO_ID: return "SDIO";
+	default: return "unknown";
+	}
+}
+
 static int
 kwboot_img_patch(void *img, size_t *size, int baudrate)
 {
@@ -1989,8 +2004,10 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 
 	hdr = img;
 
-	if (*size < sizeof(struct main_hdr_v1))
+	if (*size < sizeof(struct main_hdr_v1)) {
+		fprintf(stderr, "Invalid image header size\n");
 		goto err;
+	}
 
 	image_ver = kwbimage_version(img);
 	if (image_ver != 0 && image_ver != 1) {
@@ -2000,12 +2017,18 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 
 	hdrsz = kwbheader_size(hdr);
 
-	if (*size < hdrsz)
+	if (*size < hdrsz) {
+		fprintf(stderr, "Invalid image header size\n");
 		goto err;
+	}
+
+	kwboot_printv("Detected kwbimage v%d with %s boot signature\n", image_ver, kwboot_img_type(hdr->blockid));
 
 	csum = kwboot_hdr_csum8(hdr) - hdr->checksum;
-	if (csum != hdr->checksum)
+	if (csum != hdr->checksum) {
+		fprintf(stderr, "Image has invalid header checksum stored in image header\n");
 		goto err;
+	}
 
 	srcaddr = le32_to_cpu(hdr->srcaddr);
 
@@ -2028,9 +2051,15 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
 		break;
 	}
 
-	if (hdrsz > le32_to_cpu(hdr->srcaddr) ||
-	    *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
+	if (hdrsz > le32_to_cpu(hdr->srcaddr)) {
+		fprintf(stderr, "Image has invalid data offset stored in image header\n");
+		goto err;
+	}
+
+	if (*size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize)) {
+		fprintf(stderr, "Image has invalid data size stored in image header\n");
 		goto err;
+	}
 
 	for_each_opt_hdr_v1 (ohdr, hdr) {
 		if (!opt_hdr_v1_valid_size(ohdr, (const uint8_t *)hdr + hdrsz)) {
-- 
2.20.1

[PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition

[Pali Rohár]

Support for burning into the correct eMMC HW boot partition was broken and
removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
this functionality and bring it back again.

Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c       | 53 ++++++++++++++++++++++++++++++++++++++----
 doc/mvebu/cmd/bubt.txt | 21 ++++++++++++-----
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 2bcdf145f64a..4bad9a69527c 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
 #ifdef CONFIG_BLK
 	struct blk_desc *blk_desc;
 #endif
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+	u8		part;
+	u8		orig_part;
+#endif
+
 	mmc = find_mmc_device(mmc_dev_num);
 	if (!mmc) {
 		printf("No SD/MMC/eMMC card found\n");
@@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
 		return err;
 	}
 
+#ifdef CONFIG_BLK
+	blk_desc = mmc_get_blk_desc(mmc);
+	if (!blk_desc) {
+		printf("Error - failed to obtain block descriptor\n");
+		return -ENODEV;
+	}
+#endif
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+	orig_part = blk_desc->hwpart;
+#else
+	orig_part = mmc->block_dev.hwpart;
+#endif
+
+	part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+	if (part == 7)
+		part = 0;
+
+#ifdef CONFIG_BLK
+	err = blk_dselect_hwpart(blk_desc, part);
+#else
+	err = mmc_switch_part(mmc, part);
+#endif
+
+	if (err) {
+		printf("Error - MMC partition switch failed\n");
+		return err;
+	}
+#endif
+
 	/* SD reserves LBA-0 for MBR and boots from LBA-1,
 	 * MMC/eMMC boots from LBA-0
 	 */
@@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
 	if (image_size % mmc->write_bl_len)
 		blk_count += 1;
 
-	blk_desc = mmc_get_blk_desc(mmc);
-	if (!blk_desc) {
-		printf("Error - failed to obtain block descriptor\n");
-		return -ENODEV;
-	}
 	blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
 				 (void *)get_load_addr());
 #else
@@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
 						 start_lba, blk_count,
 						 (void *)get_load_addr());
 #endif /* CONFIG_BLK */
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+	err = blk_dselect_hwpart(blk_desc, orig_part);
+#else
+	err = mmc_switch_part(mmc, orig_part);
+#endif
+	if (err)
+		printf("Error - MMC failed to switch back to original partition\n");
+#endif
+
 	if (blk_written != blk_count) {
 		printf("Error - written %#lx blocks\n", blk_written);
 		return -ENOSPC;
diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
index 6051243f1165..1fe1f07dd187 100644
--- a/doc/mvebu/cmd/bubt.txt
+++ b/doc/mvebu/cmd/bubt.txt
@@ -14,8 +14,7 @@ Examples:
 
 Notes:
 - For the TFTP interface set serverip and ipaddr.
-- To burn image to SD/eMMC device, the target is defined
-  by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
+- To burn image to SD/eMMC device, the target is defined by HW partition.
 
 Bubt command details (burn image step by-step)
 ----------------------------------------------
@@ -40,10 +39,20 @@ Notes:
   Number 0 is used for user data partition and should not be utilized for storing
   boot images and U-Boot environment in RAW mode since it will break file system
   structures usually located here.
-  The default boot partition is BOOT0. It is selected by the following parameter:
-  CONFIG_SYS_MMC_ENV_PART=1
-  Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
-  Please never use partition number 0 here!
+
+  Currently configured boot partition can be printed by command:
+  # mmc partconf 0
+  (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
+
+  Change it to BOOT0:
+  # mmc partconf 0 0 1 1
+
+  Change it to BOOT1:
+  # mmc partconf 0 0 2 2
+
+  Change it to user data:
+  # mmc partconf 0 0 7 0
+
 - The partition number is ignored if the target device is SD card.
 - The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
   The block 0 on SD devices is left for MBR storage.
-- 
2.20.1

[PATCH RFC u-boot-mvebu 21/59] cmd: mvebu/bubt: Add support for writing image to SATA disk

[Pali Rohár]

All 32-bit Armada SoCs and also 64-bit Armada 3720 SoC can load and boot
firmware from SATA disk. This adds support for updating firmware binary for
these SoCs. On 32-bit Armada SoC is firmware stored at sector 1 and on
Armada 3720 is stored at MBR partition 0x4d or GPT partition with type GUID
6828311A-BA55-42A4-BCDE-A89BB5EDECAE (Marvell Armada 3700 Boot partition).

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/Kconfig      |  12 +++++
 cmd/mvebu/bubt.c       | 109 ++++++++++++++++++++++++++++++++++++++++-
 doc/mvebu/cmd/bubt.txt |   2 +-
 3 files changed, 121 insertions(+), 2 deletions(-)

diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig
index 9ec3aa983a51..8f30a0c22be3 100644
--- a/cmd/mvebu/Kconfig
+++ b/cmd/mvebu/Kconfig
@@ -5,6 +5,9 @@ config CMD_MVEBU_BUBT
 	bool "bubt"
 	select SHA256 if ARMADA_3700
 	select SHA512 if ARMADA_3700
+	select DOS_PARTITION if ARMADA_3700
+	select EFI_PARTITION if ARMADA_3700
+	select PARTITION_TYPE_GUID if ARMADA_3700
 	select MVEBU_EFUSE if ARMADA_38X || ARMADA_3700
 	help
 	  bubt - Burn a u-boot image to flash
@@ -44,6 +47,15 @@ config MVEBU_MMC_BOOT
 	  For details about bubt command please see the documentation
 	  in doc/mvebu/cmd/bubt.txt
 
+config MVEBU_SATA_BOOT
+	bool "SATA flash boot"
+	depends on SCSI
+	help
+	  Enable boot from SATA disk.
+	  Allow usage of SATA disk as a target for "bubt" command
+	  For details about bubt command please see the documentation
+	  in doc/mvebu/cmd/bubt.txt
+
 endchoice
 
 config MVEBU_UBOOT_DFLT_NAME
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 4bad9a69527c..1d51fde579b5 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -19,6 +19,7 @@
 #include <spi_flash.h>
 #include <spi.h>
 #include <nand.h>
+#include <scsi.h>
 #include <usb.h>
 #include <fs.h>
 #include <mmc.h>
@@ -333,6 +334,108 @@ static int is_mmc_active(void)
 }
 #endif /* CONFIG_DM_MMC */
 
+/********************************************************************
+ *     SATA services
+ ********************************************************************/
+#if defined(CONFIG_SCSI) && defined(CONFIG_BLK)
+static int sata_burn_image(size_t image_size)
+{
+#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_32BIT)
+	lbaint_t	start_lba;
+	lbaint_t	blk_count;
+	ulong		blk_written;
+	struct blk_desc *blk_desc;
+#ifdef CONFIG_ARMADA_3700
+	struct disk_partition info;
+	int		part;
+#endif
+
+	scsi_scan(false);
+
+	blk_desc = blk_get_devnum_by_uclass_id(UCLASS_SCSI, 0);
+	if (!blk_desc)
+		return -ENODEV;
+
+#ifdef CONFIG_ARMADA_3700
+	/*
+	 * 64-bit Armada 3700 BootROM loads SATA firmware from
+	 * GPT 'Marvell Armada 3700 Boot partition' or from
+	 * MBR 'M' (0x4d) partition.
+	 */
+	switch (blk_desc->part_type) {
+	case PART_TYPE_DOS:
+		for (part = 1; part <= 4; part++) {
+			info.sys_ind = 0;
+			if (part_get_info(blk_desc, part, &info))
+				continue;
+			if (info.sys_ind == 'M')
+				break;
+		}
+		if (part > 4) {
+			printf("Error - cannot find MBR 'M' (0x4d) partition on SATA disk\n");
+			return -ENODEV;
+		}
+		start_lba = info.start;
+		break;
+	case PART_TYPE_EFI:
+		for (part = 1; part <= 64; part++) {
+			info.type_guid[0] = 0;
+			if (part_get_info(blk_desc, part, &info))
+				continue;
+			/* Check for GPT type GUID of 'Marvell Armada 3700 Boot partition' */
+			if (strcmp(info.type_guid, "6828311A-BA55-42A4-BCDE-A89BB5EDECAE") == 0)
+				break;
+		}
+		if (part > 64) {
+			printf("Error - cannot find GPT 'Marvell Armada 3700 Boot partition' on SATA disk\n");
+			return -ENODEV;
+		}
+		start_lba = info.start;
+		break;
+	default:
+		printf("Error - no partitions on SATA disk\n");
+		return -ENODEV;
+	}
+#else
+	/* 32-bit Armada BootROM loads SATA firmware from the sector 1. */
+	start_lba = 1;
+#endif
+
+	blk_count = image_size / blk_desc->blksz;
+	if (image_size % blk_desc->blksz)
+		blk_count += 1;
+
+	blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
+				 (void *)get_load_addr());
+
+	if (blk_written != blk_count) {
+		printf("Error - written %#lx blocks\n", blk_written);
+		return -ENOSPC;
+	}
+
+	printf("Done!\n");
+	return 0;
+#else
+	return -ENODEV;
+#endif
+}
+
+static int is_sata_active(void)
+{
+	return 1;
+}
+#else /* CONFIG_SCSI */
+static int sata_burn_image(size_t image_size)
+{
+	return -ENODEV;
+}
+
+static int is_sata_active(void)
+{
+	return 0;
+}
+#endif /* CONFIG_SCSI */
+
 /********************************************************************
  *     SPI services
  ********************************************************************/
@@ -542,6 +645,7 @@ enum bubt_devices {
 	BUBT_DEV_NET = 0,
 	BUBT_DEV_USB,
 	BUBT_DEV_MMC,
+	BUBT_DEV_SATA,
 	BUBT_DEV_SPI,
 	BUBT_DEV_NAND,
 
@@ -552,6 +656,7 @@ struct bubt_dev bubt_devs[BUBT_MAX_DEV] = {
 	{"tftp", tftp_read_file, NULL, is_tftp_active},
 	{"usb",  usb_read_file,  NULL, is_usb_active},
 	{"mmc",  mmc_read_file,  mmc_burn_image, is_mmc_active},
+	{"sata",  NULL, sata_burn_image,  is_sata_active},
 	{"spi",  NULL, spi_burn_image,  is_spi_active},
 	{"nand", NULL, nand_burn_image, is_nand_active},
 };
@@ -1021,6 +1126,8 @@ struct bubt_dev *find_bubt_dev(char *dev_name)
 #define DEFAULT_BUBT_DST "nand"
 #elif defined(CONFIG_MVEBU_MMC_BOOT)
 #define DEFAULT_BUBT_DST "mmc"
+#elif defined(CONFIG_MVEBU_SATA_BOOT)
+#define DEFAULT_BUBT_DST "sata"
 #else
 #define DEFAULT_BUBT_DST "error"
 #endif
@@ -1098,7 +1205,7 @@ U_BOOT_CMD(
 	"Burn a u-boot image to flash",
 	"[file-name] [destination [source]]\n"
 	"\t-file-name     The image file name to burn. Default = " CONFIG_MVEBU_UBOOT_DFLT_NAME "\n"
-	"\t-destination   Flash to burn to [spi, nand, mmc]. Default = " DEFAULT_BUBT_DST "\n"
+	"\t-destination   Flash to burn to [spi, nand, mmc, sata]. Default = " DEFAULT_BUBT_DST "\n"
 	"\t-source        The source to load image from [tftp, usb, mmc]. Default = " DEFAULT_BUBT_SRC "\n"
 	"Examples:\n"
 	"\tbubt - Burn flash-image.bin from tftp to active boot device\n"
diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
index 1fe1f07dd187..515e4fb1b0e8 100644
--- a/doc/mvebu/cmd/bubt.txt
+++ b/doc/mvebu/cmd/bubt.txt
@@ -5,7 +5,7 @@ Bubt command is used to burn a new ATF image to flash device.
 The bubt command gets the following parameters: ATF file name, destination device and source device.
 bubt [file-name] [destination [source]]
 	- file-name		Image file name to burn. default = flash-image.bin
-	- destination		Flash to burn to [spi, nand, mmc]. default = active flash
+	- destination		Flash to burn to [spi, nand, mmc, sata]. default = active flash
 	- source		Source to load image from [tftp, usb]. default = tftp
 
 Examples:
-- 
2.20.1

[PATCH RFC u-boot-mvebu 22/59] cmd: mvebu/bubt: Add support for reading image from the SATA disk partition

[Pali Rohár]

This change allows to load boot image from the first SATA/SCSI device
partition and burn it to board boot location (e.g. SPI-NOR). This is
particularly when storage device is not handled by U-Boot as USB mass
storage (which is already supported by bubt) but as SATA/SCSI device.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c       | 39 +++++++++++++++++++++++++++++++++++++--
 doc/mvebu/cmd/bubt.txt |  2 +-
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 1d51fde579b5..df6b73c6a172 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -420,6 +420,36 @@ static int sata_burn_image(size_t image_size)
 #endif
 }
 
+static size_t sata_read_file(const char *file_name)
+{
+	loff_t act_read = 0;
+	struct udevice *dev;
+	int rc;
+
+	/* try to recognize storage devices immediately */
+	scsi_scan(false);
+
+	/* Try to recognize storage devices immediately */
+	blk_first_device(UCLASS_SCSI, &dev);
+	if (!dev) {
+		printf("Error: SATA device not found\n");
+		return 0;
+	}
+
+	/* Always load from scsi 0 */
+	if (fs_set_blk_dev("scsi", "0", FS_TYPE_ANY)) {
+		printf("Error: SATA 0 not found\n");
+		return 0;
+	}
+
+	/* Perfrom file read */
+	rc = fs_read(file_name, get_load_addr(), 0, 0, &act_read);
+	if (rc)
+		return 0;
+
+	return act_read;
+}
+
 static int is_sata_active(void)
 {
 	return 1;
@@ -430,6 +460,11 @@ static int sata_burn_image(size_t image_size)
 	return -ENODEV;
 }
 
+static size_t sata_read_file(const char *file_name)
+{
+	return 0;
+}
+
 static int is_sata_active(void)
 {
 	return 0;
@@ -656,7 +691,7 @@ struct bubt_dev bubt_devs[BUBT_MAX_DEV] = {
 	{"tftp", tftp_read_file, NULL, is_tftp_active},
 	{"usb",  usb_read_file,  NULL, is_usb_active},
 	{"mmc",  mmc_read_file,  mmc_burn_image, is_mmc_active},
-	{"sata",  NULL, sata_burn_image,  is_sata_active},
+	{"sata", sata_read_file, sata_burn_image,  is_sata_active},
 	{"spi",  NULL, spi_burn_image,  is_spi_active},
 	{"nand", NULL, nand_burn_image, is_nand_active},
 };
@@ -1206,7 +1241,7 @@ U_BOOT_CMD(
 	"[file-name] [destination [source]]\n"
 	"\t-file-name     The image file name to burn. Default = " CONFIG_MVEBU_UBOOT_DFLT_NAME "\n"
 	"\t-destination   Flash to burn to [spi, nand, mmc, sata]. Default = " DEFAULT_BUBT_DST "\n"
-	"\t-source        The source to load image from [tftp, usb, mmc]. Default = " DEFAULT_BUBT_SRC "\n"
+	"\t-source        The source to load image from [tftp, usb, mmc, sata]. Default = " DEFAULT_BUBT_SRC "\n"
 	"Examples:\n"
 	"\tbubt - Burn flash-image.bin from tftp to active boot device\n"
 	"\tbubt flash-image-new.bin nand - Burn flash-image-new.bin from tftp to NAND flash\n"
diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
index 515e4fb1b0e8..52bd3e66c51e 100644
--- a/doc/mvebu/cmd/bubt.txt
+++ b/doc/mvebu/cmd/bubt.txt
@@ -6,7 +6,7 @@ The bubt command gets the following parameters: ATF file name, destination devic
 bubt [file-name] [destination [source]]
 	- file-name		Image file name to burn. default = flash-image.bin
 	- destination		Flash to burn to [spi, nand, mmc, sata]. default = active flash
-	- source		Source to load image from [tftp, usb]. default = tftp
+	- source		Source to load image from [tftp, usb, mmc, sata]. default = tftp
 
 Examples:
 	bubt				- Burn flash-image.bin from tftp to active flash
-- 
2.20.1

[PATCH RFC u-boot-mvebu 23/59] cmd: mvebu/bubt: Rename variable image_size to hdr_size

[Pali Rohár]

Variable image_size contains size of the header, not size of the whole
image. Rename this variable to reflect content.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index df6b73c6a172..72ed87b89ec3 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -905,12 +905,12 @@ static int check_image_header(void)
 	u32 offset, size;
 	const struct a38x_main_hdr_v1 *hdr =
 		(struct a38x_main_hdr_v1 *)get_load_addr();
-	const size_t image_size = a38x_header_size(hdr);
+	const size_t hdr_size = a38x_header_size(hdr);
 
-	if (!image_size)
+	if (!hdr_size)
 		return -ENOEXEC;
 
-	checksum = image_checksum8(hdr, image_size);
+	checksum = image_checksum8(hdr, hdr_size);
 	checksum -= hdr->checksum;
 	if (checksum != hdr->checksum) {
 		printf("Error: Bad A38x image header checksum. 0x%x != 0x%x\n",
@@ -944,7 +944,7 @@ static int check_image_header(void)
 #if defined(CONFIG_ARMADA_38X)
 static int a38x_image_is_secure(const struct a38x_main_hdr_v1 *hdr)
 {
-	u32 image_size = a38x_header_size(hdr);
+	const size_t hdr_size = a38x_header_size(hdr);
 	struct a38x_opt_hdr_v1 *ohdr;
 	u32 ohdr_size;
 
@@ -965,7 +965,7 @@ static int a38x_image_is_secure(const struct a38x_main_hdr_v1 *hdr)
 			break;
 
 		ohdr = (struct a38x_opt_hdr_v1 *)((u8 *)ohdr + ohdr_size);
-		if ((u8 *)ohdr >= (u8 *)hdr + image_size)
+		if ((u8 *)ohdr >= (u8 *)hdr + hdr_size)
 			break;
 	} while (1);
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 24/59] cmd: mvebu/bubt: Mark all local symbols as static

[Pali Rohár]

There is no need to export these local functions and structures.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 72ed87b89ec3..820d342ae100 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -687,7 +687,7 @@ enum bubt_devices {
 	BUBT_MAX_DEV
 };
 
-struct bubt_dev bubt_devs[BUBT_MAX_DEV] = {
+static struct bubt_dev bubt_devs[BUBT_MAX_DEV] = {
 	{"tftp", tftp_read_file, NULL, is_tftp_active},
 	{"usb",  usb_read_file,  NULL, is_usb_active},
 	{"mmc",  mmc_read_file,  mmc_burn_image, is_mmc_active},
@@ -707,7 +707,7 @@ static int bubt_write_file(struct bubt_dev *dst, size_t image_size)
 }
 
 #if defined(CONFIG_ARMADA_8K)
-u32 do_checksum32(u32 *start, int32_t len)
+static u32 do_checksum32(u32 *start, int32_t len)
 {
 	u32 sum = 0;
 	u32 *startp = start;
@@ -1140,7 +1140,7 @@ static int bubt_is_dev_active(struct bubt_dev *dev)
 	return 1;
 }
 
-struct bubt_dev *find_bubt_dev(char *dev_name)
+static struct bubt_dev *find_bubt_dev(char *dev_name)
 {
 	int dev;
 
@@ -1168,7 +1168,7 @@ struct bubt_dev *find_bubt_dev(char *dev_name)
 #endif
 #endif /* DEFAULT_BUBT_DST */
 
-int do_bubt_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+static int do_bubt_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
 	struct bubt_dev *src, *dst;
 	size_t image_size;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 25/59] cmd: mvebu/bubt: Do not modify image in A8K check_image_header()

[Pali Rohár]

Change checksum verification code so it does require to modify image.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 820d342ae100..1b08ca9298c2 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -739,18 +739,14 @@ static int check_image_header(void)
 		return -ENOEXEC;
 	}
 
-	/* The checksum value is discarded from checksum calculation */
-	hdr->prolog_checksum = 0;
-
 	checksum = do_checksum32((u32 *)hdr, header_len);
+	checksum -= hdr->prolog_checksum;
 	if (checksum != checksum_ref) {
 		printf("Error: Bad Image checksum. 0x%x != 0x%x\n",
 		       checksum, checksum_ref);
 		return -ENOEXEC;
 	}
 
-	/* Restore the checksum before writing */
-	hdr->prolog_checksum = checksum_ref;
 	printf("Image checksum...OK!\n");
 
 	return 0;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 26/59] cmd: mvebu/bubt: Check also A8K boot image checksum

[Pali Rohár]

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 1b08ca9298c2..74ea037dda98 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -725,9 +725,8 @@ static int check_image_header(void)
 {
 	struct mvebu_image_header *hdr =
 			(struct mvebu_image_header *)get_load_addr();
-	u32 header_len = hdr->prolog_size;
 	u32 checksum;
-	u32 checksum_ref = hdr->prolog_checksum;
+	u32 checksum_ref;
 
 	/*
 	 * For now compare checksum, and magic. Later we can
@@ -739,8 +738,17 @@ static int check_image_header(void)
 		return -ENOEXEC;
 	}
 
-	checksum = do_checksum32((u32 *)hdr, header_len);
+	checksum_ref = hdr->prolog_checksum;
+	checksum = do_checksum32((u32 *)hdr, hdr->prolog_size);
 	checksum -= hdr->prolog_checksum;
+	if (checksum != checksum_ref) {
+		printf("Error: Bad Prolog checksum. 0x%x != 0x%x\n",
+		       checksum, checksum_ref);
+		return -ENOEXEC;
+	}
+
+	checksum_ref = hdr->boot_image_checksum;
+	checksum = do_checksum32((u32 *)((u8 *)hdr + hdr->prolog_size), hdr->boot_image_size);
 	if (checksum != checksum_ref) {
 		printf("Error: Bad Image checksum. 0x%x != 0x%x\n",
 		       checksum, checksum_ref);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 27/59] cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs

[Pali Rohár]

32-bit Armada SoCs uses u-boot binary packed in kwbimage format. Name of
the image is in CONFIG_BUILD_TARGET option. So use it as a default option
in Kconfig.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig
index 8f30a0c22be3..9f6ad2d1dd16 100644
--- a/cmd/mvebu/Kconfig
+++ b/cmd/mvebu/Kconfig
@@ -60,6 +60,7 @@ endchoice
 
 config MVEBU_UBOOT_DFLT_NAME
 	string "Default image name for bubt command"
+	default BUILD_TARGET if ARMADA_32BIT && BUILD_TARGET != ""
 	default "flash-image.bin"
 	help
 	  This option should contain a default file name to be used with
-- 
2.20.1

[PATCH RFC u-boot-mvebu 28/59] cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option

[Pali Rohár]

For 32-bit Armada boards which use SPL we can determinate boot device from
existing MVEBU_SPL_BOOT_DEVICE_* option. For all other boards (e.g. 64-bit
Armada) default option still needs to be set manually.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig
index 9f6ad2d1dd16..029f722096b1 100644
--- a/cmd/mvebu/Kconfig
+++ b/cmd/mvebu/Kconfig
@@ -18,6 +18,10 @@ if CMD_MVEBU_BUBT
 
 choice
 	prompt "Flash for image"
+	default MVEBU_SPI_BOOT if MVEBU_SPL_BOOT_DEVICE_SPI
+	default MVEBU_NAND_BOOT if MVEBU_SPL_BOOT_DEVICE_NAND
+	default MVEBU_MMC_BOOT if MVEBU_SPL_BOOT_DEVICE_MMC
+	default MVEBU_SATA_BOOT if MVEBU_SPL_BOOT_DEVICE_SATA
 	default MVEBU_SPI_BOOT
 
 config MVEBU_NAND_BOOT
-- 
2.20.1

[PATCH RFC u-boot-mvebu 29/59] cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and 'fuse_read_u64' defined but not used

[Pali Rohár]

'secure_mode' and 'fuse_read_u64' are used only on A38x and A37xx.

Fixes: f7b0bbca2b62 ("cmd: mvebu/bubt: Check for A38x/A37xx OTP secure bits and secure boot")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/bubt.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 74ea037dda98..49797b23144b 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -984,7 +984,7 @@ static int check_image_header(void)
 }
 #endif
 
-#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_32BIT)
+#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_38X)
 static u64 fuse_read_u64(u32 bank)
 {
 	u32 val[2];
@@ -1013,7 +1013,10 @@ static inline u8 maj3(u8 val)
 static int bubt_check_boot_mode(const struct bubt_dev *dst)
 {
 #if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_32BIT)
-	int mode, secure_mode;
+	int mode;
+#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_38X)
+	int secure_mode;
+#endif
 #if defined(CONFIG_ARMADA_3700)
 	const struct tim_boot_flash_sign *boot_modes = tim_boot_flash_signs;
 	const struct common_tim_data *hdr =
-- 
2.20.1

[PATCH RFC u-boot-mvebu 30/59] cmd: mvebu/bubt: Enable command by default

[Pali Rohár]

This makes updating of u-boot/firmware on Marvell boards easier.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 cmd/mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig
index 029f722096b1..e83a98294912 100644
--- a/cmd/mvebu/Kconfig
+++ b/cmd/mvebu/Kconfig
@@ -3,6 +3,7 @@ depends on ARCH_MVEBU
 
 config CMD_MVEBU_BUBT
 	bool "bubt"
+	default y
 	select SHA256 if ARMADA_3700
 	select SHA512 if ARMADA_3700
 	select DOS_PARTITION if ARMADA_3700
-- 
2.20.1

[PATCH RFC u-boot-mvebu 31/59] tools: kwbimage: Fix dumping register set / DATA commands

[Pali Rohár]

Upper-bound for iterating for-loop over register set entries is incorrect.
Fix it byt calculating correct number of entries.

And fix also dumping the last entry DATA_DELAY, which is the last and not
first (zero).

Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p -1' option")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 67b45503e466..1719b0415da1 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2148,6 +2148,7 @@ static int kwbimage_generate_config(void *ptr, struct image_tool_params *params)
 	struct ext_hdr_v0 *ehdr0;
 	struct bin_hdr_v0 *bhdr0;
 	struct opt_hdr_v1 *ohdr;
+	int regset_count;
 	int params_count;
 	unsigned offset;
 	int is_v0_ext;
@@ -2232,18 +2233,20 @@ static int kwbimage_generate_config(void *ptr, struct image_tool_params *params)
 			cur_idx++;
 		} else if (ohdr->headertype == OPT_HDR_V1_REGISTER_TYPE) {
 			regset_hdr = (struct register_set_hdr_v1 *)ohdr;
-			for (i = 0;
-			     i < opt_hdr_v1_size(ohdr) - sizeof(struct opt_hdr_v1) -
-				 sizeof(regset_hdr->data[0].last_entry);
-			     i++)
+			if (opt_hdr_v1_size(ohdr) > sizeof(*ohdr))
+				regset_count = (opt_hdr_v1_size(ohdr) - sizeof(*ohdr)) /
+					       sizeof(regset_hdr->data[0].entry);
+			else
+				regset_count = 0;
+			for (i = 0; i < regset_count; i++)
 				fprintf(f, "DATA 0x%08x 0x%08x\n",
 					le32_to_cpu(regset_hdr->data[i].entry.address),
 					le32_to_cpu(regset_hdr->data[i].entry.value));
-			if (opt_hdr_v1_size(ohdr) - sizeof(struct opt_hdr_v1) >=
-			    sizeof(regset_hdr->data[0].last_entry)) {
-				if (regset_hdr->data[0].last_entry.delay)
+			if (regset_count > 0) {
+				if (regset_hdr->data[regset_count-1].last_entry.delay !=
+				    REGISTER_SET_HDR_OPT_DELAY_SDRAM_SETUP)
 					fprintf(f, "DATA_DELAY %u\n",
-						(unsigned)regset_hdr->data[0].last_entry.delay);
+						(unsigned)regset_hdr->data[regset_count-1].last_entry.delay);
 				else
 					fprintf(f, "DATA_DELAY SDRAM_SETUP\n");
 			}
-- 
2.20.1

[PATCH RFC u-boot-mvebu 32/59] tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE

[Pali Rohár]

Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p -1' option")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 1719b0415da1..a6f6f1578c79 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2182,7 +2182,7 @@ static int kwbimage_generate_config(void *ptr, struct image_tool_params *params)
 		fprintf(f, "NAND_ECC_MODE %s\n", image_nand_ecc_mode_name(mhdr0->nandeccmode));
 
 	if (mhdr->blockid == IBR_HDR_NAND_ID)
-		fprintf(f, "NAND_PAGE_SIZE 0x%x\n", (unsigned)mhdr->nandpagesize);
+		fprintf(f, "NAND_PAGE_SIZE 0x%x\n", (unsigned)le16_to_cpu(mhdr->nandpagesize));
 
 	if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID)
 		fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 33/59] tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION

[Pali Rohár]

Value 0x0 for NAND_BADBLK_LOCATION/nandbadblklocation means that BBI is on
the first or second page and value 0x1 means that BBI is on the last page.
This indicates also NAND Flash Technology, value 0x0 is SLC NAND and value
0x1 is MLC NAND.

Therefore we need to dump NAND_BADBLK_LOCATION also when it is zero.

Note that in v0 images, nandbadblklocation field overlaps with ddrinitdelay
field in one union. ddrinitdelay is used in Kirkwood and nandbadblklocation
is used in Dove. For Dove images is_v0_ext should be set, so use it to
distinguish if nandbadblklocation is available or not. In v1 images there
is always nandbadblklocation field.

Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p -1' option")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a6f6f1578c79..4e9ba5ddfae2 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2187,7 +2187,7 @@ static int kwbimage_generate_config(void *ptr, struct image_tool_params *params)
 	if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID)
 		fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize);
 
-	if (mhdr->blockid == IBR_HDR_NAND_ID && (mhdr->nandbadblklocation != 0 || is_v0_ext))
+	if (mhdr->blockid == IBR_HDR_NAND_ID && (version != 0 || is_v0_ext))
 		fprintf(f, "NAND_BADBLK_LOCATION 0x%x\n", (unsigned)mhdr->nandbadblklocation);
 
 	if (version == 0 && mhdr->blockid == IBR_HDR_SATA_ID)
-- 
2.20.1

[PATCH RFC u-boot-mvebu 34/59] tools: kwbimage: Fix dumping NAND_BLKSZ

[Pali Rohár]

kwbimage nandblocksize field is in 64 kB unit, but NAND_BLKSZ command
expects it in bytes. So do required unit conversion.

Also zero value in nandblocksize field has special meaning. When this field
is set to zero, the default block size is used. This default size is
defined by the NAND flash page size (16 KB for a 512B page or small page
NAND and 64 KB for a large page NAND flash).

Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p -1' option")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 4e9ba5ddfae2..b6deb978f611 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2184,8 +2184,14 @@ static int kwbimage_generate_config(void *ptr, struct image_tool_params *params)
 	if (mhdr->blockid == IBR_HDR_NAND_ID)
 		fprintf(f, "NAND_PAGE_SIZE 0x%x\n", (unsigned)le16_to_cpu(mhdr->nandpagesize));
 
-	if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID)
-		fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize);
+	if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID) {
+		if (mhdr->nandblocksize != 0) /* block size explicitly set in 64 kB unit */
+			fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize * 64*1024);
+		else if (le16_to_cpu(mhdr->nandpagesize) > 512)
+			fprintf(f, "NAND_BLKSZ 0x10000\n"); /* large page NAND flash = 64 kB block size */
+		else
+			fprintf(f, "NAND_BLKSZ 0x4000\n"); /* small page NAND flash = 16 kB block size */
+	}
 
 	if (mhdr->blockid == IBR_HDR_NAND_ID && (version != 0 || is_v0_ext))
 		fprintf(f, "NAND_BADBLK_LOCATION 0x%x\n", (unsigned)mhdr->nandbadblklocation);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 35/59] tools: kwbimage: Fix generating of kwbimage v0 header checksum

[Pali Rohár]

Checksum for v0 image must be generated after filling all fields in the
main header. Otherwise it would be invalid.

Exactly same problem for v1 images was already fixed in the past in commit
9203c73895ab ("tools: kwbimage: Fix checksum calculation for v1 images").

Fixes: 5c61710c9880 ("tools: kwbimage: Properly set srcaddr in kwbimage v0")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index b6deb978f611..1128c934dda9 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1009,8 +1009,6 @@ static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
 	e = image_find_option(IMAGE_CFG_NAND_BADBLK_LOCATION);
 	if (e)
 		main_hdr->nandbadblklocation = e->nandbadblklocation;
-	main_hdr->checksum = image_checksum8(image,
-					     sizeof(struct main_hdr_v0));
 
 	/*
 	 * For SATA srcaddr is specified in number of sectors.
@@ -1049,6 +1047,9 @@ static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
 						    sizeof(struct ext_hdr_v0));
 	}
 
+	main_hdr->checksum = image_checksum8(image,
+					     sizeof(struct main_hdr_v0));
+
 	*imagesz = headersz;
 	return image;
 }
-- 
2.20.1

[PATCH RFC u-boot-mvebu 36/59] tools: kwbimage: Fix endianity when printing kwbimage header

[Pali Rohár]

All fields in kwbimage header are in little endian format.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 1128c934dda9..97be3bed79cb 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1928,9 +1928,9 @@ static void kwbimage_print_header(const void *ptr)
 	}
 
 	printf("Data Size:    ");
-	genimg_print_size(mhdr->blocksize - sizeof(uint32_t));
-	printf("Load Address: %08x\n", mhdr->destaddr);
-	printf("Entry Point:  %08x\n", mhdr->execaddr);
+	genimg_print_size(le32_to_cpu(mhdr->blocksize) - sizeof(uint32_t));
+	printf("Load Address: %08x\n", le32_to_cpu(mhdr->destaddr));
+	printf("Entry Point:  %08x\n", le32_to_cpu(mhdr->execaddr));
 }
 
 static int kwbimage_check_image_types(uint8_t type)
-- 
2.20.1

[PATCH RFC u-boot-mvebu 37/59] tools: kwbimage: Reject mkimage -F option

[Pali Rohár]

mkimage -F option (re-sign existing FIT image) signaled by fflag is not
supported by kwbimage. So mark its usage as invalid parameter.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 97be3bed79cb..0c3b40d075e9 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2440,7 +2440,7 @@ static int kwbimage_check_params(struct image_tool_params *params)
 	}
 
 	return (params->dflag && (params->fflag || params->lflag)) ||
-		(params->fflag && (params->dflag || params->lflag)) ||
+		(params->fflag) ||
 		(params->lflag && (params->dflag || params->fflag)) ||
 		(params->xflag);
 }
-- 
2.20.1

[PATCH RFC u-boot-mvebu 38/59] tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images

[Pali Rohár]

In Dove functional specification, which use kwbimage v0, is also defined
nand block size field. So dump NAND_BLKSZ also for v0 images.

In Kirkwood functional specification, which also use kwbimage v0, this
field is not defined. So when it is zero and Kirkwood is detected, do not
dump it.

Fixes: f76ae2571fe0 ("tools: kwbimage: Add support for dumping extended and binary v0 headers")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 0c3b40d075e9..eb99ac944d24 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2185,7 +2185,7 @@ static int kwbimage_generate_config(void *ptr, struct image_tool_params *params)
 	if (mhdr->blockid == IBR_HDR_NAND_ID)
 		fprintf(f, "NAND_PAGE_SIZE 0x%x\n", (unsigned)le16_to_cpu(mhdr->nandpagesize));
 
-	if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID) {
+	if (mhdr->blockid == IBR_HDR_NAND_ID && (version != 0 || is_v0_ext || mhdr->nandblocksize != 0)) {
 		if (mhdr->nandblocksize != 0) /* block size explicitly set in 64 kB unit */
 			fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize * 64*1024);
 		else if (le16_to_cpu(mhdr->nandpagesize) > 512)
-- 
2.20.1

[PATCH RFC u-boot-mvebu 39/59] tools: kwbimage: Print binary image offset as size

[Pali Rohár]

Use for it pretty print function: genimg_print_size(). This makes it more
human readable, like other offset and sizes printed by this tool.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index eb99ac944d24..a5de9855aa56 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1914,9 +1914,9 @@ static void kwbimage_print_header(const void *ptr)
 			printf("BIN Img Size: ");
 			genimg_print_size(opt_hdr_v1_size(ohdr) - 12 -
 					  4 * ohdr->data[0]);
-			printf("BIN Img Offs: %08x\n",
-				(unsigned)((uint8_t *)ohdr - (uint8_t *)mhdr) +
-				8 + 4 * ohdr->data[0]);
+			printf("BIN Img Offs: ");
+			genimg_print_size(((uint8_t *)ohdr - (uint8_t *)mhdr) +
+					  8 + 4 * ohdr->data[0]);
 		}
 	}
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 40/59] tools: kwbimage: Print image data offset when printing kwbimage header

[Pali Rohár]

For all images except SATA is data offset in bytes. For SATA it is in LBA
format (number of sectors). This is how Marvell BootROM interprets it.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a5de9855aa56..5f62ed159c4b 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1929,6 +1929,12 @@ static void kwbimage_print_header(const void *ptr)
 
 	printf("Data Size:    ");
 	genimg_print_size(le32_to_cpu(mhdr->blocksize) - sizeof(uint32_t));
+	printf("Data Offset:  ");
+	if (mhdr->blockid == IBR_HDR_SATA_ID)
+		printf("%u Sector%s (LBA)\n", le32_to_cpu(mhdr->srcaddr),
+		       le32_to_cpu(mhdr->srcaddr) != 1 ? "s" : "");
+	else
+		genimg_print_size(le32_to_cpu(mhdr->srcaddr));
 	printf("Load Address: %08x\n", le32_to_cpu(mhdr->destaddr));
 	printf("Entry Point:  %08x\n", le32_to_cpu(mhdr->execaddr));
 }
-- 
2.20.1

[PATCH RFC u-boot-mvebu 41/59] tools: kwbimage: Simplify add_secure_header_v1()

[Pali Rohár]

To make add_secure_header_v1() function more readable, call it directly
with arguments: header pointer with header size and data image pointer with
data image size. No functional change.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 5f62ed159c4b..857af6a438a4 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1322,16 +1322,14 @@ static int kwb_sign_csk_with_kak(struct image_tool_params *params,
 	return 0;
 }
 
-static int add_secure_header_v1(struct image_tool_params *params, uint8_t *ptr,
-				int payloadsz, size_t headersz, uint8_t *image,
+static int add_secure_header_v1(struct image_tool_params *params, uint8_t *image_ptr,
+				size_t image_size, uint8_t *header_ptr, size_t headersz,
 				struct secure_hdr_v1 *secure_hdr)
 {
 	struct image_cfg_element *e_jtagdelay;
 	struct image_cfg_element *e_boxid;
 	struct image_cfg_element *e_flashid;
 	RSA *csk = NULL;
-	unsigned char *image_ptr;
-	size_t image_size;
 	struct sig_v1 tmp_sig;
 	bool specialized_img = image_get_spezialized_img();
 
@@ -1357,14 +1355,11 @@ static int add_secure_header_v1(struct image_tool_params *params, uint8_t *ptr,
 	if (kwb_sign_csk_with_kak(params, secure_hdr, csk))
 		return 1;
 
-	image_ptr = ptr + headersz;
-	image_size = payloadsz - headersz;
-
 	if (kwb_sign_and_verify(csk, image_ptr, image_size,
 				&secure_hdr->imgsig, "image") < 0)
 		return 1;
 
-	if (kwb_sign_and_verify(csk, image, headersz, &tmp_sig, "header") < 0)
+	if (kwb_sign_and_verify(csk, header_ptr, headersz, &tmp_sig, "header") < 0)
 		return 1;
 
 	secure_hdr->hdrsig = tmp_sig;
@@ -1533,8 +1528,8 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
 					      &datai, delay);
 	}
 
-	if (secure_hdr && add_secure_header_v1(params, ptr, payloadsz + headersz,
-					       headersz, image, secure_hdr))
+	if (secure_hdr && add_secure_header_v1(params, ptr + headersz, payloadsz,
+					       image, headersz, secure_hdr))
 		return NULL;
 
 	*imagesz = headersz;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 42/59] tools: kwbimage: Rename imagesz to dataoff

[Pali Rohár]

Variable imagesz in functions image_create_v0(), image_create_v1() and
kwbimage_set_header() stores offset to data from the beginning of the main
header. So it is not image size.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 857af6a438a4..b32f845b7e2d 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -962,7 +962,7 @@ static size_t image_headersz_v0(int *hasext)
 	return image_headersz_align(headersz, image_get_bootfrom());
 }
 
-static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
+static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
 			     int payloadsz)
 {
 	struct image_cfg_element *e;
@@ -1050,7 +1050,7 @@ static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
 	main_hdr->checksum = image_checksum8(image,
 					     sizeof(struct main_hdr_v0));
 
-	*imagesz = headersz;
+	*dataoff = headersz;
 	return image;
 }
 
@@ -1385,7 +1385,7 @@ static void finish_register_set_header_v1(uint8_t **cur, uint8_t **next_ext,
 	*datai = 0;
 }
 
-static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
+static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 			     uint8_t *ptr, int payloadsz)
 {
 	struct image_cfg_element *e;
@@ -1532,7 +1532,7 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
 					       image, headersz, secure_hdr))
 		return NULL;
 
-	*imagesz = headersz;
+	*dataoff = headersz;
 
 	/* Fill the real header size without padding into the main header */
 	headersz = sizeof(*main_hdr);
@@ -1811,7 +1811,7 @@ static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
 	FILE *fcfg;
 	void *image = NULL;
 	int version;
-	size_t headersz = 0;
+	size_t dataoff = 0;
 	size_t datasz;
 	uint32_t checksum;
 	struct stat s;
@@ -1862,11 +1862,11 @@ static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
 		 */
 	case -1:
 	case 0:
-		image = image_create_v0(&headersz, params, datasz + 4);
+		image = image_create_v0(&dataoff, params, datasz + 4);
 		break;
 
 	case 1:
-		image = image_create_v1(&headersz, params, ptr, datasz + 4);
+		image = image_create_v1(&dataoff, params, ptr, datasz + 4);
 		break;
 
 	default:
@@ -1884,12 +1884,12 @@ static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
 	free(image_cfg);
 
 	/* Build and add image data checksum */
-	checksum = cpu_to_le32(image_checksum32((uint8_t *)ptr + headersz,
+	checksum = cpu_to_le32(image_checksum32((uint8_t *)ptr + dataoff,
 						datasz));
-	memcpy((uint8_t *)ptr + headersz + datasz, &checksum, sizeof(uint32_t));
+	memcpy((uint8_t *)ptr + dataoff + datasz, &checksum, sizeof(uint32_t));
 
 	/* Finally copy the header into the image area */
-	memcpy(ptr, image, headersz);
+	memcpy(ptr, image, dataoff);
 
 	free(image);
 }
-- 
2.20.1

[PATCH RFC u-boot-mvebu 43/59] tools: kwbimage: Fix generating secure boot data image signature

[Pali Rohár]

Secure boot data image signature is calculated from the data image without
trailing 4-bit checksum. Commit 37cb9c15d70d ("tools: kwbimage: Simplify
aligning and calculating checksum") unintentionally broke this calculation
when it increased payloadsz variable by 4 bytes which was propagated also
into the add_secure_header_v1() function. Fix this issue by decreasing size
of buffer by 4 bytes from which is calculated secure boot data image
signature.

Fixes: 37cb9c15d70d ("tools: kwbimage: Simplify aligning and calculating checksum")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index b32f845b7e2d..a8a59c154b9c 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1355,7 +1355,7 @@ static int add_secure_header_v1(struct image_tool_params *params, uint8_t *image
 	if (kwb_sign_csk_with_kak(params, secure_hdr, csk))
 		return 1;
 
-	if (kwb_sign_and_verify(csk, image_ptr, image_size,
+	if (kwb_sign_and_verify(csk, image_ptr, image_size - 4,
 				&secure_hdr->imgsig, "image") < 0)
 		return 1;
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 44/59] tools: kwbimage: Fix invalid secure boot header signature

[Pali Rohár]

Secure boot header signature is calculated from the image header with
zeroed header checksum. Calculation is done in add_secure_header_v1()
function. So after calling this function no header member except
main_hdr->checksum can be modified. Commit 2b0980c24027 ("tools: kwbimage:
Fill the real header size into the main header") broke this requirement as
final header size started to be filled into main_hdr->headersz_* members
after the add_secure_header_v1() call.

Fix this issue by following steps:
- Split header size and image data offset into two variables (headersz and
  *dataoff).
- Change image_headersz_v0() and add_binary_header_v1() functions to return
  real (unaligned) header size instead of image data offset.
- On every place use correct variable (headersz or *dataoff)

After these steps variable headersz is correctly filled into the
main_hdr->headersz_* members and so overwriting them in the end of the
image_create_v1() function is not needed anymore. Remove those overwriting
which effectively reverts changes in problematic commit without affecting
value in main_hdr->headersz_* members and makes secure boot header
signature valid again.

Fixes: 2b0980c24027 ("tools: kwbimage: Fill the real header size into the main header")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 41 ++++++++++++++---------------------------
 1 file changed, 14 insertions(+), 27 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a8a59c154b9c..da539541742d 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -959,7 +959,7 @@ static size_t image_headersz_v0(int *hasext)
 			*hasext = 1;
 	}
 
-	return image_headersz_align(headersz, image_get_bootfrom());
+	return headersz;
 }
 
 static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
@@ -972,10 +972,11 @@ static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
 	int has_ext = 0;
 
 	/*
-	 * Calculate the size of the header and the size of the
+	 * Calculate the size of the header and the offset of the
 	 * payload
 	 */
 	headersz = image_headersz_v0(&has_ext);
+	*dataoff = image_headersz_align(headersz, image_get_bootfrom());
 
 	image = malloc(headersz);
 	if (!image) {
@@ -990,7 +991,7 @@ static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
 	/* Fill in the main header */
 	main_hdr->blocksize =
 		cpu_to_le32(payloadsz);
-	main_hdr->srcaddr   = cpu_to_le32(headersz);
+	main_hdr->srcaddr   = cpu_to_le32(*dataoff);
 	main_hdr->ext       = has_ext;
 	main_hdr->version   = 0;
 	main_hdr->destaddr  = cpu_to_le32(params->addr);
@@ -1013,10 +1014,9 @@ static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
 	/*
 	 * For SATA srcaddr is specified in number of sectors.
 	 * This expects the sector size to be 512 bytes.
-	 * Header size is already aligned.
 	 */
 	if (main_hdr->blockid == IBR_HDR_SATA_ID)
-		main_hdr->srcaddr = cpu_to_le32(headersz / 512);
+		main_hdr->srcaddr = cpu_to_le32(le32_to_cpu(main_hdr->srcaddr) / 512);
 
 	/* For PCIe srcaddr is not used and must be set to 0xFFFFFFFF. */
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
@@ -1050,7 +1050,6 @@ static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
 	main_hdr->checksum = image_checksum8(image,
 					     sizeof(struct main_hdr_v0));
 
-	*dataoff = headersz;
 	return image;
 }
 
@@ -1064,10 +1063,6 @@ static size_t image_headersz_v1(int *hasext)
 	int cfgi;
 	int ret;
 
-	/*
-	 * Calculate the size of the header and the size of the
-	 * payload
-	 */
 	headersz = sizeof(struct main_hdr_v1);
 
 	if (image_get_csk_index() >= 0) {
@@ -1163,7 +1158,7 @@ static size_t image_headersz_v1(int *hasext)
 	if (count > 0)
 		headersz += sizeof(struct register_set_hdr_v1) + 8 * count + 4;
 
-	return image_headersz_align(headersz, image_get_bootfrom());
+	return headersz;
 }
 
 static int add_binary_header_v1(uint8_t **cur, uint8_t **next_ext,
@@ -1390,7 +1385,6 @@ static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 {
 	struct image_cfg_element *e;
 	struct main_hdr_v1 *main_hdr;
-	struct opt_hdr_v1 *ohdr;
 	struct register_set_hdr_v1 *register_set_hdr;
 	struct secure_hdr_v1 *secure_hdr = NULL;
 	size_t headersz;
@@ -1401,12 +1395,13 @@ static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 	uint8_t delay;
 
 	/*
-	 * Calculate the size of the header and the size of the
+	 * Calculate the size of the header and the offset of the
 	 * payload
 	 */
 	headersz = image_headersz_v1(&hasext);
 	if (headersz == 0)
 		return NULL;
+	*dataoff = image_headersz_align(headersz, image_get_bootfrom());
 
 	image = malloc(headersz);
 	if (!image) {
@@ -1428,7 +1423,7 @@ static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 	main_hdr->headersz_msb = (headersz & 0xFFFF0000) >> 16;
 	main_hdr->destaddr     = cpu_to_le32(params->addr);
 	main_hdr->execaddr     = cpu_to_le32(params->ep);
-	main_hdr->srcaddr      = cpu_to_le32(headersz);
+	main_hdr->srcaddr      = cpu_to_le32(*dataoff);
 	main_hdr->ext          = hasext;
 	main_hdr->version      = 1;
 	main_hdr->blockid      = image_get_bootfrom();
@@ -1458,10 +1453,9 @@ static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 	/*
 	 * For SATA srcaddr is specified in number of sectors.
 	 * This expects the sector size to be 512 bytes.
-	 * Header size is already aligned.
 	 */
 	if (main_hdr->blockid == IBR_HDR_SATA_ID)
-		main_hdr->srcaddr = cpu_to_le32(headersz / 512);
+		main_hdr->srcaddr = cpu_to_le32(le32_to_cpu(main_hdr->srcaddr) / 512);
 
 	/* For PCIe srcaddr is not used and must be set to 0xFFFFFFFF. */
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
@@ -1528,19 +1522,10 @@ static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 					      &datai, delay);
 	}
 
-	if (secure_hdr && add_secure_header_v1(params, ptr + headersz, payloadsz,
+	if (secure_hdr && add_secure_header_v1(params, ptr + *dataoff, payloadsz,
 					       image, headersz, secure_hdr))
 		return NULL;
 
-	*dataoff = headersz;
-
-	/* Fill the real header size without padding into the main header */
-	headersz = sizeof(*main_hdr);
-	for_each_opt_hdr_v1 (ohdr, main_hdr)
-		headersz += opt_hdr_v1_size(ohdr);
-	main_hdr->headersz_lsb = cpu_to_le16(headersz & 0xFFFF);
-	main_hdr->headersz_msb = (headersz & 0xFFFF0000) >> 16;
-
 	/* Calculate and set the header checksum */
 	main_hdr->checksum = image_checksum8(main_hdr, headersz);
 
@@ -1889,7 +1874,7 @@ static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
 	memcpy((uint8_t *)ptr + dataoff + datasz, &checksum, sizeof(uint32_t));
 
 	/* Finally copy the header into the image area */
-	memcpy(ptr, image, dataoff);
+	memcpy(ptr, image, kwbheader_size(image));
 
 	free(image);
 }
@@ -2109,6 +2094,8 @@ static int kwbimage_generate(struct image_tool_params *params,
 		exit(EXIT_FAILURE);
 	}
 
+	alloc_len = image_headersz_align(alloc_len, image_get_bootfrom());
+
 	free(image_cfg);
 
 	hdr = malloc(alloc_len);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 45/59] tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images

[Pali Rohár]

Skip filling legacy_img_hdr structure for XIP images which do not use
legacy_img_hdr structure header. Adding unwanted header to other image
formats, like kwbimage cause generation of broken image.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/mkimage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 30c6df77081f..955a1f39a419 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -842,7 +842,9 @@ copy_file (int ifd, const char *datafile, int pad)
 		exit (EXIT_FAILURE);
 	}
 
-	if (params.xflag) {
+	if (params.xflag &&
+	    (((params.type > IH_TYPE_INVALID) && (params.type < IH_TYPE_FLATDT)) ||
+	     (params.type == IH_TYPE_KERNEL_NOLOAD) || (params.type == IH_TYPE_FIRMWARE_IVT))) {
 		unsigned char *p = NULL;
 		/*
 		 * XIP: do not append the struct legacy_img_hdr at the
-- 
2.20.1

[PATCH RFC u-boot-mvebu 46/59] tools: kwbimage: Add support for XIP SPI/NOR images

[Pali Rohár]

Marvell BootROM can execute SPI images directly from NOR (either SPI/serial
or parallel) without copying them to DDR RAM. This is know at XIP - execute
in place. To achieve that, destination address in kwbimage must be set to
0xFFFFFFFF and execute address to the offset in bytes from the beginning of
NOR memory.

Kirkwood and Dove which use kwbimage v0 format and have SPI address space
mapped to physical memory at 0xE8000000-0xEFFFFFFF by BootROM.

Armada SoCs use kwbimage v1 format and have SPI address space mapped to
physical memory at 0xD4000000-0xD7FFFFFF and Device bus address space (used
for parallel NOR) at 0xD8000000-0xDFFFFFFF.

Add support for generating XIP kwbimages by mkimage -x flag and mark xflag
as valid option in kwbimage.c.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 96 ++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 89 insertions(+), 7 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index da539541742d..7ebb625d03b9 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -927,6 +927,71 @@ done:
 	return ret;
 }
 
+static int image_fill_xip_header(void *image, struct image_tool_params *params)
+{
+	struct main_hdr_v1 *main_hdr = image; /* kwbimage v0 and v1 have same XIP members */
+	int version = kwbimage_version(image);
+	uint32_t srcaddr = le32_to_cpu(main_hdr->srcaddr);
+	uint32_t startaddr = 0;
+
+	if (main_hdr->blockid != IBR_HDR_SPI_ID) {
+		fprintf(stderr, "XIP is supported only for SPI images\n");
+		return 0;
+	}
+
+	if (version == 0 &&
+		   params->addr >= 0xE8000000 && params->addr < 0xEFFFFFFF &&
+		   params->ep >= 0xE8000000 && params->ep < 0xEFFFFFFF) {
+		/* Load and Execute address is in SPI address space (kwbimage v0) */
+		startaddr = 0xE8000000;
+	} else if (version != 0 &&
+		   params->addr >= 0xD4000000 && params->addr < 0xD7FFFFFF &&
+		   params->ep >= 0xD4000000 && params->ep < 0xD7FFFFFF) {
+		/* Load and Execute address is in SPI address space (kwbimage v1) */
+		startaddr = 0xD4000000;
+	} else if (version != 0 &&
+		   params->addr >= 0xD8000000 && params->addr < 0xDFFFFFFF &&
+		   params->ep >= 0xD8000000 && params->ep < 0xDFFFFFFF) {
+		/* Load and Execute address is in Device bus space (kwbimage v1) */
+		startaddr = 0xD8000000;
+	} else if (params->addr != 0x0) {
+		/* Load address is non-zero */
+		if (version == 0)
+			fprintf(stderr, "XIP Load Address or XIP Entry Point is not in SPI address space\n");
+		else
+			fprintf(stderr, "XIP Load Address or XIP Entry Point is not in SPI nor in Device bus address space\n");
+		return 0;
+	}
+
+	/*
+	 * For XIP destaddr must be set to 0xFFFFFFFF and
+	 * execaddr relative to the start of XIP memory address space.
+	 */
+	main_hdr->destaddr = cpu_to_le32(0xFFFFFFFF);
+
+	if (startaddr == 0) {
+		/*
+		 * mkimage's --load-address 0x0 means that binary is Position
+		 * Independent and in this case mkimage's --entry-point address
+		 * is relative offset from beginning of the data part of image.
+		 */
+		main_hdr->execaddr = cpu_to_le32(srcaddr + params->ep);
+	} else {
+		/* The lowest possible load address is after the header at srcaddr. */
+		if (params->addr - startaddr < srcaddr) {
+			fprintf(stderr,
+				"Invalid XIP Load Address 0x%08x.\n"
+				"The lowest address for this configuration is 0x%08x.\n",
+				params->addr, (unsigned)(startaddr + srcaddr));
+			return 0;
+		}
+		main_hdr->srcaddr = cpu_to_le32(params->addr - startaddr);
+		main_hdr->execaddr = cpu_to_le32(params->ep - startaddr);
+	}
+
+	return 1;
+}
+
 static size_t image_headersz_align(size_t headersz, uint8_t blockid)
 {
 	/*
@@ -1022,6 +1087,14 @@ static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
 		main_hdr->srcaddr = cpu_to_le32(0xFFFFFFFF);
 
+	if (params->xflag) {
+		if (!image_fill_xip_header(main_hdr, params)) {
+			free(image);
+			return NULL;
+		}
+		*dataoff = le32_to_cpu(main_hdr->srcaddr);
+	}
+
 	/* Generate the ext header */
 	if (has_ext) {
 		struct ext_hdr_v0 *ext_hdr;
@@ -1461,6 +1534,14 @@ static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
 	if (main_hdr->blockid == IBR_HDR_PEX_ID)
 		main_hdr->srcaddr = cpu_to_le32(0xFFFFFFFF);
 
+	if (params->xflag) {
+		if (!image_fill_xip_header(main_hdr, params)) {
+			free(image);
+			return NULL;
+		}
+		*dataoff = le32_to_cpu(main_hdr->srcaddr);
+	}
+
 	if (image_get_csk_index() >= 0) {
 		/*
 		 * only reserve the space here; we fill the header later since
@@ -1915,8 +1996,13 @@ static void kwbimage_print_header(const void *ptr)
 		       le32_to_cpu(mhdr->srcaddr) != 1 ? "s" : "");
 	else
 		genimg_print_size(le32_to_cpu(mhdr->srcaddr));
-	printf("Load Address: %08x\n", le32_to_cpu(mhdr->destaddr));
-	printf("Entry Point:  %08x\n", le32_to_cpu(mhdr->execaddr));
+	if (mhdr->blockid == IBR_HDR_SPI_ID && le32_to_cpu(mhdr->destaddr) == 0xFFFFFFFF) {
+		printf("Load Address: XIP\n");
+		printf("Execute Offs: %08x\n", le32_to_cpu(mhdr->execaddr));
+	} else {
+		printf("Load Address: %08x\n", le32_to_cpu(mhdr->destaddr));
+		printf("Entry Point:  %08x\n", le32_to_cpu(mhdr->execaddr));
+	}
 }
 
 static int kwbimage_check_image_types(uint8_t type)
@@ -2414,9 +2500,6 @@ static int kwbimage_extract_subimage(void *ptr, struct image_tool_params *params
 	return imagetool_save_subimage(params->outfile, image, size);
 }
 
-/*
- * Report Error if xflag is set in addition to default
- */
 static int kwbimage_check_params(struct image_tool_params *params)
 {
 	if (!params->lflag && !params->iflag && !params->pflag &&
@@ -2429,8 +2512,7 @@ static int kwbimage_check_params(struct image_tool_params *params)
 
 	return (params->dflag && (params->fflag || params->lflag)) ||
 		(params->fflag) ||
-		(params->lflag && (params->dflag || params->fflag)) ||
-		(params->xflag);
+		(params->lflag && (params->dflag || params->fflag));
 }
 
 /*
-- 
2.20.1

[PATCH RFC u-boot-mvebu 47/59] tools: mkimage: Print human readable error when -d is not specified

[Pali Rohár]

When asking mkimage to create a new image file and option -d is not
specified then mkimage show human unfriendly error message:

  mkimage: Can't open (null): Bad address

Without debugger it is hard to debug what is the issue. Function open() is
being called with file name set to NULL. So add a check for this and if it
happens then show human readable message that option -d was not specified.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/mkimage.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 955a1f39a419..c53768f8d8de 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -568,6 +568,11 @@ int main(int argc, char **argv)
 	}
 
 	if ((params.type != IH_TYPE_MULTI) && (params.type != IH_TYPE_SCRIPT)) {
+		if (!params.datafile) {
+			fprintf(stderr, "%s: Option -d with image data file was not specified\n",
+				params.cmdname);
+			exit(EXIT_FAILURE);
+		}
 		dfd = open(params.datafile, O_RDONLY | O_BINARY);
 		if (dfd < 0) {
 			fprintf(stderr, "%s: Can't open %s: %s\n",
-- 
2.20.1

[PATCH RFC u-boot-mvebu 48/59] tools: mkimage: Do not try to open datafile when it is skipped

[Pali Rohár]

When mkimage was instructed to skip datafile via option -s then do not try
to validate or open datafile as it does not have to exist or to be
specified via -d option.

This change allows to use -s option for skipping datafile when -d option
for datafile was not specified.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/mkimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index c53768f8d8de..19c139f402c9 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -567,7 +567,7 @@ int main(int argc, char **argv)
 		exit (retval);
 	}
 
-	if ((params.type != IH_TYPE_MULTI) && (params.type != IH_TYPE_SCRIPT)) {
+	if (!params.skipcpy && params.type != IH_TYPE_MULTI && params.type != IH_TYPE_SCRIPT) {
 		if (!params.datafile) {
 			fprintf(stderr, "%s: Option -d with image data file was not specified\n",
 				params.cmdname);
-- 
2.20.1

[PATCH RFC u-boot-mvebu 49/59] tools: kwbimage: Add support for creating an image with no data

[Pali Rohár]

This change add support for mkimage's -s option to kwbimage format. It will
create an kwbimage with empty data part of image (data part would contain
only required 32-bit checksum). mkimage's -s option is indicated by skipcpy
flag and it is basically in conflict with mkimage's -d (datafile) option.

"Empty" kwbimage with no data can still contain headers. For example it can
contain binary executable header which is copied by BootROM into L2SRAM.
This is useful for example for small images which can do not require DDR
RAM and can be run in L2SRAM (which do not require any initialization).

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwbimage.c | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 7ebb625d03b9..309657a5637b 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1887,7 +1887,9 @@ static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
 	 * Do not use sbuf->st_size as it contains size with padding.
 	 * We need original image data size, so stat original file.
 	 */
-	if (stat(params->datafile, &s)) {
+	if (params->skipcpy) {
+		s.st_size = 0;
+	} else if (stat(params->datafile, &s)) {
 		fprintf(stderr, "Could not stat data file %s: %s\n",
 			params->datafile, strerror(errno));
 		exit(EXIT_FAILURE);
@@ -2106,6 +2108,8 @@ static int kwbimage_verify_header(unsigned char *ptr, int image_size,
 	return 0;
 }
 
+static int kwbimage_align_size(int bootfrom, int alloc_len, struct stat s);
+
 static int kwbimage_generate(struct image_tool_params *params,
 			     struct image_type_params *tparams)
 {
@@ -2124,7 +2128,9 @@ static int kwbimage_generate(struct image_tool_params *params,
 		exit(EXIT_FAILURE);
 	}
 
-	if (stat(params->datafile, &s)) {
+	if (params->skipcpy) {
+		s.st_size = 0;
+	} else if (stat(params->datafile, &s)) {
 		fprintf(stderr, "Could not stat data file %s: %s\n",
 			params->datafile, strerror(errno));
 		exit(EXIT_FAILURE);
@@ -2195,6 +2201,22 @@ static int kwbimage_generate(struct image_tool_params *params,
 	tparams->header_size = alloc_len;
 	tparams->hdr = hdr;
 
+	/*
+	 * This function should return aligned size of the datafile.
+	 * When skipcpy is set (datafile is skipped) then return value of this
+	 * function is ignored, so we have to put required kwbimage aligning
+	 * into the preallocated header size.
+	 */
+	if (params->skipcpy) {
+		tparams->header_size += kwbimage_align_size(bootfrom, alloc_len, s);
+		return 0;
+	} else {
+		return kwbimage_align_size(bootfrom, alloc_len, s);
+	}
+}
+
+static int kwbimage_align_size(int bootfrom, int alloc_len, struct stat s)
+{
 	/*
 	 * The resulting image needs to be 4-byte aligned. At least
 	 * the Marvell hdrparser tool complains if its unaligned.
@@ -2510,7 +2532,7 @@ static int kwbimage_check_params(struct image_tool_params *params)
 		return 1;
 	}
 
-	return (params->dflag && (params->fflag || params->lflag)) ||
+	return (params->dflag && (params->fflag || params->lflag || params->skipcpy)) ||
 		(params->fflag) ||
 		(params->lflag && (params->dflag || params->fflag));
 }
-- 
2.20.1

[PATCH RFC u-boot-mvebu 50/59] arm: mvebu: Add support for generating NAND kwbimage

[Pali Rohár]

Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND which instruct
make to generate kwbimage with NAND header. This image is used for booting
from NAND flash (either SPI or parallel).

Support is very simple, SPL after finishes DDR training returns back to the
BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then loads and
executes U-Boot proper.

To generate correct kwbimage NAND header, it is required to set following
Kconfig options:

CONFIG_SYS_NAND_PAGE_SIZE
CONFIG_SYS_NAND_BLOCK_SIZE
CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION

They are used only by make / mkimage when generating final kwbimage.

CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION is a new mvebu specific Kconfig
option which is set into kwbimage NAND_BADBLK_LOCATION header field.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/Kconfig         | 13 +++++++++++++
 arch/arm/mach-mvebu/Makefile        | 10 ++++++++++
 arch/arm/mach-mvebu/kwbimage.cfg.in |  5 +++++
 drivers/mtd/nand/raw/Kconfig        |  4 +++-
 4 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 2863babefbe3..5e9480aed291 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -321,6 +321,11 @@ config MVEBU_SPL_BOOT_DEVICE_SPI
 	imply SPL_SPI
 	select SPL_BOOTROM_SUPPORT
 
+config MVEBU_SPL_BOOT_DEVICE_NAND
+	bool "NAND flash (SPI or parallel)"
+	select MTD_RAW_NAND
+	select SPL_BOOTROM_SUPPORT
+
 config MVEBU_SPL_BOOT_DEVICE_MMC
 	bool "SDIO/MMC card"
 	imply ENV_IS_IN_MMC
@@ -346,6 +351,14 @@ config MVEBU_SPL_BOOT_DEVICE_UART
 
 endchoice
 
+config MVEBU_SPL_NAND_BADBLK_LOCATION
+	hex "NAND Bad block indicator location"
+	depends on MVEBU_SPL_BOOT_DEVICE_NAND
+	range 0x0 0x1
+	help
+	  Value 0x0 = SLC flash = BBI at page 0 or page 1
+	  Value 0x1 = MLC flash = BBI at last page in the block
+
 config MVEBU_EFUSE
 	bool "Enable eFuse support"
 	depends on HAVE_MVEBU_EFUSE
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index a23511b113bb..4b7b9ff8b2f2 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -50,6 +50,9 @@ KWB_REPLACE += BOOT_FROM
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),)
 	KWB_CFG_BOOT_FROM=spi
 endif
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),)
+	KWB_CFG_BOOT_FROM=nand
+endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
 	KWB_CFG_BOOT_FROM=sdio
 endif
@@ -60,6 +63,13 @@ ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
 	KWB_CFG_BOOT_FROM=uart
 endif
 
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),)
+KWB_REPLACE += NAND_PAGE_SIZE NAND_BLKSZ NAND_BADBLK_LOCATION
+KWB_CFG_NAND_PAGE_SIZE = $(CONFIG_SYS_NAND_PAGE_SIZE)
+KWB_CFG_NAND_BLKSZ = $(CONFIG_SYS_NAND_BLOCK_SIZE)
+KWB_CFG_NAND_BADBLK_LOCATION = $(CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION)
+endif
+
 ifneq ($(CONFIG_SECURED_MODE_IMAGE),)
 KWB_REPLACE += CSK_INDEX
 KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX)
diff --git a/arch/arm/mach-mvebu/kwbimage.cfg.in b/arch/arm/mach-mvebu/kwbimage.cfg.in
index ccb09975817e..90cf00c5b984 100644
--- a/arch/arm/mach-mvebu/kwbimage.cfg.in
+++ b/arch/arm/mach-mvebu/kwbimage.cfg.in
@@ -11,6 +11,11 @@ VERSION		1
 # Boot Media configurations
 #@BOOT_FROM
 
+# NAND configuration
+#@NAND_PAGE_SIZE
+#@NAND_BLKSZ
+#@NAND_BADBLK_LOCATION
+
 # Enable BootROM output via DEBUG flag on SoCs which require it
 #@DEBUG
 
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 8aaba8b1a2cf..8aaf135ab45d 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -550,7 +550,8 @@ comment "Generic NAND options"
 
 config SYS_NAND_BLOCK_SIZE
 	hex "NAND chip eraseblock size"
-	depends on ARCH_SUNXI || SPL_NAND_SUPPORT || TPL_NAND_SUPPORT
+	depends on ARCH_SUNXI || SPL_NAND_SUPPORT || TPL_NAND_SUPPORT || \
+		MVEBU_SPL_BOOT_DEVICE_NAND
 	depends on !NAND_MXS && !NAND_DENALI_DT && !NAND_LPC32XX_MLC && \
 		!NAND_FSL_IFC && !NAND_MT7621
 	help
@@ -576,6 +577,7 @@ config SYS_NAND_PAGE_SIZE
 	hex "NAND chip page size"
 	depends on ARCH_SUNXI || NAND_OMAP_GPMC || NAND_LPC32XX_SLC || \
 		SPL_NAND_SIMPLE || (NAND_MXC && SPL_NAND_SUPPORT) || \
+		MVEBU_SPL_BOOT_DEVICE_NAND || \
 		(NAND_ATMEL && SPL_NAND_SUPPORT) || SPL_GENERATE_ATMEL_PMECC_HEADER
 	depends on !NAND_MXS && !NAND_DENALI_DT && !NAND_LPC32XX_MLC && !NAND_MT7621
 	help
-- 
2.20.1

[PATCH RFC u-boot-mvebu 51/59] arm: mvebu: Add support for generating PEX kwbimage

[Pali Rohár]

Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX which instruct
make to generate kwbimage with PEX header. This image is used for booting
from PCI Express device which is in the Root Complex mode.

Support is very simple, SPL after finishes DDR training returns back to the
BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then start
executing U-Boot proper.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/Kconfig  | 4 ++++
 arch/arm/mach-mvebu/Makefile | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e9480aed291..5abcdc4972ab 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -345,6 +345,10 @@ config MVEBU_SPL_BOOT_DEVICE_SATA
 	imply SPL_LIBDISK_SUPPORT
 	select SPL_BOOTROM_SUPPORT
 
+config MVEBU_SPL_BOOT_DEVICE_PEX
+	bool "PCI Express"
+	select SPL_BOOTROM_SUPPORT
+
 config MVEBU_SPL_BOOT_DEVICE_UART
 	bool "UART"
 	select SPL_BOOTROM_SUPPORT
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 4b7b9ff8b2f2..00014375e7fb 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -59,6 +59,9 @@ endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
 	KWB_CFG_BOOT_FROM=sata
 endif
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX),)
+	KWB_CFG_BOOT_FROM=pex
+endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
 	KWB_CFG_BOOT_FROM=uart
 endif
-- 
2.20.1

[PATCH RFC u-boot-mvebu 52/59] arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options

[Pali Rohár]

MVEBU_SPL_BOOT_DEVICE_SPI is for NOR flash. Either serial or parallel. Not
for general serial/SPI devices. The correct name should be BOOT_DEVICE_NOR
but name SPI is already used in mkimage config format which we do not want
to change for compatibility reasons.

MVEBU_SPL_BOOT_DEVICE_MMC is for MMC and SD compatible devices. Not for
SDIO devices. In most cases used for eMMC or SD card.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5abcdc4972ab..ba40c59f4a95 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -313,7 +313,7 @@ choice
 	depends on SPL
 
 config MVEBU_SPL_BOOT_DEVICE_SPI
-	bool "SPI NOR flash"
+	bool "NOR flash (SPI or parallel)"
 	imply ENV_IS_IN_SPI_FLASH
 	imply SPL_DM_SPI
 	imply SPL_SPI_FLASH_SUPPORT
@@ -327,7 +327,7 @@ config MVEBU_SPL_BOOT_DEVICE_NAND
 	select SPL_BOOTROM_SUPPORT
 
 config MVEBU_SPL_BOOT_DEVICE_MMC
-	bool "SDIO/MMC card"
+	bool "eMMC or SD card"
 	imply ENV_IS_IN_MMC
 	# GPIO needed for eMMC/SD card presence detection
 	imply SPL_DM_GPIO
-- 
2.20.1

[PATCH RFC u-boot-mvebu 53/59] arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting

[Pali Rohár]

This new db-88f6820-amc_nand_defconfig file is copy of existing
db-88f6820-amc_defconfig file and changed to instruct build system to
generate final kwbimage for NAND booting. It was done by adding options:

    CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND=y
    CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION=0x00
    CONFIG_SYS_NAND_BLOCK_SIZE=0x40000
    CONFIG_SYS_NAND_PAGE_SIZE=0x1000

Board has Micron MT29F8G08ABACAWP chip which is SLC NAND with 4kB page size
and block size of 64 pages.

This change was only compile-tested and is useful for CI testing that
mkimage can generate valid kwbimage of NAND type.

This change is more readable via git option --find-copies-harder.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 ...-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
 copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)

diff --git a/configs/db-88f6820-amc_defconfig b/configs/db-88f6820-amc_nand_defconfig
similarity index 92%
copy from configs/db-88f6820-amc_defconfig
copy to configs/db-88f6820-amc_nand_defconfig
index b33bb66b5957..e784c34563f4 100644
--- a/configs/db-88f6820-amc_defconfig
+++ b/configs/db-88f6820-amc_nand_defconfig
@@ -6,6 +6,8 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_TARGET_DB_88F6820_AMC=y
+CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND=y
+CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION=0x00
 CONFIG_ENV_SIZE=0x10000
 CONFIG_ENV_OFFSET=0x100000
 CONFIG_ENV_SECT_SIZE=0x40000
@@ -53,6 +55,7 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_EFI_PARTITION=y
 CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_SPI_MAX_HZ=50000000
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ARP_TIMEOUT=200
@@ -64,10 +67,11 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
 # CONFIG_MMC is not set
 CONFIG_MTD=y
-CONFIG_MTD_RAW_NAND=y
 CONFIG_SYS_NAND_USE_FLASH_BBT=y
 CONFIG_NAND_PXA3XX=y
+CONFIG_SYS_NAND_BLOCK_SIZE=0x40000
 CONFIG_SYS_NAND_ONFI_DETECTION=y
+CONFIG_SYS_NAND_PAGE_SIZE=0x1000
 CONFIG_SF_DEFAULT_BUS=1
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
-- 
2.20.1

[PATCH RFC u-boot-mvebu 54/59] arm: mvebu: clearfog: Add defconfig for SATA booting

[Pali Rohár]

This new clearfog_sata_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SATA booting.

This change is more readable via git option --find-copies-harder.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 configs/{clearfog_defconfig => clearfog_sata_defconfig} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_sata_defconfig
similarity index 98%
copy from configs/clearfog_defconfig
copy to configs/clearfog_sata_defconfig
index f91942865a3b..e9b36150eae9 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_sata_defconfig
@@ -7,7 +7,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y
+CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
 CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
 CONFIG_SPL_TEXT_BASE=0x40000030
 CONFIG_SPL_SERIAL=y
-- 
2.20.1

[PATCH RFC u-boot-mvebu 55/59] arm: mvebu: Remove A39x relicts

[Pali Rohár]

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 .../serdes/a38x/high_speed_env_spec.c         |  4 +--
 .../serdes/a38x/high_speed_env_spec.h         |  4 +--
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c | 14 +++------
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h | 30 -------------------
 4 files changed, 8 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 943ae019425f..3349f4eb5491 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -53,7 +53,7 @@ u8 serdes_lane_in_use_count[MAX_UNITS_ID][MAX_UNIT_NUMB] = {
  */
 u8 serdes_unit_count[MAX_UNITS_ID] = { 0 };
 
-/* Selector mapping for A380-A0 and A390-Z1 */
+/* Selector mapping for A380-A0 */
 u8 selectors_serdes_rev2_map[LAST_SERDES_TYPE][MAX_SERDES_LANES] = {
 	/* 0      1      2       3       4       5       6 */
 	{ 0x1,   0x1,    NA,	 NA,	 NA,	 NA,     NA  }, /* PEX0 */
@@ -812,7 +812,7 @@ u8 hws_ctrl_serdes_rev_get(void)
 	if (sys_env_device_rev_get() == MV_88F68XX_Z1_ID)
 		return MV_SERDES_REV_1_2;
 
-	/* for A39x-Z1, A38x-A0 */
+	/* for A38x-A0 */
 	return MV_SERDES_REV_2_1;
 }
 
diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.h b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.h
index dd229e1a4701..6925a9d236ed 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.h
@@ -15,12 +15,12 @@
 #define SET_BIT(data, bit)		((data) | (0x1 << (bit)))
 #define CLEAR_BIT(data, bit)		((data) & (~(0x1 << (bit))))
 
-#define MAX_SERDES_LANES		7	/* as in a39x */
+#define MAX_SERDES_LANES		7
 
 /* Serdes revision */
 /* Serdes revision 1.2 (for A38x-Z1) */
 #define MV_SERDES_REV_1_2		0x0
-/* Serdes revision 2.1 (for A39x-Z1, A38x-A0) */
+/* Serdes revision 2.1 (for A38x-A0) */
 #define MV_SERDES_REV_2_1		0x1
 #define MV_SERDES_REV_NA		0xff
 
diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
index 950680a58167..fb8ec11dfb95 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
@@ -145,10 +145,6 @@ u32 sys_env_id_index_get(u32 ctrl_model)
 		return MV_6811_INDEX;
 	case MV_6828_DEV_ID:
 		return MV_6828_INDEX;
-	case MV_6920_DEV_ID:
-		return MV_6920_INDEX;
-	case MV_6928_DEV_ID:
-		return MV_6928_INDEX;
 	default:
 		return MV_6820_INDEX;
 	}
@@ -183,11 +179,9 @@ u16 sys_env_model_get(void)
 	case MV_6810_DEV_ID:
 	case MV_6811_DEV_ID:
 	case MV_6828_DEV_ID:
-	case MV_6920_DEV_ID:
-	case MV_6928_DEV_ID:
 		return ctrl_id;
 	default:
-		/* Device ID Default for A38x: 6820 , for A39x: 6920 */
+		/* Device ID Default for A38x: 6820 */
 		default_ctrl_id =  MV_6820_DEV_ID;
 		printf("%s: Error retrieving device ID (%x), using default ID = %x\n",
 		       __func__, ctrl_id, default_ctrl_id);
@@ -201,8 +195,8 @@ u16 sys_env_model_get(void)
  */
 u32 sys_env_device_id_get(void)
 {
-	char *device_id_str[7] = {
-		"6810", "6820", "6811", "6828", "NONE", "6920", "6928"
+	char *device_id_str[4] = {
+		"6810", "6820", "6811", "6828",
 	};
 
 	if (g_dev_id != -1)
@@ -210,7 +204,7 @@ u32 sys_env_device_id_get(void)
 
 	g_dev_id = reg_read(DEVICE_SAMPLE_AT_RESET1_REG);
 	g_dev_id = g_dev_id >> SAR_DEV_ID_OFFS & SAR_DEV_ID_MASK;
-	printf("Detected Device ID %s\n", device_id_str[g_dev_id]);
+	printf("Detected Device ID %s\n", g_dev_id < 4 ? device_id_str[g_dev_id] : "NONE");
 
 	return g_dev_id;
 }
diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
index 94c43b4dafa2..20039f72d8b1 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
@@ -198,22 +198,6 @@
 #define A38X_MV_MARVELL_BOARD_NUM	(A38X_MV_MAX_MARVELL_BOARD_ID - \
 					 A38X_MARVELL_BOARD_ID_BASE)
 
-/* Customer boards for A39x */
-#define A39X_CUSTOMER_BOARD_ID_BASE	0x20
-#define A39X_CUSTOMER_BOARD_ID0		(A39X_CUSTOMER_BOARD_ID_BASE + 0)
-#define A39X_CUSTOMER_BOARD_ID1		(A39X_CUSTOMER_BOARD_ID_BASE + 1)
-#define A39X_MV_MAX_CUSTOMER_BOARD_ID	(A39X_CUSTOMER_BOARD_ID_BASE + 2)
-#define A39X_MV_CUSTOMER_BOARD_NUM	(A39X_MV_MAX_CUSTOMER_BOARD_ID - \
-					 A39X_CUSTOMER_BOARD_ID_BASE)
-
-/* Marvell boards for A39x */
-#define A39X_MARVELL_BOARD_ID_BASE	0x30
-#define A39X_DB_69XX_ID			(A39X_MARVELL_BOARD_ID_BASE + 0)
-#define A39X_RD_69XX_ID			(A39X_MARVELL_BOARD_ID_BASE + 1)
-#define A39X_MV_MAX_MARVELL_BOARD_ID	(A39X_MARVELL_BOARD_ID_BASE + 2)
-#define A39X_MV_MARVELL_BOARD_NUM	(A39X_MV_MAX_MARVELL_BOARD_ID - \
-					 A39X_MARVELL_BOARD_ID_BASE)
-
 #define CUTOMER_BOARD_ID_BASE		A38X_CUSTOMER_BOARD_ID_BASE
 #define CUSTOMER_BOARD_ID0		A38X_CUSTOMER_BOARD_ID0
 #define CUSTOMER_BOARD_ID1		A38X_CUSTOMER_BOARD_ID1
@@ -236,8 +220,6 @@
 #define MV_88F68XX_Z1_ID		0x0
 #define MV_88F68XX_A0_ID		0x4
 #define MV_88F68XX_B0_ID		0xa
-/* A39x revisions */
-#define MV_88F69XX_Z1_ID		0x2
 
 #define MPP_CONTROL_REG(id)		(0x18000 + (id * 4))
 #define GPP_DATA_OUT_REG(grp)		(MV_GPP_REGS_BASE(grp) + 0x00)
@@ -257,19 +239,12 @@
 #define MV_6811_DEV_ID		0x6811
 #define MV_6820_DEV_ID		0x6820
 #define MV_6828_DEV_ID		0x6828
-/* Armada 39x Family */
-#define MV_6920_DEV_ID		0x6920
-#define MV_6928_DEV_ID		0x6928
 
 enum {
 	MV_6810,
 	MV_6820,
 	MV_6811,
 	MV_6828,
-	MV_NONE,
-	MV_6920,
-	MV_6928,
-	MV_MAX_DEV_ID,
 };
 
 #define MV_6820_INDEX			0
@@ -277,17 +252,12 @@ enum {
 #define MV_6811_INDEX			2
 #define MV_6828_INDEX			3
 
-#define MV_6920_INDEX			0
-#define MV_6928_INDEX			1
-
 #define MAX_DEV_ID_NUM			4
 
 #define MV_6820_INDEX			0
 #define MV_6810_INDEX			1
 #define MV_6811_INDEX			2
 #define MV_6828_INDEX			3
-#define MV_6920_INDEX			0
-#define MV_6928_INDEX			1
 
 enum unit_id {
 	PEX_UNIT_ID,
-- 
2.20.1

[PATCH RFC u-boot-mvebu 56/59] arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping

[Pali Rohár]

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 1f8cdf8744e6..c5089a91c747 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -25,7 +25,7 @@ static const struct mbus_win windows[] = {
 	{ MBUS_SPI_BASE, MBUS_SPI_SIZE,
 	  CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_SPIFLASH },
 
-	/* NOR */
+	/* BootROM */
 	{ MBUS_BOOTROM_BASE, MBUS_BOOTROM_SIZE,
 	  CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_BOOTROM },
 
-- 
2.20.1

[PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot

[Pali Rohár]

Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD4000000 to 0xF4000000
and change its size from 64 MB to 8 MB. Definitions are already in
MBUS_SPI_BASE/MBUS_SPI_SIZE macros. So define these macros also for SPL
build, use them in env_sf_get_env_addr() function and move this function
from spl.c to cpu.c to be available in Proper U-Boot too.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/cpu.c              |  9 +++++++++
 arch/arm/mach-mvebu/include/mach/cpu.h |  5 +++++
 arch/arm/mach-mvebu/spl.c              | 13 -------------
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index c5089a91c747..97154aaa2a7e 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -35,6 +35,15 @@ static const struct mbus_win windows[] = {
 #endif
 };
 
+/* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */
+#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
+    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
+void *env_sf_get_env_addr(void)
+{
+	return (void *)MBUS_SPI_BASE + CONFIG_ENV_OFFSET;
+}
+#endif
+
 void lowlevel_init(void)
 {
 	/*
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h
index c17c2440f1b1..906a8737a401 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -71,8 +71,13 @@ enum cpu_attrib {
 #define MBUS_PCI_MEM_SIZE	((MBUS_PCI_MAX_PORTS * 128) << 20)
 #define MBUS_PCI_IO_BASE	0xF1100000
 #define MBUS_PCI_IO_SIZE	((MBUS_PCI_MAX_PORTS * 64) << 10)
+#ifdef CONFIG_SPL_BUILD
+#define MBUS_SPI_BASE		0xD4000000
+#define MBUS_SPI_SIZE		(64 << 20)
+#else
 #define MBUS_SPI_BASE		0xF4000000
 #define MBUS_SPI_SIZE		(8 << 20)
+#endif
 #define MBUS_DFX_BASE		0xF6000000
 #define MBUS_DFX_SIZE		(1 << 20)
 #define MBUS_BOOTROM_BASE	0xF8000000
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 02528e025d8c..6b8c72a71dab 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -308,19 +308,6 @@ int board_return_to_bootrom(struct spl_image_info *spl_image,
 	hang();
 }
 
-/*
- * SPI0 CS0 Flash is mapped to address range 0xD4000000 - 0xD7FFFFFF by BootROM.
- * Proper U-Boot removes this direct mapping. So it is available only in SPL.
- */
-#if defined(CONFIG_SPL_ENV_IS_IN_SPI_FLASH) && \
-    CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
-    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= 64*1024*1024
-void *env_sf_get_env_addr(void)
-{
-	return (void *)0xD4000000 + CONFIG_ENV_OFFSET;
-}
-#endif
-
 void board_init_f(ulong dummy)
 {
 	int ret;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 58/59] arm: mvebu: Define SPL memory maps

[Pali Rohár]

In SPL are active memory maps set by the BootROM. Define them in cpu.h file
to the correct values. Some peripherals are not mapped at all.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/include/mach/cpu.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h
index 906a8737a401..904e7157ba61 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -66,11 +66,21 @@ enum cpu_attrib {
 /*
  * Default Device Address MAP BAR values
  */
+#ifdef CONFIG_SPL_BUILD
+#ifdef CONFIG_ARMADA_38X
+#define MBUS_PCI_MEM_BASE	0x88000000
+#define MBUS_PCI_MEM_SIZE	((3 * 128) << 20)
+#else
+#define MBUS_PCI_MEM_BASE	0x80000000
+#define MBUS_PCI_MEM_SIZE	((4 * 128) << 20)
+#endif
+#else
 #define MBUS_PCI_MAX_PORTS	6
 #define MBUS_PCI_MEM_BASE	MVEBU_SDRAM_SIZE_MAX
 #define MBUS_PCI_MEM_SIZE	((MBUS_PCI_MAX_PORTS * 128) << 20)
 #define MBUS_PCI_IO_BASE	0xF1100000
 #define MBUS_PCI_IO_SIZE	((MBUS_PCI_MAX_PORTS * 64) << 10)
+#endif
 #ifdef CONFIG_SPL_BUILD
 #define MBUS_SPI_BASE		0xD4000000
 #define MBUS_SPI_SIZE		(64 << 20)
@@ -78,10 +88,16 @@ enum cpu_attrib {
 #define MBUS_SPI_BASE		0xF4000000
 #define MBUS_SPI_SIZE		(8 << 20)
 #endif
+#ifndef CONFIG_SPL_BUILD
 #define MBUS_DFX_BASE		0xF6000000
 #define MBUS_DFX_SIZE		(1 << 20)
+#endif
 #define MBUS_BOOTROM_BASE	0xF8000000
+#ifdef CONFIG_SPL_BUILD
+#define MBUS_BOOTROM_SIZE	(128 << 20)
+#else
 #define MBUS_BOOTROM_SIZE	(8 << 20)
+#endif
 
 struct mbus_win {
 	u32 base;
-- 
2.20.1

[PATCH RFC u-boot-mvebu 59/59] doc/kwboot.1: Update example description

[Pali Rohár]

Mention fact about changing baudrate back when -B is used.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 doc/kwboot.1 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/kwboot.1 b/doc/kwboot.1
index a528fbbe8c38..5cda3b4d88a8 100644
--- a/doc/kwboot.1
+++ b/doc/kwboot.1
@@ -159,7 +159,8 @@ program:
 Instruct BootROM to enter boot Xmodem boot mode, send header of
 \fIu-boot-with-spl.kwb\fP kwbimage file via Xmodem at 115200 Bd, then instruct
 BootROM to change baudrate to 5200000 Bd, send data part of the kwbimage
-file via Xmodem at high speed and finally run terminal program:
+file via Xmodem at high speed, then change baudrate back to 115200 Bd,
+and finally run terminal program:
 .IP
 .B kwboot -b u-boot-with-spl.kwb -B 5200000 -t /dev/ttyUSB0
 
-- 
2.20.1

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Tony Dinh]

Hi Pali,

On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
>
> This patch series contains various improvements and fixes for existing
> logical errors. Boot phase was adjusted to match behavior of Armada 385
> BootROM by inspecting and disassembling of BootROM binary dump itself.
> Important information are included in documentation patch for kwboot.
> Most of the changes are untested, hence this patch series is just RFC.
> So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> Nevertheless all patches on github passed CI testing in this PR:
> https://github.com/u-boot/u-boot/pull/275
>
> Pali Rohár (59):
>   tools: kwbimage: Fix generating, verifying and extracting SDIO
>     kwbimage
>   tools: kwboot: Fix parsing SDIO kwbimage
>   arm: mvebu: spl: Fix parsing SDIO kwbimage
>   cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>   tools: kwbimage: Fix generating, verifying and extracting SATA
>     kwbimage
>   tools: kwboot: Fix parsing SATA kwbimage
>   arm: mvebu: spl: Fix parsing SATA kwbimage
>   cmd: mvebu/bubt: Fix parsing SATA kwbimage
>   arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>     BOOT_DEVICE_MMC2_2
>   arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
>   spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>   arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
>   tools: kwboot: Add more documentation references
>   tools: kwboot: Add image type documentation
>   tools: kwboot: Fix parsing UART image without data checksum
>   tools: kwboot: Validate optional kwbimage v1 headers
>   tools: kwboot: Add check that kwbimage contains DDR init code
>   tools: kwboot: Fix patching of SPI/NOR XIP images
>   tools: kwboot: Show image type and error parsing reasons
>   cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>   cmd: mvebu/bubt: Add support for writing image to SATA disk
>   cmd: mvebu/bubt: Add support for reading image from the SATA disk
>     partition
>   cmd: mvebu/bubt: Rename variable image_size to hdr_size
>   cmd: mvebu/bubt: Mark all local symbols as static
>   cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
>   cmd: mvebu/bubt: Check also A8K boot image checksum
>   cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
>   cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>   cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
>     'fuse_read_u64' defined but not used
>   cmd: mvebu/bubt: Enable command by default
>   tools: kwbimage: Fix dumping register set / DATA commands
>   tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>   tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>   tools: kwbimage: Fix dumping NAND_BLKSZ
>   tools: kwbimage: Fix generating of kwbimage v0 header checksum
>   tools: kwbimage: Fix endianity when printing kwbimage header
>   tools: kwbimage: Reject mkimage -F option
>   tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
>   tools: kwbimage: Print binary image offset as size
>   tools: kwbimage: Print image data offset when printing kwbimage header
>   tools: kwbimage: Simplify add_secure_header_v1()
>   tools: kwbimage: Rename imagesz to dataoff
>   tools: kwbimage: Fix generating secure boot data image signature
>   tools: kwbimage: Fix invalid secure boot header signature
>   tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
>   tools: kwbimage: Add support for XIP SPI/NOR images
>   tools: mkimage: Print human readable error when -d is not specified
>   tools: mkimage: Do not try to open datafile when it is skipped
>   tools: kwbimage: Add support for creating an image with no data
>   arm: mvebu: Add support for generating NAND kwbimage
>   arm: mvebu: Add support for generating PEX kwbimage
>   arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>   arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>   arm: mvebu: clearfog: Add defconfig for SATA booting
>   arm: mvebu: Remove A39x relicts
>   arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>   arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
>   arm: mvebu: Define SPL memory maps
>   doc/kwboot.1: Update example description
>
>  arch/arm/mach-mvebu/Kconfig                   |  23 +-
>  arch/arm/mach-mvebu/Makefile                  |  13 +
>  arch/arm/mach-mvebu/cpu.c                     |  11 +-
>  arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>  arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
>  .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>  .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>  arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>  arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>  arch/arm/mach-mvebu/spl.c                     |  84 +++--
>  cmd/mvebu/Kconfig                             |  18 ++
>  cmd/mvebu/bubt.c                              | 253 ++++++++++++---
>  common/spl/Kconfig                            |   9 +
>  common/spl/spl_mmc.c                          |  12 +-
>  ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>  ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>  doc/kwboot.1                                  |   3 +-
>  doc/mvebu/cmd/bubt.txt                        |  25 +-
>  drivers/mtd/nand/raw/Kconfig                  |   4 +-
>  tools/kwbimage.c                              | 297 +++++++++++-------
>  tools/kwboot.c                                | 200 +++++++++++-
>  tools/mkimage.c                               |  11 +-
>  22 files changed, 768 insertions(+), 281 deletions(-)
>  copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
>  copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)
>
> --
> 2.20.1
>

I went to patchwork and downloaded the series.
https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org

When I applied the patches set there were some rejections.
<BEGIN LOG>
# patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch

patching file tools/kwbimage.c
patching file tools/kwboot.c
patching file arch/arm/mach-mvebu/spl.c
patching file cmd/mvebu/bubt.c
patching file tools/kwboot.c
patching file arch/arm/mach-mvebu/spl.c
patching file cmd/mvebu/bubt.c
patching file arch/arm/mach-mvebu/spl.c
patching file arch/arm/mach-mvebu/Kconfig
Hunk #1 succeeded at 348 (offset 18 lines).
patching file arch/arm/mach-mvebu/spl.c
patching file arch/arm/mach-mvebu/Kconfig
Hunk #1 succeeded at 349 (offset 18 lines).
patching file arch/arm/mach-mvebu/spl.c
patching file tools/kwboot.c
patching file tools/kwboot.c
patching file tools/kwboot.c
patching file tools/kwboot.c
patching file tools/kwboot.c
patching file tools/kwboot.c
patching file tools/kwboot.c
patching file cmd/mvebu/bubt.c
patching file doc/mvebu/cmd/bubt.txt
patching file cmd/mvebu/bubt.c
Hunk #1 FAILED at 420.
Hunk #2 FAILED at 430.
Hunk #3 FAILED at 656.
Hunk #4 FAILED at 1206.
4 out of 4 hunks FAILED -- saving rejects to file cmd/mvebu/bubt.c.rej
patching file doc/mvebu/cmd/bubt.txt
Hunk #1 FAILED at 6.
1 out of 1 hunk FAILED -- saving rejects to file doc/mvebu/cmd/bubt.txt.rej
patching file cmd/mvebu/bubt.c
Hunk #1 succeeded at 765 (offset -140 lines).
Hunk #2 succeeded at 804 (offset -140 lines).
Hunk #3 succeeded at 825 (offset -140 lines).
patching file cmd/mvebu/bubt.c
Hunk #1 succeeded at 548 (offset -139 lines).
Hunk #2 succeeded at 567 (offset -140 lines).
Hunk #3 succeeded at 1000 (offset -140 lines).
Hunk #4 succeeded at 1026 (offset -142 lines).
patching file cmd/mvebu/bubt.c
Hunk #1 succeeded at 599 (offset -140 lines).
patching file cmd/mvebu/bubt.c
Hunk #1 succeeded at 585 (offset -140 lines).
Hunk #2 succeeded at 598 (offset -140 lines).
patching file cmd/mvebu/Kconfig
Hunk #1 succeeded at 15 (offset -3 lines).
patching file cmd/mvebu/bubt.c
Hunk #1 succeeded at 844 (offset -140 lines).
Hunk #2 succeeded at 873 (offset -140 lines).
patching file cmd/mvebu/Kconfig
Hunk #1 succeeded at 3 with fuzz 1.
patching file tools/kwbimage.c
Hunk #1 succeeded at 2156 (offset 8 lines).
Hunk #2 succeeded at 2241 (offset 8 lines).
patching file tools/kwbimage.c
Hunk #1 succeeded at 2190 (offset 8 lines).
patching file tools/kwbimage.c
Hunk #1 succeeded at 2192 with fuzz 2 (offset 8 lines).
patching file tools/kwbimage.c
Hunk #1 succeeded at 1929 (offset 1 line).
patching file tools/kwbimage.c
Hunk #1 succeeded at 2449 (offset 9 lines).
patching file tools/kwbimage.c
Hunk #1 succeeded at 2192 (offset 7 lines).
patching file tools/kwbimage.c
Hunk #1 succeeded at 1915 (offset 1 line).
patching file tools/kwbimage.c
Hunk #1 succeeded at 1930 (offset 1 line).
patching file tools/kwbimage.c
Hunk #3 succeeded at 1529 (offset 1 line).
patching file tools/kwbimage.c
Hunk #2 succeeded at 1050 with fuzz 2.
Hunk #4 succeeded at 1533 (offset 1 line).
Hunk #5 succeeded at 1812 (offset 1 line).
Hunk #6 succeeded at 1863 (offset 1 line).
Hunk #7 succeeded at 1885 (offset 1 line).
patching file tools/kwbimage.c
patching file tools/kwbimage.c
Hunk #4 FAILED at 1014.
Hunk #5 succeeded at 1051 with fuzz 2.
Hunk #11 FAILED at 1454.
Hunk #12 succeeded at 1525 (offset 1 line).
Hunk #13 succeeded at 1877 (offset 1 line).
Hunk #14 succeeded at 2103 (offset 7 lines).
2 out of 14 hunks FAILED -- saving rejects to file tools/kwbimage.c.rej
patching file tools/mkimage.c
Hunk #1 succeeded at 860 (offset 18 lines).
patching file tools/mkimage.c
Hunk #1 succeeded at 600 (offset 32 lines).
patching file tools/mkimage.c
Hunk #1 succeeded at 599 (offset 32 lines).
patching file tools/kwbimage.c
Hunk #1 succeeded at 1809 (offset -78 lines).
Hunk #2 succeeded at 2031 (offset -77 lines).
Hunk #3 succeeded at 2051 (offset -77 lines).
Hunk #4 succeeded at 2124 (offset -77 lines).
Hunk #5 succeeded at 2460 with fuzz 2 (offset -72 lines).
patching file arch/arm/mach-mvebu/Kconfig
Hunk #1 succeeded at 339 (offset 18 lines).
Hunk #2 succeeded at 369 (offset 18 lines).
patching file arch/arm/mach-mvebu/Makefile
patching file arch/arm/mach-mvebu/kwbimage.cfg.in
patching file drivers/mtd/nand/raw/Kconfig
Hunk #1 succeeded at 628 (offset 78 lines).
Hunk #2 succeeded at 656 (offset 79 lines).
patching file arch/arm/mach-mvebu/Kconfig
Hunk #1 succeeded at 363 (offset 18 lines).
patching file arch/arm/mach-mvebu/Makefile
patching file arch/arm/mach-mvebu/Kconfig
Hunk #1 succeeded at 331 (offset 18 lines).
Hunk #2 succeeded at 345 (offset 18 lines).
patching file configs/db-88f6820-amc_nand_defconfig (copied from
configs/db-88f6820-amc_defconfig)
Hunk #1 succeeded at 8 with fuzz 2 (offset 2 lines).
patching file configs/clearfog_sata_defconfig (copied from
configs/clearfog_defconfig)
Hunk #1 succeeded at 9 with fuzz 2 (offset 2 lines).
patching file arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
patching file arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.h
patching file arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
patching file arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
patching file arch/arm/mach-mvebu/cpu.c
patching file arch/arm/mach-mvebu/cpu.c
patching file arch/arm/mach-mvebu/include/mach/cpu.h
patching file arch/arm/mach-mvebu/spl.c
patching file arch/arm/mach-mvebu/include/mach/cpu.h
patching file doc/kwboot.1
<END LOG>

I'm on the latest master branch (just did a git pull today). Could
some patches be out of order?

Thanks,
Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> Hi Pali,
> 
> On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > This patch series contains various improvements and fixes for existing
> > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > Important information are included in documentation patch for kwboot.
> > Most of the changes are untested, hence this patch series is just RFC.
> > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > Nevertheless all patches on github passed CI testing in this PR:
> > https://github.com/u-boot/u-boot/pull/275
...
> I went to patchwork and downloaded the series.
> https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> 
> When I applied the patches set there were some rejections.
> <BEGIN LOG>
> # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> 
...
FAILED
...
> <END LOG>
> 
> I'm on the latest master branch (just did a git pull today). Could
> some patches be out of order?
> 
> Thanks,
> Tony

Well, that is because DENX mail server is broken and it crashed during
processing antispam filter on my some of my patches. So some patches are
missing in archive and then applying dependent patches failed.

So ignore patchwork and email patches. Rather fetch changes from the
mentioned github pull request https://github.com/u-boot/u-boot/pull/275

You can do it via git command (it fetch it to the new mvebu branch):

  git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Tony Dinh]

Hi Pali,

On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > This patch series contains various improvements and fixes for existing
> > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > Important information are included in documentation patch for kwboot.
> > > Most of the changes are untested, hence this patch series is just RFC.
> > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > Nevertheless all patches on github passed CI testing in this PR:
> > > https://github.com/u-boot/u-boot/pull/275
> ...
> > I went to patchwork and downloaded the series.
> > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> >
> > When I applied the patches set there were some rejections.
> > <BEGIN LOG>
> > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> >
> ...
> FAILED
> ...
> > <END LOG>
> >
> > I'm on the latest master branch (just did a git pull today). Could
> > some patches be out of order?
> >
> > Thanks,
> > Tony
>
> Well, that is because DENX mail server is broken and it crashed during
> processing antispam filter on my some of my patches. So some patches are
> missing in archive and then applying dependent patches failed.
>
> So ignore patchwork and email patches. Rather fetch changes from the
> mentioned github pull request https://github.com/u-boot/u-boot/pull/275
>
> You can do it via git command (it fetch it to the new mvebu branch):
>
>   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu

Indeed! That pull request was applied without problem.

So I did a general regression test running rebuilt kwboot binary, and
rebuilt u-boot images for these 2 Marvell boards:

Thecus N2350 (Armada 385)
Pogo V4 (Kirkwood 88F6192).

So for that part:
Tested-by: Tony Dinh <mibodhi@gmail.com>

All the best,
Tony

Re: [PATCH RFC u-boot-mvebu 19/59] tools: kwboot: Show image type and error parsing reasons

[Tony Dinh]

On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
>
> Show image type and version during parsing of kwbimage.
> And show reasons in error messages when parsing failed.
> This can help to debug issues with invalid images.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  tools/kwboot.c | 39 ++++++++++++++++++++++++++++++++++-----
>  1 file changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index cb31d5b858ce..7c666486f31f 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -1976,6 +1976,21 @@ _inject_baudrate_change_code(void *img, size_t *size, int for_data,
>         }
>  }
>
> +static const char *
> +kwboot_img_type(uint8_t blockid)
> +{
> +       switch (blockid) {
> +       case IBR_HDR_I2C_ID: return "I2C";
> +       case IBR_HDR_SPI_ID: return "SPI";
> +       case IBR_HDR_NAND_ID: return "NAND";
> +       case IBR_HDR_SATA_ID: return "SATA";
> +       case IBR_HDR_PEX_ID: return "PEX";
> +       case IBR_HDR_UART_ID: return "UART";
> +       case IBR_HDR_SDIO_ID: return "SDIO";
> +       default: return "unknown";
> +       }
> +}
> +
>  static int
>  kwboot_img_patch(void *img, size_t *size, int baudrate)
>  {
> @@ -1989,8 +2004,10 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
>
>         hdr = img;
>
> -       if (*size < sizeof(struct main_hdr_v1))
> +       if (*size < sizeof(struct main_hdr_v1)) {
> +               fprintf(stderr, "Invalid image header size\n");
>                 goto err;
> +       }
>
>         image_ver = kwbimage_version(img);
>         if (image_ver != 0 && image_ver != 1) {
> @@ -2000,12 +2017,18 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
>
>         hdrsz = kwbheader_size(hdr);
>
> -       if (*size < hdrsz)
> +       if (*size < hdrsz) {
> +               fprintf(stderr, "Invalid image header size\n");
>                 goto err;
> +       }
> +
> +       kwboot_printv("Detected kwbimage v%d with %s boot signature\n", image_ver, kwboot_img_type(hdr->blockid));
>
>         csum = kwboot_hdr_csum8(hdr) - hdr->checksum;
> -       if (csum != hdr->checksum)
> +       if (csum != hdr->checksum) {
> +               fprintf(stderr, "Image has invalid header checksum stored in image header\n");
>                 goto err;
> +       }
>
>         srcaddr = le32_to_cpu(hdr->srcaddr);
>
> @@ -2028,9 +2051,15 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
>                 break;
>         }
>
> -       if (hdrsz > le32_to_cpu(hdr->srcaddr) ||
> -           *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
> +       if (hdrsz > le32_to_cpu(hdr->srcaddr)) {
> +               fprintf(stderr, "Image has invalid data offset stored in image header\n");
> +               goto err;
> +       }
> +
> +       if (*size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize)) {
> +               fprintf(stderr, "Image has invalid data size stored in image header\n");
>                 goto err;
> +       }
>
>         for_each_opt_hdr_v1 (ohdr, hdr) {
>                 if (!opt_hdr_v1_valid_size(ohdr, (const uint8_t *)hdr + hdrsz)) {
> --
> 2.20.1
>
Nominal cases (no error) with Armada 385 and KIrkwood 6192:

Detected kwbimage v1 with SPI boot signature
Detected kwbimage v0 with NAND boot signature

Tested-by: Tony Dinh <mibodhi@gmail.com>

All the best,
Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> Hi Pali,
> 
> On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > This patch series contains various improvements and fixes for existing
> > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > Important information are included in documentation patch for kwboot.
> > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > https://github.com/u-boot/u-boot/pull/275
> > ...
> > > I went to patchwork and downloaded the series.
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > >
> > > When I applied the patches set there were some rejections.
> > > <BEGIN LOG>
> > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > >
> > ...
> > FAILED
> > ...
> > > <END LOG>
> > >
> > > I'm on the latest master branch (just did a git pull today). Could
> > > some patches be out of order?
> > >
> > > Thanks,
> > > Tony
> >
> > Well, that is because DENX mail server is broken and it crashed during
> > processing antispam filter on my some of my patches. So some patches are
> > missing in archive and then applying dependent patches failed.
> >
> > So ignore patchwork and email patches. Rather fetch changes from the
> > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> >
> > You can do it via git command (it fetch it to the new mvebu branch):
> >
> >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> 
> Indeed! That pull request was applied without problem.
> 
> So I did a general regression test running rebuilt kwboot binary, and
> rebuilt u-boot images for these 2 Marvell boards:
> 
> Thecus N2350 (Armada 385)
> Pogo V4 (Kirkwood 88F6192).
> 
> So for that part:
> Tested-by: Tony Dinh <mibodhi@gmail.com>
> 
> All the best,
> Tony

Thanks for testing! Anyway do you have some A38x board which can boot
from SD/MMC, SATA or NAND? This is what is needed to test too. I see
that Pogo boots from NAND but it does not use SPL.

Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition

[Stefan Roese]

Hi Pali,

On 2/21/23 21:18, Pali Rohár wrote:
> Support for burning into the correct eMMC HW boot partition was broken and
> removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
> this functionality and bring it back again.
> 
> Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>   cmd/mvebu/bubt.c       | 53 ++++++++++++++++++++++++++++++++++++++----
>   doc/mvebu/cmd/bubt.txt | 21 ++++++++++++-----
>   2 files changed, 63 insertions(+), 11 deletions(-)
> 
> diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
> index 2bcdf145f64a..4bad9a69527c 100644
> --- a/cmd/mvebu/bubt.c
> +++ b/cmd/mvebu/bubt.c
> @@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
>   #ifdef CONFIG_BLK
>   	struct blk_desc *blk_desc;
>   #endif
> +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> +	u8		part;
> +	u8		orig_part;
> +#endif
> +
>   	mmc = find_mmc_device(mmc_dev_num);
>   	if (!mmc) {
>   		printf("No SD/MMC/eMMC card found\n");
> @@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
>   		return err;
>   	}
>   
> +#ifdef CONFIG_BLK
> +	blk_desc = mmc_get_blk_desc(mmc);
> +	if (!blk_desc) {
> +		printf("Error - failed to obtain block descriptor\n");
> +		return -ENODEV;
> +	}
> +#endif

This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
introduce it here. Still, perhaps some of this can be moved to using
IS_ENABLED or CONFIG_IS_ENABLED instead?

And I just checked that "bubt" is not compiled for CONFIG_BLK not
defined. So please depend this file on CONFIG_BLK in Kconfig and remove
the non CONFIG_BLK code here.

Thanks,
Stefan

> +
> +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> +#ifdef CONFIG_BLK
> +	orig_part = blk_desc->hwpart;
> +#else
> +	orig_part = mmc->block_dev.hwpart;
> +#endif
> +
> +	part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> +
> +	if (part == 7)
> +		part = 0;
> +
> +#ifdef CONFIG_BLK
> +	err = blk_dselect_hwpart(blk_desc, part);
> +#else
> +	err = mmc_switch_part(mmc, part);
> +#endif
> +
> +	if (err) {
> +		printf("Error - MMC partition switch failed\n");
> +		return err;
> +	}
> +#endif
> +
>   	/* SD reserves LBA-0 for MBR and boots from LBA-1,
>   	 * MMC/eMMC boots from LBA-0
>   	 */
> @@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
>   	if (image_size % mmc->write_bl_len)
>   		blk_count += 1;
>   
> -	blk_desc = mmc_get_blk_desc(mmc);
> -	if (!blk_desc) {
> -		printf("Error - failed to obtain block descriptor\n");
> -		return -ENODEV;
> -	}
>   	blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
>   				 (void *)get_load_addr());
>   #else
> @@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
>   						 start_lba, blk_count,
>   						 (void *)get_load_addr());
>   #endif /* CONFIG_BLK */
> +
> +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> +#ifdef CONFIG_BLK
> +	err = blk_dselect_hwpart(blk_desc, orig_part);
> +#else
> +	err = mmc_switch_part(mmc, orig_part);
> +#endif
> +	if (err)
> +		printf("Error - MMC failed to switch back to original partition\n");
> +#endif
> +
>   	if (blk_written != blk_count) {
>   		printf("Error - written %#lx blocks\n", blk_written);
>   		return -ENOSPC;
> diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
> index 6051243f1165..1fe1f07dd187 100644
> --- a/doc/mvebu/cmd/bubt.txt
> +++ b/doc/mvebu/cmd/bubt.txt
> @@ -14,8 +14,7 @@ Examples:
>   
>   Notes:
>   - For the TFTP interface set serverip and ipaddr.
> -- To burn image to SD/eMMC device, the target is defined
> -  by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
> +- To burn image to SD/eMMC device, the target is defined by HW partition.
>   
>   Bubt command details (burn image step by-step)
>   ----------------------------------------------
> @@ -40,10 +39,20 @@ Notes:
>     Number 0 is used for user data partition and should not be utilized for storing
>     boot images and U-Boot environment in RAW mode since it will break file system
>     structures usually located here.
> -  The default boot partition is BOOT0. It is selected by the following parameter:
> -  CONFIG_SYS_MMC_ENV_PART=1
> -  Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
> -  Please never use partition number 0 here!
> +
> +  Currently configured boot partition can be printed by command:
> +  # mmc partconf 0
> +  (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
> +
> +  Change it to BOOT0:
> +  # mmc partconf 0 0 1 1
> +
> +  Change it to BOOT1:
> +  # mmc partconf 0 0 2 2
> +
> +  Change it to user data:
> +  # mmc partconf 0 0 7 0
> +
>   - The partition number is ignored if the target device is SD card.
>   - The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
>     The block 0 on SD devices is left for MBR storage.

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

Pali,

Good news:

A388 Clearfog Base (SD card model):
- MMC from SD card works
- UART works
- SATA with new defconfig works
- SPI (if you select MVEBU_SPL_BOOT_DEVICE_SPI yourself) works
A388 Clearfog Pro (eMMC model):
- MMC from eMMC works, but still requires the dts to be patched for
eMMC (included at bottom)

I tried eMMC both with and without the dts patched, but only the
patched version boots. I am not easily able to test the other boot
methods on the Pro, but they're the same as the Base. Let me know if
you need any extra data/outputs.

Also, the extra/updated comments with these changes are great! Thanks.

Tested-by: Martin Rowe <martin.p.rowe@gmail.com>

Martin

diff --git a/arch/arm/dts/armada-388-clearfog.dts
b/arch/arm/dts/armada-388-clearfog.dts
index e4164f49b2..29a608abcf 100644
--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -101,7 +101,7 @@

                        sdhci@d8000 {
                                bus-width = <4>;
-                               cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
+                               non-removable;
                                no-1-8-v;
                                pinctrl-0 = <&microsom_sdhci_pins
                                             &clearfog_sdhci_cd_pins>;

On Wed, 22 Feb 2023 at 07:58, Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > This patch series contains various improvements and fixes for existing
> > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > Important information are included in documentation patch for kwboot.
> > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > https://github.com/u-boot/u-boot/pull/275
> > > ...
> > > > I went to patchwork and downloaded the series.
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > >
> > > > When I applied the patches set there were some rejections.
> > > > <BEGIN LOG>
> > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > >
> > > ...
> > > FAILED
> > > ...
> > > > <END LOG>
> > > >
> > > > I'm on the latest master branch (just did a git pull today). Could
> > > > some patches be out of order?
> > > >
> > > > Thanks,
> > > > Tony
> > >
> > > Well, that is because DENX mail server is broken and it crashed during
> > > processing antispam filter on my some of my patches. So some patches are
> > > missing in archive and then applying dependent patches failed.
> > >
> > > So ignore patchwork and email patches. Rather fetch changes from the
> > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > >
> > > You can do it via git command (it fetch it to the new mvebu branch):
> > >
> > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> >
> > Indeed! That pull request was applied without problem.
> >
> > So I did a general regression test running rebuilt kwboot binary, and
> > rebuilt u-boot images for these 2 Marvell boards:
> >
> > Thecus N2350 (Armada 385)
> > Pogo V4 (Kirkwood 88F6192).
> >
> > So for that part:
> > Tested-by: Tony Dinh <mibodhi@gmail.com>
> >
> > All the best,
> > Tony
>
> Thanks for testing! Anyway do you have some A38x board which can boot
> from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> that Pogo boots from NAND but it does not use SPL.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

Hello! Thank you for testing.

On Wednesday 22 February 2023 11:59:35 Martin Rowe wrote:
> Pali,
> 
> Good news:
> 
> A388 Clearfog Base (SD card model):
> - MMC from SD card works
> - UART works
> - SATA with new defconfig works
> - SPI (if you select MVEBU_SPL_BOOT_DEVICE_SPI yourself) works

Could you send a patch which adds appropriate defconfig file for SPI
boot? So this configuration would be tested in U-Boot CI automatically.

> A388 Clearfog Pro (eMMC model):
> - MMC from eMMC works, but still requires the dts to be patched for
> eMMC (included at bottom)

Have you tried booting from eMMC boot partition or eMMC user data
partition? Because all 3 options should work, but I'm not fully sure if
BootROM choose partition from eMMC register or if tries all 3 in some
order. This is something which needs to be checked and verified.

> I tried eMMC both with and without the dts patched, but only the
> patched version boots. I am not easily able to test the other boot
> methods on the Pro, but they're the same as the Base. Let me know if
> you need any extra data/outputs.

Could you try to use SolidRun eMMC patch which SolidRun has for years in
its repository?

https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99

Probably same functionality is needed to implement also into
board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
other boards how they use CONFIG_OF_BOARD_FIXUP.

And if ... you can try to put this logic in board_late_init() function.
For inspiration look into Espressobin board which deactivates eMMC at
runtime by checking existence of eMMC:
https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c

> Also, the extra/updated comments with these changes are great! Thanks.

There is still missing documentation for kwbimage config file format.
It should be in "kwbimage" section of ./doc/mkimage.1 file but there is
only placeholder... It would be nice if somebody can take it and write
it.

> Tested-by: Martin Rowe <martin.p.rowe@gmail.com>
> 
> Martin
> 
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index e4164f49b2..29a608abcf 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -101,7 +101,7 @@
> 
>                         sdhci@d8000 {
>                                 bus-width = <4>;
> -                               cd-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
> +                               non-removable;
>                                 no-1-8-v;
>                                 pinctrl-0 = <&microsom_sdhci_pins
>                                              &clearfog_sdhci_cd_pins>;
> 
> On Wed, 22 Feb 2023 at 07:58, Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > >
> > > > > > This patch series contains various improvements and fixes for existing
> > > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > > Important information are included in documentation patch for kwboot.
> > > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > > https://github.com/u-boot/u-boot/pull/275
> > > > ...
> > > > > I went to patchwork and downloaded the series.
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > > >
> > > > > When I applied the patches set there were some rejections.
> > > > > <BEGIN LOG>
> > > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > >
> > > > ...
> > > > FAILED
> > > > ...
> > > > > <END LOG>
> > > > >
> > > > > I'm on the latest master branch (just did a git pull today). Could
> > > > > some patches be out of order?
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > >
> > > > Well, that is because DENX mail server is broken and it crashed during
> > > > processing antispam filter on my some of my patches. So some patches are
> > > > missing in archive and then applying dependent patches failed.
> > > >
> > > > So ignore patchwork and email patches. Rather fetch changes from the
> > > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > > >
> > > > You can do it via git command (it fetch it to the new mvebu branch):
> > > >
> > > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > >
> > > Indeed! That pull request was applied without problem.
> > >
> > > So I did a general regression test running rebuilt kwboot binary, and
> > > rebuilt u-boot images for these 2 Marvell boards:
> > >
> > > Thecus N2350 (Armada 385)
> > > Pogo V4 (Kirkwood 88F6192).
> > >
> > > So for that part:
> > > Tested-by: Tony Dinh <mibodhi@gmail.com>
> > >
> > > All the best,
> > > Tony
> >
> > Thanks for testing! Anyway do you have some A38x board which can boot
> > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > that Pogo boots from NAND but it does not use SPL.

Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition

[Pali Rohár]

On Wednesday 22 February 2023 10:55:54 Stefan Roese wrote:
> Hi Pali,
> 
> On 2/21/23 21:18, Pali Rohár wrote:
> > Support for burning into the correct eMMC HW boot partition was broken and
> > removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
> > this functionality and bring it back again.
> > 
> > Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > ---
> >   cmd/mvebu/bubt.c       | 53 ++++++++++++++++++++++++++++++++++++++----
> >   doc/mvebu/cmd/bubt.txt | 21 ++++++++++++-----
> >   2 files changed, 63 insertions(+), 11 deletions(-)
> > 
> > diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
> > index 2bcdf145f64a..4bad9a69527c 100644
> > --- a/cmd/mvebu/bubt.c
> > +++ b/cmd/mvebu/bubt.c
> > @@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
> >   #ifdef CONFIG_BLK
> >   	struct blk_desc *blk_desc;
> >   #endif
> > +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> > +	u8		part;
> > +	u8		orig_part;
> > +#endif
> > +
> >   	mmc = find_mmc_device(mmc_dev_num);
> >   	if (!mmc) {
> >   		printf("No SD/MMC/eMMC card found\n");
> > @@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
> >   		return err;
> >   	}
> > +#ifdef CONFIG_BLK
> > +	blk_desc = mmc_get_blk_desc(mmc);
> > +	if (!blk_desc) {
> > +		printf("Error - failed to obtain block descriptor\n");
> > +		return -ENODEV;
> > +	}
> > +#endif
> 
> This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
> introduce it here. Still, perhaps some of this can be moved to using
> IS_ENABLED or CONFIG_IS_ENABLED instead?
> 
> And I just checked that "bubt" is not compiled for CONFIG_BLK not
> defined. So please depend this file on CONFIG_BLK in Kconfig and remove
> the non CONFIG_BLK code here.

bubt is used for at least 4 different mvebu platforms (AXP, A38x, A3720,
A7K) and every one has slightly different code and configuration.

I really do not know if all those configurations support CONFIG_BLK, so
I decided to let it as it was before to eliminate possible issues.

> Thanks,
> Stefan
> 
> > +
> > +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> > +#ifdef CONFIG_BLK
> > +	orig_part = blk_desc->hwpart;
> > +#else
> > +	orig_part = mmc->block_dev.hwpart;
> > +#endif
> > +
> > +	part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> > +
> > +	if (part == 7)
> > +		part = 0;
> > +
> > +#ifdef CONFIG_BLK
> > +	err = blk_dselect_hwpart(blk_desc, part);
> > +#else
> > +	err = mmc_switch_part(mmc, part);
> > +#endif
> > +
> > +	if (err) {
> > +		printf("Error - MMC partition switch failed\n");
> > +		return err;
> > +	}
> > +#endif
> > +
> >   	/* SD reserves LBA-0 for MBR and boots from LBA-1,
> >   	 * MMC/eMMC boots from LBA-0
> >   	 */
> > @@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
> >   	if (image_size % mmc->write_bl_len)
> >   		blk_count += 1;
> > -	blk_desc = mmc_get_blk_desc(mmc);
> > -	if (!blk_desc) {
> > -		printf("Error - failed to obtain block descriptor\n");
> > -		return -ENODEV;
> > -	}
> >   	blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
> >   				 (void *)get_load_addr());
> >   #else
> > @@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
> >   						 start_lba, blk_count,
> >   						 (void *)get_load_addr());
> >   #endif /* CONFIG_BLK */
> > +
> > +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> > +#ifdef CONFIG_BLK
> > +	err = blk_dselect_hwpart(blk_desc, orig_part);
> > +#else
> > +	err = mmc_switch_part(mmc, orig_part);
> > +#endif
> > +	if (err)
> > +		printf("Error - MMC failed to switch back to original partition\n");
> > +#endif
> > +
> >   	if (blk_written != blk_count) {
> >   		printf("Error - written %#lx blocks\n", blk_written);
> >   		return -ENOSPC;
> > diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
> > index 6051243f1165..1fe1f07dd187 100644
> > --- a/doc/mvebu/cmd/bubt.txt
> > +++ b/doc/mvebu/cmd/bubt.txt
> > @@ -14,8 +14,7 @@ Examples:
> >   Notes:
> >   - For the TFTP interface set serverip and ipaddr.
> > -- To burn image to SD/eMMC device, the target is defined
> > -  by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
> > +- To burn image to SD/eMMC device, the target is defined by HW partition.
> >   Bubt command details (burn image step by-step)
> >   ----------------------------------------------
> > @@ -40,10 +39,20 @@ Notes:
> >     Number 0 is used for user data partition and should not be utilized for storing
> >     boot images and U-Boot environment in RAW mode since it will break file system
> >     structures usually located here.
> > -  The default boot partition is BOOT0. It is selected by the following parameter:
> > -  CONFIG_SYS_MMC_ENV_PART=1
> > -  Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
> > -  Please never use partition number 0 here!
> > +
> > +  Currently configured boot partition can be printed by command:
> > +  # mmc partconf 0
> > +  (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
> > +
> > +  Change it to BOOT0:
> > +  # mmc partconf 0 0 1 1
> > +
> > +  Change it to BOOT1:
> > +  # mmc partconf 0 0 2 2
> > +
> > +  Change it to user data:
> > +  # mmc partconf 0 0 7 0
> > +
> >   - The partition number is ignored if the target device is SD card.
> >   - The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
> >     The block 0 on SD devices is left for MBR storage.
> 
> 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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

Hi

> Could you send a patch which adds appropriate defconfig file for SPI
> boot? So this configuration would be tested in U-Boot CI automatically.

Will do. Does it need to be the same as the other defconfigs
otherwise? I suggest putting the environment in SPI as well if u-boot
is already there (default is MMC).

> Have you tried booting from eMMC boot partition or eMMC user data
> partition? Because all 3 options should work, but I'm not fully sure if
> BootROM choose partition from eMMC register or if tries all 3 in some
> order. This is something which needs to be checked and verified.

I only tested from boot0, but will test the others as well. I've only
ever seen it fallback, but I'll check the new changes and see if they
can select the boot device.

> Could you try to use SolidRun eMMC patch which SolidRun has for years in
> its repository?
>
> https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
>
> Probably same functionality is needed to implement also into
> board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> other boards how they use CONFIG_OF_BOARD_FIXUP.
>
> And if ... you can try to put this logic in board_late_init() function.
> For inspiration look into Espressobin board which deactivates eMMC at
> runtime by checking existence of eMMC:
> https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c

This is still on my TODO from earlier discussions.

> There is still missing documentation for kwbimage config file format.
> It should be in "kwbimage" section of ./doc/mkimage.1 file but there is
> only placeholder... It would be nice if somebody can take it and write
> it.

I'm not sure if I have the expertise for this, but can take a look as well.

Martin

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Wednesday 22 February 2023 21:20:58 Martin Rowe wrote:
> Hi
> 
> > Could you send a patch which adds appropriate defconfig file for SPI
> > boot? So this configuration would be tested in U-Boot CI automatically.
> 
> Will do. Does it need to be the same as the other defconfigs
> otherwise? I suggest putting the environment in SPI as well if u-boot
> is already there (default is MMC).

Yes, it makes sense.

> > Have you tried booting from eMMC boot partition or eMMC user data
> > partition? Because all 3 options should work, but I'm not fully sure if
> > BootROM choose partition from eMMC register or if tries all 3 in some
> > order. This is something which needs to be checked and verified.
> 
> I only tested from boot0, but will test the others as well. I've only
> ever seen it fallback, but I'll check the new changes and see if they
> can select the boot device.

Ok. When testing, ensure that you erase uboots from other partitions or
check that it boots the correct version from the correction partition.

> > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > its repository?
> >
> > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> >
> > Probably same functionality is needed to implement also into
> > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > other boards how they use CONFIG_OF_BOARD_FIXUP.
> >
> > And if ... you can try to put this logic in board_late_init() function.
> > For inspiration look into Espressobin board which deactivates eMMC at
> > runtime by checking existence of eMMC:
> > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
> 
> This is still on my TODO from earlier discussions.
> 
> > There is still missing documentation for kwbimage config file format.
> > It should be in "kwbimage" section of ./doc/mkimage.1 file but there is
> > only placeholder... It would be nice if somebody can take it and write
> > it.
> 
> I'm not sure if I have the expertise for this, but can take a look as well.
> 
> Martin

Ok.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Tony Dinh]

Hi Pali,

On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > This patch series contains various improvements and fixes for existing
> > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > Important information are included in documentation patch for kwboot.
> > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > https://github.com/u-boot/u-boot/pull/275
> > > ...
> > > > I went to patchwork and downloaded the series.
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > >
> > > > When I applied the patches set there were some rejections.
> > > > <BEGIN LOG>
> > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > >
> > > ...
> > > FAILED
> > > ...
> > > > <END LOG>
> > > >
> > > > I'm on the latest master branch (just did a git pull today). Could
> > > > some patches be out of order?
> > > >
> > > > Thanks,
> > > > Tony
> > >
> > > Well, that is because DENX mail server is broken and it crashed during
> > > processing antispam filter on my some of my patches. So some patches are
> > > missing in archive and then applying dependent patches failed.
> > >
> > > So ignore patchwork and email patches. Rather fetch changes from the
> > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > >
> > > You can do it via git command (it fetch it to the new mvebu branch):
> > >
> > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> >
> > Indeed! That pull request was applied without problem.
> >
> > So I did a general regression test running rebuilt kwboot binary, and
> > rebuilt u-boot images for these 2 Marvell boards:
> >
> > Thecus N2350 (Armada 385)
> > Pogo V4 (Kirkwood 88F6192).
> >
> > So for that part:
> > Tested-by: Tony Dinh <mibodhi@gmail.com>
> >
> > All the best,
> > Tony
>
> Thanks for testing! Anyway do you have some A38x board which can boot
> from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> that Pogo boots from NAND but it does not use SPL.

I have only one A38x board with NAND: the Thecus N2350. I am creating
a new defconfig and will see if I can boot it from the NAND flash.

By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
defined. What should it be for A38x? is it the same for Kirkwood?

All the best,
Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Wednesday 22 February 2023 14:16:36 Tony Dinh wrote:
> Hi Pali,
> 
> On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > >
> > > > > > This patch series contains various improvements and fixes for existing
> > > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > > Important information are included in documentation patch for kwboot.
> > > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > > https://github.com/u-boot/u-boot/pull/275
> > > > ...
> > > > > I went to patchwork and downloaded the series.
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > > >
> > > > > When I applied the patches set there were some rejections.
> > > > > <BEGIN LOG>
> > > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > >
> > > > ...
> > > > FAILED
> > > > ...
> > > > > <END LOG>
> > > > >
> > > > > I'm on the latest master branch (just did a git pull today). Could
> > > > > some patches be out of order?
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > >
> > > > Well, that is because DENX mail server is broken and it crashed during
> > > > processing antispam filter on my some of my patches. So some patches are
> > > > missing in archive and then applying dependent patches failed.
> > > >
> > > > So ignore patchwork and email patches. Rather fetch changes from the
> > > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > > >
> > > > You can do it via git command (it fetch it to the new mvebu branch):
> > > >
> > > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > >
> > > Indeed! That pull request was applied without problem.
> > >
> > > So I did a general regression test running rebuilt kwboot binary, and
> > > rebuilt u-boot images for these 2 Marvell boards:
> > >
> > > Thecus N2350 (Armada 385)
> > > Pogo V4 (Kirkwood 88F6192).
> > >
> > > So for that part:
> > > Tested-by: Tony Dinh <mibodhi@gmail.com>
> > >
> > > All the best,
> > > Tony
> >
> > Thanks for testing! Anyway do you have some A38x board which can boot
> > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > that Pogo boots from NAND but it does not use SPL.
> 
> I have only one A38x board with NAND: the Thecus N2350. I am creating
> a new defconfig and will see if I can boot it from the NAND flash.

Ok. And do you have some switch on this board which instruct BootROM to
really boot from NAND?

> By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
> defined. What should it be for A38x? is it the same for Kirkwood?
> 
> All the best,
> Tony

Is SYS_NAND_BASE really needed? If yet then I think it should be macro
MVEBU_NAND_BASE.

But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is
memory mapping of NAND device via mbus. On Armada devices is not NAND
device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu
registers. So I'm quite not sure if it would work.

So lets try with MVEBU_NAND_BASE.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Tony Dinh]

Hi Pali,

On Wed, Feb 22, 2023 at 3:06 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 22 February 2023 14:16:36 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > > >
> > > > > > > This patch series contains various improvements and fixes for existing
> > > > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > > > Important information are included in documentation patch for kwboot.
> > > > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > > > https://github.com/u-boot/u-boot/pull/275
> > > > > ...
> > > > > > I went to patchwork and downloaded the series.
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > > > >
> > > > > > When I applied the patches set there were some rejections.
> > > > > > <BEGIN LOG>
> > > > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > > >
> > > > > ...
> > > > > FAILED
> > > > > ...
> > > > > > <END LOG>
> > > > > >
> > > > > > I'm on the latest master branch (just did a git pull today). Could
> > > > > > some patches be out of order?
> > > > > >
> > > > > > Thanks,
> > > > > > Tony
> > > > >
> > > > > Well, that is because DENX mail server is broken and it crashed during
> > > > > processing antispam filter on my some of my patches. So some patches are
> > > > > missing in archive and then applying dependent patches failed.
> > > > >
> > > > > So ignore patchwork and email patches. Rather fetch changes from the
> > > > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > > > >
> > > > > You can do it via git command (it fetch it to the new mvebu branch):
> > > > >
> > > > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > >
> > > > Indeed! That pull request was applied without problem.
> > > >
> > > > So I did a general regression test running rebuilt kwboot binary, and
> > > > rebuilt u-boot images for these 2 Marvell boards:
> > > >
> > > > Thecus N2350 (Armada 385)
> > > > Pogo V4 (Kirkwood 88F6192).
> > > >
> > > > So for that part:
> > > > Tested-by: Tony Dinh <mibodhi@gmail.com>
> > > >
> > > > All the best,
> > > > Tony
> > >
> > > Thanks for testing! Anyway do you have some A38x board which can boot
> > > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > > that Pogo boots from NAND but it does not use SPL.
> >
> > I have only one A38x board with NAND: the Thecus N2350. I am creating
> > a new defconfig and will see if I can boot it from the NAND flash.
>
> Ok. And do you have some switch on this board which instruct BootROM to
> really boot from NAND?

No switch that I can see. So I'm going to erase the u-boot image in
SPI to let the BootROM try booting from NAND.

>
> > By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
> > defined. What should it be for A38x? is it the same for Kirkwood?
> >
> > All the best,
> > Tony
>
> Is SYS_NAND_BASE really needed? If yet then I think it should be macro
> MVEBU_NAND_BASE.

The build error looks like this:
drivers/mtd/nand/raw/nand.c:15:34: error: ‘CFG_SYS_NAND_BASE’
undeclared here (not in a function); did you mean
‘CFG_SYS_PL310_BASE’?
   15 | #define CFG_SYS_NAND_BASE_LIST { CFG_SYS_NAND_BASE }

>
> But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is
> memory mapping of NAND device via mbus. On Armada devices is not NAND
> device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu
> registers. So I'm quite not sure if it would work.
>
> So lets try with MVEBU_NAND_BASE.

OK.

Thanks,
Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Wednesday 22 February 2023 15:16:06 Tony Dinh wrote:
> Hi Pali,
> 
> On Wed, Feb 22, 2023 at 3:06 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Wednesday 22 February 2023 14:16:36 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > >
> > > > > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > > > >
> > > > > > > > This patch series contains various improvements and fixes for existing
> > > > > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > > > > Important information are included in documentation patch for kwboot.
> > > > > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > > > > https://github.com/u-boot/u-boot/pull/275
> > > > > > ...
> > > > > > > I went to patchwork and downloaded the series.
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > > > > >
> > > > > > > When I applied the patches set there were some rejections.
> > > > > > > <BEGIN LOG>
> > > > > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > > > >
> > > > > > ...
> > > > > > FAILED
> > > > > > ...
> > > > > > > <END LOG>
> > > > > > >
> > > > > > > I'm on the latest master branch (just did a git pull today). Could
> > > > > > > some patches be out of order?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Tony
> > > > > >
> > > > > > Well, that is because DENX mail server is broken and it crashed during
> > > > > > processing antispam filter on my some of my patches. So some patches are
> > > > > > missing in archive and then applying dependent patches failed.
> > > > > >
> > > > > > So ignore patchwork and email patches. Rather fetch changes from the
> > > > > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > > > > >
> > > > > > You can do it via git command (it fetch it to the new mvebu branch):
> > > > > >
> > > > > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > > >
> > > > > Indeed! That pull request was applied without problem.
> > > > >
> > > > > So I did a general regression test running rebuilt kwboot binary, and
> > > > > rebuilt u-boot images for these 2 Marvell boards:
> > > > >
> > > > > Thecus N2350 (Armada 385)
> > > > > Pogo V4 (Kirkwood 88F6192).
> > > > >
> > > > > So for that part:
> > > > > Tested-by: Tony Dinh <mibodhi@gmail.com>
> > > > >
> > > > > All the best,
> > > > > Tony
> > > >
> > > > Thanks for testing! Anyway do you have some A38x board which can boot
> > > > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > > > that Pogo boots from NAND but it does not use SPL.
> > >
> > > I have only one A38x board with NAND: the Thecus N2350. I am creating
> > > a new defconfig and will see if I can boot it from the NAND flash.
> >
> > Ok. And do you have some switch on this board which instruct BootROM to
> > really boot from NAND?
> 
> No switch that I can see. So I'm going to erase the u-boot image in
> SPI to let the BootROM try booting from NAND.

BootROM on 32-bit mvebu SoCs always boots from the location configured
by strapping pins. So if you do not have any switch (or possible
soldered zero-ohm resistors) on the board then I doubt that BootROM will
try to boot from NAND.

> >
> > > By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
> > > defined. What should it be for A38x? is it the same for Kirkwood?
> > >
> > > All the best,
> > > Tony
> >
> > Is SYS_NAND_BASE really needed? If yet then I think it should be macro
> > MVEBU_NAND_BASE.
> 
> The build error looks like this:
> drivers/mtd/nand/raw/nand.c:15:34: error: ‘CFG_SYS_NAND_BASE’
> undeclared here (not in a function); did you mean
> ‘CFG_SYS_PL310_BASE’?
>    15 | #define CFG_SYS_NAND_BASE_LIST { CFG_SYS_NAND_BASE }
> 

I see... Maybe you can try to enable SYS_NAND_SELF_INIT.

> >
> > But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is
> > memory mapping of NAND device via mbus. On Armada devices is not NAND
> > device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu
> > registers. So I'm quite not sure if it would work.
> >
> > So lets try with MVEBU_NAND_BASE.
> 
> OK.
> 
> Thanks,
> Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Tony Dinh]

Hi Pali,

On Wed, Feb 22, 2023 at 3:40 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 22 February 2023 15:16:06 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Wed, Feb 22, 2023 at 3:06 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Wednesday 22 February 2023 14:16:36 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > > >
> > > > > > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > > > > >
> > > > > > > > > This patch series contains various improvements and fixes for existing
> > > > > > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > > > > > Important information are included in documentation patch for kwboot.
> > > > > > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > > > > > https://github.com/u-boot/u-boot/pull/275
> > > > > > > ...
> > > > > > > > I went to patchwork and downloaded the series.
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > > > > > >
> > > > > > > > When I applied the patches set there were some rejections.
> > > > > > > > <BEGIN LOG>
> > > > > > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > > > > >
> > > > > > > ...
> > > > > > > FAILED
> > > > > > > ...
> > > > > > > > <END LOG>
> > > > > > > >
> > > > > > > > I'm on the latest master branch (just did a git pull today). Could
> > > > > > > > some patches be out of order?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Tony
> > > > > > >
> > > > > > > Well, that is because DENX mail server is broken and it crashed during
> > > > > > > processing antispam filter on my some of my patches. So some patches are
> > > > > > > missing in archive and then applying dependent patches failed.
> > > > > > >
> > > > > > > So ignore patchwork and email patches. Rather fetch changes from the
> > > > > > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > > > > > >
> > > > > > > You can do it via git command (it fetch it to the new mvebu branch):
> > > > > > >
> > > > > > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > > > >
> > > > > > Indeed! That pull request was applied without problem.
> > > > > >
> > > > > > So I did a general regression test running rebuilt kwboot binary, and
> > > > > > rebuilt u-boot images for these 2 Marvell boards:
> > > > > >
> > > > > > Thecus N2350 (Armada 385)
> > > > > > Pogo V4 (Kirkwood 88F6192).
> > > > > >
> > > > > > So for that part:
> > > > > > Tested-by: Tony Dinh <mibodhi@gmail.com>
> > > > > >
> > > > > > All the best,
> > > > > > Tony
> > > > >
> > > > > Thanks for testing! Anyway do you have some A38x board which can boot
> > > > > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > > > > that Pogo boots from NAND but it does not use SPL.
> > > >
> > > > I have only one A38x board with NAND: the Thecus N2350. I am creating
> > > > a new defconfig and will see if I can boot it from the NAND flash.
> > >
> > > Ok. And do you have some switch on this board which instruct BootROM to
> > > really boot from NAND?
> >
> > No switch that I can see. So I'm going to erase the u-boot image in
> > SPI to let the BootROM try booting from NAND.
>
> BootROM on 32-bit mvebu SoCs always boots from the location configured
> by strapping pins. So if you do not have any switch (or possible
> soldered zero-ohm resistors) on the board then I doubt that BootROM will
> try to boot from NAND.
>
Argh! I misremember that boot flow, it must have been for another SoC.
Then I guess I have to look at the board again to see if there is any
jumper/switch... Perhaps the other way is to run in the BootROM
debugging prompt and set the boot device to NAND?

> > >
> > > > By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
> > > > defined. What should it be for A38x? is it the same for Kirkwood?
> > > >
> > > > All the best,
> > > > Tony
> > >
> > > Is SYS_NAND_BASE really needed? If yet then I think it should be macro
> > > MVEBU_NAND_BASE.
> >
> > The build error looks like this:
> > drivers/mtd/nand/raw/nand.c:15:34: error: ‘CFG_SYS_NAND_BASE’
> > undeclared here (not in a function); did you mean
> > ‘CFG_SYS_PL310_BASE’?
> >    15 | #define CFG_SYS_NAND_BASE_LIST { CFG_SYS_NAND_BASE }
> >
>
> I see... Maybe you can try to enable SYS_NAND_SELF_INIT.

Thanks, that was it. I did configure the board incorrectly :) I need
CONFIG_NAND_PXA3XX which selects SYS_NAND_SELF_INIT.

Thanks,
Tony

> > >
> > > But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is
> > > memory mapping of NAND device via mbus. On Armada devices is not NAND
> > > device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu
> > > registers. So I'm quite not sure if it would work.
> > >
> > > So lets try with MVEBU_NAND_BASE.
> >
> > OK.
> >
> > Thanks,
> > Tony

Re: [PATCH RFC u-boot-mvebu 15/59] tools: kwboot: Fix parsing UART image without data checksum

[Tony Dinh]

Hi Pali,

On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
>
> The 32-bit data checksum in UART image is not checked by the BootROM and
> also Marvell tools do not generate it.
>
> So if data checksum stored in UART image does not match calculated checksum
> from the image then treat those checksum bytes as part of the executable
> image code (and not as the checksum) and for compatibility with the rest of
> the code manually insert data checksum into the in-memory image after the
> executable code, without overwriting it.
>
> This should allow to boot UART images generated by Marvell tools.

Tested with GTI Mirabox (Armada 370). Using the stock u-boot image
from NAND mtd0 (nanddump), I've modified the u-boot CONFIG_SYS_PROMPT
text using hexedit. The image checksum should be invalid after that.
New kwboot booted it without problem.

Tested-by: Tony Dinh <mibodhi@gmail.com>

Thanks,
Tony

>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  tools/kwboot.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index 7a7dd5bf3d7b..da840864b565 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -1990,8 +1990,18 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
>             *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
>                 goto err;
>
> -       if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img))
> -               goto err;
> +       /*
> +        * The 32-bit data checksum is optional for UART image. If it is not
> +        * present (checksum detected as invalid) then grow data part of the
> +        * image for the checksum, so it can be inserted there.
> +        */
> +       if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img)) {
> +               if (hdr->blockid != IBR_HDR_UART_ID) {
> +                       fprintf(stderr, "Image has invalid data checksum\n");
> +                       goto err;
> +               }
> +               kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
> +       }
>
>         is_secure = kwboot_img_is_secure(img);
>
> @@ -2256,6 +2266,7 @@ main(int argc, char **argv)
>                                  KWBOOT_XM_BLKSZ +
>                                  sizeof(kwboot_baud_code) +
>                                  sizeof(kwboot_baud_code_data_jump) +
> +                                sizeof(uint32_t) +
>                                  KWBOOT_XM_BLKSZ;
>
>         if (imgpath) {
> --
> 2.20.1
>

Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition

[Stefan Roese]

Hi Pali,

On 2/22/23 19:06, Pali Rohár wrote:
> On Wednesday 22 February 2023 10:55:54 Stefan Roese wrote:
>> Hi Pali,
>>
>> On 2/21/23 21:18, Pali Rohár wrote:
>>> Support for burning into the correct eMMC HW boot partition was broken and
>>> removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
>>> this functionality and bring it back again.
>>>
>>> Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
>>> Signed-off-by: Pali Rohár <pali@kernel.org>
>>> ---
>>>    cmd/mvebu/bubt.c       | 53 ++++++++++++++++++++++++++++++++++++++----
>>>    doc/mvebu/cmd/bubt.txt | 21 ++++++++++++-----
>>>    2 files changed, 63 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
>>> index 2bcdf145f64a..4bad9a69527c 100644
>>> --- a/cmd/mvebu/bubt.c
>>> +++ b/cmd/mvebu/bubt.c
>>> @@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
>>>    #ifdef CONFIG_BLK
>>>    	struct blk_desc *blk_desc;
>>>    #endif
>>> +#ifdef CONFIG_SUPPORT_EMMC_BOOT
>>> +	u8		part;
>>> +	u8		orig_part;
>>> +#endif
>>> +
>>>    	mmc = find_mmc_device(mmc_dev_num);
>>>    	if (!mmc) {
>>>    		printf("No SD/MMC/eMMC card found\n");
>>> @@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
>>>    		return err;
>>>    	}
>>> +#ifdef CONFIG_BLK
>>> +	blk_desc = mmc_get_blk_desc(mmc);
>>> +	if (!blk_desc) {
>>> +		printf("Error - failed to obtain block descriptor\n");
>>> +		return -ENODEV;
>>> +	}
>>> +#endif
>>
>> This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
>> introduce it here. Still, perhaps some of this can be moved to using
>> IS_ENABLED or CONFIG_IS_ENABLED instead?
>>
>> And I just checked that "bubt" is not compiled for CONFIG_BLK not
>> defined. So please depend this file on CONFIG_BLK in Kconfig and remove
>> the non CONFIG_BLK code here.
> 
> bubt is used for at least 4 different mvebu platforms (AXP, A38x, A3720,
> A7K) and every one has slightly different code and configuration.
> 
> I really do not know if all those configurations support CONFIG_BLK, so
> I decided to let it as it was before to eliminate possible issues.

As mentioned above, I've checked this myself before sending the
suggestion yesterday. No platform compiling this cmd has CONFIG_BLK
disabled.

My understanding is that CONFIG_BLK will be required at some time and
all non CONFIG_BLK code will get dropped.

Still, if you feel you don't want to make this change, as it's not
really related to your current patchset, then this is no showstopper.

Thanks,
Stefan

>> Thanks,
>> Stefan
>>
>>> +
>>> +#ifdef CONFIG_SUPPORT_EMMC_BOOT
>>> +#ifdef CONFIG_BLK
>>> +	orig_part = blk_desc->hwpart;
>>> +#else
>>> +	orig_part = mmc->block_dev.hwpart;
>>> +#endif
>>> +
>>> +	part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
>>> +
>>> +	if (part == 7)
>>> +		part = 0;
>>> +
>>> +#ifdef CONFIG_BLK
>>> +	err = blk_dselect_hwpart(blk_desc, part);
>>> +#else
>>> +	err = mmc_switch_part(mmc, part);
>>> +#endif
>>> +
>>> +	if (err) {
>>> +		printf("Error - MMC partition switch failed\n");
>>> +		return err;
>>> +	}
>>> +#endif
>>> +
>>>    	/* SD reserves LBA-0 for MBR and boots from LBA-1,
>>>    	 * MMC/eMMC boots from LBA-0
>>>    	 */
>>> @@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
>>>    	if (image_size % mmc->write_bl_len)
>>>    		blk_count += 1;
>>> -	blk_desc = mmc_get_blk_desc(mmc);
>>> -	if (!blk_desc) {
>>> -		printf("Error - failed to obtain block descriptor\n");
>>> -		return -ENODEV;
>>> -	}
>>>    	blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
>>>    				 (void *)get_load_addr());
>>>    #else
>>> @@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
>>>    						 start_lba, blk_count,
>>>    						 (void *)get_load_addr());
>>>    #endif /* CONFIG_BLK */
>>> +
>>> +#ifdef CONFIG_SUPPORT_EMMC_BOOT
>>> +#ifdef CONFIG_BLK
>>> +	err = blk_dselect_hwpart(blk_desc, orig_part);
>>> +#else
>>> +	err = mmc_switch_part(mmc, orig_part);
>>> +#endif
>>> +	if (err)
>>> +		printf("Error - MMC failed to switch back to original partition\n");
>>> +#endif
>>> +
>>>    	if (blk_written != blk_count) {
>>>    		printf("Error - written %#lx blocks\n", blk_written);
>>>    		return -ENOSPC;
>>> diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
>>> index 6051243f1165..1fe1f07dd187 100644
>>> --- a/doc/mvebu/cmd/bubt.txt
>>> +++ b/doc/mvebu/cmd/bubt.txt
>>> @@ -14,8 +14,7 @@ Examples:
>>>    Notes:
>>>    - For the TFTP interface set serverip and ipaddr.
>>> -- To burn image to SD/eMMC device, the target is defined
>>> -  by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
>>> +- To burn image to SD/eMMC device, the target is defined by HW partition.
>>>    Bubt command details (burn image step by-step)
>>>    ----------------------------------------------
>>> @@ -40,10 +39,20 @@ Notes:
>>>      Number 0 is used for user data partition and should not be utilized for storing
>>>      boot images and U-Boot environment in RAW mode since it will break file system
>>>      structures usually located here.
>>> -  The default boot partition is BOOT0. It is selected by the following parameter:
>>> -  CONFIG_SYS_MMC_ENV_PART=1
>>> -  Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
>>> -  Please never use partition number 0 here!
>>> +
>>> +  Currently configured boot partition can be printed by command:
>>> +  # mmc partconf 0
>>> +  (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
>>> +
>>> +  Change it to BOOT0:
>>> +  # mmc partconf 0 0 1 1
>>> +
>>> +  Change it to BOOT1:
>>> +  # mmc partconf 0 0 2 2
>>> +
>>> +  Change it to user data:
>>> +  # mmc partconf 0 0 7 0
>>> +
>>>    - The partition number is ignored if the target device is SD card.
>>>    - The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
>>>      The block 0 on SD devices is left for MBR storage.
>>
>> 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

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Wednesday 22 February 2023 16:17:32 Tony Dinh wrote:
> Hi Pali,
> 
> On Wed, Feb 22, 2023 at 3:40 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Wednesday 22 February 2023 15:16:06 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Wed, Feb 22, 2023 at 3:06 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Wednesday 22 February 2023 14:16:36 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > >
> > > > > > On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote:
> > > > > > > > > Hi Pali,
> > > > > > > > >
> > > > > > > > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > This patch series contains various improvements and fixes for existing
> > > > > > > > > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > > > > > > > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > > > > > > > > Important information are included in documentation patch for kwboot.
> > > > > > > > > > Most of the changes are untested, hence this patch series is just RFC.
> > > > > > > > > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > > > > > > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > > > > > > https://github.com/u-boot/u-boot/pull/275
> > > > > > > > ...
> > > > > > > > > I went to patchwork and downloaded the series.
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@kernel.org
> > > > > > > > >
> > > > > > > > > When I applied the patches set there were some rejections.
> > > > > > > > > <BEGIN LOG>
> > > > > > > > > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > > > > > >
> > > > > > > > ...
> > > > > > > > FAILED
> > > > > > > > ...
> > > > > > > > > <END LOG>
> > > > > > > > >
> > > > > > > > > I'm on the latest master branch (just did a git pull today). Could
> > > > > > > > > some patches be out of order?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Tony
> > > > > > > >
> > > > > > > > Well, that is because DENX mail server is broken and it crashed during
> > > > > > > > processing antispam filter on my some of my patches. So some patches are
> > > > > > > > missing in archive and then applying dependent patches failed.
> > > > > > > >
> > > > > > > > So ignore patchwork and email patches. Rather fetch changes from the
> > > > > > > > mentioned github pull request https://github.com/u-boot/u-boot/pull/275
> > > > > > > >
> > > > > > > > You can do it via git command (it fetch it to the new mvebu branch):
> > > > > > > >
> > > > > > > >   git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > > > > >
> > > > > > > Indeed! That pull request was applied without problem.
> > > > > > >
> > > > > > > So I did a general regression test running rebuilt kwboot binary, and
> > > > > > > rebuilt u-boot images for these 2 Marvell boards:
> > > > > > >
> > > > > > > Thecus N2350 (Armada 385)
> > > > > > > Pogo V4 (Kirkwood 88F6192).
> > > > > > >
> > > > > > > So for that part:
> > > > > > > Tested-by: Tony Dinh <mibodhi@gmail.com>
> > > > > > >
> > > > > > > All the best,
> > > > > > > Tony
> > > > > >
> > > > > > Thanks for testing! Anyway do you have some A38x board which can boot
> > > > > > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > > > > > that Pogo boots from NAND but it does not use SPL.
> > > > >
> > > > > I have only one A38x board with NAND: the Thecus N2350. I am creating
> > > > > a new defconfig and will see if I can boot it from the NAND flash.
> > > >
> > > > Ok. And do you have some switch on this board which instruct BootROM to
> > > > really boot from NAND?
> > >
> > > No switch that I can see. So I'm going to erase the u-boot image in
> > > SPI to let the BootROM try booting from NAND.
> >
> > BootROM on 32-bit mvebu SoCs always boots from the location configured
> > by strapping pins. So if you do not have any switch (or possible
> > soldered zero-ohm resistors) on the board then I doubt that BootROM will
> > try to boot from NAND.
> >
> Argh! I misremember that boot flow, it must have been for another SoC.
> Then I guess I have to look at the board again to see if there is any
> jumper/switch... Perhaps the other way is to run in the BootROM
> debugging prompt and set the boot device to NAND?

Hm... You can try it. But when I tried on A385 to set boot device to
SPI-NOR from debugging prompt it did not work and I suspect bug in
BootROM. But maybe setting boot device to NAND would work. Who knows.

> > > >
> > > > > By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
> > > > > defined. What should it be for A38x? is it the same for Kirkwood?
> > > > >
> > > > > All the best,
> > > > > Tony
> > > >
> > > > Is SYS_NAND_BASE really needed? If yet then I think it should be macro
> > > > MVEBU_NAND_BASE.
> > >
> > > The build error looks like this:
> > > drivers/mtd/nand/raw/nand.c:15:34: error: ‘CFG_SYS_NAND_BASE’
> > > undeclared here (not in a function); did you mean
> > > ‘CFG_SYS_PL310_BASE’?
> > >    15 | #define CFG_SYS_NAND_BASE_LIST { CFG_SYS_NAND_BASE }
> > >
> >
> > I see... Maybe you can try to enable SYS_NAND_SELF_INIT.
> 
> Thanks, that was it. I did configure the board incorrectly :) I need
> CONFIG_NAND_PXA3XX which selects SYS_NAND_SELF_INIT.

Perfect! Anyway for booting from NAND you do not have CONFIG_NAND_PXA3XX
support. You need CONFIG_NAND_PXA3XX if you want to access NAND from
u-boot (e.g. for writing bootloder there; so you need it at least once).

> Thanks,
> Tony
> 
> > > >
> > > > But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is
> > > > memory mapping of NAND device via mbus. On Armada devices is not NAND
> > > > device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu
> > > > registers. So I'm quite not sure if it would work.
> > > >
> > > > So lets try with MVEBU_NAND_BASE.
> > >
> > > OK.
> > >
> > > Thanks,
> > > Tony

Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition

[Pali Rohár]

On Thursday 23 February 2023 07:17:26 Stefan Roese wrote:
> Hi Pali,
> 
> On 2/22/23 19:06, Pali Rohár wrote:
> > On Wednesday 22 February 2023 10:55:54 Stefan Roese wrote:
> > > Hi Pali,
> > > 
> > > On 2/21/23 21:18, Pali Rohár wrote:
> > > > Support for burning into the correct eMMC HW boot partition was broken and
> > > > removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
> > > > this functionality and bring it back again.
> > > > 
> > > > Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > ---
> > > >    cmd/mvebu/bubt.c       | 53 ++++++++++++++++++++++++++++++++++++++----
> > > >    doc/mvebu/cmd/bubt.txt | 21 ++++++++++++-----
> > > >    2 files changed, 63 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
> > > > index 2bcdf145f64a..4bad9a69527c 100644
> > > > --- a/cmd/mvebu/bubt.c
> > > > +++ b/cmd/mvebu/bubt.c
> > > > @@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
> > > >    #ifdef CONFIG_BLK
> > > >    	struct blk_desc *blk_desc;
> > > >    #endif
> > > > +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> > > > +	u8		part;
> > > > +	u8		orig_part;
> > > > +#endif
> > > > +
> > > >    	mmc = find_mmc_device(mmc_dev_num);
> > > >    	if (!mmc) {
> > > >    		printf("No SD/MMC/eMMC card found\n");
> > > > @@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
> > > >    		return err;
> > > >    	}
> > > > +#ifdef CONFIG_BLK
> > > > +	blk_desc = mmc_get_blk_desc(mmc);
> > > > +	if (!blk_desc) {
> > > > +		printf("Error - failed to obtain block descriptor\n");
> > > > +		return -ENODEV;
> > > > +	}
> > > > +#endif
> > > 
> > > This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
> > > introduce it here. Still, perhaps some of this can be moved to using
> > > IS_ENABLED or CONFIG_IS_ENABLED instead?
> > > 
> > > And I just checked that "bubt" is not compiled for CONFIG_BLK not
> > > defined. So please depend this file on CONFIG_BLK in Kconfig and remove
> > > the non CONFIG_BLK code here.
> > 
> > bubt is used for at least 4 different mvebu platforms (AXP, A38x, A3720,
> > A7K) and every one has slightly different code and configuration.
> > 
> > I really do not know if all those configurations support CONFIG_BLK, so
> > I decided to let it as it was before to eliminate possible issues.
> 
> As mentioned above, I've checked this myself before sending the
> suggestion yesterday. No platform compiling this cmd has CONFIG_BLK
> disabled.

OK! In this case I would rather send an additional cleanup patch which
removes usage of non-CONFIG_BLK code from the whole command. As it does
not make sense to not-have it in MMC and have it in SATA.

> My understanding is that CONFIG_BLK will be required at some time and
> all non CONFIG_BLK code will get dropped.
> 
> Still, if you feel you don't want to make this change, as it's not
> really related to your current patchset, then this is no showstopper.
> 
> Thanks,
> Stefan
> 
> > > Thanks,
> > > Stefan
> > > 
> > > > +
> > > > +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> > > > +#ifdef CONFIG_BLK
> > > > +	orig_part = blk_desc->hwpart;
> > > > +#else
> > > > +	orig_part = mmc->block_dev.hwpart;
> > > > +#endif
> > > > +
> > > > +	part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> > > > +
> > > > +	if (part == 7)
> > > > +		part = 0;
> > > > +
> > > > +#ifdef CONFIG_BLK
> > > > +	err = blk_dselect_hwpart(blk_desc, part);
> > > > +#else
> > > > +	err = mmc_switch_part(mmc, part);
> > > > +#endif
> > > > +
> > > > +	if (err) {
> > > > +		printf("Error - MMC partition switch failed\n");
> > > > +		return err;
> > > > +	}
> > > > +#endif
> > > > +
> > > >    	/* SD reserves LBA-0 for MBR and boots from LBA-1,
> > > >    	 * MMC/eMMC boots from LBA-0
> > > >    	 */
> > > > @@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
> > > >    	if (image_size % mmc->write_bl_len)
> > > >    		blk_count += 1;
> > > > -	blk_desc = mmc_get_blk_desc(mmc);
> > > > -	if (!blk_desc) {
> > > > -		printf("Error - failed to obtain block descriptor\n");
> > > > -		return -ENODEV;
> > > > -	}
> > > >    	blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
> > > >    				 (void *)get_load_addr());
> > > >    #else
> > > > @@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
> > > >    						 start_lba, blk_count,
> > > >    						 (void *)get_load_addr());
> > > >    #endif /* CONFIG_BLK */
> > > > +
> > > > +#ifdef CONFIG_SUPPORT_EMMC_BOOT
> > > > +#ifdef CONFIG_BLK
> > > > +	err = blk_dselect_hwpart(blk_desc, orig_part);
> > > > +#else
> > > > +	err = mmc_switch_part(mmc, orig_part);
> > > > +#endif
> > > > +	if (err)
> > > > +		printf("Error - MMC failed to switch back to original partition\n");
> > > > +#endif
> > > > +
> > > >    	if (blk_written != blk_count) {
> > > >    		printf("Error - written %#lx blocks\n", blk_written);
> > > >    		return -ENOSPC;
> > > > diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
> > > > index 6051243f1165..1fe1f07dd187 100644
> > > > --- a/doc/mvebu/cmd/bubt.txt
> > > > +++ b/doc/mvebu/cmd/bubt.txt
> > > > @@ -14,8 +14,7 @@ Examples:
> > > >    Notes:
> > > >    - For the TFTP interface set serverip and ipaddr.
> > > > -- To burn image to SD/eMMC device, the target is defined
> > > > -  by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
> > > > +- To burn image to SD/eMMC device, the target is defined by HW partition.
> > > >    Bubt command details (burn image step by-step)
> > > >    ----------------------------------------------
> > > > @@ -40,10 +39,20 @@ Notes:
> > > >      Number 0 is used for user data partition and should not be utilized for storing
> > > >      boot images and U-Boot environment in RAW mode since it will break file system
> > > >      structures usually located here.
> > > > -  The default boot partition is BOOT0. It is selected by the following parameter:
> > > > -  CONFIG_SYS_MMC_ENV_PART=1
> > > > -  Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
> > > > -  Please never use partition number 0 here!
> > > > +
> > > > +  Currently configured boot partition can be printed by command:
> > > > +  # mmc partconf 0
> > > > +  (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
> > > > +
> > > > +  Change it to BOOT0:
> > > > +  # mmc partconf 0 0 1 1
> > > > +
> > > > +  Change it to BOOT1:
> > > > +  # mmc partconf 0 0 2 2
> > > > +
> > > > +  Change it to user data:
> > > > +  # mmc partconf 0 0 7 0
> > > > +
> > > >    - The partition number is ignored if the target device is SD card.
> > > >    - The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
> > > >      The block 0 on SD devices is left for MBR storage.
> > > 
> > > 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
> 
> 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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Wednesday 22 February 2023 11:59:35 Martin Rowe wrote:
> A388 Clearfog Base (SD card model):
> - MMC from SD card works
> - UART works
> - SATA with new defconfig works
> - SPI (if you select MVEBU_SPL_BOOT_DEVICE_SPI yourself) works
> A388 Clearfog Pro (eMMC model):
> - MMC from eMMC works, but still requires the dts to be patched for
> eMMC (included at bottom)

Could you test also bubt command for upgrading u-boot on all those
variants? So to ensure that upgrading u-boot would work correctly.

Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition

[Stefan Roese]

Hi Pali,

On 2/23/23 08:55, Pali Rohár wrote:

<snip>

>>>> This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
>>>> introduce it here. Still, perhaps some of this can be moved to using
>>>> IS_ENABLED or CONFIG_IS_ENABLED instead?
>>>>
>>>> And I just checked that "bubt" is not compiled for CONFIG_BLK not
>>>> defined. So please depend this file on CONFIG_BLK in Kconfig and remove
>>>> the non CONFIG_BLK code here.
>>>
>>> bubt is used for at least 4 different mvebu platforms (AXP, A38x, A3720,
>>> A7K) and every one has slightly different code and configuration.
>>>
>>> I really do not know if all those configurations support CONFIG_BLK, so
>>> I decided to let it as it was before to eliminate possible issues.
>>
>> As mentioned above, I've checked this myself before sending the
>> suggestion yesterday. No platform compiling this cmd has CONFIG_BLK
>> disabled.
> 
> OK! In this case I would rather send an additional cleanup patch which
> removes usage of non-CONFIG_BLK code from the whole command. As it does
> not make sense to not-have it in MMC and have it in SATA.

Handling this via a follow-up patch is even better. Thanks for working
on this.

Thanks,
Stefan

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

> > > Have you tried booting from eMMC boot partition or eMMC user data
> > > partition? Because all 3 options should work, but I'm not fully sure if
> > > BootROM choose partition from eMMC register or if tries all 3 in some
> > > order. This is something which needs to be checked and verified.
> >
> > I only tested from boot0, but will test the others as well. I've only
> > ever seen it fallback, but I'll check the new changes and see if they
> > can select the boot device.
>
> Ok. When testing, ensure that you erase uboots from other partitions or
> check that it boots the correct version from the correction partition.

BootROM always tries boot0, boot1, then user, regardless of partconf
setting. SPL does use the partconf setting, though. So when I
configure:
boot0 - zeroed
boot1 - u-boot (with local version 'boot1')
user - u-boot (with local version 'user')
mmc partconf 0 0 7 0
I see the output below. Note that BootROM tries boot0 first with two
addresses, switches to boot1 (see 'boot1' following 2023.04-rc2),
loads SPL, which then loads u-boot from user (see 'user' following
2023.04-rc2)
=================================================
BootROM - 1.73

Booting from MMC
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.

U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 -
19:43:59 +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 MMC1


U-Boot 2023.04-rc2user-00098-g93408c61cd-dirty (Feb 23 2023 - 19:44:54 +1000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
Core:  38 devices, 22 uclasses, devicetree: separate
MMC:   mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Model: SolidRun Clearfog A1
Board: SolidRun Clearfog Pro
Net:
Warning: ethernet@70000 (eth1) using random MAC address - ae:50:98:34:2e:3e
eth1: ethernet@70000
Warning: ethernet@30000 (eth2) using random MAC address - 0a:66:2b:f7:45:09
, eth2: ethernet@30000
Warning: ethernet@34000 (eth3) using random MAC address - d2:8e:11:7e:64:c0
, eth3: ethernet@34000
Hit any key to stop autoboot:  0
=>
=================================================

> > > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > > its repository?
> > >
> > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> > >
> > > Probably same functionality is needed to implement also into
> > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > > other boards how they use CONFIG_OF_BOARD_FIXUP.
> > >
> > > And if ... you can try to put this logic in board_late_init() function.
> > > For inspiration look into Espressobin board which deactivates eMMC at
> > > runtime by checking existence of eMMC:
> > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c

I've not been able to get this to work. I enable CONFIG_OF_BOARD_FIXUP
in my config and add the following to
board/solidrun/clearfog/clearfog.c:
+int board_fix_fdt(void *blob)
+       {
+       int offset;
+       offset = fdt_path_offset(blob, "/soc/internal-regs/sdhci@d8000");
+       if (offset >= 0) {
+               printf("offset");
+               fdt_delprop(blob, offset, "cd-gpios");
+               fdt_setprop_empty(blob, offset, "non-removable");
+       }
+       return 0;
+}
Then I boot from MMC and get the following:
=================================================
BootROM - 1.73

Booting from MMC

U-Boot SPL 2023.04-rc2-00098-g93408c61cd-dirty (Feb 23 2023 - 21:32:01 +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 MMC1
MMC: no card present
spl: mmc init failed with error: -123
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
BootROM: Image checksum verification FAILED
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
BootROM: Invalid header checksum
Switching BootPartitions.
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
BootROM: Invalid header checksum
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
sdioSdhciSendCmd: Timeout for status update!
BootROM: Invalid header checksum
Switching BootPartitions.
=================================================
This is exactly the same error as I get without the board_fix_fdt
change. I tried adding some printfs and returning 1 from the function,
but I can't see any evidence that it is getting called in the SPL at
all. I also see that SolidRun has dropped the patch you linked to in
newer a38x branches, but can't see how else they're handling the eMMC
detection.

I could wrap the dts change with a kconfig, but anyone enabling that
kconfig would also need to patch the kernel dtb, unless u-boot has a
hook to patch the file before passing it to the kernel.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Thursday 23 February 2023 12:11:46 Martin Rowe wrote:
> > > > Have you tried booting from eMMC boot partition or eMMC user data
> > > > partition? Because all 3 options should work, but I'm not fully sure if
> > > > BootROM choose partition from eMMC register or if tries all 3 in some
> > > > order. This is something which needs to be checked and verified.
> > >
> > > I only tested from boot0, but will test the others as well. I've only
> > > ever seen it fallback, but I'll check the new changes and see if they
> > > can select the boot device.
> >
> > Ok. When testing, ensure that you erase uboots from other partitions or
> > check that it boots the correct version from the correction partition.
> 
> BootROM always tries boot0, boot1, then user, regardless of partconf
> setting. SPL does use the partconf setting, though. So when I
> configure:
> boot0 - zeroed
> boot1 - u-boot (with local version 'boot1')
> user - u-boot (with local version 'user')
> mmc partconf 0 0 7 0
> I see the output below. Note that BootROM tries boot0 first with two
> addresses, switches to boot1 (see 'boot1' following 2023.04-rc2),
> loads SPL, which then loads u-boot from user (see 'user' following
> 2023.04-rc2)

Ok, I was not sure how that bootrom is choosing initial partition as I
have not fully understood bootrom mmc code. So from this it looks like
that bootrom ignores MMC EXT_CSD[179] register, try booting from BOOT0
and then it really switch to the next partition. (My understanding of
that bootrom binary was that "Switching BootPartitions." does nothing.)

Can you check if boot_ack argument has some effect on the initial
choice? Or if completely disabling boot partitions (boot_enable to 0)
have some effect?

If really EXT_CSD[179] register is completely ignored we may change SPL
to always boot from BOOT0 (when eMMC with boot partitions is used) and
if it fails then fallback to BootROM booting.

> =================================================
> BootROM - 1.73
> 
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> 
> U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 -
> 19:43:59 +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 MMC1
> 
> 
> U-Boot 2023.04-rc2user-00098-g93408c61cd-dirty (Feb 23 2023 - 19:44:54 +1000)
> 
> SoC:   MV88F6828-A0 at 1600 MHz
> DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> Core:  38 devices, 22 uclasses, devicetree: separate
> MMC:   mv_sdh: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> Model: SolidRun Clearfog A1
> Board: SolidRun Clearfog Pro
> Net:
> Warning: ethernet@70000 (eth1) using random MAC address - ae:50:98:34:2e:3e
> eth1: ethernet@70000
> Warning: ethernet@30000 (eth2) using random MAC address - 0a:66:2b:f7:45:09
> , eth2: ethernet@30000
> Warning: ethernet@34000 (eth3) using random MAC address - d2:8e:11:7e:64:c0
> , eth3: ethernet@34000
> Hit any key to stop autoboot:  0
> =>
> =================================================
> 
> > > > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > > > its repository?
> > > >
> > > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> > > >
> > > > Probably same functionality is needed to implement also into
> > > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > > > other boards how they use CONFIG_OF_BOARD_FIXUP.
> > > >
> > > > And if ... you can try to put this logic in board_late_init() function.
> > > > For inspiration look into Espressobin board which deactivates eMMC at
> > > > runtime by checking existence of eMMC:
> > > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
> 
> I've not been able to get this to work. I enable CONFIG_OF_BOARD_FIXUP
> in my config and add the following to
> board/solidrun/clearfog/clearfog.c:
> +int board_fix_fdt(void *blob)
> +       {
> +       int offset;
> +       offset = fdt_path_offset(blob, "/soc/internal-regs/sdhci@d8000");
> +       if (offset >= 0) {
> +               printf("offset");
> +               fdt_delprop(blob, offset, "cd-gpios");
> +               fdt_setprop_empty(blob, offset, "non-removable");
> +       }
> +       return 0;
> +}
> Then I boot from MMC and get the following:
> =================================================
> BootROM - 1.73
> 
> Booting from MMC
> 
> U-Boot SPL 2023.04-rc2-00098-g93408c61cd-dirty (Feb 23 2023 - 21:32:01 +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 MMC1
> MMC: no card present
> spl: mmc init failed with error: -123
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...

After this line, SPL give control to the BootROM...

> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Image checksum verification FAILED
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Invalid header checksum
> Switching BootPartitions.
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Invalid header checksum
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> sdioSdhciSendCmd: Timeout for status update!
> BootROM: Invalid header checksum
> Switching BootPartitions.

...and bootrom tried to load main U-Boot. But apparently SPL
reconfigured MMC controller in such way that it cannot access eMMC
anymore.

Seems that something in mmc initialization code is buggy. You can try to
debug it by starting disabling parts of initialization code until you
find the line/function which makes those BootROM messages "Timeout for
status update!".

> =================================================
> This is exactly the same error as I get without the board_fix_fdt
> change. I tried adding some printfs and returning 1 from the function,
> but I can't see any evidence that it is getting called in the SPL at
> all.

Hm... Yes, "offset" string is not in your output, so that function is
not called in SPL. Only in main U-Boot.

What is in SPL called is board_early_init_f() function or
fdtdec_board_setup() function or also board_late_init() function.
Pointer to blob is in global variable gd->fdt_blob.

Note that adding new properties/nodes into fdt blob may fail. So always
check for return values of fdt_*() function! You would probably need to
call fdt_increase_size() first to make a place for new properties.

> I also see that SolidRun has dropped the patch you linked to in
> newer a38x branches, but can't see how else they're handling the eMMC
> detection.
> 
> I could wrap the dts change with a kconfig, but anyone enabling that
> kconfig would also need to patch the kernel dtb, unless u-boot has a
> hook to patch the file before passing it to the kernel.

Yes, it has a hook. It is called ft_board_setup() and is called
immediately before booting linux kernel. Basically in this hook you
should check if u-boot's blob was patched for eMMC and if yes then patch
also blob passed as argument in that function, as this blob would be
used for linux. See Turris Omnia hook for inspiration which fixups
ethernet node for linux blob based on what is in u-boot blob:
https://source.denx.de/u-boot/u-boot/-/blob/master/board/CZ.NIC/turris_omnia/turris_omnia.c

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

> > boot0 - zeroed
> > boot1 - u-boot (with local version 'boot1')
> > user - u-boot (with local version 'user')
> Can you check if boot_ack argument has some effect on the initial
> choice? Or if completely disabling boot partitions (boot_enable to 0)
> have some effect?

boot_ack doesn't appear to do anything. I can only set 0 or 1 and
there's no noticeable change to the boot process.

Setting `mmc partconf 0 0 0 0` with the same setup as described above
results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in
BOOT1 loads u-boot from the user area, which is identical to the `mmc
partconf 0 0 7 0` flow.

> If really EXT_CSD[179] register is completely ignored we may change SPL
> to always boot from BOOT0 (when eMMC with boot partitions is used) and
> if it fails then fallback to BootROM booting.

Is there a way of knowing where the SPL was loaded from? Because it
would make sense to me that if SPL was loaded from BOOT1 to try and
load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from
BOOT0, etc. Having u-boot loaded from a different location is not what
I expected and seems like it would cause a lot of confusion,
especially in a failed A/B rollout. BootROM seems to completely ignore
the setting, so I agree that SPL should ignore it as well, but
hardcoding BOOT0 (or even setting the partition as a compile-time
option) is probably not a great outcome.

Two observations that might help here:
1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS
is set to 0x0, even it it was set to something else prior to reset
2. With the same setup as described above and `mmc partconf 0 0 1 1`
the SPL eventually times out trying to load from the zeroed BOOT0 and
returns to BootROM, which results in u-boot being loaded from BOOT1:
=================================================
BootROM - 1.73

Booting from MMC
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.

U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 -
19:43:59 +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 MMC1
ERROR: Invalid kwbimage v1
mmc_load_image_raw_sector: mmc block read error
spl: mmc: wrong boot mode
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
Timeout waiting card ready
BootROM: Image checksum verification PASSED


U-Boot 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - 19:43:59 +1000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
Core:  38 devices, 22 uclasses, devicetree: separate
MMC:   mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Model: SolidRun Clearfog A1
Board: SolidRun Clearfog Pro
Net:
Warning: ethernet@70000 (eth1) using random MAC address - be:13:3f:c3:c2:19
eth1: ethernet@70000
Warning: ethernet@30000 (eth2) using random MAC address - be:4c:72:3e:eb:bc
, eth2: ethernet@30000
Warning: ethernet@34000 (eth3) using random MAC address - 86:e7:dd:8d:c5:c1
, eth3: ethernet@34000
Hit any key to stop autoboot:  0
=>
=================================================

> Seems that something in mmc initialization code is buggy. You can try to
> debug it by starting disabling parts of initialization code until you
> find the line/function which makes those BootROM messages "Timeout for
> status update!".

> Hm... Yes, "offset" string is not in your output, so that function is
> not called in SPL. Only in main U-Boot.
>
> What is in SPL called is board_early_init_f() function or
> fdtdec_board_setup() function or also board_late_init() function.
> Pointer to blob is in global variable gd->fdt_blob.
>
> Note that adding new properties/nodes into fdt blob may fail. So always
> check for return values of fdt_*() function! You would probably need to
> call fdt_increase_size() first to make a place for new properties.

> Yes, it has a hook. It is called ft_board_setup() and is called
> immediately before booting linux kernel. Basically in this hook you
> should check if u-boot's blob was patched for eMMC and if yes then patch
> also blob passed as argument in that function, as this blob would be
> used for linux. See Turris Omnia hook for inspiration which fixups
> ethernet node for linux blob based on what is in u-boot blob:
> https://source.denx.de/u-boot/u-boot/-/blob/master/board/CZ.NIC/turris_omnia/turris_omnia.c

Lots of great ideas to look into, plus the bubt and defconfig stuff.
I'll let you know how I go or if I get stuck again.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

[PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.

Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
---
 configs/clearfog_defconfig      | 3 +--
 configs/clearfog_sata_defconfig | 8 ++++----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 8cd35f9f1a..24e7c16ac7 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_MVEBU_BUBT=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_MIN_ENTRIES=128
 CONFIG_ARP_TIMEOUT=200
@@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SPL_I2C_EEPROM=y
-CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_MMC_BROKEN_CD=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_MV=y
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
index e9b36150ea..84f900bf50 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_sata_defconfig
@@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
 CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
 CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
 CONFIG_SPL_TEXT_BASE=0x40000030
 CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK=0x4002c000
 CONFIG_SPL=y
 CONFIG_DEBUG_UART_BASE=0xf1012000
 CONFIG_DEBUG_UART_CLOCK=250000000
@@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
 CONFIG_DEBUG_UART=y
 CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
 CONFIG_BOOTDELAY=3
 CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
@@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
 CONFIG_SPL_BSS_MAX_SIZE=0x4000
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
-CONFIG_SPL_STACK=0x4002c000
 CONFIG_SPL_I2C=y
 CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_TLV_EEPROM=y
@@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_MVEBU_BUBT=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_MIN_ENTRIES=128
 CONFIG_ARP_TIMEOUT=200
@@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SPL_I2C_EEPROM=y
+CONFIG_MMC_BROKEN_CD=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
-- 
2.39.2

On Wed, 22 Feb 2023 at 21:23, Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 22 February 2023 21:20:58 Martin Rowe wrote:
> > Hi
> >
> > > Could you send a patch which adds appropriate defconfig file for SPI
> > > boot? So this configuration would be tested in U-Boot CI automatically.
> >
> > Will do. Does it need to be the same as the other defconfigs
> > otherwise? I suggest putting the environment in SPI as well if u-boot
> > is already there (default is MMC).
>
> Yes, it makes sense.
>
> > > Have you tried booting from eMMC boot partition or eMMC user data
> > > partition? Because all 3 options should work, but I'm not fully sure if
> > > BootROM choose partition from eMMC register or if tries all 3 in some
> > > order. This is something which needs to be checked and verified.
> >
> > I only tested from boot0, but will test the others as well. I've only
> > ever seen it fallback, but I'll check the new changes and see if they
> > can select the boot device.
>
> Ok. When testing, ensure that you erase uboots from other partitions or
> check that it boots the correct version from the correction partition.
>
> > > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > > its repository?
> > >
> > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> > >
> > > Probably same functionality is needed to implement also into
> > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > > other boards how they use CONFIG_OF_BOARD_FIXUP.
> > >
> > > And if ... you can try to put this logic in board_late_init() function.
> > > For inspiration look into Espressobin board which deactivates eMMC at
> > > runtime by checking existence of eMMC:
> > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
> >
> > This is still on my TODO from earlier discussions.
> >
> > > There is still missing documentation for kwbimage config file format.
> > > It should be in "kwbimage" section of ./doc/mkimage.1 file but there is
> > > only placeholder... It would be nice if somebody can take it and write
> > > it.
> >
> > I'm not sure if I have the expertise for this, but can take a look as well.
> >
> > Martin
>
> Ok.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SPI booting and to store the
environment in SPI as well.

Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
---
 configs/clearfog_spi_defconfig | 88 ++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 configs/clearfog_spi_defconfig

diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig
new file mode 100644
index 0000000000..31b1e9fce8
--- /dev/null
+++ b/configs/clearfog_spi_defconfig
@@ -0,0 +1,88 @@
+CONFIG_ARM=y
+CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_TEXT_BASE=0x00800000
+CONFIG_SPL_GPIO=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
+CONFIG_TARGET_CLEARFOG=y
+CONFIG_ENV_SECT_SIZE=0x10000
+CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
+CONFIG_SPL_TEXT_BASE=0x40000030
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK=0x4002c000
+CONFIG_SPL=y
+CONFIG_DEBUG_UART_BASE=0xf1012000
+CONFIG_DEBUG_UART_CLOCK=250000000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
+CONFIG_SYS_LOAD_ADDR=0x800000
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTDELAY=3
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x22fd0
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x40023000
+CONFIG_SPL_BSS_MAX_SIZE=0x4000
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_I2C=y
+CONFIG_SYS_MAXARGS=32
+CONFIG_CMD_TLV_EEPROM=y
+CONFIG_SPL_CMD_TLV_EEPROM=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_MIN_ENTRIES=128
+CONFIG_ARP_TIMEOUT=200
+CONFIG_NET_RETRY_COUNT=50
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_AHCI_MVEBU=y
+CONFIG_DM_PCA953X=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_MVTWSI=y
+CONFIG_I2C_EEPROM=y
+CONFIG_SPL_I2C_EEPROM=y
+CONFIG_MMC_BROKEN_CD=y
+CONFIG_SPL_DM_MMC=y
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_MV=y
+CONFIG_MTD=y
+CONFIG_SF_DEFAULT_BUS=1
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_MTD=y
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_GIGE=y
+CONFIG_MVNETA=y
+CONFIG_MII=y
+CONFIG_MVMDIO=y
+CONFIG_PCI=y
+CONFIG_PCI_MVEBU=y
+CONFIG_SCSI=y
+CONFIG_SPL_DEBUG_UART_BASE=0xd0012000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550=y
+CONFIG_KIRKWOOD_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
-- 
2.39.2

On Fri, 24 Feb 2023 at 06:27, Martin Rowe <martin.p.rowe@gmail.com> wrote:
>
> > > boot0 - zeroed
> > > boot1 - u-boot (with local version 'boot1')
> > > user - u-boot (with local version 'user')
> > Can you check if boot_ack argument has some effect on the initial
> > choice? Or if completely disabling boot partitions (boot_enable to 0)
> > have some effect?
>
> boot_ack doesn't appear to do anything. I can only set 0 or 1 and
> there's no noticeable change to the boot process.
>
> Setting `mmc partconf 0 0 0 0` with the same setup as described above
> results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in
> BOOT1 loads u-boot from the user area, which is identical to the `mmc
> partconf 0 0 7 0` flow.
>
> > If really EXT_CSD[179] register is completely ignored we may change SPL
> > to always boot from BOOT0 (when eMMC with boot partitions is used) and
> > if it fails then fallback to BootROM booting.
>
> Is there a way of knowing where the SPL was loaded from? Because it
> would make sense to me that if SPL was loaded from BOOT1 to try and
> load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from
> BOOT0, etc. Having u-boot loaded from a different location is not what
> I expected and seems like it would cause a lot of confusion,
> especially in a failed A/B rollout. BootROM seems to completely ignore
> the setting, so I agree that SPL should ignore it as well, but
> hardcoding BOOT0 (or even setting the partition as a compile-time
> option) is probably not a great outcome.
>
> Two observations that might help here:
> 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS
> is set to 0x0, even it it was set to something else prior to reset
> 2. With the same setup as described above and `mmc partconf 0 0 1 1`
> the SPL eventually times out trying to load from the zeroed BOOT0 and
> returns to BootROM, which results in u-boot being loaded from BOOT1:
> =================================================
> BootROM - 1.73
>
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
>
> U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 -
> 19:43:59 +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 MMC1
> ERROR: Invalid kwbimage v1
> mmc_load_image_raw_sector: mmc block read error
> spl: mmc: wrong boot mode
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> Timeout waiting card ready
> BootROM: Image checksum verification PASSED
>
>
> U-Boot 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - 19:43:59 +1000)
>
> SoC:   MV88F6828-A0 at 1600 MHz
> DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> Core:  38 devices, 22 uclasses, devicetree: separate
> MMC:   mv_sdh: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
>
> Model: SolidRun Clearfog A1
> Board: SolidRun Clearfog Pro
> Net:
> Warning: ethernet@70000 (eth1) using random MAC address - be:13:3f:c3:c2:19
> eth1: ethernet@70000
> Warning: ethernet@30000 (eth2) using random MAC address - be:4c:72:3e:eb:bc
> , eth2: ethernet@30000
> Warning: ethernet@34000 (eth3) using random MAC address - 86:e7:dd:8d:c5:c1
> , eth3: ethernet@34000
> Hit any key to stop autoboot:  0
> =>
> =================================================
>
> > Seems that something in mmc initialization code is buggy. You can try to
> > debug it by starting disabling parts of initialization code until you
> > find the line/function which makes those BootROM messages "Timeout for
> > status update!".
>
> > Hm... Yes, "offset" string is not in your output, so that function is
> > not called in SPL. Only in main U-Boot.
> >
> > What is in SPL called is board_early_init_f() function or
> > fdtdec_board_setup() function or also board_late_init() function.
> > Pointer to blob is in global variable gd->fdt_blob.
> >
> > Note that adding new properties/nodes into fdt blob may fail. So always
> > check for return values of fdt_*() function! You would probably need to
> > call fdt_increase_size() first to make a place for new properties.
>
> > Yes, it has a hook. It is called ft_board_setup() and is called
> > immediately before booting linux kernel. Basically in this hook you
> > should check if u-boot's blob was patched for eMMC and if yes then patch
> > also blob passed as argument in that function, as this blob would be
> > used for linux. See Turris Omnia hook for inspiration which fixups
> > ethernet node for linux blob based on what is in u-boot blob:
> > https://source.denx.de/u-boot/u-boot/-/blob/master/board/CZ.NIC/turris_omnia/turris_omnia.c
>
> Lots of great ideas to look into, plus the bubt and defconfig stuff.
> I'll let you know how I go or if I get stuck again.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Martin,

On 2/24/23 16:07, Martin Rowe wrote:
> [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
> 
> A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> 
> Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>

Please note that this patch is sent to the list a s reply to the
RFC patchset from Pali. Something went wrong here, so that the
commit subject was not used. Also for the 2nd patch.

Another comment below.

> ---
>   configs/clearfog_defconfig      | 3 +--
>   configs/clearfog_sata_defconfig | 8 ++++----
>   2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> index 8cd35f9f1a..24e7c16ac7 100644
> --- a/configs/clearfog_defconfig
> +++ b/configs/clearfog_defconfig
> @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
>   CONFIG_CMD_TFTPPUT=y
>   CONFIG_CMD_CACHE=y
>   CONFIG_CMD_TIME=y
> -CONFIG_CMD_MVEBU_BUBT=y

You are removing the bubt cmd here. This is most likely a mistake.

So please re-send the patches with a correct subject and also without
removing the bubt cmd support.

Thanks,
Stefan

>   CONFIG_ENV_OVERWRITE=y
>   CONFIG_ENV_MIN_ENTRIES=128
>   CONFIG_ARP_TIMEOUT=200
> @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
>   CONFIG_SYS_I2C_MVTWSI=y
>   CONFIG_I2C_EEPROM=y
>   CONFIG_SPL_I2C_EEPROM=y
> -CONFIG_SUPPORT_EMMC_BOOT=y
> +CONFIG_MMC_BROKEN_CD=y
>   CONFIG_MMC_SDHCI=y
>   CONFIG_MMC_SDHCI_SDMA=y
>   CONFIG_MMC_SDHCI_MV=y
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
> index e9b36150ea..84f900bf50 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_sata_defconfig
> @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
>   CONFIG_SPL_LIBCOMMON_SUPPORT=y
>   CONFIG_SPL_LIBGENERIC_SUPPORT=y
>   CONFIG_NR_DRAM_BANKS=2
> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
>   CONFIG_TARGET_CLEARFOG=y
>   CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
>   CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
>   CONFIG_SPL_TEXT_BASE=0x40000030
>   CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_STACK=0x4002c000
>   CONFIG_SPL=y
>   CONFIG_DEBUG_UART_BASE=0xf1012000
>   CONFIG_DEBUG_UART_CLOCK=250000000
> @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
>   CONFIG_DEBUG_UART=y
>   CONFIG_AHCI=y
>   CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
>   CONFIG_BOOTDELAY=3
>   CONFIG_USE_PREBOOT=y
>   CONFIG_SYS_CONSOLE_INFO_QUIET=y
> @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
>   CONFIG_SPL_BSS_MAX_SIZE=0x4000
>   CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>   # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> -CONFIG_SPL_STACK=0x4002c000
>   CONFIG_SPL_I2C=y
>   CONFIG_SYS_MAXARGS=32
>   CONFIG_CMD_TLV_EEPROM=y
> @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
>   CONFIG_CMD_TFTPPUT=y
>   CONFIG_CMD_CACHE=y
>   CONFIG_CMD_TIME=y
> -CONFIG_CMD_MVEBU_BUBT=y
>   CONFIG_ENV_OVERWRITE=y
>   CONFIG_ENV_MIN_ENTRIES=128
>   CONFIG_ARP_TIMEOUT=200
> @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
>   CONFIG_SYS_I2C_MVTWSI=y
>   CONFIG_I2C_EEPROM=y
>   CONFIG_SPL_I2C_EEPROM=y
> +CONFIG_MMC_BROKEN_CD=y
>   CONFIG_SUPPORT_EMMC_BOOT=y
>   CONFIG_MMC_SDHCI=y
>   CONFIG_MMC_SDHCI_SDMA=y

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

> Please note that this patch is sent to the list a s reply to the
> RFC patchset from Pali. Something went wrong here, so that the
> commit subject was not used. Also for the 2nd patch.

Ah, sorry, I'm not really set up for this. The first patch branches
from Pali's RFC, though, so maybe it would be best to include my two
when the final mvebu changes are sent in?

> You are removing the bubt cmd here. This is most likely a mistake.

I had to double check this as well, but CONFIG_MMC_BROKEN_CD also
enables bubt for some reason, so it's definitely still included in the
config but gets removed by savedefconfig.

Martin

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Friday 24 February 2023 06:27:49 Martin Rowe wrote:
> > > boot0 - zeroed
> > > boot1 - u-boot (with local version 'boot1')
> > > user - u-boot (with local version 'user')
> > Can you check if boot_ack argument has some effect on the initial
> > choice? Or if completely disabling boot partitions (boot_enable to 0)
> > have some effect?
> 
> boot_ack doesn't appear to do anything. I can only set 0 or 1 and
> there's no noticeable change to the boot process.

Ok.

> Setting `mmc partconf 0 0 0 0` with the same setup as described above
> results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in
> BOOT1 loads u-boot from the user area, which is identical to the `mmc
> partconf 0 0 7 0` flow.

Ok.

> > If really EXT_CSD[179] register is completely ignored we may change SPL
> > to always boot from BOOT0 (when eMMC with boot partitions is used) and
> > if it fails then fallback to BootROM booting.
> 
> Is there a way of knowing where the SPL was loaded from?

I was trying to figure it out but it looks like that bootrom stores this
information into variable on the bootrom stack. So I think that this is
impossible.

> Because it
> would make sense to me that if SPL was loaded from BOOT1 to try and
> load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from
> BOOT0, etc. Having u-boot loaded from a different location is not what
> I expected and seems like it would cause a lot of confusion,
> especially in a failed A/B rollout.

Exactly, I want to avoid it.

> BootROM seems to completely ignore
> the setting, so I agree that SPL should ignore it as well, but
> hardcoding BOOT0 (or even setting the partition as a compile-time
> option) is probably not a great outcome.

It is a solution and nice trick to how to fix it. Reason is that if SPL
fails to load U-Boot from selected partition then it fallbacks to the
BootROM, which loads U-Boot from the correct location.

So if we hardcode partition to BOOT0 then it obviously works correctly
when SPL+U-Boot is on BOOT0. And if it is stored on BOOT1 or USER then
BootROM already has to fail load it from BOOT0, which means that on
BOOT0 is not valid U-Boot and when SPL tries to load main U-Boot from
BOOT0 it fails too, and it returns control to the BootROM which knows
that it should load it from BOOT0. And this would work also for DATA.

> Two observations that might help here:
> 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS
> is set to 0x0, even it it was set to something else prior to reset

Ok, so access permissions are reset. I do not know if this is in MMC
standard or not.

> 2. With the same setup as described above and `mmc partconf 0 0 1 1`
> the SPL eventually times out trying to load from the zeroed BOOT0 and
> returns to BootROM, which results in u-boot being loaded from BOOT1:

Access permissions can disable access to particular partition. So it
makes sense that it timeouts. And BootROM can always load and run main
u-boot from the correct location. We are using SPL for loading main
u-boot because this is way how it was first implemented and return to
bootrom was broken in the past. Anyway, if you completely disable MMC
support in SPL then SPL just returns control to BootROM which loads main
U-Boot.

Reading main u-boot via BootROM is slower as from SPL for SPI-NOR
booting because SPL can use faster SPI transfers than BootROM. So this
is the reason why we want in SPL to use native load method and not just
BootROM. But maybe for MMC it would make sense?

> =================================================
> BootROM - 1.73
> 
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> 
> U-Boot SPL 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 -
> 19:43:59 +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 MMC1
> ERROR: Invalid kwbimage v1
> mmc_load_image_raw_sector: mmc block read error
> spl: mmc: wrong boot mode
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> Timeout waiting card ready
> BootROM: Image checksum verification PASSED
> 
> 
> U-Boot 2023.04-rc2boot1-00098-g93408c61cd-dirty (Feb 23 2023 - 19:43:59 +1000)
> 
> SoC:   MV88F6828-A0 at 1600 MHz
> DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> Core:  38 devices, 22 uclasses, devicetree: separate
> MMC:   mv_sdh: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default environment
> 
> Model: SolidRun Clearfog A1
> Board: SolidRun Clearfog Pro
> Net:
> Warning: ethernet@70000 (eth1) using random MAC address - be:13:3f:c3:c2:19
> eth1: ethernet@70000
> Warning: ethernet@30000 (eth2) using random MAC address - be:4c:72:3e:eb:bc
> , eth2: ethernet@30000
> Warning: ethernet@34000 (eth3) using random MAC address - 86:e7:dd:8d:c5:c1
> , eth3: ethernet@34000
> Hit any key to stop autoboot:  0
> =>
> =================================================
> 
> > Seems that something in mmc initialization code is buggy. You can try to
> > debug it by starting disabling parts of initialization code until you
> > find the line/function which makes those BootROM messages "Timeout for
> > status update!".
> 
> > Hm... Yes, "offset" string is not in your output, so that function is
> > not called in SPL. Only in main U-Boot.
> >
> > What is in SPL called is board_early_init_f() function or
> > fdtdec_board_setup() function or also board_late_init() function.
> > Pointer to blob is in global variable gd->fdt_blob.
> >
> > Note that adding new properties/nodes into fdt blob may fail. So always
> > check for return values of fdt_*() function! You would probably need to
> > call fdt_increase_size() first to make a place for new properties.
> 
> > Yes, it has a hook. It is called ft_board_setup() and is called
> > immediately before booting linux kernel. Basically in this hook you
> > should check if u-boot's blob was patched for eMMC and if yes then patch
> > also blob passed as argument in that function, as this blob would be
> > used for linux. See Turris Omnia hook for inspiration which fixups
> > ethernet node for linux blob based on what is in u-boot blob:
> > https://source.denx.de/u-boot/u-boot/-/blob/master/board/CZ.NIC/turris_omnia/turris_omnia.c
> 
> Lots of great ideas to look into, plus the bubt and defconfig stuff.
> I'll let you know how I go or if I get stuck again.

Ok!

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Friday 24 February 2023 15:07:43 Martin Rowe wrote:
> [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
> 
> This new clearfog_spi_defconfig file is copy of existing
> clearfog_defconfig file and changed to instruct build system to
> generate final kwbimage for SPI booting and to store the
> environment in SPI as well.
> 
> Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> ---
>  configs/clearfog_spi_defconfig | 88 ++++++++++++++++++++++++++++++++++
>  1 file changed, 88 insertions(+)
>  create mode 100644 configs/clearfog_spi_defconfig
> 
> diff --git a/configs/clearfog_spi_defconfig b/configs/clearfog_spi_defconfig
> new file mode 100644
> index 0000000000..31b1e9fce8
> --- /dev/null
> +++ b/configs/clearfog_spi_defconfig

When generating this patch, use git options -M, -C and
--find-copies-harder. It will detect that you created this file as copy
from other file and generate better diff.

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

> When generating this patch, use git options -M, -C and
> --find-copies-harder. It will detect that you created this file as copy
> from other file and generate better diff.

Will do.

This thread has gotten quite long! I've:
 - tested all the boot modes and bubt update types
 - created the SPI defconfig,
 - fixed the eMMC detection by enabling MMC_BROKEN_CD
 - taken a look at the kwbimage documentation, but I don't think I can
be of much help there
I'm also able to help test any new changes for the MMC boot flow. Is
there anything else that I've missed that I can help with while I've
got it all setup?

Martin

[PATCH 0/2] arm: mvebu: clearfog: defconfig updates

[Martin Rowe]

Minor defconfig updates to Pali's RFC "arm: mvebu: Various fixes" for
SolidRun's A388 Clearfog devices.

Martin Rowe (2):
  arm: mvebu: clearfog: Fix MMC detection
  arm: mvebu: clearfog: Add defconfig for SPI booting

 configs/clearfog_defconfig                        |  3 +--
 configs/clearfog_sata_defconfig                   |  8 ++++----
 ...rfog_sata_defconfig => clearfog_spi_defconfig} | 15 ++++++++++-----
 3 files changed, 15 insertions(+), 11 deletions(-)
 copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (92%)

-- 
2.39.2

[PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

[Martin Rowe]

A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.

Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
---
 configs/clearfog_defconfig      | 3 +--
 configs/clearfog_sata_defconfig | 8 ++++----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index 8cd35f9f1a..24e7c16ac7 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_MVEBU_BUBT=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_MIN_ENTRIES=128
 CONFIG_ARP_TIMEOUT=200
@@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SPL_I2C_EEPROM=y
-CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_MMC_BROKEN_CD=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
 CONFIG_MMC_SDHCI_MV=y
diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
index e9b36150ea..84f900bf50 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_sata_defconfig
@@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
 CONFIG_TARGET_CLEARFOG=y
 CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
 CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
 CONFIG_SPL_TEXT_BASE=0x40000030
 CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK=0x4002c000
 CONFIG_SPL=y
 CONFIG_DEBUG_UART_BASE=0xf1012000
 CONFIG_DEBUG_UART_CLOCK=250000000
@@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
 CONFIG_DEBUG_UART=y
 CONFIG_AHCI=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
 CONFIG_BOOTDELAY=3
 CONFIG_USE_PREBOOT=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
@@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
 CONFIG_SPL_BSS_MAX_SIZE=0x4000
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
-CONFIG_SPL_STACK=0x4002c000
 CONFIG_SPL_I2C=y
 CONFIG_SYS_MAXARGS=32
 CONFIG_CMD_TLV_EEPROM=y
@@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_MVEBU_BUBT=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_MIN_ENTRIES=128
 CONFIG_ARP_TIMEOUT=200
@@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SPL_I2C_EEPROM=y
+CONFIG_MMC_BROKEN_CD=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
-- 
2.39.2

[PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Martin Rowe]

This new clearfog_spi_defconfig file is copy of existing
clearfog_defconfig file and changed to instruct build system to
generate final kwbimage for SPI booting and to store the
environment in SPI as well.

Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
---
 .../{clearfog_sata_defconfig => clearfog_spi_defconfig}    | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
 copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)

diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
similarity index 93%
copy from configs/clearfog_sata_defconfig
copy to configs/clearfog_spi_defconfig
index 84f900bf50..31b1e9fce8 100644
--- a/configs/clearfog_sata_defconfig
+++ b/configs/clearfog_spi_defconfig
@@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_TEXT_BASE=0x00800000
+CONFIG_SPL_GPIO=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
 CONFIG_TARGET_CLEARFOG=y
-CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
+CONFIG_ENV_SECT_SIZE=0x10000
 CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
 CONFIG_SPL_TEXT_BASE=0x40000030
+CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
 CONFIG_SPL_STACK=0x4002c000
 CONFIG_SPL=y
 CONFIG_DEBUG_UART_BASE=0xf1012000
 CONFIG_DEBUG_UART_CLOCK=250000000
+CONFIG_SPL_LIBDISK_SUPPORT=y
+# CONFIG_SPL_SPI is not set
 CONFIG_SYS_LOAD_ADDR=0x800000
 CONFIG_DEBUG_UART=y
 CONFIG_AHCI=y
@@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SPL_I2C_EEPROM=y
 CONFIG_MMC_BROKEN_CD=y
+CONFIG_SPL_DM_MMC=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_SDMA=y
-- 
2.39.2

Re: [PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot

[Tony Dinh]

Hi Pali,

On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
>
> Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD4000000 to 0xF4000000
> and change its size from 64 MB to 8 MB. Definitions are already in
> MBUS_SPI_BASE/MBUS_SPI_SIZE macros. So define these macros also for SPL
> build, use them in env_sf_get_env_addr() function and move this function
> from spl.c to cpu.c to be available in Proper U-Boot too.

Interesting! So would it  affect the board that has a 4MB SPI flash ?
I know there is a bug somewhere, because I need to set both
CONFIG_ENV_OFFSET and CONFIG_ENV_ADDR. One or the other is not enough.

I'm debugging an error that seemingly has something to do with the SPI
envs area: how u-boot set envs and recalculate checksum, and Linux
fw_setenv() seems to not be doing the same thing. This is on a 4MB SPI
mx25l3205d flash (Thecus N2350 board).

It might also have something to do with a SPI flash being set to some
protected  blocks (in the Status Register upon boot).

Thanks,
Tony

>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  arch/arm/mach-mvebu/cpu.c              |  9 +++++++++
>  arch/arm/mach-mvebu/include/mach/cpu.h |  5 +++++
>  arch/arm/mach-mvebu/spl.c              | 13 -------------
>  3 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> index c5089a91c747..97154aaa2a7e 100644
> --- a/arch/arm/mach-mvebu/cpu.c
> +++ b/arch/arm/mach-mvebu/cpu.c
> @@ -35,6 +35,15 @@ static const struct mbus_win windows[] = {
>  #endif
>  };
>
> +/* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */
> +#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> +    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
> +void *env_sf_get_env_addr(void)
> +{
> +       return (void *)MBUS_SPI_BASE + CONFIG_ENV_OFFSET;
> +}
> +#endif
> +
>  void lowlevel_init(void)
>  {
>         /*
> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h
> index c17c2440f1b1..906a8737a401 100644
> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> @@ -71,8 +71,13 @@ enum cpu_attrib {
>  #define MBUS_PCI_MEM_SIZE      ((MBUS_PCI_MAX_PORTS * 128) << 20)
>  #define MBUS_PCI_IO_BASE       0xF1100000
>  #define MBUS_PCI_IO_SIZE       ((MBUS_PCI_MAX_PORTS * 64) << 10)
> +#ifdef CONFIG_SPL_BUILD
> +#define MBUS_SPI_BASE          0xD4000000
> +#define MBUS_SPI_SIZE          (64 << 20)
> +#else
>  #define MBUS_SPI_BASE          0xF4000000
>  #define MBUS_SPI_SIZE          (8 << 20)
> +#endif
>  #define MBUS_DFX_BASE          0xF6000000
>  #define MBUS_DFX_SIZE          (1 << 20)
>  #define MBUS_BOOTROM_BASE      0xF8000000
> diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> index 02528e025d8c..6b8c72a71dab 100644
> --- a/arch/arm/mach-mvebu/spl.c
> +++ b/arch/arm/mach-mvebu/spl.c
> @@ -308,19 +308,6 @@ int board_return_to_bootrom(struct spl_image_info *spl_image,
>         hang();
>  }
>
> -/*
> - * SPI0 CS0 Flash is mapped to address range 0xD4000000 - 0xD7FFFFFF by BootROM.
> - * Proper U-Boot removes this direct mapping. So it is available only in SPL.
> - */
> -#if defined(CONFIG_SPL_ENV_IS_IN_SPI_FLASH) && \
> -    CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> -    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= 64*1024*1024
> -void *env_sf_get_env_addr(void)
> -{
> -       return (void *)0xD4000000 + CONFIG_ENV_OFFSET;
> -}
> -#endif
> -
>  void board_init_f(ulong dummy)
>  {
>         int ret;
> --
> 2.20.1
>

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> This new clearfog_spi_defconfig file is copy of existing
> clearfog_defconfig file and changed to instruct build system to
> generate final kwbimage for SPI booting and to store the
> environment in SPI as well.
> 
> Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> ---
>  .../{clearfog_sata_defconfig => clearfog_spi_defconfig}    | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>  copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
> 
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
> similarity index 93%
> copy from configs/clearfog_sata_defconfig
> copy to configs/clearfog_spi_defconfig
> index 84f900bf50..31b1e9fce8 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_spi_defconfig
> @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
>  CONFIG_SYS_THUMB_BUILD=y
>  CONFIG_ARCH_MVEBU=y
>  CONFIG_TEXT_BASE=0x00800000
> +CONFIG_SPL_GPIO=y
>  CONFIG_SPL_LIBCOMMON_SUPPORT=y
>  CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=2
>  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
>  CONFIG_TARGET_CLEARFOG=y
> -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> +CONFIG_ENV_SECT_SIZE=0x10000
>  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
>  CONFIG_SPL_TEXT_BASE=0x40000030
> +CONFIG_SPL_MMC=y
>  CONFIG_SPL_SERIAL=y
>  CONFIG_SPL_STACK=0x4002c000
>  CONFIG_SPL=y
>  CONFIG_DEBUG_UART_BASE=0xf1012000
>  CONFIG_DEBUG_UART_CLOCK=250000000
> +CONFIG_SPL_LIBDISK_SUPPORT=y
> +# CONFIG_SPL_SPI is not set

Any reason to disable it?

>  CONFIG_SYS_LOAD_ADDR=0x800000
>  CONFIG_DEBUG_UART=y
>  CONFIG_AHCI=y
> @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
>  CONFIG_I2C_EEPROM=y
>  CONFIG_SPL_I2C_EEPROM=y
>  CONFIG_MMC_BROKEN_CD=y
> +CONFIG_SPL_DM_MMC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
> -- 
> 2.39.2
> 

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Martin Rowe]

On Sat, 25 Feb 2023 at 07:41, Pali Rohár <pali@kernel.org> wrote:
>
> On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
> > This new clearfog_spi_defconfig file is copy of existing
> > clearfog_defconfig file and changed to instruct build system to
> > generate final kwbimage for SPI booting and to store the
> > environment in SPI as well.
> >
> > Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> > ---
> >  .../{clearfog_sata_defconfig => clearfog_spi_defconfig}    | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >  copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
> >
> > diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
> > similarity index 93%
> > copy from configs/clearfog_sata_defconfig
> > copy to configs/clearfog_spi_defconfig
> > index 84f900bf50..31b1e9fce8 100644
> > --- a/configs/clearfog_sata_defconfig
> > +++ b/configs/clearfog_spi_defconfig
> > @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
> >  CONFIG_SYS_THUMB_BUILD=y
> >  CONFIG_ARCH_MVEBU=y
> >  CONFIG_TEXT_BASE=0x00800000
> > +CONFIG_SPL_GPIO=y
> >  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
> >  CONFIG_NR_DRAM_BANKS=2
> >  CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> >  CONFIG_TARGET_CLEARFOG=y
> > -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > +CONFIG_ENV_SECT_SIZE=0x10000
> >  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> >  CONFIG_SPL_TEXT_BASE=0x40000030
> > +CONFIG_SPL_MMC=y
> >  CONFIG_SPL_SERIAL=y
> >  CONFIG_SPL_STACK=0x4002c000
> >  CONFIG_SPL=y
> >  CONFIG_DEBUG_UART_BASE=0xf1012000
> >  CONFIG_DEBUG_UART_CLOCK=250000000
> > +CONFIG_SPL_LIBDISK_SUPPORT=y
> > +# CONFIG_SPL_SPI is not set
>
> Any reason to disable it?

It's the same as MMC and SATA defconfigs this way, it just needs to be
explicit here because of something SPI related that we've enabled.
SPL_DM_SPI is enabled in all of the configs, so I'm guessing that it
is providing driver support because everything seems to work without
SPL_SPI.

I re-tested with and without the config and it doesn't seem to change
anything. With it enabled the file is 588K instead of 580K without it,
but that's not really an issue with 4M of flash storage available.

> >  CONFIG_SYS_LOAD_ADDR=0x800000
> >  CONFIG_DEBUG_UART=y
> >  CONFIG_AHCI=y
> > @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> >  CONFIG_I2C_EEPROM=y
> >  CONFIG_SPL_I2C_EEPROM=y
> >  CONFIG_MMC_BROKEN_CD=y
> > +CONFIG_SPL_DM_MMC=y
> >  CONFIG_SUPPORT_EMMC_BOOT=y
> >  CONFIG_MMC_SDHCI=y
> >  CONFIG_MMC_SDHCI_SDMA=y
> > --
> > 2.39.2
> >

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Josua Mayer]

Hi Pali, Martin,

Am 25.02.23 um 10:48 schrieb Martin Rowe:
> On Sat, 25 Feb 2023 at 07:41, Pali Rohár<pali@kernel.org>  wrote:
>> On Saturday 25 February 2023 11:42:20 Martin Rowe wrote:
>>> This new clearfog_spi_defconfig file is copy of existing
>>> clearfog_defconfig file and changed to instruct build system to
>>> generate final kwbimage for SPI booting and to store the
>>> environment in SPI as well.
>>>
>>> Signed-off-by: Martin Rowe<martin.p.rowe@gmail.com>
>>> ---
>>>   .../{clearfog_sata_defconfig => clearfog_spi_defconfig}    | 7 ++++++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>   copy configs/{clearfog_sata_defconfig => clearfog_spi_defconfig} (93%)
>>>
>>> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_spi_defconfig
>>> similarity index 93%
>>> copy from configs/clearfog_sata_defconfig
>>> copy to configs/clearfog_spi_defconfig
>>> index 84f900bf50..31b1e9fce8 100644
>>> --- a/configs/clearfog_sata_defconfig
>>> +++ b/configs/clearfog_spi_defconfig
>>> @@ -3,20 +3,24 @@ CONFIG_ARCH_CPU_INIT=y
>>>   CONFIG_SYS_THUMB_BUILD=y
>>>   CONFIG_ARCH_MVEBU=y
>>>   CONFIG_TEXT_BASE=0x00800000
>>> +CONFIG_SPL_GPIO=y
>>>   CONFIG_SPL_LIBCOMMON_SUPPORT=y
>>>   CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>>   CONFIG_NR_DRAM_BANKS=2
>>>   CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>>>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
>>>   CONFIG_TARGET_CLEARFOG=y
>>> -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
>>> +CONFIG_ENV_SECT_SIZE=0x10000
>>>   CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
>>>   CONFIG_SPL_TEXT_BASE=0x40000030
>>> +CONFIG_SPL_MMC=y
>>>   CONFIG_SPL_SERIAL=y
>>>   CONFIG_SPL_STACK=0x4002c000
>>>   CONFIG_SPL=y
>>>   CONFIG_DEBUG_UART_BASE=0xf1012000
>>>   CONFIG_DEBUG_UART_CLOCK=250000000
>>> +CONFIG_SPL_LIBDISK_SUPPORT=y
>>> +# CONFIG_SPL_SPI is not set
>> Any reason to disable it?
> It's the same as MMC and SATA defconfigs this way, it just needs to be
> explicit here because of something SPI related that we've enabled.
> SPL_DM_SPI is enabled in all of the configs, so I'm guessing that it
> is providing driver support because everything seems to work without
> SPL_SPI.
>
> I re-tested with and without the config and it doesn't seem to change
> anything. With it enabled the file is 588K instead of 580K without it,
> but that's not really an issue with 4M of flash storage available.

While I haven't tested this patchset - I have tested SPI booting with 
v2022.01 after applying lots of patches.
I found that the magic value reported by bootrom when booting from SPI 
will be 0x34 on clearfog.
The current sources only handle 0x32, hence having or not having SPL_SPI 
will always lead to returning to the bootrom.

Please consider pulling in this patch:
https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d
I can send it separately if you like.

which I have tested by adding these config options:

|CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y # CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC 
is not set # CONFIG_SPL_MMC is not set CONFIG_SPL_SPI_FLASH_SUPPORT=y 
CONFIG_SPL_SPI=y CONFIG_SPL_SPI_FLASH_TINY=y CONFIG_SPL_SPI_LOAD=y 
CONFIG_SYS_SPI_U_BOOT_OFFS=0x0 # CONFIG_ENV_IS_IN_MMC is not set 
CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_ENV_SECT_SIZE_AUTO is not set # 
CONFIG_USE_ENV_SPI_BUS is not set # CONFIG_USE_ENV_SPI_CS is not set # 
CONFIG_USE_ENV_SPI_MAX_HZ is not set # CONFIG_USE_ENV_SPI_MODE is not 
set # CONFIG_ENV_SPI_EARLY is not set CONFIG_ENV_ADDR=0x0|

>>>   CONFIG_SYS_LOAD_ADDR=0x800000
>>>   CONFIG_DEBUG_UART=y
>>>   CONFIG_AHCI=y
>>> @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
>>>   CONFIG_I2C_EEPROM=y
>>>   CONFIG_SPL_I2C_EEPROM=y
>>>   CONFIG_MMC_BROKEN_CD=y
>>> +CONFIG_SPL_DM_MMC=y
>>>   CONFIG_SUPPORT_EMMC_BOOT=y
>>>   CONFIG_MMC_SDHCI=y
>>>   CONFIG_MMC_SDHCI_SDMA=y
>>> --
>>> 2.39.2
>>>

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Martin Rowe]

> While I haven't tested this patchset - I have tested SPI booting with v2022.01 after applying lots of patches.
> I found that the magic value reported by bootrom when booting from SPI will be 0x34 on clearfog.
> The current sources only handle 0x32, hence having or not having SPL_SPI will always lead to returning to the bootrom.
>
> Please consider pulling in this patch:
> https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d
> I can send it separately if you like.

Tested with the patch on a Clearfog Base:
================== Without SPL_SPI same return to BootROM
...
mv_ddr: completed successfully
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
BootROM: Image checksum verification PASSED


U-Boot 2023.04-rc2...
================== With SPL_SPI loads directly from SPI
...
mv_ddr: completed successfully
Trying to boot from SPI


U-Boot 2023.04-rc2...
==================

I'm not sure how to run proper timing tests on the process, but
stopwatch timing just between seeing "Trying to boot" and "U-Boot
2023.04-rc2" showed the return to BootROM under 1 second, and the
direct from SPI around 4 seconds. I thought the goal of loading from
SPI directly was speed, but returning to BootROM is significantly
faster on this board.

> which I have tested by adding these config options:

I tested the new spi_defconfig with and without SPL_SPI; no other changes

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Saturday 25 February 2023 11:47:07 Martin Rowe wrote:
> > While I haven't tested this patchset - I have tested SPI booting with v2022.01 after applying lots of patches.
> > I found that the magic value reported by bootrom when booting from SPI will be 0x34 on clearfog.
> > The current sources only handle 0x32, hence having or not having SPL_SPI will always lead to returning to the bootrom.
> >
> > Please consider pulling in this patch:
> > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d
> > I can send it separately if you like.
> 
> Tested with the patch on a Clearfog Base:
> ================== Without SPL_SPI same return to BootROM
> ...
> mv_ddr: completed successfully
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> BootROM: Image checksum verification PASSED
> 
> 
> U-Boot 2023.04-rc2...
> ================== With SPL_SPI loads directly from SPI
> ...
> mv_ddr: completed successfully
> Trying to boot from SPI
> 
> 
> U-Boot 2023.04-rc2...
> ==================
> 
> I'm not sure how to run proper timing tests on the process, but
> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> direct from SPI around 4 seconds. I thought the goal of loading from
> SPI directly was speed, but returning to BootROM is significantly
> faster on this board.

You should check SPI speed in DTS file and also in the defconfig.

> > which I have tested by adding these config options:
> 
> I tested the new spi_defconfig with and without SPL_SPI; no other changes

Re: [PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot

[Pali Rohár]

On Friday 24 February 2023 19:58:37 Tony Dinh wrote:
> Hi Pali,
> 
> On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD4000000 to 0xF4000000
> > and change its size from 64 MB to 8 MB. Definitions are already in
> > MBUS_SPI_BASE/MBUS_SPI_SIZE macros. So define these macros also for SPL
> > build, use them in env_sf_get_env_addr() function and move this function
> > from spl.c to cpu.c to be available in Proper U-Boot too.
> 
> Interesting! So would it  affect the board that has a 4MB SPI flash ?

This change just allows to use read-only SPI0 CS0 Flash mapping in the
env code in proper u-boot. If there is a board code which requires
access to env from proper u-boot before relocation happens then this
change allows it. But only if env is stored in the first 8MB of SPI0
flash.

Note that after relocation u-boot uses full-feature SPI driver for
accessing flash memory, by coping its content to RAM during read.

So any access to env after relocation should not be affected by this
change.

IIRC only Omnia board for now uses this feature (for configuring
serdes based on env settings) and for now only in SPL.

> I know there is a bug somewhere, because I need to set both
> CONFIG_ENV_OFFSET and CONFIG_ENV_ADDR. One or the other is not enough.

I am not sure for what is _ADDR needed (I am only on mobile for now, so
I cannot check it)

> I'm debugging an error that seemingly has something to do with the SPI
> envs area: how u-boot set envs and recalculate checksum, and Linux
> fw_setenv() seems to not be doing the same thing. This is on a 4MB SPI
> mx25l3205d flash (Thecus N2350 board).

Maybe you have set wrong env size or wrong flash erase block size?

> It might also have something to do with a SPI flash being set to some
> protected  blocks (in the Status Register upon boot).
> 
> Thanks,
> Tony
> 
> >
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > ---
> >  arch/arm/mach-mvebu/cpu.c              |  9 +++++++++
> >  arch/arm/mach-mvebu/include/mach/cpu.h |  5 +++++
> >  arch/arm/mach-mvebu/spl.c              | 13 -------------
> >  3 files changed, 14 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> > index c5089a91c747..97154aaa2a7e 100644
> > --- a/arch/arm/mach-mvebu/cpu.c
> > +++ b/arch/arm/mach-mvebu/cpu.c
> > @@ -35,6 +35,15 @@ static const struct mbus_win windows[] = {
> >  #endif
> >  };
> >
> > +/* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */
> > +#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> > +    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
> > +void *env_sf_get_env_addr(void)
> > +{
> > +       return (void *)MBUS_SPI_BASE + CONFIG_ENV_OFFSET;
> > +}
> > +#endif
> > +
> >  void lowlevel_init(void)
> >  {
> >         /*
> > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h
> > index c17c2440f1b1..906a8737a401 100644
> > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > @@ -71,8 +71,13 @@ enum cpu_attrib {
> >  #define MBUS_PCI_MEM_SIZE      ((MBUS_PCI_MAX_PORTS * 128) << 20)
> >  #define MBUS_PCI_IO_BASE       0xF1100000
> >  #define MBUS_PCI_IO_SIZE       ((MBUS_PCI_MAX_PORTS * 64) << 10)
> > +#ifdef CONFIG_SPL_BUILD
> > +#define MBUS_SPI_BASE          0xD4000000
> > +#define MBUS_SPI_SIZE          (64 << 20)
> > +#else
> >  #define MBUS_SPI_BASE          0xF4000000
> >  #define MBUS_SPI_SIZE          (8 << 20)
> > +#endif
> >  #define MBUS_DFX_BASE          0xF6000000
> >  #define MBUS_DFX_SIZE          (1 << 20)
> >  #define MBUS_BOOTROM_BASE      0xF8000000
> > diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> > index 02528e025d8c..6b8c72a71dab 100644
> > --- a/arch/arm/mach-mvebu/spl.c
> > +++ b/arch/arm/mach-mvebu/spl.c
> > @@ -308,19 +308,6 @@ int board_return_to_bootrom(struct spl_image_info *spl_image,
> >         hang();
> >  }
> >
> > -/*
> > - * SPI0 CS0 Flash is mapped to address range 0xD4000000 - 0xD7FFFFFF by BootROM.
> > - * Proper U-Boot removes this direct mapping. So it is available only in SPL.
> > - */
> > -#if defined(CONFIG_SPL_ENV_IS_IN_SPI_FLASH) && \
> > -    CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> > -    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= 64*1024*1024
> > -void *env_sf_get_env_addr(void)
> > -{
> > -       return (void *)0xD4000000 + CONFIG_ENV_OFFSET;
> > -}
> > -#endif
> > -
> >  void board_init_f(ulong dummy)
> >  {
> >         int ret;
> > --
> > 2.20.1
> >

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Saturday 25 February 2023 01:18:26 Martin Rowe wrote:
> > When generating this patch, use git options -M, -C and
> > --find-copies-harder. It will detect that you created this file as copy
> > from other file and generate better diff.
> 
> Will do.
> 
> This thread has gotten quite long! I've:
>  - tested all the boot modes and bubt update types
>  - created the SPI defconfig,
>  - fixed the eMMC detection by enabling MMC_BROKEN_CD

Thanks!

>  - taken a look at the kwbimage documentation, but I don't think I can
> be of much help there
> I'm also able to help test any new changes for the MMC boot flow. Is
> there anything else that I've missed that I can help with while I've
> got it all setup?
> 
> Martin

I think that the remaining part is to patch linux DTB file at runtime
for emmc support. So if u-boot mmc device is of eMMC type then fixup
linux dtb file and others do nothing.

Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

[Pali Rohár]

On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> 
> Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>

It looks like a hack but I think we do not have a better option for now.

If I understand the issue correctly then card-detect pin is unconnected
for eMMC variant and used for checking if SD card is present for SD
variant. Unconnected pin seems to have some internal pull-up/down which
reports not-present state for eMMC variant. eMMC does not have any
presence signal, so card-detect pin must be ignored for eMMC.

This looks like a chicken and egg problem and the only option to support
both variants is to ignore card-detect pin and always try to initialize
device connected to mmc controller (which may be eMMC or SD).

I do not know if there is a better option for ignoring card-detect pin
in u-boot, so:

Acked-by: Pali Rohár <pali@kernel.org>

> ---
>  configs/clearfog_defconfig      | 3 +--
>  configs/clearfog_sata_defconfig | 8 ++++----
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> index 8cd35f9f1a..24e7c16ac7 100644
> --- a/configs/clearfog_defconfig
> +++ b/configs/clearfog_defconfig
> @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
>  CONFIG_CMD_TFTPPUT=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_CMD_TIME=y
> -CONFIG_CMD_MVEBU_BUBT=y
>  CONFIG_ENV_OVERWRITE=y
>  CONFIG_ENV_MIN_ENTRIES=128
>  CONFIG_ARP_TIMEOUT=200
> @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_MVTWSI=y
>  CONFIG_I2C_EEPROM=y
>  CONFIG_SPL_I2C_EEPROM=y
> -CONFIG_SUPPORT_EMMC_BOOT=y
> +CONFIG_MMC_BROKEN_CD=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
>  CONFIG_MMC_SDHCI_MV=y
> diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
> index e9b36150ea..84f900bf50 100644
> --- a/configs/clearfog_sata_defconfig
> +++ b/configs/clearfog_sata_defconfig
> @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
>  CONFIG_SPL_LIBCOMMON_SUPPORT=y
>  CONFIG_SPL_LIBGENERIC_SUPPORT=y
>  CONFIG_NR_DRAM_BANKS=2
> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
>  CONFIG_TARGET_CLEARFOG=y
>  CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
>  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
>  CONFIG_SPL_TEXT_BASE=0x40000030
>  CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_STACK=0x4002c000
>  CONFIG_SPL=y
>  CONFIG_DEBUG_UART_BASE=0xf1012000
>  CONFIG_DEBUG_UART_CLOCK=250000000
> @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
>  CONFIG_DEBUG_UART=y
>  CONFIG_AHCI=y
>  CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
>  CONFIG_BOOTDELAY=3
>  CONFIG_USE_PREBOOT=y
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
>  CONFIG_SPL_BSS_MAX_SIZE=0x4000
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
>  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> -CONFIG_SPL_STACK=0x4002c000
>  CONFIG_SPL_I2C=y
>  CONFIG_SYS_MAXARGS=32
>  CONFIG_CMD_TLV_EEPROM=y
> @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
>  CONFIG_CMD_TFTPPUT=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_CMD_TIME=y
> -CONFIG_CMD_MVEBU_BUBT=y
>  CONFIG_ENV_OVERWRITE=y
>  CONFIG_ENV_MIN_ENTRIES=128
>  CONFIG_ARP_TIMEOUT=200
> @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_MVTWSI=y
>  CONFIG_I2C_EEPROM=y
>  CONFIG_SPL_I2C_EEPROM=y
> +CONFIG_MMC_BROKEN_CD=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_SDMA=y
> -- 
> 2.39.2
> 

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Saturday 25 February 2023 11:51:28 Josua Mayer wrote:
> While I haven't tested this patchset

Are you going to test it?

> I have tested SPI booting with
> v2022.01 after applying lots of patches.
> I found that the magic value reported by bootrom when booting from SPI will
> be 0x34 on clearfog.
> The current sources only handle 0x32, hence having or not having SPL_SPI
> will always lead to returning to the bootrom.
> 
> Please consider pulling in this patch:
> https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d
> I can send it separately if you like.

There are lot of more strapping boot options for SPI and for other
peripherals. All are described in the A38x Hardware Specifications
document, publicly available and linked from the Linux ARM Marvell
documentation. Maybe it would make sense to rework this code to handle
all combinations and not just selected one?

> which I have tested by adding these config options:
> 
> |CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y # CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC is
> not set # CONFIG_SPL_MMC is not set CONFIG_SPL_SPI_FLASH_SUPPORT=y
> CONFIG_SPL_SPI=y CONFIG_SPL_SPI_FLASH_TINY=y CONFIG_SPL_SPI_LOAD=y
> CONFIG_SYS_SPI_U_BOOT_OFFS=0x0 # CONFIG_ENV_IS_IN_MMC is not set
> CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_ENV_SECT_SIZE_AUTO is not set #
> CONFIG_USE_ENV_SPI_BUS is not set # CONFIG_USE_ENV_SPI_CS is not set #
> CONFIG_USE_ENV_SPI_MAX_HZ is not set # CONFIG_USE_ENV_SPI_MODE is not set #
> CONFIG_ENV_SPI_EARLY is not set CONFIG_ENV_ADDR=0x0|
> 
> > > >   CONFIG_SYS_LOAD_ADDR=0x800000
> > > >   CONFIG_DEBUG_UART=y
> > > >   CONFIG_AHCI=y
> > > > @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> > > >   CONFIG_I2C_EEPROM=y
> > > >   CONFIG_SPL_I2C_EEPROM=y
> > > >   CONFIG_MMC_BROKEN_CD=y
> > > > +CONFIG_SPL_DM_MMC=y
> > > >   CONFIG_SUPPORT_EMMC_BOOT=y
> > > >   CONFIG_MMC_SDHCI=y
> > > >   CONFIG_MMC_SDHCI_SDMA=y
> > > > --
> > > > 2.39.2
> > > > 

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> This patch series contains various improvements and fixes for existing
> logical errors. Boot phase was adjusted to match behavior of Armada 385
> BootROM by inspecting and disassembling of BootROM binary dump itself.
> Important information are included in documentation patch for kwboot.
> Most of the changes are untested, hence this patch series is just RFC.
> So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> Nevertheless all patches on github passed CI testing in this PR:
> https://github.com/u-boot/u-boot/pull/275

Patches were tested on more boards and seems there is no reported issue,
but other improvements.

So do you need something to modify in this relatively big patch series?
If it is not really needed I would like to not send it again because
denx servers are not able to handle it. And it take me lot of time to
send patches over emails to denx servers.

> 
> Pali Rohár (59):
>   tools: kwbimage: Fix generating, verifying and extracting SDIO
>     kwbimage
>   tools: kwboot: Fix parsing SDIO kwbimage
>   arm: mvebu: spl: Fix parsing SDIO kwbimage
>   cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>   tools: kwbimage: Fix generating, verifying and extracting SATA
>     kwbimage
>   tools: kwboot: Fix parsing SATA kwbimage
>   arm: mvebu: spl: Fix parsing SATA kwbimage
>   cmd: mvebu/bubt: Fix parsing SATA kwbimage
>   arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>     BOOT_DEVICE_MMC2_2
>   arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
>   spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>   arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
>   tools: kwboot: Add more documentation references
>   tools: kwboot: Add image type documentation
>   tools: kwboot: Fix parsing UART image without data checksum
>   tools: kwboot: Validate optional kwbimage v1 headers
>   tools: kwboot: Add check that kwbimage contains DDR init code
>   tools: kwboot: Fix patching of SPI/NOR XIP images
>   tools: kwboot: Show image type and error parsing reasons
>   cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>   cmd: mvebu/bubt: Add support for writing image to SATA disk
>   cmd: mvebu/bubt: Add support for reading image from the SATA disk
>     partition
>   cmd: mvebu/bubt: Rename variable image_size to hdr_size
>   cmd: mvebu/bubt: Mark all local symbols as static
>   cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
>   cmd: mvebu/bubt: Check also A8K boot image checksum
>   cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
>   cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>   cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
>     'fuse_read_u64' defined but not used
>   cmd: mvebu/bubt: Enable command by default
>   tools: kwbimage: Fix dumping register set / DATA commands
>   tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>   tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>   tools: kwbimage: Fix dumping NAND_BLKSZ
>   tools: kwbimage: Fix generating of kwbimage v0 header checksum
>   tools: kwbimage: Fix endianity when printing kwbimage header
>   tools: kwbimage: Reject mkimage -F option
>   tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
>   tools: kwbimage: Print binary image offset as size
>   tools: kwbimage: Print image data offset when printing kwbimage header
>   tools: kwbimage: Simplify add_secure_header_v1()
>   tools: kwbimage: Rename imagesz to dataoff
>   tools: kwbimage: Fix generating secure boot data image signature
>   tools: kwbimage: Fix invalid secure boot header signature
>   tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
>   tools: kwbimage: Add support for XIP SPI/NOR images
>   tools: mkimage: Print human readable error when -d is not specified
>   tools: mkimage: Do not try to open datafile when it is skipped
>   tools: kwbimage: Add support for creating an image with no data
>   arm: mvebu: Add support for generating NAND kwbimage
>   arm: mvebu: Add support for generating PEX kwbimage
>   arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>   arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>   arm: mvebu: clearfog: Add defconfig for SATA booting
>   arm: mvebu: Remove A39x relicts
>   arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>   arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
>   arm: mvebu: Define SPL memory maps
>   doc/kwboot.1: Update example description
> 
>  arch/arm/mach-mvebu/Kconfig                   |  23 +-
>  arch/arm/mach-mvebu/Makefile                  |  13 +
>  arch/arm/mach-mvebu/cpu.c                     |  11 +-
>  arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>  arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
>  .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>  .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>  arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>  arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>  arch/arm/mach-mvebu/spl.c                     |  84 +++--
>  cmd/mvebu/Kconfig                             |  18 ++
>  cmd/mvebu/bubt.c                              | 253 ++++++++++++---
>  common/spl/Kconfig                            |   9 +
>  common/spl/spl_mmc.c                          |  12 +-
>  ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>  ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>  doc/kwboot.1                                  |   3 +-
>  doc/mvebu/cmd/bubt.txt                        |  25 +-
>  drivers/mtd/nand/raw/Kconfig                  |   4 +-
>  tools/kwbimage.c                              | 297 +++++++++++-------
>  tools/kwboot.c                                | 200 +++++++++++-
>  tools/mkimage.c                               |  11 +-
>  22 files changed, 768 insertions(+), 281 deletions(-)
>  copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
>  copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)
> 
> -- 
> 2.20.1
> 

Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

[Pali Rohár]

On Saturday 25 February 2023 22:49:56 Pali Rohár wrote:
> On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> > 
> > Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> 
> It looks like a hack but I think we do not have a better option for now.
> 
> If I understand the issue correctly then card-detect pin is unconnected
> for eMMC variant and used for checking if SD card is present for SD
> variant. Unconnected pin seems to have some internal pull-up/down which
> reports not-present state for eMMC variant. eMMC does not have any
> presence signal, so card-detect pin must be ignored for eMMC.
> 
> This looks like a chicken and egg problem and the only option to support
> both variants is to ignore card-detect pin and always try to initialize
> device connected to mmc controller (which may be eMMC or SD).

Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi
file and add there this? /delete-property/ cd-gpios;

> I do not know if there is a better option for ignoring card-detect pin
> in u-boot, so:
> 
> Acked-by: Pali Rohár <pali@kernel.org>
> 
> > ---
> >  configs/clearfog_defconfig      | 3 +--
> >  configs/clearfog_sata_defconfig | 8 ++++----
> >  2 files changed, 5 insertions(+), 6 deletions(-)
> > 
> > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > index 8cd35f9f1a..24e7c16ac7 100644
> > --- a/configs/clearfog_defconfig
> > +++ b/configs/clearfog_defconfig
> > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> >  CONFIG_CMD_TFTPPUT=y
> >  CONFIG_CMD_CACHE=y
> >  CONFIG_CMD_TIME=y
> > -CONFIG_CMD_MVEBU_BUBT=y
> >  CONFIG_ENV_OVERWRITE=y
> >  CONFIG_ENV_MIN_ENTRIES=128
> >  CONFIG_ARP_TIMEOUT=200
> > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> >  CONFIG_SYS_I2C_MVTWSI=y
> >  CONFIG_I2C_EEPROM=y
> >  CONFIG_SPL_I2C_EEPROM=y
> > -CONFIG_SUPPORT_EMMC_BOOT=y
> > +CONFIG_MMC_BROKEN_CD=y
> >  CONFIG_MMC_SDHCI=y
> >  CONFIG_MMC_SDHCI_SDMA=y
> >  CONFIG_MMC_SDHCI_MV=y
> > diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
> > index e9b36150ea..84f900bf50 100644
> > --- a/configs/clearfog_sata_defconfig
> > +++ b/configs/clearfog_sata_defconfig
> > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
> >  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
> >  CONFIG_NR_DRAM_BANKS=2
> > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> >  CONFIG_TARGET_CLEARFOG=y
> >  CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> >  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> >  CONFIG_SPL_TEXT_BASE=0x40000030
> >  CONFIG_SPL_SERIAL=y
> > +CONFIG_SPL_STACK=0x4002c000
> >  CONFIG_SPL=y
> >  CONFIG_DEBUG_UART_BASE=0xf1012000
> >  CONFIG_DEBUG_UART_CLOCK=250000000
> > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
> >  CONFIG_DEBUG_UART=y
> >  CONFIG_AHCI=y
> >  CONFIG_DISTRO_DEFAULTS=y
> > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> >  CONFIG_BOOTDELAY=3
> >  CONFIG_USE_PREBOOT=y
> >  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
> >  CONFIG_SPL_BSS_MAX_SIZE=0x4000
> >  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> >  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > -CONFIG_SPL_STACK=0x4002c000
> >  CONFIG_SPL_I2C=y
> >  CONFIG_SYS_MAXARGS=32
> >  CONFIG_CMD_TLV_EEPROM=y
> > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> >  CONFIG_CMD_TFTPPUT=y
> >  CONFIG_CMD_CACHE=y
> >  CONFIG_CMD_TIME=y
> > -CONFIG_CMD_MVEBU_BUBT=y
> >  CONFIG_ENV_OVERWRITE=y
> >  CONFIG_ENV_MIN_ENTRIES=128
> >  CONFIG_ARP_TIMEOUT=200
> > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
> >  CONFIG_SYS_I2C_MVTWSI=y
> >  CONFIG_I2C_EEPROM=y
> >  CONFIG_SPL_I2C_EEPROM=y
> > +CONFIG_MMC_BROKEN_CD=y
> >  CONFIG_SUPPORT_EMMC_BOOT=y
> >  CONFIG_MMC_SDHCI=y
> >  CONFIG_MMC_SDHCI_SDMA=y
> > -- 
> > 2.39.2
> > 

Re: [PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot

[Tony Dinh]

Hi Pali,

On Sat, Feb 25, 2023 at 1:13 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Friday 24 February 2023 19:58:37 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD4000000 to 0xF4000000
> > > and change its size from 64 MB to 8 MB. Definitions are already in
> > > MBUS_SPI_BASE/MBUS_SPI_SIZE macros. So define these macros also for SPL
> > > build, use them in env_sf_get_env_addr() function and move this function
> > > from spl.c to cpu.c to be available in Proper U-Boot too.
> >
> > Interesting! So would it  affect the board that has a 4MB SPI flash ?
>
> This change just allows to use read-only SPI0 CS0 Flash mapping in the
> env code in proper u-boot. If there is a board code which requires
> access to env from proper u-boot before relocation happens then this
> change allows it. But only if env is stored in the first 8MB of SPI0
> flash.
>
> Note that after relocation u-boot uses full-feature SPI driver for
> accessing flash memory, by coping its content to RAM during read.
>
> So any access to env after relocation should not be affected by this
> change.
>
> IIRC only Omnia board for now uses this feature (for configuring
> serdes based on env settings) and for now only in SPL.
>
> > I know there is a bug somewhere, because I need to set both
> > CONFIG_ENV_OFFSET and CONFIG_ENV_ADDR. One or the other is not enough.
>
> I am not sure for what is _ADDR needed (I am only on mobile for now, so
> I cannot check it)
>
> > I'm debugging an error that seemingly has something to do with the SPI
> > envs area: how u-boot set envs and recalculate checksum, and Linux
> > fw_setenv() seems to not be doing the same thing. This is on a 4MB SPI
> > mx25l3205d flash (Thecus N2350 board).
>
> Maybe you have set wrong env size or wrong flash erase block size?

I've double checked that in u-boot and Linux to make sure both use
64KB env size and 4K sector, and at the same location!  I was guessing
that the block protection is causing a problem, so I also had a patch
for the flash chip mx25l3205d to unprotect all blocks too (currently
u-boot spi-nor does not do that for the Macronix flash). But that
still doesn't help :) I think I might try moving the envs to a
different location to see if it helps.

Thanks,
Tony

>
> > It might also have something to do with a SPI flash being set to some
> > protected  blocks (in the Status Register upon boot).
> >
> > Thanks,
> > Tony
> >
> > >
> > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > ---
> > >  arch/arm/mach-mvebu/cpu.c              |  9 +++++++++
> > >  arch/arm/mach-mvebu/include/mach/cpu.h |  5 +++++
> > >  arch/arm/mach-mvebu/spl.c              | 13 -------------
> > >  3 files changed, 14 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> > > index c5089a91c747..97154aaa2a7e 100644
> > > --- a/arch/arm/mach-mvebu/cpu.c
> > > +++ b/arch/arm/mach-mvebu/cpu.c
> > > @@ -35,6 +35,15 @@ static const struct mbus_win windows[] = {
> > >  #endif
> > >  };
> > >
> > > +/* SPI0 CS0 Flash of size MBUS_SPI_SIZE is mapped to address MBUS_SPI_BASE */
> > > +#if CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> > > +    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= MBUS_SPI_SIZE
> > > +void *env_sf_get_env_addr(void)
> > > +{
> > > +       return (void *)MBUS_SPI_BASE + CONFIG_ENV_OFFSET;
> > > +}
> > > +#endif
> > > +
> > >  void lowlevel_init(void)
> > >  {
> > >         /*
> > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > index c17c2440f1b1..906a8737a401 100644
> > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > @@ -71,8 +71,13 @@ enum cpu_attrib {
> > >  #define MBUS_PCI_MEM_SIZE      ((MBUS_PCI_MAX_PORTS * 128) << 20)
> > >  #define MBUS_PCI_IO_BASE       0xF1100000
> > >  #define MBUS_PCI_IO_SIZE       ((MBUS_PCI_MAX_PORTS * 64) << 10)
> > > +#ifdef CONFIG_SPL_BUILD
> > > +#define MBUS_SPI_BASE          0xD4000000
> > > +#define MBUS_SPI_SIZE          (64 << 20)
> > > +#else
> > >  #define MBUS_SPI_BASE          0xF4000000
> > >  #define MBUS_SPI_SIZE          (8 << 20)
> > > +#endif
> > >  #define MBUS_DFX_BASE          0xF6000000
> > >  #define MBUS_DFX_SIZE          (1 << 20)
> > >  #define MBUS_BOOTROM_BASE      0xF8000000
> > > diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> > > index 02528e025d8c..6b8c72a71dab 100644
> > > --- a/arch/arm/mach-mvebu/spl.c
> > > +++ b/arch/arm/mach-mvebu/spl.c
> > > @@ -308,19 +308,6 @@ int board_return_to_bootrom(struct spl_image_info *spl_image,
> > >         hang();
> > >  }
> > >
> > > -/*
> > > - * SPI0 CS0 Flash is mapped to address range 0xD4000000 - 0xD7FFFFFF by BootROM.
> > > - * Proper U-Boot removes this direct mapping. So it is available only in SPL.
> > > - */
> > > -#if defined(CONFIG_SPL_ENV_IS_IN_SPI_FLASH) && \
> > > -    CONFIG_ENV_SPI_BUS == 0 && CONFIG_ENV_SPI_CS == 0 && \
> > > -    CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE <= 64*1024*1024
> > > -void *env_sf_get_env_addr(void)
> > > -{
> > > -       return (void *)0xD4000000 + CONFIG_ENV_OFFSET;
> > > -}
> > > -#endif
> > > -
> > >  void board_init_f(ulong dummy)
> > >  {
> > >         int ret;
> > > --
> > > 2.20.1
> > >

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,
Hi Martin,

On Sat, Feb 25, 2023 at 5:41 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Saturday 25 February 2023 11:47:07 Martin Rowe wrote:
> > > While I haven't tested this patchset - I have tested SPI booting with v2022.01 after applying lots of patches.
> > > I found that the magic value reported by bootrom when booting from SPI will be 0x34 on clearfog.
> > > The current sources only handle 0x32, hence having or not having SPL_SPI will always lead to returning to the bootrom.
> > >
> > > Please consider pulling in this patch:
> > > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d
> > > I can send it separately if you like.
> >
> > Tested with the patch on a Clearfog Base:
> > ================== Without SPL_SPI same return to BootROM
> > ...
> > mv_ddr: completed successfully
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> > BootROM: Image checksum verification PASSED
> >
> >
> > U-Boot 2023.04-rc2...
> > ================== With SPL_SPI loads directly from SPI
> > ...
> > mv_ddr: completed successfully
> > Trying to boot from SPI
> >
> >
> > U-Boot 2023.04-rc2...
> > ==================
> >
> > I'm not sure how to run proper timing tests on the process, but
> > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > direct from SPI around 4 seconds. I thought the goal of loading from
> > SPI directly was speed, but returning to BootROM is significantly
> > faster on this board.
>
> You should check SPI speed in DTS file and also in the defconfig.

I think we have probably seen this slowdown before. There is a TODO in
the way the DTS nodes are parsed by DM uclass. So this config must be
set in defconfig to get around that bug:
CONFIG_SF_DEFAULT_SPEED=50000000

All the best,
Tony
>
> > > which I have tested by adding these config options:
> >
> > I tested the new spi_defconfig with and without SPL_SPI; no other changes

Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

[Martin Rowe]

On Sat, 25 Feb 2023 at 22:14, Pali Rohár <pali@kernel.org> wrote:
> On Saturday 25 February 2023 22:49:56 Pali Rohár wrote:
> > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> > > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> > >
> > > Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> >
> > It looks like a hack but I think we do not have a better option for now.
> >
> > If I understand the issue correctly then card-detect pin is unconnected
> > for eMMC variant and used for checking if SD card is present for SD
> > variant. Unconnected pin seems to have some internal pull-up/down which
> > reports not-present state for eMMC variant. eMMC does not have any
> > presence signal, so card-detect pin must be ignored for eMMC.
> >
> > This looks like a chicken and egg problem and the only option to support
> > both variants is to ignore card-detect pin and always try to initialize
> > device connected to mmc controller (which may be eMMC or SD).
>
> Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi
> file and add there this? /delete-property/ cd-gpios;

I just tried this and the device is not detected again; adding
"non-removable" seems to be required if changing the dts.

> > I do not know if there is a better option for ignoring card-detect pin
> > in u-boot, so:

I should point out that I did investigate runtime detection. Patching
the fdt alone didn't seem to work using the hooks that were available,
so I started looking into how MMC was being initialised to figure out
if there was something changing the state of the device before it was
returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init
trying to figure out how we always end up with the "MMC: no card
present" message in the eMMC case. I was going to write some extra
logic around the mmc_getcd call, but realised there was already an
ifndef with a config that seemed like this exact use-case. Given that
config solved the problem it seemed like the cleanest solution.

> > Acked-by: Pali Rohár <pali@kernel.org>
> >
> > > ---
> > >  configs/clearfog_defconfig      | 3 +--
> > >  configs/clearfog_sata_defconfig | 8 ++++----
> > >  2 files changed, 5 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > > index 8cd35f9f1a..24e7c16ac7 100644
> > > --- a/configs/clearfog_defconfig
> > > +++ b/configs/clearfog_defconfig
> > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > >  CONFIG_CMD_TFTPPUT=y
> > >  CONFIG_CMD_CACHE=y
> > >  CONFIG_CMD_TIME=y
> > > -CONFIG_CMD_MVEBU_BUBT=y
> > >  CONFIG_ENV_OVERWRITE=y
> > >  CONFIG_ENV_MIN_ENTRIES=128
> > >  CONFIG_ARP_TIMEOUT=200
> > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> > >  CONFIG_SYS_I2C_MVTWSI=y
> > >  CONFIG_I2C_EEPROM=y
> > >  CONFIG_SPL_I2C_EEPROM=y
> > > -CONFIG_SUPPORT_EMMC_BOOT=y
> > > +CONFIG_MMC_BROKEN_CD=y
> > >  CONFIG_MMC_SDHCI=y
> > >  CONFIG_MMC_SDHCI_SDMA=y
> > >  CONFIG_MMC_SDHCI_MV=y
> > > diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
> > > index e9b36150ea..84f900bf50 100644
> > > --- a/configs/clearfog_sata_defconfig
> > > +++ b/configs/clearfog_sata_defconfig
> > > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
> > >  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > >  CONFIG_NR_DRAM_BANKS=2
> > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> > >  CONFIG_TARGET_CLEARFOG=y
> > >  CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > >  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > >  CONFIG_SPL_TEXT_BASE=0x40000030
> > >  CONFIG_SPL_SERIAL=y
> > > +CONFIG_SPL_STACK=0x4002c000
> > >  CONFIG_SPL=y
> > >  CONFIG_DEBUG_UART_BASE=0xf1012000
> > >  CONFIG_DEBUG_UART_CLOCK=250000000
> > > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
> > >  CONFIG_DEBUG_UART=y
> > >  CONFIG_AHCI=y
> > >  CONFIG_DISTRO_DEFAULTS=y
> > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> > >  CONFIG_BOOTDELAY=3
> > >  CONFIG_USE_PREBOOT=y
> > >  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> > > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
> > >  CONFIG_SPL_BSS_MAX_SIZE=0x4000
> > >  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> > >  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > > -CONFIG_SPL_STACK=0x4002c000
> > >  CONFIG_SPL_I2C=y
> > >  CONFIG_SYS_MAXARGS=32
> > >  CONFIG_CMD_TLV_EEPROM=y
> > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > >  CONFIG_CMD_TFTPPUT=y
> > >  CONFIG_CMD_CACHE=y
> > >  CONFIG_CMD_TIME=y
> > > -CONFIG_CMD_MVEBU_BUBT=y
> > >  CONFIG_ENV_OVERWRITE=y
> > >  CONFIG_ENV_MIN_ENTRIES=128
> > >  CONFIG_ARP_TIMEOUT=200
> > > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
> > >  CONFIG_SYS_I2C_MVTWSI=y
> > >  CONFIG_I2C_EEPROM=y
> > >  CONFIG_SPL_I2C_EEPROM=y
> > > +CONFIG_MMC_BROKEN_CD=y
> > >  CONFIG_SUPPORT_EMMC_BOOT=y
> > >  CONFIG_MMC_SDHCI=y
> > >  CONFIG_MMC_SDHCI_SDMA=y
> > > --
> > > 2.39.2
> > >

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

On Sat, 25 Feb 2023 at 21:16, Pali Rohár <pali@kernel.org> wrote:
> I think that the remaining part is to patch linux DTB file at runtime
> for emmc support. So if u-boot mmc device is of eMMC type then fixup
> linux dtb file and others do nothing.

One question I didn't think of when suggesting this: does runtime
patching the kernel's dtb break signed/verified booting? The reason I
ask is because we now only need to patch the kernel dtb, not the
u-boot one. If we needed to do both, then it would make sense to
handle them in the same way through u-boot. The barrier to creating a
patched kernel dtb file on its own is very low, so I'm not sure adding
some "magic" to u-boot to make it work is the best solution,
especially if it might break verified boot.

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Martin Rowe]

> > > I'm not sure how to run proper timing tests on the process, but
> > > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > direct from SPI around 4 seconds. I thought the goal of loading from
> > > SPI directly was speed, but returning to BootROM is significantly
> > > faster on this board.
> >
> > You should check SPI speed in DTS file and also in the defconfig.
>
> I think we have probably seen this slowdown before. There is a TODO in
> the way the DTS nodes are parsed by DM uclass. So this config must be
> set in defconfig to get around that bug:
> CONFIG_SF_DEFAULT_SPEED=50000000

That works and is much faster now. I'll submit it in a V2 for these
two patches once Pali's mvebu changes are accepted. Only question I
have is: should the faster speed be applied to all three defconfigs?
CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
MMC and SATA configs at the moment.

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Martin,

On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
>
> > > > I'm not sure how to run proper timing tests on the process, but
> > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > > direct from SPI around 4 seconds. I thought the goal of loading from
> > > > SPI directly was speed, but returning to BootROM is significantly
> > > > faster on this board.
> > >
> > > You should check SPI speed in DTS file and also in the defconfig.
> >
> > I think we have probably seen this slowdown before. There is a TODO in
> > the way the DTS nodes are parsed by DM uclass. So this config must be
> > set in defconfig to get around that bug:
> > CONFIG_SF_DEFAULT_SPEED=50000000
>
> That works and is much faster now. I'll submit it in a V2 for these
> two patches once Pali's mvebu changes are accepted. Only question I
> have is: should the faster speed be applied to all three defconfigs?
> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> MMC and SATA configs at the moment.

This is only a workaround to get the SPI probe to work correctly. The
real fix should be in spi_flash_probe()
./common/spl/spl_spi.c
        flash = spi_flash_probe(sf_bus, sf_cs,
                                CONFIG_SF_DEFAULT_SPEED,
                                CONFIG_SF_DEFAULT_MODE);
If spi_flash_probe() failed to get SPI max_hz from the DTS, the
fallback is CONFIG_SF_DEFAULT_SPEED.

IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
some other common place. And when we will have fixed the DTS parsing
problem, they can be removed.

I'd like to hear from Stefan and Pali if this approach sounds good.

All the best,
Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Sunday 26 February 2023 01:56:23 Martin Rowe wrote:
> On Sat, 25 Feb 2023 at 21:16, Pali Rohár <pali@kernel.org> wrote:
> > I think that the remaining part is to patch linux DTB file at runtime
> > for emmc support. So if u-boot mmc device is of eMMC type then fixup
> > linux dtb file and others do nothing.
> 
> One question I didn't think of when suggesting this: does runtime
> patching the kernel's dtb break signed/verified booting

I do not think so. Signature verification should be done before
patching.

> The reason I
> ask is because we now only need to patch the kernel dtb, not the
> u-boot one. If we needed to do both, then it would make sense to
> handle them in the same way through u-boot. The barrier to creating a
> patched kernel dtb file on its own is very low, so I'm not sure adding
> some "magic" to u-boot to make it work is the best solution,
> especially if it might break verified boot.

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> Hi Martin,
> 
> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> >
> > > > > I'm not sure how to run proper timing tests on the process, but
> > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > > > direct from SPI around 4 seconds. I thought the goal of loading from
> > > > > SPI directly was speed, but returning to BootROM is significantly
> > > > > faster on this board.
> > > >
> > > > You should check SPI speed in DTS file and also in the defconfig.
> > >
> > > I think we have probably seen this slowdown before. There is a TODO in
> > > the way the DTS nodes are parsed by DM uclass. So this config must be
> > > set in defconfig to get around that bug:
> > > CONFIG_SF_DEFAULT_SPEED=50000000
> >
> > That works and is much faster now. I'll submit it in a V2 for these
> > two patches once Pali's mvebu changes are accepted. Only question I
> > have is: should the faster speed be applied to all three defconfigs?
> > CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > MMC and SATA configs at the moment.
> 
> This is only a workaround to get the SPI probe to work correctly. The
> real fix should be in spi_flash_probe()
> ./common/spl/spl_spi.c
>         flash = spi_flash_probe(sf_bus, sf_cs,
>                                 CONFIG_SF_DEFAULT_SPEED,
>                                 CONFIG_SF_DEFAULT_MODE);
> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> fallback is CONFIG_SF_DEFAULT_SPEED.
> 
> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> some other common place. And when we will have fixed the DTS parsing
> problem, they can be removed.
> 
> I'd like to hear from Stefan and Pali if this approach sounds good.
> 
> All the best,
> Tony

Well, the maximal SPI speed depends on the wiring. You can have on the
board some SPI device which does not support high frequency.

But having some sane defaults in Kconfig for mvebu makes sense.

Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

[Pali Rohár]

On Sunday 26 February 2023 01:45:16 Martin Rowe wrote:
> On Sat, 25 Feb 2023 at 22:14, Pali Rohár <pali@kernel.org> wrote:
> > On Saturday 25 February 2023 22:49:56 Pali Rohár wrote:
> > > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> > > > A388 Clearfog MMC is either SD Card or eMMC with different behaviour for
> > > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> > > >
> > > > Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> > >
> > > It looks like a hack but I think we do not have a better option for now.
> > >
> > > If I understand the issue correctly then card-detect pin is unconnected
> > > for eMMC variant and used for checking if SD card is present for SD
> > > variant. Unconnected pin seems to have some internal pull-up/down which
> > > reports not-present state for eMMC variant. eMMC does not have any
> > > presence signal, so card-detect pin must be ignored for eMMC.
> > >
> > > This looks like a chicken and egg problem and the only option to support
> > > both variants is to ignore card-detect pin and always try to initialize
> > > device connected to mmc controller (which may be eMMC or SD).
> >
> > Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi
> > file and add there this? /delete-property/ cd-gpios;
> 
> I just tried this and the device is not detected again; adding
> "non-removable" seems to be required if changing the dts.
> 
> > > I do not know if there is a better option for ignoring card-detect pin
> > > in u-boot, so:
> 
> I should point out that I did investigate runtime detection.

But how you want to do that runtime detection? As I pointed above I
think it is impossible do runtime detection because it is chicken and
egg problem.

You can patch fdt only after u-boot initialize mmc, so this can be used
just for patching kernel fdt.

> Patching
> the fdt alone didn't seem to work using the hooks that were available,
> so I started looking into how MMC was being initialised to figure out
> if there was something changing the state of the device before it was
> returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init
> trying to figure out how we always end up with the "MMC: no card
> present" message in the eMMC case. I was going to write some extra
> logic around the mmc_getcd call, but realised there was already an
> ifndef with a config that seemed like this exact use-case. Given that
> config solved the problem it seemed like the cleanest solution.
> 
> > > Acked-by: Pali Rohár <pali@kernel.org>
> > >
> > > > ---
> > > >  configs/clearfog_defconfig      | 3 +--
> > > >  configs/clearfog_sata_defconfig | 8 ++++----
> > > >  2 files changed, 5 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
> > > > index 8cd35f9f1a..24e7c16ac7 100644
> > > > --- a/configs/clearfog_defconfig
> > > > +++ b/configs/clearfog_defconfig
> > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > > >  CONFIG_CMD_TFTPPUT=y
> > > >  CONFIG_CMD_CACHE=y
> > > >  CONFIG_CMD_TIME=y
> > > > -CONFIG_CMD_MVEBU_BUBT=y
> > > >  CONFIG_ENV_OVERWRITE=y
> > > >  CONFIG_ENV_MIN_ENTRIES=128
> > > >  CONFIG_ARP_TIMEOUT=200
> > > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> > > >  CONFIG_SYS_I2C_MVTWSI=y
> > > >  CONFIG_I2C_EEPROM=y
> > > >  CONFIG_SPL_I2C_EEPROM=y
> > > > -CONFIG_SUPPORT_EMMC_BOOT=y
> > > > +CONFIG_MMC_BROKEN_CD=y
> > > >  CONFIG_MMC_SDHCI=y
> > > >  CONFIG_MMC_SDHCI_SDMA=y
> > > >  CONFIG_MMC_SDHCI_MV=y
> > > > diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig
> > > > index e9b36150ea..84f900bf50 100644
> > > > --- a/configs/clearfog_sata_defconfig
> > > > +++ b/configs/clearfog_sata_defconfig
> > > > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
> > > >  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > > >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > > >  CONFIG_NR_DRAM_BANKS=2
> > > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> > > >  CONFIG_TARGET_CLEARFOG=y
> > > >  CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > > >  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > > >  CONFIG_SPL_TEXT_BASE=0x40000030
> > > >  CONFIG_SPL_SERIAL=y
> > > > +CONFIG_SPL_STACK=0x4002c000
> > > >  CONFIG_SPL=y
> > > >  CONFIG_DEBUG_UART_BASE=0xf1012000
> > > >  CONFIG_DEBUG_UART_CLOCK=250000000
> > > > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
> > > >  CONFIG_DEBUG_UART=y
> > > >  CONFIG_AHCI=y
> > > >  CONFIG_DISTRO_DEFAULTS=y
> > > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> > > >  CONFIG_BOOTDELAY=3
> > > >  CONFIG_USE_PREBOOT=y
> > > >  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> > > > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
> > > >  CONFIG_SPL_BSS_MAX_SIZE=0x4000
> > > >  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> > > >  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > > > -CONFIG_SPL_STACK=0x4002c000
> > > >  CONFIG_SPL_I2C=y
> > > >  CONFIG_SYS_MAXARGS=32
> > > >  CONFIG_CMD_TLV_EEPROM=y
> > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > > >  CONFIG_CMD_TFTPPUT=y
> > > >  CONFIG_CMD_CACHE=y
> > > >  CONFIG_CMD_TIME=y
> > > > -CONFIG_CMD_MVEBU_BUBT=y
> > > >  CONFIG_ENV_OVERWRITE=y
> > > >  CONFIG_ENV_MIN_ENTRIES=128
> > > >  CONFIG_ARP_TIMEOUT=200
> > > > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
> > > >  CONFIG_SYS_I2C_MVTWSI=y
> > > >  CONFIG_I2C_EEPROM=y
> > > >  CONFIG_SPL_I2C_EEPROM=y
> > > > +CONFIG_MMC_BROKEN_CD=y
> > > >  CONFIG_SUPPORT_EMMC_BOOT=y
> > > >  CONFIG_MMC_SDHCI=y
> > > >  CONFIG_MMC_SDHCI_SDMA=y
> > > > --
> > > > 2.39.2
> > > >

Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection

[Martin Rowe]

On Sun, 26 Feb 2023 at 11:18, Pali Rohár <pali@kernel.org> wrote:

> On Sunday 26 February 2023 01:45:16 Martin Rowe wrote:
> > On Sat, 25 Feb 2023 at 22:14, Pali Rohár <pali@kernel.org> wrote:
> > > On Saturday 25 February 2023 22:49:56 Pali Rohár wrote:
> > > > On Saturday 25 February 2023 11:42:19 Martin Rowe wrote:
> > > > > A388 Clearfog MMC is either SD Card or eMMC with different
> behaviour for
> > > > > both. Setting MMC_BROKEN_CD allows both to correctly detect MMC.
> > > > >
> > > > > Signed-off-by: Martin Rowe <martin.p.rowe@gmail.com>
> > > >
> > > > It looks like a hack but I think we do not have a better option for
> now.
> > > >
> > > > If I understand the issue correctly then card-detect pin is
> unconnected
> > > > for eMMC variant and used for checking if SD card is present for SD
> > > > variant. Unconnected pin seems to have some internal pull-up/down
> which
> > > > reports not-present state for eMMC variant. eMMC does not have any
> > > > presence signal, so card-detect pin must be ignored for eMMC.
> > > >
> > > > This looks like a chicken and egg problem and the only option to
> support
> > > > both variants is to ignore card-detect pin and always try to
> initialize
> > > > device connected to mmc controller (which may be eMMC or SD).
> > >
> > > Hm... maybe better way could be to edit armada-388-clearfog-u-boot.dtsi
> > > file and add there this? /delete-property/ cd-gpios;
> >
> > I just tried this and the device is not detected again; adding
> > "non-removable" seems to be required if changing the dts.
> >
> > > > I do not know if there is a better option for ignoring card-detect
> pin
> > > > in u-boot, so:
> >
> > I should point out that I did investigate runtime detection.
>
> But how you want to do that runtime detection? As I pointed above I
> think it is impossible do runtime detection because it is chicken and
> egg problem.
>
> You can patch fdt only after u-boot initialize mmc, so this can be used
> just for patching kernel fdt.
>

I was just trying to address your concerns about the solution looking like
a "hack". I did investigate it, and that work confirmed the issues you
expected, so that's confirmation that there isn't a better option. I think
we're saying the same thing :)

I'll look at runtime patching the kernel fdt, but it might not be as quick
a turn around as the defconfig work. If anyone looks at it before me, the
fdt memory allocation needs to be increased by 2 to fit "non-removable" in
the space left by removing the "cd-gpios".

> Patching
> > the fdt alone didn't seem to work using the hooks that were available,
> > so I started looking into how MMC was being initialised to figure out
> > if there was something changing the state of the device before it was
> > returned to BootROM. I ended up in drivers/mmc/mmc.c mmc_start_init
> > trying to figure out how we always end up with the "MMC: no card
> > present" message in the eMMC case. I was going to write some extra
> > logic around the mmc_getcd call, but realised there was already an
> > ifndef with a config that seemed like this exact use-case. Given that
> > config solved the problem it seemed like the cleanest solution.
> >
> > > > Acked-by: Pali Rohár <pali@kernel.org>
> > > >
> > > > > ---
> > > > >  configs/clearfog_defconfig      | 3 +--
> > > > >  configs/clearfog_sata_defconfig | 8 ++++----
> > > > >  2 files changed, 5 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/configs/clearfog_defconfig
> b/configs/clearfog_defconfig
> > > > > index 8cd35f9f1a..24e7c16ac7 100644
> > > > > --- a/configs/clearfog_defconfig
> > > > > +++ b/configs/clearfog_defconfig
> > > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > > > >  CONFIG_CMD_TFTPPUT=y
> > > > >  CONFIG_CMD_CACHE=y
> > > > >  CONFIG_CMD_TIME=y
> > > > > -CONFIG_CMD_MVEBU_BUBT=y
> > > > >  CONFIG_ENV_OVERWRITE=y
> > > > >  CONFIG_ENV_MIN_ENTRIES=128
> > > > >  CONFIG_ARP_TIMEOUT=200
> > > > > @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y
> > > > >  CONFIG_SYS_I2C_MVTWSI=y
> > > > >  CONFIG_I2C_EEPROM=y
> > > > >  CONFIG_SPL_I2C_EEPROM=y
> > > > > -CONFIG_SUPPORT_EMMC_BOOT=y
> > > > > +CONFIG_MMC_BROKEN_CD=y
> > > > >  CONFIG_MMC_SDHCI=y
> > > > >  CONFIG_MMC_SDHCI_SDMA=y
> > > > >  CONFIG_MMC_SDHCI_MV=y
> > > > > diff --git a/configs/clearfog_sata_defconfig
> b/configs/clearfog_sata_defconfig
> > > > > index e9b36150ea..84f900bf50 100644
> > > > > --- a/configs/clearfog_sata_defconfig
> > > > > +++ b/configs/clearfog_sata_defconfig
> > > > > @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x00800000
> > > > >  CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > > > >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > > > >  CONFIG_NR_DRAM_BANKS=2
> > > > > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > > > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> > > > >  CONFIG_TARGET_CLEARFOG=y
> > > > >  CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> > > > >  CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> > > > >  CONFIG_SPL_TEXT_BASE=0x40000030
> > > > >  CONFIG_SPL_SERIAL=y
> > > > > +CONFIG_SPL_STACK=0x4002c000
> > > > >  CONFIG_SPL=y
> > > > >  CONFIG_DEBUG_UART_BASE=0xf1012000
> > > > >  CONFIG_DEBUG_UART_CLOCK=250000000
> > > > > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x800000
> > > > >  CONFIG_DEBUG_UART=y
> > > > >  CONFIG_AHCI=y
> > > > >  CONFIG_DISTRO_DEFAULTS=y
> > > > > -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > > > > -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff0000
> > > > >  CONFIG_BOOTDELAY=3
> > > > >  CONFIG_USE_PREBOOT=y
> > > > >  CONFIG_SYS_CONSOLE_INFO_QUIET=y
> > > > > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000
> > > > >  CONFIG_SPL_BSS_MAX_SIZE=0x4000
> > > > >  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> > > > >  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> > > > > -CONFIG_SPL_STACK=0x4002c000
> > > > >  CONFIG_SPL_I2C=y
> > > > >  CONFIG_SYS_MAXARGS=32
> > > > >  CONFIG_CMD_TLV_EEPROM=y
> > > > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y
> > > > >  CONFIG_CMD_TFTPPUT=y
> > > > >  CONFIG_CMD_CACHE=y
> > > > >  CONFIG_CMD_TIME=y
> > > > > -CONFIG_CMD_MVEBU_BUBT=y
> > > > >  CONFIG_ENV_OVERWRITE=y
> > > > >  CONFIG_ENV_MIN_ENTRIES=128
> > > > >  CONFIG_ARP_TIMEOUT=200
> > > > > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y
> > > > >  CONFIG_SYS_I2C_MVTWSI=y
> > > > >  CONFIG_I2C_EEPROM=y
> > > > >  CONFIG_SPL_I2C_EEPROM=y
> > > > > +CONFIG_MMC_BROKEN_CD=y
> > > > >  CONFIG_SUPPORT_EMMC_BOOT=y
> > > > >  CONFIG_MMC_SDHCI=y
> > > > >  CONFIG_MMC_SDHCI_SDMA=y
> > > > > --
> > > > > 2.39.2
> > > > >
>

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,

On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> > Hi Martin,
> >
> > On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > >
> > > > > > I'm not sure how to run proper timing tests on the process, but
> > > > > > stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > > > > 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > > > > direct from SPI around 4 seconds. I thought the goal of loading from
> > > > > > SPI directly was speed, but returning to BootROM is significantly
> > > > > > faster on this board.
> > > > >
> > > > > You should check SPI speed in DTS file and also in the defconfig.
> > > >
> > > > I think we have probably seen this slowdown before. There is a TODO in
> > > > the way the DTS nodes are parsed by DM uclass. So this config must be
> > > > set in defconfig to get around that bug:
> > > > CONFIG_SF_DEFAULT_SPEED=50000000
> > >
> > > That works and is much faster now. I'll submit it in a V2 for these
> > > two patches once Pali's mvebu changes are accepted. Only question I
> > > have is: should the faster speed be applied to all three defconfigs?
> > > CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > > MMC and SATA configs at the moment.
> >
> > This is only a workaround to get the SPI probe to work correctly. The
> > real fix should be in spi_flash_probe()
> > ./common/spl/spl_spi.c
> >         flash = spi_flash_probe(sf_bus, sf_cs,
> >                                 CONFIG_SF_DEFAULT_SPEED,
> >                                 CONFIG_SF_DEFAULT_MODE);
> > If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> > fallback is CONFIG_SF_DEFAULT_SPEED.
> >
> > IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> > CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> > some other common place. And when we will have fixed the DTS parsing
> > problem, they can be removed.
> >
> > I'd like to hear from Stefan and Pali if this approach sounds good.
> >
> > All the best,
> > Tony
>
> Well, the maximal SPI speed depends on the wiring. You can have on the
> board some SPI device which does not support high frequency.
>
> But having some sane defaults in Kconfig for mvebu makes sense.

The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
does not specify it. I think the sane default value is 10_000_000
(grepping the Armada* DTS files showing the slowest spi-max-frequency
is 10_000_000). While a big improvement, it is not fast enough for
many other boards. So we still need to define it in those board
defconfigs (before fixing that bug), or use return to BootROM.

All the best,
Tony,

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Stefan Roese]

Hi Tony,

On 2/27/23 01:11, Tony Dinh wrote:
> Hi Pali,
> 
> On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
>>
>> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
>>> Hi Martin,
>>>
>>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
>>>>
>>>>>>> I'm not sure how to run proper timing tests on the process, but
>>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
>>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
>>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
>>>>>>> SPI directly was speed, but returning to BootROM is significantly
>>>>>>> faster on this board.
>>>>>>
>>>>>> You should check SPI speed in DTS file and also in the defconfig.
>>>>>
>>>>> I think we have probably seen this slowdown before. There is a TODO in
>>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
>>>>> set in defconfig to get around that bug:
>>>>> CONFIG_SF_DEFAULT_SPEED=50000000
>>>>
>>>> That works and is much faster now. I'll submit it in a V2 for these
>>>> two patches once Pali's mvebu changes are accepted. Only question I
>>>> have is: should the faster speed be applied to all three defconfigs?
>>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
>>>> MMC and SATA configs at the moment.
>>>
>>> This is only a workaround to get the SPI probe to work correctly. The
>>> real fix should be in spi_flash_probe()
>>> ./common/spl/spl_spi.c
>>>          flash = spi_flash_probe(sf_bus, sf_cs,
>>>                                  CONFIG_SF_DEFAULT_SPEED,
>>>                                  CONFIG_SF_DEFAULT_MODE);
>>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
>>> fallback is CONFIG_SF_DEFAULT_SPEED.
>>>
>>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
>>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
>>> some other common place. And when we will have fixed the DTS parsing
>>> problem, they can be removed.
>>>
>>> I'd like to hear from Stefan and Pali if this approach sounds good.
>>>
>>> All the best,
>>> Tony
>>
>> Well, the maximal SPI speed depends on the wiring. You can have on the
>> board some SPI device which does not support high frequency.
>>
>> But having some sane defaults in Kconfig for mvebu makes sense.

Agreed.

> The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> does not specify it. I think the sane default value is 10_000_000
> (grepping the Armada* DTS files showing the slowest spi-max-frequency
> is 10_000_000). While a big improvement, it is not fast enough for
> many other boards. So we still need to define it in those board
> defconfigs (before fixing that bug), or use return to BootROM.

I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
currently has no platform- / board- specific configurations. Perhaps
it can be done in a mach-mvebu Kconfig file instead?

Thanks,
Stefan

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Pali,

On 2/25/23 23:00, Pali Rohár wrote:
> On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
>> This patch series contains various improvements and fixes for existing
>> logical errors. Boot phase was adjusted to match behavior of Armada 385
>> BootROM by inspecting and disassembling of BootROM binary dump itself.
>> Important information are included in documentation patch for kwboot.
>> Most of the changes are untested, hence this patch series is just RFC.
>> So please test changes before applying, idealy on SPI, SATA and SD/MMC.
>> Nevertheless all patches on github passed CI testing in this PR:
>> https://github.com/u-boot/u-boot/pull/275
> 
> Patches were tested on more boards and seems there is no reported issue,
> but other improvements.
> 
> So do you need something to modify in this relatively big patch series?
> If it is not really needed I would like to not send it again because
> denx servers are not able to handle it. And it take me lot of time to
> send patches over emails to denx servers.

I'm fine with applying the series as-is. I'm a bit hesitant though, if
it should be applied to master or to next. As Tom clearly noticed, that
only fixes should be added after rc2 this time.

What is your thinking on this?

Thanks,
Stefan

> 
>>
>> Pali Rohár (59):
>>    tools: kwbimage: Fix generating, verifying and extracting SDIO
>>      kwbimage
>>    tools: kwboot: Fix parsing SDIO kwbimage
>>    arm: mvebu: spl: Fix parsing SDIO kwbimage
>>    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>>    tools: kwbimage: Fix generating, verifying and extracting SATA
>>      kwbimage
>>    tools: kwboot: Fix parsing SATA kwbimage
>>    arm: mvebu: spl: Fix parsing SATA kwbimage
>>    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>>    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>>      BOOT_DEVICE_MMC2_2
>>    arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
>>    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>>    arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
>>    tools: kwboot: Add more documentation references
>>    tools: kwboot: Add image type documentation
>>    tools: kwboot: Fix parsing UART image without data checksum
>>    tools: kwboot: Validate optional kwbimage v1 headers
>>    tools: kwboot: Add check that kwbimage contains DDR init code
>>    tools: kwboot: Fix patching of SPI/NOR XIP images
>>    tools: kwboot: Show image type and error parsing reasons
>>    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>>    cmd: mvebu/bubt: Add support for writing image to SATA disk
>>    cmd: mvebu/bubt: Add support for reading image from the SATA disk
>>      partition
>>    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>>    cmd: mvebu/bubt: Mark all local symbols as static
>>    cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
>>    cmd: mvebu/bubt: Check also A8K boot image checksum
>>    cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
>>    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>>    cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
>>      'fuse_read_u64' defined but not used
>>    cmd: mvebu/bubt: Enable command by default
>>    tools: kwbimage: Fix dumping register set / DATA commands
>>    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>>    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>>    tools: kwbimage: Fix dumping NAND_BLKSZ
>>    tools: kwbimage: Fix generating of kwbimage v0 header checksum
>>    tools: kwbimage: Fix endianity when printing kwbimage header
>>    tools: kwbimage: Reject mkimage -F option
>>    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
>>    tools: kwbimage: Print binary image offset as size
>>    tools: kwbimage: Print image data offset when printing kwbimage header
>>    tools: kwbimage: Simplify add_secure_header_v1()
>>    tools: kwbimage: Rename imagesz to dataoff
>>    tools: kwbimage: Fix generating secure boot data image signature
>>    tools: kwbimage: Fix invalid secure boot header signature
>>    tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
>>    tools: kwbimage: Add support for XIP SPI/NOR images
>>    tools: mkimage: Print human readable error when -d is not specified
>>    tools: mkimage: Do not try to open datafile when it is skipped
>>    tools: kwbimage: Add support for creating an image with no data
>>    arm: mvebu: Add support for generating NAND kwbimage
>>    arm: mvebu: Add support for generating PEX kwbimage
>>    arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>>    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>>    arm: mvebu: clearfog: Add defconfig for SATA booting
>>    arm: mvebu: Remove A39x relicts
>>    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>>    arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
>>    arm: mvebu: Define SPL memory maps
>>    doc/kwboot.1: Update example description
>>
>>   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>>   arch/arm/mach-mvebu/Makefile                  |  13 +
>>   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>>   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>>   arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
>>   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>>   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>>   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>>   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>>   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>>   cmd/mvebu/Kconfig                             |  18 ++
>>   cmd/mvebu/bubt.c                              | 253 ++++++++++++---
>>   common/spl/Kconfig                            |   9 +
>>   common/spl/spl_mmc.c                          |  12 +-
>>   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>>   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>>   doc/kwboot.1                                  |   3 +-
>>   doc/mvebu/cmd/bubt.txt                        |  25 +-
>>   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>>   tools/kwbimage.c                              | 297 +++++++++++-------
>>   tools/kwboot.c                                | 200 +++++++++++-
>>   tools/mkimage.c                               |  11 +-
>>   22 files changed, 768 insertions(+), 281 deletions(-)
>>   copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
>>   copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)
>>
>> -- 
>> 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

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
> Hi Pali,
> 
> On 2/25/23 23:00, Pali Rohár wrote:
> > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> > > This patch series contains various improvements and fixes for existing
> > > logical errors. Boot phase was adjusted to match behavior of Armada 385
> > > BootROM by inspecting and disassembling of BootROM binary dump itself.
> > > Important information are included in documentation patch for kwboot.
> > > Most of the changes are untested, hence this patch series is just RFC.
> > > So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> > > Nevertheless all patches on github passed CI testing in this PR:
> > > https://github.com/u-boot/u-boot/pull/275
> > 
> > Patches were tested on more boards and seems there is no reported issue,
> > but other improvements.
> > 
> > So do you need something to modify in this relatively big patch series?
> > If it is not really needed I would like to not send it again because
> > denx servers are not able to handle it. And it take me lot of time to
> > send patches over emails to denx servers.
> 
> I'm fine with applying the series as-is. I'm a bit hesitant though, if
> it should be applied to master or to next. As Tom clearly noticed, that
> only fixes should be added after rc2 this time.
> 
> What is your thinking on this?

Well, I do not know. AFAIK more patches here are fixing broken mvebu
boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?

> Thanks,
> Stefan
> 
> > 
> > > 
> > > Pali Rohár (59):
> > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
> > >      kwbimage
> > >    tools: kwboot: Fix parsing SDIO kwbimage
> > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
> > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> > >    tools: kwbimage: Fix generating, verifying and extracting SATA
> > >      kwbimage
> > >    tools: kwboot: Fix parsing SATA kwbimage
> > >    arm: mvebu: spl: Fix parsing SATA kwbimage
> > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
> > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> > >      BOOT_DEVICE_MMC2_2
> > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
> > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> > >    arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
> > >    tools: kwboot: Add more documentation references
> > >    tools: kwboot: Add image type documentation
> > >    tools: kwboot: Fix parsing UART image without data checksum
> > >    tools: kwboot: Validate optional kwbimage v1 headers
> > >    tools: kwboot: Add check that kwbimage contains DDR init code
> > >    tools: kwboot: Fix patching of SPI/NOR XIP images
> > >    tools: kwboot: Show image type and error parsing reasons
> > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
> > >    cmd: mvebu/bubt: Add support for reading image from the SATA disk
> > >      partition
> > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
> > >    cmd: mvebu/bubt: Mark all local symbols as static
> > >    cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
> > >    cmd: mvebu/bubt: Check also A8K boot image checksum
> > >    cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
> > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> > >    cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
> > >      'fuse_read_u64' defined but not used
> > >    cmd: mvebu/bubt: Enable command by default
> > >    tools: kwbimage: Fix dumping register set / DATA commands
> > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> > >    tools: kwbimage: Fix dumping NAND_BLKSZ
> > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
> > >    tools: kwbimage: Fix endianity when printing kwbimage header
> > >    tools: kwbimage: Reject mkimage -F option
> > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
> > >    tools: kwbimage: Print binary image offset as size
> > >    tools: kwbimage: Print image data offset when printing kwbimage header
> > >    tools: kwbimage: Simplify add_secure_header_v1()
> > >    tools: kwbimage: Rename imagesz to dataoff
> > >    tools: kwbimage: Fix generating secure boot data image signature
> > >    tools: kwbimage: Fix invalid secure boot header signature
> > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
> > >    tools: kwbimage: Add support for XIP SPI/NOR images
> > >    tools: mkimage: Print human readable error when -d is not specified
> > >    tools: mkimage: Do not try to open datafile when it is skipped
> > >    tools: kwbimage: Add support for creating an image with no data
> > >    arm: mvebu: Add support for generating NAND kwbimage
> > >    arm: mvebu: Add support for generating PEX kwbimage
> > >    arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
> > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
> > >    arm: mvebu: clearfog: Add defconfig for SATA booting
> > >    arm: mvebu: Remove A39x relicts
> > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
> > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
> > >    arm: mvebu: Define SPL memory maps
> > >    doc/kwboot.1: Update example description
> > > 
> > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
> > >   arch/arm/mach-mvebu/Makefile                  |  13 +
> > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
> > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
> > >   arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
> > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
> > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
> > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
> > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
> > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
> > >   cmd/mvebu/Kconfig                             |  18 ++
> > >   cmd/mvebu/bubt.c                              | 253 ++++++++++++---
> > >   common/spl/Kconfig                            |   9 +
> > >   common/spl/spl_mmc.c                          |  12 +-
> > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
> > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
> > >   doc/kwboot.1                                  |   3 +-
> > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
> > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
> > >   tools/kwbimage.c                              | 297 +++++++++++-------
> > >   tools/kwboot.c                                | 200 +++++++++++-
> > >   tools/mkimage.c                               |  11 +-
> > >   22 files changed, 768 insertions(+), 281 deletions(-)
> > >   copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
> > >   copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)
> > > 
> > > -- 
> > > 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

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Martin Rowe]

On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org> wrote:

> On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
> > Hi Pali,
> >
> > On 2/25/23 23:00, Pali Rohár wrote:
> > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> > > > This patch series contains various improvements and fixes for
> existing
> > > > logical errors. Boot phase was adjusted to match behavior of Armada
> 385
> > > > BootROM by inspecting and disassembling of BootROM binary dump
> itself.
> > > > Important information are included in documentation patch for kwboot.
> > > > Most of the changes are untested, hence this patch series is just
> RFC.
> > > > So please test changes before applying, idealy on SPI, SATA and
> SD/MMC.
> > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > https://github.com/u-boot/u-boot/pull/275
> > >
> > > Patches were tested on more boards and seems there is no reported
> issue,
> > > but other improvements.
> > >
> > > So do you need something to modify in this relatively big patch series?
> > > If it is not really needed I would like to not send it again because
> > > denx servers are not able to handle it. And it take me lot of time to
> > > send patches over emails to denx servers.
> >
> > I'm fine with applying the series as-is. I'm a bit hesitant though, if
> > it should be applied to master or to next. As Tom clearly noticed, that
> > only fixes should be added after rc2 this time.
> >
> > What is your thinking on this?
>
> Well, I do not know. AFAIK more patches here are fixing broken mvebu
> boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
>

A388 Clearfog was definitely broken prior to this patchset. There is quite
a bit of churn that this has caused for some OpenWRT users [1] as well as
for me. It would be nice to have a stable build for these boards.

[1] https://github.com/openwrt/openwrt/issues/11661


> > Thanks,
> > Stefan
> >
> > >
> > > >
> > > > Pali Rohár (59):
> > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
> > > >      kwbimage
> > > >    tools: kwboot: Fix parsing SDIO kwbimage
> > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
> > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
> > > >      kwbimage
> > > >    tools: kwboot: Fix parsing SATA kwbimage
> > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
> > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
> > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> > > >      BOOT_DEVICE_MMC2_2
> > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC boot
> partition
> > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> > > >    arm: mvebu: spl: Fix support for loading U-Boot proper from SD
> card
> > > >    tools: kwboot: Add more documentation references
> > > >    tools: kwboot: Add image type documentation
> > > >    tools: kwboot: Fix parsing UART image without data checksum
> > > >    tools: kwboot: Validate optional kwbimage v1 headers
> > > >    tools: kwboot: Add check that kwbimage contains DDR init code
> > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
> > > >    tools: kwboot: Show image type and error parsing reasons
> > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
> > > >    cmd: mvebu/bubt: Add support for reading image from the SATA disk
> > > >      partition
> > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
> > > >    cmd: mvebu/bubt: Mark all local symbols as static
> > > >    cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
> > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
> > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit Armada
> SoCs
> > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> > > >    cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
> > > >      'fuse_read_u64' defined but not used
> > > >    cmd: mvebu/bubt: Enable command by default
> > > >    tools: kwbimage: Fix dumping register set / DATA commands
> > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
> > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
> > > >    tools: kwbimage: Fix endianity when printing kwbimage header
> > > >    tools: kwbimage: Reject mkimage -F option
> > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
> > > >    tools: kwbimage: Print binary image offset as size
> > > >    tools: kwbimage: Print image data offset when printing kwbimage
> header
> > > >    tools: kwbimage: Simplify add_secure_header_v1()
> > > >    tools: kwbimage: Rename imagesz to dataoff
> > > >    tools: kwbimage: Fix generating secure boot data image signature
> > > >    tools: kwbimage: Fix invalid secure boot header signature
> > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP
> images
> > > >    tools: kwbimage: Add support for XIP SPI/NOR images
> > > >    tools: mkimage: Print human readable error when -d is not
> specified
> > > >    tools: mkimage: Do not try to open datafile when it is skipped
> > > >    tools: kwbimage: Add support for creating an image with no data
> > > >    arm: mvebu: Add support for generating NAND kwbimage
> > > >    arm: mvebu: Add support for generating PEX kwbimage
> > > >    arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC)
> options
> > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
> > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
> > > >    arm: mvebu: Remove A39x relicts
> > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
> > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
> > > >    arm: mvebu: Define SPL memory maps
> > > >    doc/kwboot.1: Update example description
> > > >
> > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
> > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
> > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
> > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
> > > >   arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
> > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
> > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
> > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
> > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
> > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
> > > >   cmd/mvebu/Kconfig                             |  18 ++
> > > >   cmd/mvebu/bubt.c                              | 253 ++++++++++++---
> > > >   common/spl/Kconfig                            |   9 +
> > > >   common/spl/spl_mmc.c                          |  12 +-
> > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
> > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
> > > >   doc/kwboot.1                                  |   3 +-
> > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
> > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
> > > >   tools/kwbimage.c                              | 297
> +++++++++++-------
> > > >   tools/kwboot.c                                | 200 +++++++++++-
> > > >   tools/mkimage.c                               |  11 +-
> > > >   22 files changed, 768 insertions(+), 281 deletions(-)
> > > >   copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
> > > >   copy configs/{db-88f6820-amc_defconfig =>
> db-88f6820-amc_nand_defconfig} (92%)
> > > >
> > > > --
> > > > 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
>

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Stefan,

On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese <sr@denx.de> wrote:
>
> Hi Tony,
>
> On 2/27/23 01:11, Tony Dinh wrote:
> > Hi Pali,
> >
> > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
> >>
> >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> >>> Hi Martin,
> >>>
> >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> >>>>
> >>>>>>> I'm not sure how to run proper timing tests on the process, but
> >>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> >>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> >>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
> >>>>>>> SPI directly was speed, but returning to BootROM is significantly
> >>>>>>> faster on this board.
> >>>>>>
> >>>>>> You should check SPI speed in DTS file and also in the defconfig.
> >>>>>
> >>>>> I think we have probably seen this slowdown before. There is a TODO in
> >>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
> >>>>> set in defconfig to get around that bug:
> >>>>> CONFIG_SF_DEFAULT_SPEED=50000000
> >>>>
> >>>> That works and is much faster now. I'll submit it in a V2 for these
> >>>> two patches once Pali's mvebu changes are accepted. Only question I
> >>>> have is: should the faster speed be applied to all three defconfigs?
> >>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> >>>> MMC and SATA configs at the moment.
> >>>
> >>> This is only a workaround to get the SPI probe to work correctly. The
> >>> real fix should be in spi_flash_probe()
> >>> ./common/spl/spl_spi.c
> >>>          flash = spi_flash_probe(sf_bus, sf_cs,
> >>>                                  CONFIG_SF_DEFAULT_SPEED,
> >>>                                  CONFIG_SF_DEFAULT_MODE);
> >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> >>> fallback is CONFIG_SF_DEFAULT_SPEED.
> >>>
> >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> >>> some other common place. And when we will have fixed the DTS parsing
> >>> problem, they can be removed.
> >>>
> >>> I'd like to hear from Stefan and Pali if this approach sounds good.
> >>>
> >>> All the best,
> >>> Tony
> >>
> >> Well, the maximal SPI speed depends on the wiring. You can have on the
> >> board some SPI device which does not support high frequency.
> >>
> >> But having some sane defaults in Kconfig for mvebu makes sense.
>
> Agreed.
>
> > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> > does not specify it. I think the sane default value is 10_000_000
> > (grepping the Armada* DTS files showing the slowest spi-max-frequency
> > is 10_000_000). While a big improvement, it is not fast enough for
> > many other boards. So we still need to define it in those board
> > defconfigs (before fixing that bug), or use return to BootROM.
>
> I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
> Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
> currently has no platform- / board- specific configurations. Perhaps
> it can be done in a mach-mvebu Kconfig file instead?

Yes, I think it should be done in mach-mvebu Kconfig, too. I will run
some tests.

Thanks,
Tony

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,

On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Stefan,
>
> On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese <sr@denx.de> wrote:
> >
> > Hi Tony,
> >
> > On 2/27/23 01:11, Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
> > >>
> > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> > >>> Hi Martin,
> > >>>
> > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > >>>>
> > >>>>>>> I'm not sure how to run proper timing tests on the process, but
> > >>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > >>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > >>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
> > >>>>>>> SPI directly was speed, but returning to BootROM is significantly
> > >>>>>>> faster on this board.
> > >>>>>>
> > >>>>>> You should check SPI speed in DTS file and also in the defconfig.
> > >>>>>
> > >>>>> I think we have probably seen this slowdown before. There is a TODO in
> > >>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
> > >>>>> set in defconfig to get around that bug:
> > >>>>> CONFIG_SF_DEFAULT_SPEED=50000000
> > >>>>
> > >>>> That works and is much faster now. I'll submit it in a V2 for these
> > >>>> two patches once Pali's mvebu changes are accepted. Only question I
> > >>>> have is: should the faster speed be applied to all three defconfigs?
> > >>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > >>>> MMC and SATA configs at the moment.
> > >>>
> > >>> This is only a workaround to get the SPI probe to work correctly. The
> > >>> real fix should be in spi_flash_probe()
> > >>> ./common/spl/spl_spi.c
> > >>>          flash = spi_flash_probe(sf_bus, sf_cs,
> > >>>                                  CONFIG_SF_DEFAULT_SPEED,
> > >>>                                  CONFIG_SF_DEFAULT_MODE);
> > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> > >>> fallback is CONFIG_SF_DEFAULT_SPEED.
> > >>>
> > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> > >>> some other common place. And when we will have fixed the DTS parsing
> > >>> problem, they can be removed.
> > >>>
> > >>> I'd like to hear from Stefan and Pali if this approach sounds good.
> > >>>
> > >>> All the best,
> > >>> Tony
> > >>
> > >> Well, the maximal SPI speed depends on the wiring. You can have on the
> > >> board some SPI device which does not support high frequency.
> > >>
> > >> But having some sane defaults in Kconfig for mvebu makes sense.
> >
> > Agreed.
> >
> > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> > > does not specify it. I think the sane default value is 10_000_000
> > > (grepping the Armada* DTS files showing the slowest spi-max-frequency
> > > is 10_000_000). While a big improvement, it is not fast enough for
> > > many other boards. So we still need to define it in those board
> > > defconfigs (before fixing that bug), or use return to BootROM.
> >
> > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
> > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
> > currently has no platform- / board- specific configurations. Perhaps
> > it can be done in a mach-mvebu Kconfig file instead?
>
> Yes, I think it should be done in mach-mvebu Kconfig, too. I will run
> some tests.

It is not related to this patch series (I also tested without the
patch series to confirm). But it is strange that I can no longer get
the configuration to boot from SPI. The 1st device in the boot order
is alway BOOTROM. The spl_boot_list is printed out below.

<BEGIN LOG>
High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR4 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
board_boot_order spl_boot_list[0] = 15
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
BootROM: Image checksum verification PASSED
<END LOG>

The SPL SPI configs (board Thecus N2350) are:
# grep SPL .config| grep SPI

CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
CONFIG_SPL_DM_SPI=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI=y
CONFIG_SPL_DM_SPI_FLASH=y
CONFIG_SPL_SPI_FLASH_TINY=y
# CONFIG_SPL_SPI_FLASH_MTD is not set
CONFIG_SPL_SPI_LOAD=y

Did I miss something new lately?

Thanks,
Tony

Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
BootROM: Image checksum verification PASSED

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,

On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Pali,
>
> On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh <mibodhi@gmail.com> wrote:
> >
> > Hi Stefan,
> >
> > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese <sr@denx.de> wrote:
> > >
> > > Hi Tony,
> > >
> > > On 2/27/23 01:11, Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
> > > >>
> > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> > > >>> Hi Martin,
> > > >>>
> > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > > >>>>
> > > >>>>>>> I'm not sure how to run proper timing tests on the process, but
> > > >>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > >>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > >>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
> > > >>>>>>> SPI directly was speed, but returning to BootROM is significantly
> > > >>>>>>> faster on this board.
> > > >>>>>>
> > > >>>>>> You should check SPI speed in DTS file and also in the defconfig.
> > > >>>>>
> > > >>>>> I think we have probably seen this slowdown before. There is a TODO in
> > > >>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
> > > >>>>> set in defconfig to get around that bug:
> > > >>>>> CONFIG_SF_DEFAULT_SPEED=50000000
> > > >>>>
> > > >>>> That works and is much faster now. I'll submit it in a V2 for these
> > > >>>> two patches once Pali's mvebu changes are accepted. Only question I
> > > >>>> have is: should the faster speed be applied to all three defconfigs?
> > > >>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > > >>>> MMC and SATA configs at the moment.
> > > >>>
> > > >>> This is only a workaround to get the SPI probe to work correctly. The
> > > >>> real fix should be in spi_flash_probe()
> > > >>> ./common/spl/spl_spi.c
> > > >>>          flash = spi_flash_probe(sf_bus, sf_cs,
> > > >>>                                  CONFIG_SF_DEFAULT_SPEED,
> > > >>>                                  CONFIG_SF_DEFAULT_MODE);
> > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> > > >>> fallback is CONFIG_SF_DEFAULT_SPEED.
> > > >>>
> > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> > > >>> some other common place. And when we will have fixed the DTS parsing
> > > >>> problem, they can be removed.
> > > >>>
> > > >>> I'd like to hear from Stefan and Pali if this approach sounds good.
> > > >>>
> > > >>> All the best,
> > > >>> Tony
> > > >>
> > > >> Well, the maximal SPI speed depends on the wiring. You can have on the
> > > >> board some SPI device which does not support high frequency.
> > > >>
> > > >> But having some sane defaults in Kconfig for mvebu makes sense.
> > >
> > > Agreed.
> > >
> > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> > > > does not specify it. I think the sane default value is 10_000_000
> > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency
> > > > is 10_000_000). While a big improvement, it is not fast enough for
> > > > many other boards. So we still need to define it in those board
> > > > defconfigs (before fixing that bug), or use return to BootROM.
> > >
> > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
> > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
> > > currently has no platform- / board- specific configurations. Perhaps
> > > it can be done in a mach-mvebu Kconfig file instead?
> >
> > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run
> > some tests.
>
> It is not related to this patch series (I also tested without the
> patch series to confirm). But it is strange that I can no longer get
> the configuration to boot from SPI. The 1st device in the boot order
> is alway BOOTROM. The spl_boot_list is printed out below.
>
> <BEGIN LOG>
> High speed PHY - Ended Successfully
> mv_ddr: 14.0.0
> DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> mv_ddr: completed successfully
> board_boot_order spl_boot_list[0] = 15
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> BootROM: Image checksum verification PASSED
> <END LOG>
>
> The SPL SPI configs (board Thecus N2350) are:
> # grep SPL .config| grep SPI
>
> CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> CONFIG_SPL_DM_SPI=y
> CONFIG_SPL_SPI_FLASH_SUPPORT=y
> CONFIG_SPL_SPI=y
> CONFIG_SPL_DM_SPI_FLASH=y
> CONFIG_SPL_SPI_FLASH_TINY=y
> # CONFIG_SPL_SPI_FLASH_MTD is not set
> CONFIG_SPL_SPI_LOAD=y
>
> Did I miss something new lately?
>
> Thanks,
> Tony
>
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> BootROM: Image checksum verification PASSED

It turns out that the board strapping register itself is the problem.
boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
surely does not match what we expected for A38x  (#define
BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
it fell to the default case, which is BOOTROM.

<BEGIN LOG>
U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
16:24:01 -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
BOOTROM_REG=0x97001000 boot_device=0x9
spl_boot_device boot_device = 15
board_boot_order spl_boot_list[0] = 15
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
BootROM: Image checksum verification PASSED
<END LOG>

Is there a chance this value 0x9 means something that we have not come across?

Thanks,
Tony

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,

On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Pali,
>
> On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
> >
> > Hi Pali,
> >
> > On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > >
> > > Hi Stefan,
> > >
> > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese <sr@denx.de> wrote:
> > > >
> > > > Hi Tony,
> > > >
> > > > On 2/27/23 01:11, Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
> > > > >>
> > > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> > > > >>> Hi Martin,
> > > > >>>
> > > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > > > >>>>
> > > > >>>>>>> I'm not sure how to run proper timing tests on the process, but
> > > > >>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > > >>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > > >>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
> > > > >>>>>>> SPI directly was speed, but returning to BootROM is significantly
> > > > >>>>>>> faster on this board.
> > > > >>>>>>
> > > > >>>>>> You should check SPI speed in DTS file and also in the defconfig.
> > > > >>>>>
> > > > >>>>> I think we have probably seen this slowdown before. There is a TODO in
> > > > >>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
> > > > >>>>> set in defconfig to get around that bug:
> > > > >>>>> CONFIG_SF_DEFAULT_SPEED=50000000
> > > > >>>>
> > > > >>>> That works and is much faster now. I'll submit it in a V2 for these
> > > > >>>> two patches once Pali's mvebu changes are accepted. Only question I
> > > > >>>> have is: should the faster speed be applied to all three defconfigs?
> > > > >>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > > > >>>> MMC and SATA configs at the moment.
> > > > >>>
> > > > >>> This is only a workaround to get the SPI probe to work correctly. The
> > > > >>> real fix should be in spi_flash_probe()
> > > > >>> ./common/spl/spl_spi.c
> > > > >>>          flash = spi_flash_probe(sf_bus, sf_cs,
> > > > >>>                                  CONFIG_SF_DEFAULT_SPEED,
> > > > >>>                                  CONFIG_SF_DEFAULT_MODE);
> > > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> > > > >>> fallback is CONFIG_SF_DEFAULT_SPEED.
> > > > >>>
> > > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> > > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> > > > >>> some other common place. And when we will have fixed the DTS parsing
> > > > >>> problem, they can be removed.
> > > > >>>
> > > > >>> I'd like to hear from Stefan and Pali if this approach sounds good.
> > > > >>>
> > > > >>> All the best,
> > > > >>> Tony
> > > > >>
> > > > >> Well, the maximal SPI speed depends on the wiring. You can have on the
> > > > >> board some SPI device which does not support high frequency.
> > > > >>
> > > > >> But having some sane defaults in Kconfig for mvebu makes sense.
> > > >
> > > > Agreed.
> > > >
> > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> > > > > does not specify it. I think the sane default value is 10_000_000
> > > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency
> > > > > is 10_000_000). While a big improvement, it is not fast enough for
> > > > > many other boards. So we still need to define it in those board
> > > > > defconfigs (before fixing that bug), or use return to BootROM.
> > > >
> > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
> > > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
> > > > currently has no platform- / board- specific configurations. Perhaps
> > > > it can be done in a mach-mvebu Kconfig file instead?
> > >
> > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run
> > > some tests.
> >
> > It is not related to this patch series (I also tested without the
> > patch series to confirm). But it is strange that I can no longer get
> > the configuration to boot from SPI. The 1st device in the boot order
> > is alway BOOTROM. The spl_boot_list is printed out below.
> >
> > <BEGIN LOG>
> > High speed PHY - Ended Successfully
> > mv_ddr: 14.0.0
> > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > mv_ddr: completed successfully
> > board_boot_order spl_boot_list[0] = 15
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> > BootROM: Image checksum verification PASSED
> > <END LOG>
> >
> > The SPL SPI configs (board Thecus N2350) are:
> > # grep SPL .config| grep SPI
> >
> > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > CONFIG_SPL_DM_SPI=y
> > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > CONFIG_SPL_SPI=y
> > CONFIG_SPL_DM_SPI_FLASH=y
> > CONFIG_SPL_SPI_FLASH_TINY=y
> > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > CONFIG_SPL_SPI_LOAD=y
> >
> > Did I miss something new lately?
> >
> > Thanks,
> > Tony
> >
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> > BootROM: Image checksum verification PASSED
>
> It turns out that the board strapping register itself is the problem.
> boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> surely does not match what we expected for A38x  (#define
> BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> it fell to the default case, which is BOOTROM.
>
> <BEGIN LOG>
> U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> 16:24:01 -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
> BOOTROM_REG=0x97001000 boot_device=0x9
> spl_boot_device boot_device = 15
> board_boot_order spl_boot_list[0] = 15
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> BootROM: Image checksum verification PASSED
> <END LOG>
>
> Is there a chance this value 0x9 means something that we have not come across?

Found the answer in the A38x Hardware Specs. I've never noticed this
before. This board has the Sample at Reset set to boot from NAND!

"Table 48: Boot Device Mode Options
0x9
BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
4 Address cycles support per page, using MPP multiplexing option of
NAND 8 bits
0x32
BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
Flash type, using MPP multiplexing option of SPI on MPP[25:22]"

So what we actually see here is the fall back to BootROM. And BootROM
still loads the image from SPI, ignoring that strapping. Am I confused
or correct? :)

Thanks,
Tony

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Martin,
Hi Pali,

On 2/27/23 12:29, Martin Rowe wrote:
> On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org 
> <mailto:pali@kernel.org>> wrote:
> 
>     On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
>      > Hi Pali,
>      >
>      > On 2/25/23 23:00, Pali Rohár wrote:
>      > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
>      > > > This patch series contains various improvements and fixes for
>     existing
>      > > > logical errors. Boot phase was adjusted to match behavior of
>     Armada 385
>      > > > BootROM by inspecting and disassembling of BootROM binary
>     dump itself.
>      > > > Important information are included in documentation patch for
>     kwboot.
>      > > > Most of the changes are untested, hence this patch series is
>     just RFC.
>      > > > So please test changes before applying, idealy on SPI, SATA
>     and SD/MMC.
>      > > > Nevertheless all patches on github passed CI testing in this PR:
>      > > > https://github.com/u-boot/u-boot/pull/275
>     <https://github.com/u-boot/u-boot/pull/275>
>      > >
>      > > Patches were tested on more boards and seems there is no
>     reported issue,
>      > > but other improvements.
>      > >
>      > > So do you need something to modify in this relatively big patch
>     series?
>      > > If it is not really needed I would like to not send it again
>     because
>      > > denx servers are not able to handle it. And it take me lot of
>     time to
>      > > send patches over emails to denx servers.
>      >
>      > I'm fine with applying the series as-is. I'm a bit hesitant
>     though, if
>      > it should be applied to master or to next. As Tom clearly
>     noticed, that
>      > only fixes should be added after rc2 this time.
>      >
>      > What is your thinking on this?
> 
>     Well, I do not know. AFAIK more patches here are fixing broken mvebu
>     boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
> 
> 
> A388 Clearfog was definitely broken prior to this patchset. There is 
> quite a bit of churn that this has caused for some OpenWRT users [1] as 
> well as for me. It would be nice to have a stable build for these boards.
> 
> [1] https://github.com/openwrt/openwrt/issues/11661 
> <https://github.com/openwrt/openwrt/issues/11661>

Okay. Thanks for the explanation. So it makes sense to pull this
patchset at this stage IMHO.

BUT: While trying to apply the patches sent to me directly this fails at
this patch:

tools: kwbimage: Add support for XIP SPI/NOR images

I tried to fix this merge problem manually, but this looks a bit bogus.
That's why I followed your instruction to pull the patches directly from
github:

git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu

This works and all patches apply clean. But looking into the patches I
noticed, that these patches from github do not include all patches
sent to the list. refs/pull/275/merge:mvebu stops after

tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images

This is the patch directly before the failing patch mentioned above.

Pali, could you please explain what went wrong here? Maybe I'm missing
something?

Thanks,
Stefan

> 
>      > Thanks,
>      > Stefan
>      >
>      > >
>      > > >
>      > > > Pali Rohár (59):
>      > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
>      > > >      kwbimage
>      > > >    tools: kwboot: Fix parsing SDIO kwbimage
>      > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
>      > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>      > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
>      > > >      kwbimage
>      > > >    tools: kwboot: Fix parsing SATA kwbimage
>      > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
>      > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>      > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>      > > >      BOOT_DEVICE_MMC2_2
>      > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
>     boot partition
>      > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>      > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
>     from SD card
>      > > >    tools: kwboot: Add more documentation references
>      > > >    tools: kwboot: Add image type documentation
>      > > >    tools: kwboot: Fix parsing UART image without data checksum
>      > > >    tools: kwboot: Validate optional kwbimage v1 headers
>      > > >    tools: kwboot: Add check that kwbimage contains DDR init code
>      > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
>      > > >    tools: kwboot: Show image type and error parsing reasons
>      > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>      > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
>      > > >    cmd: mvebu/bubt: Add support for reading image from the
>     SATA disk
>      > > >      partition
>      > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>      > > >    cmd: mvebu/bubt: Mark all local symbols as static
>      > > >    cmd: mvebu/bubt: Do not modify image in A8K
>     check_image_header()
>      > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
>      > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
>     Armada SoCs
>      > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>      > > >    cmd: mvebu/bubt: Fix warnings: unused variable
>     'secure_mode' and
>      > > >      'fuse_read_u64' defined but not used
>      > > >    cmd: mvebu/bubt: Enable command by default
>      > > >    tools: kwbimage: Fix dumping register set / DATA commands
>      > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>      > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>      > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
>      > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
>      > > >    tools: kwbimage: Fix endianity when printing kwbimage header
>      > > >    tools: kwbimage: Reject mkimage -F option
>      > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
>     images
>      > > >    tools: kwbimage: Print binary image offset as size
>      > > >    tools: kwbimage: Print image data offset when printing
>     kwbimage header
>      > > >    tools: kwbimage: Simplify add_secure_header_v1()
>      > > >    tools: kwbimage: Rename imagesz to dataoff
>      > > >    tools: kwbimage: Fix generating secure boot data image
>     signature
>      > > >    tools: kwbimage: Fix invalid secure boot header signature
>      > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
>     XIP images
>      > > >    tools: kwbimage: Add support for XIP SPI/NOR images
>      > > >    tools: mkimage: Print human readable error when -d is not
>     specified
>      > > >    tools: mkimage: Do not try to open datafile when it is skipped
>      > > >    tools: kwbimage: Add support for creating an image with no
>     data
>      > > >    arm: mvebu: Add support for generating NAND kwbimage
>      > > >    arm: mvebu: Add support for generating PEX kwbimage
>      > > >    arm: mvebu: Fix description of
>     MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>      > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>      > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
>      > > >    arm: mvebu: Remove A39x relicts
>      > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>      > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
>     U-Boot
>      > > >    arm: mvebu: Define SPL memory maps
>      > > >    doc/kwboot.1: Update example description
>      > > >
>      > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>      > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
>      > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>      > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>      > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
>     <http://kwbimage.cfg.in>           |   5 +
>      > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>      > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>      > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>      > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>      > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>      > > >   cmd/mvebu/Kconfig                             |  18 ++
>      > > >   cmd/mvebu/bubt.c                              | 253
>     ++++++++++++---
>      > > >   common/spl/Kconfig                            |   9 +
>      > > >   common/spl/spl_mmc.c                          |  12 +-
>      > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>      > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>      > > >   doc/kwboot.1                                  |   3 +-
>      > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
>      > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>      > > >   tools/kwbimage.c                              | 297
>     +++++++++++-------
>      > > >   tools/kwboot.c                                | 200
>     +++++++++++-
>      > > >   tools/mkimage.c                               |  11 +-
>      > > >   22 files changed, 768 insertions(+), 281 deletions(-)
>      > > >   copy configs/{clearfog_defconfig =>
>     clearfog_sata_defconfig} (98%)
>      > > >   copy configs/{db-88f6820-amc_defconfig =>
>     db-88f6820-amc_nand_defconfig} (92%)
>      > > >
>      > > > --
>      > > > 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 <mailto:sr@denx.de>
> 

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Pali,

On 2/28/23 08:03, Stefan Roese wrote:
> Hi Martin,
> Hi Pali,
> 
> On 2/27/23 12:29, Martin Rowe wrote:
>> On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org 
>> <mailto:pali@kernel.org>> wrote:
>>
>>     On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
>>      > Hi Pali,
>>      >
>>      > On 2/25/23 23:00, Pali Rohár wrote:
>>      > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
>>      > > > This patch series contains various improvements and fixes for
>>     existing
>>      > > > logical errors. Boot phase was adjusted to match behavior of
>>     Armada 385
>>      > > > BootROM by inspecting and disassembling of BootROM binary
>>     dump itself.
>>      > > > Important information are included in documentation patch for
>>     kwboot.
>>      > > > Most of the changes are untested, hence this patch series is
>>     just RFC.
>>      > > > So please test changes before applying, idealy on SPI, SATA
>>     and SD/MMC.
>>      > > > Nevertheless all patches on github passed CI testing in 
>> this PR:
>>      > > > https://github.com/u-boot/u-boot/pull/275
>>     <https://github.com/u-boot/u-boot/pull/275>
>>      > >
>>      > > Patches were tested on more boards and seems there is no
>>     reported issue,
>>      > > but other improvements.
>>      > >
>>      > > So do you need something to modify in this relatively big patch
>>     series?
>>      > > If it is not really needed I would like to not send it again
>>     because
>>      > > denx servers are not able to handle it. And it take me lot of
>>     time to
>>      > > send patches over emails to denx servers.
>>      >
>>      > I'm fine with applying the series as-is. I'm a bit hesitant
>>     though, if
>>      > it should be applied to master or to next. As Tom clearly
>>     noticed, that
>>      > only fixes should be added after rc2 this time.
>>      >
>>      > What is your thinking on this?
>>
>>     Well, I do not know. AFAIK more patches here are fixing broken mvebu
>>     boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could 
>> comment?
>>
>>
>> A388 Clearfog was definitely broken prior to this patchset. There is 
>> quite a bit of churn that this has caused for some OpenWRT users [1] 
>> as well as for me. It would be nice to have a stable build for these 
>> boards.
>>
>> [1] https://github.com/openwrt/openwrt/issues/11661 
>> <https://github.com/openwrt/openwrt/issues/11661>
> 
> Okay. Thanks for the explanation. So it makes sense to pull this
> patchset at this stage IMHO.

Short update: I've just now seen that rc3 has been released. And Tom
explicitly mentioned, that bigger pull requests are "not very welcome"
any more from now on. I'll push this patchset to "next" now instead,
once the problems mentioned below are resolved.

Thanks,
Stefan

> BUT: While trying to apply the patches sent to me directly this fails at
> this patch:
> 
> tools: kwbimage: Add support for XIP SPI/NOR images
> 
> I tried to fix this merge problem manually, but this looks a bit bogus.
> That's why I followed your instruction to pull the patches directly from
> github:
> 
> git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> 
> This works and all patches apply clean. But looking into the patches I
> noticed, that these patches from github do not include all patches
> sent to the list. refs/pull/275/merge:mvebu stops after
> 
> tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
> 
> This is the patch directly before the failing patch mentioned above.
> 
> Pali, could you please explain what went wrong here? Maybe I'm missing
> something?
> 
> Thanks,
> Stefan
> 
>>
>>      > Thanks,
>>      > Stefan
>>      >
>>      > >
>>      > > >
>>      > > > Pali Rohár (59):
>>      > > >    tools: kwbimage: Fix generating, verifying and 
>> extracting SDIO
>>      > > >      kwbimage
>>      > > >    tools: kwboot: Fix parsing SDIO kwbimage
>>      > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
>>      > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>>      > > >    tools: kwbimage: Fix generating, verifying and 
>> extracting SATA
>>      > > >      kwbimage
>>      > > >    tools: kwboot: Fix parsing SATA kwbimage
>>      > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
>>      > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>>      > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>>      > > >      BOOT_DEVICE_MMC2_2
>>      > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
>>     boot partition
>>      > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>>      > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
>>     from SD card
>>      > > >    tools: kwboot: Add more documentation references
>>      > > >    tools: kwboot: Add image type documentation
>>      > > >    tools: kwboot: Fix parsing UART image without data checksum
>>      > > >    tools: kwboot: Validate optional kwbimage v1 headers
>>      > > >    tools: kwboot: Add check that kwbimage contains DDR init 
>> code
>>      > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
>>      > > >    tools: kwboot: Show image type and error parsing reasons
>>      > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW 
>> partition
>>      > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
>>      > > >    cmd: mvebu/bubt: Add support for reading image from the
>>     SATA disk
>>      > > >      partition
>>      > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>>      > > >    cmd: mvebu/bubt: Mark all local symbols as static
>>      > > >    cmd: mvebu/bubt: Do not modify image in A8K
>>     check_image_header()
>>      > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
>>      > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
>>     Armada SoCs
>>      > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>>      > > >    cmd: mvebu/bubt: Fix warnings: unused variable
>>     'secure_mode' and
>>      > > >      'fuse_read_u64' defined but not used
>>      > > >    cmd: mvebu/bubt: Enable command by default
>>      > > >    tools: kwbimage: Fix dumping register set / DATA commands
>>      > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>>      > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>>      > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
>>      > > >    tools: kwbimage: Fix generating of kwbimage v0 header 
>> checksum
>>      > > >    tools: kwbimage: Fix endianity when printing kwbimage 
>> header
>>      > > >    tools: kwbimage: Reject mkimage -F option
>>      > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
>>     images
>>      > > >    tools: kwbimage: Print binary image offset as size
>>      > > >    tools: kwbimage: Print image data offset when printing
>>     kwbimage header
>>      > > >    tools: kwbimage: Simplify add_secure_header_v1()
>>      > > >    tools: kwbimage: Rename imagesz to dataoff
>>      > > >    tools: kwbimage: Fix generating secure boot data image
>>     signature
>>      > > >    tools: kwbimage: Fix invalid secure boot header signature
>>      > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
>>     XIP images
>>      > > >    tools: kwbimage: Add support for XIP SPI/NOR images
>>      > > >    tools: mkimage: Print human readable error when -d is not
>>     specified
>>      > > >    tools: mkimage: Do not try to open datafile when it is 
>> skipped
>>      > > >    tools: kwbimage: Add support for creating an image with no
>>     data
>>      > > >    arm: mvebu: Add support for generating NAND kwbimage
>>      > > >    arm: mvebu: Add support for generating PEX kwbimage
>>      > > >    arm: mvebu: Fix description of
>>     MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>>      > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>>      > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
>>      > > >    arm: mvebu: Remove A39x relicts
>>      > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>>      > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
>>     U-Boot
>>      > > >    arm: mvebu: Define SPL memory maps
>>      > > >    doc/kwboot.1: Update example description
>>      > > >
>>      > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>>      > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
>>      > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>>      > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>>      > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
>>     <http://kwbimage.cfg.in>           |   5 +
>>      > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>>      > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>>      > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>>      > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>>      > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>>      > > >   cmd/mvebu/Kconfig                             |  18 ++
>>      > > >   cmd/mvebu/bubt.c                              | 253
>>     ++++++++++++---
>>      > > >   common/spl/Kconfig                            |   9 +
>>      > > >   common/spl/spl_mmc.c                          |  12 +-
>>      > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>>      > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>>      > > >   doc/kwboot.1                                  |   3 +-
>>      > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
>>      > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>>      > > >   tools/kwbimage.c                              | 297
>>     +++++++++++-------
>>      > > >   tools/kwboot.c                                | 200
>>     +++++++++++-
>>      > > >   tools/mkimage.c                               |  11 +-
>>      > > >   22 files changed, 768 insertions(+), 281 deletions(-)
>>      > > >   copy configs/{clearfog_defconfig =>
>>     clearfog_sata_defconfig} (98%)
>>      > > >   copy configs/{db-88f6820-amc_defconfig =>
>>     db-88f6820-amc_nand_defconfig} (92%)
>>      > > >
>>      > > > --
>>      > > > 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 <mailto:sr@denx.de>
>>
> 
> Viele Grüße,
> Stefan Roese
> 

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 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Monday 27 February 2023 17:17:31 Tony Dinh wrote:
> Hi Pali,
> 
> On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi@gmail.com> wrote:
> >
> > Hi Pali,
> >
> > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > >
> > > Hi Pali,
> > >
> > > On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > >
> > > > Hi Stefan,
> > > >
> > > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese <sr@denx.de> wrote:
> > > > >
> > > > > Hi Tony,
> > > > >
> > > > > On 2/27/23 01:11, Tony Dinh wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
> > > > > >>
> > > > > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> > > > > >>> Hi Martin,
> > > > > >>>
> > > > > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > > > > >>>>
> > > > > >>>>>>> I'm not sure how to run proper timing tests on the process, but
> > > > > >>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > > > > >>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > > > > >>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
> > > > > >>>>>>> SPI directly was speed, but returning to BootROM is significantly
> > > > > >>>>>>> faster on this board.
> > > > > >>>>>>
> > > > > >>>>>> You should check SPI speed in DTS file and also in the defconfig.
> > > > > >>>>>
> > > > > >>>>> I think we have probably seen this slowdown before. There is a TODO in
> > > > > >>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
> > > > > >>>>> set in defconfig to get around that bug:
> > > > > >>>>> CONFIG_SF_DEFAULT_SPEED=50000000
> > > > > >>>>
> > > > > >>>> That works and is much faster now. I'll submit it in a V2 for these
> > > > > >>>> two patches once Pali's mvebu changes are accepted. Only question I
> > > > > >>>> have is: should the faster speed be applied to all three defconfigs?
> > > > > >>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > > > > >>>> MMC and SATA configs at the moment.
> > > > > >>>
> > > > > >>> This is only a workaround to get the SPI probe to work correctly. The
> > > > > >>> real fix should be in spi_flash_probe()
> > > > > >>> ./common/spl/spl_spi.c
> > > > > >>>          flash = spi_flash_probe(sf_bus, sf_cs,
> > > > > >>>                                  CONFIG_SF_DEFAULT_SPEED,
> > > > > >>>                                  CONFIG_SF_DEFAULT_MODE);
> > > > > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> > > > > >>> fallback is CONFIG_SF_DEFAULT_SPEED.
> > > > > >>>
> > > > > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> > > > > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> > > > > >>> some other common place. And when we will have fixed the DTS parsing
> > > > > >>> problem, they can be removed.
> > > > > >>>
> > > > > >>> I'd like to hear from Stefan and Pali if this approach sounds good.
> > > > > >>>
> > > > > >>> All the best,
> > > > > >>> Tony
> > > > > >>
> > > > > >> Well, the maximal SPI speed depends on the wiring. You can have on the
> > > > > >> board some SPI device which does not support high frequency.
> > > > > >>
> > > > > >> But having some sane defaults in Kconfig for mvebu makes sense.
> > > > >
> > > > > Agreed.
> > > > >
> > > > > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> > > > > > does not specify it. I think the sane default value is 10_000_000
> > > > > > (grepping the Armada* DTS files showing the slowest spi-max-frequency
> > > > > > is 10_000_000). While a big improvement, it is not fast enough for
> > > > > > many other boards. So we still need to define it in those board
> > > > > > defconfigs (before fixing that bug), or use return to BootROM.
> > > > >
> > > > > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
> > > > > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
> > > > > currently has no platform- / board- specific configurations. Perhaps
> > > > > it can be done in a mach-mvebu Kconfig file instead?
> > > >
> > > > Yes, I think it should be done in mach-mvebu Kconfig, too. I will run
> > > > some tests.
> > >
> > > It is not related to this patch series (I also tested without the
> > > patch series to confirm). But it is strange that I can no longer get
> > > the configuration to boot from SPI. The 1st device in the boot order
> > > is alway BOOTROM. The spl_boot_list is printed out below.
> > >
> > > <BEGIN LOG>
> > > High speed PHY - Ended Successfully
> > > mv_ddr: 14.0.0
> > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > mv_ddr: completed successfully
> > > board_boot_order spl_boot_list[0] = 15
> > > Trying to boot from BOOTROM
> > > Returning to BootROM (return address 0xffff05c4)...
> > > BootROM: Image checksum verification PASSED
> > > <END LOG>
> > >
> > > The SPL SPI configs (board Thecus N2350) are:
> > > # grep SPL .config| grep SPI
> > >
> > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > > CONFIG_SPL_DM_SPI=y
> > > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > > CONFIG_SPL_SPI=y
> > > CONFIG_SPL_DM_SPI_FLASH=y
> > > CONFIG_SPL_SPI_FLASH_TINY=y
> > > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > > CONFIG_SPL_SPI_LOAD=y
> > >
> > > Did I miss something new lately?
> > >
> > > Thanks,
> > > Tony
> > >
> > > Trying to boot from BOOTROM
> > > Returning to BootROM (return address 0xffff05c4)...
> > > BootROM: Image checksum verification PASSED
> >
> > It turns out that the board strapping register itself is the problem.
> > boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> > surely does not match what we expected for A38x  (#define
> > BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> > it fell to the default case, which is BOOTROM.
> >
> > <BEGIN LOG>
> > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> > 16:24:01 -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
> > BOOTROM_REG=0x97001000 boot_device=0x9
> > spl_boot_device boot_device = 15
> > board_boot_order spl_boot_list[0] = 15
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> > BootROM: Image checksum verification PASSED
> > <END LOG>
> >
> > Is there a chance this value 0x9 means something that we have not come across?
> 
> Found the answer in the A38x Hardware Specs. I've never noticed this
> before. This board has the Sample at Reset set to boot from NAND!
> 
> "Table 48: Boot Device Mode Options
> 0x9
> BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
> 4 Address cycles support per page, using MPP multiplexing option of
> NAND 8 bits
> 0x32
> BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
> Flash type, using MPP multiplexing option of SPI on MPP[25:22]"
> 
> So what we actually see here is the fall back to BootROM. And BootROM
> still loads the image from SPI, ignoring that strapping. Am I confused
> or correct? :)
> 
> Thanks,
> Tony

I already wrote in some thread that in Hardware Specifications are
documented all strapping pins options and u-boot has defined just few of
them in header files. Beware that strapping pins are SoC specific and so
you always need to look at the correct document.

About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart
from bootrom to main u-boot and type of the SoC?

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote:
> Hi Martin,
> Hi Pali,
> 
> On 2/27/23 12:29, Martin Rowe wrote:
> > On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org
> > <mailto:pali@kernel.org>> wrote:
> > 
> >     On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
> >      > Hi Pali,
> >      >
> >      > On 2/25/23 23:00, Pali Rohár wrote:
> >      > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> >      > > > This patch series contains various improvements and fixes for
> >     existing
> >      > > > logical errors. Boot phase was adjusted to match behavior of
> >     Armada 385
> >      > > > BootROM by inspecting and disassembling of BootROM binary
> >     dump itself.
> >      > > > Important information are included in documentation patch for
> >     kwboot.
> >      > > > Most of the changes are untested, hence this patch series is
> >     just RFC.
> >      > > > So please test changes before applying, idealy on SPI, SATA
> >     and SD/MMC.
> >      > > > Nevertheless all patches on github passed CI testing in this PR:
> >      > > > https://github.com/u-boot/u-boot/pull/275
> >     <https://github.com/u-boot/u-boot/pull/275>
> >      > >
> >      > > Patches were tested on more boards and seems there is no
> >     reported issue,
> >      > > but other improvements.
> >      > >
> >      > > So do you need something to modify in this relatively big patch
> >     series?
> >      > > If it is not really needed I would like to not send it again
> >     because
> >      > > denx servers are not able to handle it. And it take me lot of
> >     time to
> >      > > send patches over emails to denx servers.
> >      >
> >      > I'm fine with applying the series as-is. I'm a bit hesitant
> >     though, if
> >      > it should be applied to master or to next. As Tom clearly
> >     noticed, that
> >      > only fixes should be added after rc2 this time.
> >      >
> >      > What is your thinking on this?
> > 
> >     Well, I do not know. AFAIK more patches here are fixing broken mvebu
> >     boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
> > 
> > 
> > A388 Clearfog was definitely broken prior to this patchset. There is
> > quite a bit of churn that this has caused for some OpenWRT users [1] as
> > well as for me. It would be nice to have a stable build for these
> > boards.
> > 
> > [1] https://github.com/openwrt/openwrt/issues/11661
> > <https://github.com/openwrt/openwrt/issues/11661>
> 
> Okay. Thanks for the explanation. So it makes sense to pull this
> patchset at this stage IMHO.
> 
> BUT: While trying to apply the patches sent to me directly this fails at
> this patch:
> 
> tools: kwbimage: Add support for XIP SPI/NOR images
> 
> I tried to fix this merge problem manually, but this looks a bit bogus.
> That's why I followed your instruction to pull the patches directly from
> github:
> 
> git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> 
> This works and all patches apply clean. But looking into the patches I
> noticed, that these patches from github do not include all patches
> sent to the list. refs/pull/275/merge:mvebu stops after
> 
> tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
> 
> This is the patch directly before the failing patch mentioned above.
> 
> Pali, could you please explain what went wrong here? Maybe I'm missing
> something?

Yes, denx mail server is broken and randomly crashes when receiving /
processing email. It just bounce back with server stacktrace or what.
I tried to resend patches to ML which did not appeared on patchwork.
But I cannot do more. So you can try to download patches from patchwork
or from github.

> Thanks,
> Stefan
> 
> > 
> >      > Thanks,
> >      > Stefan
> >      >
> >      > >
> >      > > >
> >      > > > Pali Rohár (59):
> >      > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
> >      > > >      kwbimage
> >      > > >    tools: kwboot: Fix parsing SDIO kwbimage
> >      > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
> >      > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> >      > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
> >      > > >      kwbimage
> >      > > >    tools: kwboot: Fix parsing SATA kwbimage
> >      > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
> >      > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
> >      > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> >      > > >      BOOT_DEVICE_MMC2_2
> >      > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
> >     boot partition
> >      > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> >      > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
> >     from SD card
> >      > > >    tools: kwboot: Add more documentation references
> >      > > >    tools: kwboot: Add image type documentation
> >      > > >    tools: kwboot: Fix parsing UART image without data checksum
> >      > > >    tools: kwboot: Validate optional kwbimage v1 headers
> >      > > >    tools: kwboot: Add check that kwbimage contains DDR init code
> >      > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
> >      > > >    tools: kwboot: Show image type and error parsing reasons
> >      > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> >      > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
> >      > > >    cmd: mvebu/bubt: Add support for reading image from the
> >     SATA disk
> >      > > >      partition
> >      > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
> >      > > >    cmd: mvebu/bubt: Mark all local symbols as static
> >      > > >    cmd: mvebu/bubt: Do not modify image in A8K
> >     check_image_header()
> >      > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
> >      > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
> >     Armada SoCs
> >      > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> >      > > >    cmd: mvebu/bubt: Fix warnings: unused variable
> >     'secure_mode' and
> >      > > >      'fuse_read_u64' defined but not used
> >      > > >    cmd: mvebu/bubt: Enable command by default
> >      > > >    tools: kwbimage: Fix dumping register set / DATA commands
> >      > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> >      > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> >      > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
> >      > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
> >      > > >    tools: kwbimage: Fix endianity when printing kwbimage header
> >      > > >    tools: kwbimage: Reject mkimage -F option
> >      > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
> >     images
> >      > > >    tools: kwbimage: Print binary image offset as size
> >      > > >    tools: kwbimage: Print image data offset when printing
> >     kwbimage header
> >      > > >    tools: kwbimage: Simplify add_secure_header_v1()
> >      > > >    tools: kwbimage: Rename imagesz to dataoff
> >      > > >    tools: kwbimage: Fix generating secure boot data image
> >     signature
> >      > > >    tools: kwbimage: Fix invalid secure boot header signature
> >      > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
> >     XIP images
> >      > > >    tools: kwbimage: Add support for XIP SPI/NOR images
> >      > > >    tools: mkimage: Print human readable error when -d is not
> >     specified
> >      > > >    tools: mkimage: Do not try to open datafile when it is skipped
> >      > > >    tools: kwbimage: Add support for creating an image with no
> >     data
> >      > > >    arm: mvebu: Add support for generating NAND kwbimage
> >      > > >    arm: mvebu: Add support for generating PEX kwbimage
> >      > > >    arm: mvebu: Fix description of
> >     MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
> >      > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
> >      > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
> >      > > >    arm: mvebu: Remove A39x relicts
> >      > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
> >      > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
> >     U-Boot
> >      > > >    arm: mvebu: Define SPL memory maps
> >      > > >    doc/kwboot.1: Update example description
> >      > > >
> >      > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
> >      > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
> >      > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
> >      > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
> >      > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
> >     <http://kwbimage.cfg.in>           |   5 +
> >      > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
> >      > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
> >      > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
> >      > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
> >      > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
> >      > > >   cmd/mvebu/Kconfig                             |  18 ++
> >      > > >   cmd/mvebu/bubt.c                              | 253
> >     ++++++++++++---
> >      > > >   common/spl/Kconfig                            |   9 +
> >      > > >   common/spl/spl_mmc.c                          |  12 +-
> >      > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
> >      > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
> >      > > >   doc/kwboot.1                                  |   3 +-
> >      > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
> >      > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
> >      > > >   tools/kwbimage.c                              | 297
> >     +++++++++++-------
> >      > > >   tools/kwboot.c                                | 200
> >     +++++++++++-
> >      > > >   tools/mkimage.c                               |  11 +-
> >      > > >   22 files changed, 768 insertions(+), 281 deletions(-)
> >      > > >   copy configs/{clearfog_defconfig =>
> >     clearfog_sata_defconfig} (98%)
> >      > > >   copy configs/{db-88f6820-amc_defconfig =>
> >     db-88f6820-amc_nand_defconfig} (92%)
> >      > > >
> >      > > > --
> >      > > > 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 <mailto:sr@denx.de>
> > 
> 
> 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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Pali,

On 2/28/23 10:54, Pali Rohár wrote:
> On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote:
>> Hi Martin,
>> Hi Pali,
>>
>> On 2/27/23 12:29, Martin Rowe wrote:
>>> On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org
>>> <mailto:pali@kernel.org>> wrote:
>>>
>>>      On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
>>>       > Hi Pali,
>>>       >
>>>       > On 2/25/23 23:00, Pali Rohár wrote:
>>>       > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
>>>       > > > This patch series contains various improvements and fixes for
>>>      existing
>>>       > > > logical errors. Boot phase was adjusted to match behavior of
>>>      Armada 385
>>>       > > > BootROM by inspecting and disassembling of BootROM binary
>>>      dump itself.
>>>       > > > Important information are included in documentation patch for
>>>      kwboot.
>>>       > > > Most of the changes are untested, hence this patch series is
>>>      just RFC.
>>>       > > > So please test changes before applying, idealy on SPI, SATA
>>>      and SD/MMC.
>>>       > > > Nevertheless all patches on github passed CI testing in this PR:
>>>       > > > https://github.com/u-boot/u-boot/pull/275
>>>      <https://github.com/u-boot/u-boot/pull/275>
>>>       > >
>>>       > > Patches were tested on more boards and seems there is no
>>>      reported issue,
>>>       > > but other improvements.
>>>       > >
>>>       > > So do you need something to modify in this relatively big patch
>>>      series?
>>>       > > If it is not really needed I would like to not send it again
>>>      because
>>>       > > denx servers are not able to handle it. And it take me lot of
>>>      time to
>>>       > > send patches over emails to denx servers.
>>>       >
>>>       > I'm fine with applying the series as-is. I'm a bit hesitant
>>>      though, if
>>>       > it should be applied to master or to next. As Tom clearly
>>>      noticed, that
>>>       > only fixes should be added after rc2 this time.
>>>       >
>>>       > What is your thinking on this?
>>>
>>>      Well, I do not know. AFAIK more patches here are fixing broken mvebu
>>>      boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
>>>
>>>
>>> A388 Clearfog was definitely broken prior to this patchset. There is
>>> quite a bit of churn that this has caused for some OpenWRT users [1] as
>>> well as for me. It would be nice to have a stable build for these
>>> boards.
>>>
>>> [1] https://github.com/openwrt/openwrt/issues/11661
>>> <https://github.com/openwrt/openwrt/issues/11661>
>>
>> Okay. Thanks for the explanation. So it makes sense to pull this
>> patchset at this stage IMHO.
>>
>> BUT: While trying to apply the patches sent to me directly this fails at
>> this patch:
>>
>> tools: kwbimage: Add support for XIP SPI/NOR images
>>
>> I tried to fix this merge problem manually, but this looks a bit bogus.
>> That's why I followed your instruction to pull the patches directly from
>> github:
>>
>> git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
>>
>> This works and all patches apply clean. But looking into the patches I
>> noticed, that these patches from github do not include all patches
>> sent to the list. refs/pull/275/merge:mvebu stops after
>>
>> tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
>>
>> This is the patch directly before the failing patch mentioned above.
>>
>> Pali, could you please explain what went wrong here? Maybe I'm missing
>> something?
> 
> Yes, denx mail server is broken and randomly crashes when receiving /
> processing email. It just bounce back with server stacktrace or what.
> I tried to resend patches to ML which did not appeared on patchwork.
> But I cannot do more. So you can try to download patches from patchwork
> or from github.

Okay, I understood the issues with the DENX mail server. Sorry about
this.

But: Please re-read my lines above. The patches on github are less than
the patches sent to the list. There are *more* patches sent to the list
(or to me directly) than in your github branch.

So my question is, why are less patches in your github branch? Or did
you try to re-send with this smaller amount of patches and this did not
work because of the crashing mail server?

Thanks,
Stefan

> 
>> Thanks,
>> Stefan
>>
>>>
>>>       > Thanks,
>>>       > Stefan
>>>       >
>>>       > >
>>>       > > >
>>>       > > > Pali Rohár (59):
>>>       > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
>>>       > > >      kwbimage
>>>       > > >    tools: kwboot: Fix parsing SDIO kwbimage
>>>       > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
>>>       > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>>>       > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
>>>       > > >      kwbimage
>>>       > > >    tools: kwboot: Fix parsing SATA kwbimage
>>>       > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
>>>       > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>>>       > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>>>       > > >      BOOT_DEVICE_MMC2_2
>>>       > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
>>>      boot partition
>>>       > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>>>       > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
>>>      from SD card
>>>       > > >    tools: kwboot: Add more documentation references
>>>       > > >    tools: kwboot: Add image type documentation
>>>       > > >    tools: kwboot: Fix parsing UART image without data checksum
>>>       > > >    tools: kwboot: Validate optional kwbimage v1 headers
>>>       > > >    tools: kwboot: Add check that kwbimage contains DDR init code
>>>       > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
>>>       > > >    tools: kwboot: Show image type and error parsing reasons
>>>       > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>>>       > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
>>>       > > >    cmd: mvebu/bubt: Add support for reading image from the
>>>      SATA disk
>>>       > > >      partition
>>>       > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>>>       > > >    cmd: mvebu/bubt: Mark all local symbols as static
>>>       > > >    cmd: mvebu/bubt: Do not modify image in A8K
>>>      check_image_header()
>>>       > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
>>>       > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
>>>      Armada SoCs
>>>       > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>>>       > > >    cmd: mvebu/bubt: Fix warnings: unused variable
>>>      'secure_mode' and
>>>       > > >      'fuse_read_u64' defined but not used
>>>       > > >    cmd: mvebu/bubt: Enable command by default
>>>       > > >    tools: kwbimage: Fix dumping register set / DATA commands
>>>       > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>>>       > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>>>       > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
>>>       > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
>>>       > > >    tools: kwbimage: Fix endianity when printing kwbimage header
>>>       > > >    tools: kwbimage: Reject mkimage -F option
>>>       > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
>>>      images
>>>       > > >    tools: kwbimage: Print binary image offset as size
>>>       > > >    tools: kwbimage: Print image data offset when printing
>>>      kwbimage header
>>>       > > >    tools: kwbimage: Simplify add_secure_header_v1()
>>>       > > >    tools: kwbimage: Rename imagesz to dataoff
>>>       > > >    tools: kwbimage: Fix generating secure boot data image
>>>      signature
>>>       > > >    tools: kwbimage: Fix invalid secure boot header signature
>>>       > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
>>>      XIP images
>>>       > > >    tools: kwbimage: Add support for XIP SPI/NOR images
>>>       > > >    tools: mkimage: Print human readable error when -d is not
>>>      specified
>>>       > > >    tools: mkimage: Do not try to open datafile when it is skipped
>>>       > > >    tools: kwbimage: Add support for creating an image with no
>>>      data
>>>       > > >    arm: mvebu: Add support for generating NAND kwbimage
>>>       > > >    arm: mvebu: Add support for generating PEX kwbimage
>>>       > > >    arm: mvebu: Fix description of
>>>      MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>>>       > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>>>       > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
>>>       > > >    arm: mvebu: Remove A39x relicts
>>>       > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>>>       > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
>>>      U-Boot
>>>       > > >    arm: mvebu: Define SPL memory maps
>>>       > > >    doc/kwboot.1: Update example description
>>>       > > >
>>>       > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>>>       > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
>>>       > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>>>       > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>>>       > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
>>>      <http://kwbimage.cfg.in>           |   5 +
>>>       > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>>>       > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>>>       > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>>>       > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>>>       > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>>>       > > >   cmd/mvebu/Kconfig                             |  18 ++
>>>       > > >   cmd/mvebu/bubt.c                              | 253
>>>      ++++++++++++---
>>>       > > >   common/spl/Kconfig                            |   9 +
>>>       > > >   common/spl/spl_mmc.c                          |  12 +-
>>>       > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>>>       > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>>>       > > >   doc/kwboot.1                                  |   3 +-
>>>       > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
>>>       > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>>>       > > >   tools/kwbimage.c                              | 297
>>>      +++++++++++-------
>>>       > > >   tools/kwboot.c                                | 200
>>>      +++++++++++-
>>>       > > >   tools/mkimage.c                               |  11 +-
>>>       > > >   22 files changed, 768 insertions(+), 281 deletions(-)
>>>       > > >   copy configs/{clearfog_defconfig =>
>>>      clearfog_sata_defconfig} (98%)
>>>       > > >   copy configs/{db-88f6820-amc_defconfig =>
>>>      db-88f6820-amc_nand_defconfig} (92%)
>>>       > > >
>>>       > > > --
>>>       > > > 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 <mailto:sr@denx.de>
>>>
>>
>> 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

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 28 February 2023 11:01:55 Stefan Roese wrote:
> Hi Pali,
> 
> On 2/28/23 10:54, Pali Rohár wrote:
> > On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote:
> > > Hi Martin,
> > > Hi Pali,
> > > 
> > > On 2/27/23 12:29, Martin Rowe wrote:
> > > > On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org
> > > > <mailto:pali@kernel.org>> wrote:
> > > > 
> > > >      On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
> > > >       > Hi Pali,
> > > >       >
> > > >       > On 2/25/23 23:00, Pali Rohár wrote:
> > > >       > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> > > >       > > > This patch series contains various improvements and fixes for
> > > >      existing
> > > >       > > > logical errors. Boot phase was adjusted to match behavior of
> > > >      Armada 385
> > > >       > > > BootROM by inspecting and disassembling of BootROM binary
> > > >      dump itself.
> > > >       > > > Important information are included in documentation patch for
> > > >      kwboot.
> > > >       > > > Most of the changes are untested, hence this patch series is
> > > >      just RFC.
> > > >       > > > So please test changes before applying, idealy on SPI, SATA
> > > >      and SD/MMC.
> > > >       > > > Nevertheless all patches on github passed CI testing in this PR:
> > > >       > > > https://github.com/u-boot/u-boot/pull/275
> > > >      <https://github.com/u-boot/u-boot/pull/275>
> > > >       > >
> > > >       > > Patches were tested on more boards and seems there is no
> > > >      reported issue,
> > > >       > > but other improvements.
> > > >       > >
> > > >       > > So do you need something to modify in this relatively big patch
> > > >      series?
> > > >       > > If it is not really needed I would like to not send it again
> > > >      because
> > > >       > > denx servers are not able to handle it. And it take me lot of
> > > >      time to
> > > >       > > send patches over emails to denx servers.
> > > >       >
> > > >       > I'm fine with applying the series as-is. I'm a bit hesitant
> > > >      though, if
> > > >       > it should be applied to master or to next. As Tom clearly
> > > >      noticed, that
> > > >       > only fixes should be added after rc2 this time.
> > > >       >
> > > >       > What is your thinking on this?
> > > > 
> > > >      Well, I do not know. AFAIK more patches here are fixing broken mvebu
> > > >      boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
> > > > 
> > > > 
> > > > A388 Clearfog was definitely broken prior to this patchset. There is
> > > > quite a bit of churn that this has caused for some OpenWRT users [1] as
> > > > well as for me. It would be nice to have a stable build for these
> > > > boards.
> > > > 
> > > > [1] https://github.com/openwrt/openwrt/issues/11661
> > > > <https://github.com/openwrt/openwrt/issues/11661>
> > > 
> > > Okay. Thanks for the explanation. So it makes sense to pull this
> > > patchset at this stage IMHO.
> > > 
> > > BUT: While trying to apply the patches sent to me directly this fails at
> > > this patch:
> > > 
> > > tools: kwbimage: Add support for XIP SPI/NOR images
> > > 
> > > I tried to fix this merge problem manually, but this looks a bit bogus.
> > > That's why I followed your instruction to pull the patches directly from
> > > github:
> > > 
> > > git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > 
> > > This works and all patches apply clean. But looking into the patches I
> > > noticed, that these patches from github do not include all patches
> > > sent to the list. refs/pull/275/merge:mvebu stops after
> > > 
> > > tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
> > > 
> > > This is the patch directly before the failing patch mentioned above.
> > > 
> > > Pali, could you please explain what went wrong here? Maybe I'm missing
> > > something?
> > 
> > Yes, denx mail server is broken and randomly crashes when receiving /
> > processing email. It just bounce back with server stacktrace or what.
> > I tried to resend patches to ML which did not appeared on patchwork.
> > But I cannot do more. So you can try to download patches from patchwork
> > or from github.
> 
> Okay, I understood the issues with the DENX mail server. Sorry about
> this.
> 
> But: Please re-read my lines above. The patches on github are less than
> the patches sent to the list. There are *more* patches sent to the list
> (or to me directly) than in your github branch.

Ou, so there are more patches on the list than on github? Strange
because I sent exactly same patches to ML and on github and some patches
were not correctly delivered to mail, therefore number of mail patches
could be less than on github.

> So my question is, why are less patches in your github branch? Or did
> you try to re-send with this smaller amount of patches and this did not
> work because of the crashing mail server?

I cannot understand how it is possible. There should be 59 patches. I
have not created / sent more patches. If there is missing some patch on
Github I can double check it...

> Thanks,
> Stefan
> 
> > 
> > > Thanks,
> > > Stefan
> > > 
> > > > 
> > > >       > Thanks,
> > > >       > Stefan
> > > >       >
> > > >       > >
> > > >       > > >
> > > >       > > > Pali Rohár (59):
> > > >       > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
> > > >       > > >      kwbimage
> > > >       > > >    tools: kwboot: Fix parsing SDIO kwbimage
> > > >       > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
> > > >       > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> > > >       > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
> > > >       > > >      kwbimage
> > > >       > > >    tools: kwboot: Fix parsing SATA kwbimage
> > > >       > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
> > > >       > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
> > > >       > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> > > >       > > >      BOOT_DEVICE_MMC2_2
> > > >       > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
> > > >      boot partition
> > > >       > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> > > >       > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
> > > >      from SD card
> > > >       > > >    tools: kwboot: Add more documentation references
> > > >       > > >    tools: kwboot: Add image type documentation
> > > >       > > >    tools: kwboot: Fix parsing UART image without data checksum
> > > >       > > >    tools: kwboot: Validate optional kwbimage v1 headers
> > > >       > > >    tools: kwboot: Add check that kwbimage contains DDR init code
> > > >       > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
> > > >       > > >    tools: kwboot: Show image type and error parsing reasons
> > > >       > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> > > >       > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
> > > >       > > >    cmd: mvebu/bubt: Add support for reading image from the
> > > >      SATA disk
> > > >       > > >      partition
> > > >       > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
> > > >       > > >    cmd: mvebu/bubt: Mark all local symbols as static
> > > >       > > >    cmd: mvebu/bubt: Do not modify image in A8K
> > > >      check_image_header()
> > > >       > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
> > > >       > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
> > > >      Armada SoCs
> > > >       > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> > > >       > > >    cmd: mvebu/bubt: Fix warnings: unused variable
> > > >      'secure_mode' and
> > > >       > > >      'fuse_read_u64' defined but not used
> > > >       > > >    cmd: mvebu/bubt: Enable command by default
> > > >       > > >    tools: kwbimage: Fix dumping register set / DATA commands
> > > >       > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> > > >       > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> > > >       > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
> > > >       > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
> > > >       > > >    tools: kwbimage: Fix endianity when printing kwbimage header
> > > >       > > >    tools: kwbimage: Reject mkimage -F option
> > > >       > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
> > > >      images
> > > >       > > >    tools: kwbimage: Print binary image offset as size
> > > >       > > >    tools: kwbimage: Print image data offset when printing
> > > >      kwbimage header
> > > >       > > >    tools: kwbimage: Simplify add_secure_header_v1()
> > > >       > > >    tools: kwbimage: Rename imagesz to dataoff
> > > >       > > >    tools: kwbimage: Fix generating secure boot data image
> > > >      signature
> > > >       > > >    tools: kwbimage: Fix invalid secure boot header signature
> > > >       > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
> > > >      XIP images
> > > >       > > >    tools: kwbimage: Add support for XIP SPI/NOR images
> > > >       > > >    tools: mkimage: Print human readable error when -d is not
> > > >      specified
> > > >       > > >    tools: mkimage: Do not try to open datafile when it is skipped
> > > >       > > >    tools: kwbimage: Add support for creating an image with no
> > > >      data
> > > >       > > >    arm: mvebu: Add support for generating NAND kwbimage
> > > >       > > >    arm: mvebu: Add support for generating PEX kwbimage
> > > >       > > >    arm: mvebu: Fix description of
> > > >      MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
> > > >       > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
> > > >       > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
> > > >       > > >    arm: mvebu: Remove A39x relicts
> > > >       > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
> > > >       > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
> > > >      U-Boot
> > > >       > > >    arm: mvebu: Define SPL memory maps
> > > >       > > >    doc/kwboot.1: Update example description
> > > >       > > >
> > > >       > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
> > > >       > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
> > > >       > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
> > > >       > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
> > > >       > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
> > > >      <http://kwbimage.cfg.in>           |   5 +
> > > >       > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
> > > >       > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
> > > >       > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
> > > >       > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
> > > >       > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
> > > >       > > >   cmd/mvebu/Kconfig                             |  18 ++
> > > >       > > >   cmd/mvebu/bubt.c                              | 253
> > > >      ++++++++++++---
> > > >       > > >   common/spl/Kconfig                            |   9 +
> > > >       > > >   common/spl/spl_mmc.c                          |  12 +-
> > > >       > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
> > > >       > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
> > > >       > > >   doc/kwboot.1                                  |   3 +-
> > > >       > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
> > > >       > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
> > > >       > > >   tools/kwbimage.c                              | 297
> > > >      +++++++++++-------
> > > >       > > >   tools/kwboot.c                                | 200
> > > >      +++++++++++-
> > > >       > > >   tools/mkimage.c                               |  11 +-
> > > >       > > >   22 files changed, 768 insertions(+), 281 deletions(-)
> > > >       > > >   copy configs/{clearfog_defconfig =>
> > > >      clearfog_sata_defconfig} (98%)
> > > >       > > >   copy configs/{db-88f6820-amc_defconfig =>
> > > >      db-88f6820-amc_nand_defconfig} (92%)
> > > >       > > >
> > > >       > > > --
> > > >       > > > 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 <mailto:sr@denx.de>
> > > > 
> > > 
> > > 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
> 
> 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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Pali,

On 2/28/23 11:10, Pali Rohár wrote:
> On Tuesday 28 February 2023 11:01:55 Stefan Roese wrote:
>> Hi Pali,
>>
>> On 2/28/23 10:54, Pali Rohár wrote:
>>> On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote:
>>>> Hi Martin,
>>>> Hi Pali,
>>>>
>>>> On 2/27/23 12:29, Martin Rowe wrote:
>>>>> On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org
>>>>> <mailto:pali@kernel.org>> wrote:
>>>>>
>>>>>       On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
>>>>>        > Hi Pali,
>>>>>        >
>>>>>        > On 2/25/23 23:00, Pali Rohár wrote:
>>>>>        > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
>>>>>        > > > This patch series contains various improvements and fixes for
>>>>>       existing
>>>>>        > > > logical errors. Boot phase was adjusted to match behavior of
>>>>>       Armada 385
>>>>>        > > > BootROM by inspecting and disassembling of BootROM binary
>>>>>       dump itself.
>>>>>        > > > Important information are included in documentation patch for
>>>>>       kwboot.
>>>>>        > > > Most of the changes are untested, hence this patch series is
>>>>>       just RFC.
>>>>>        > > > So please test changes before applying, idealy on SPI, SATA
>>>>>       and SD/MMC.
>>>>>        > > > Nevertheless all patches on github passed CI testing in this PR:
>>>>>        > > > https://github.com/u-boot/u-boot/pull/275
>>>>>       <https://github.com/u-boot/u-boot/pull/275>
>>>>>        > >
>>>>>        > > Patches were tested on more boards and seems there is no
>>>>>       reported issue,
>>>>>        > > but other improvements.
>>>>>        > >
>>>>>        > > So do you need something to modify in this relatively big patch
>>>>>       series?
>>>>>        > > If it is not really needed I would like to not send it again
>>>>>       because
>>>>>        > > denx servers are not able to handle it. And it take me lot of
>>>>>       time to
>>>>>        > > send patches over emails to denx servers.
>>>>>        >
>>>>>        > I'm fine with applying the series as-is. I'm a bit hesitant
>>>>>       though, if
>>>>>        > it should be applied to master or to next. As Tom clearly
>>>>>       noticed, that
>>>>>        > only fixes should be added after rc2 this time.
>>>>>        >
>>>>>        > What is your thinking on this?
>>>>>
>>>>>       Well, I do not know. AFAIK more patches here are fixing broken mvebu
>>>>>       boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
>>>>>
>>>>>
>>>>> A388 Clearfog was definitely broken prior to this patchset. There is
>>>>> quite a bit of churn that this has caused for some OpenWRT users [1] as
>>>>> well as for me. It would be nice to have a stable build for these
>>>>> boards.
>>>>>
>>>>> [1] https://github.com/openwrt/openwrt/issues/11661
>>>>> <https://github.com/openwrt/openwrt/issues/11661>
>>>>
>>>> Okay. Thanks for the explanation. So it makes sense to pull this
>>>> patchset at this stage IMHO.
>>>>
>>>> BUT: While trying to apply the patches sent to me directly this fails at
>>>> this patch:
>>>>
>>>> tools: kwbimage: Add support for XIP SPI/NOR images
>>>>
>>>> I tried to fix this merge problem manually, but this looks a bit bogus.
>>>> That's why I followed your instruction to pull the patches directly from
>>>> github:
>>>>
>>>> git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
>>>>
>>>> This works and all patches apply clean. But looking into the patches I
>>>> noticed, that these patches from github do not include all patches
>>>> sent to the list. refs/pull/275/merge:mvebu stops after
>>>>
>>>> tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
>>>>
>>>> This is the patch directly before the failing patch mentioned above.
>>>>
>>>> Pali, could you please explain what went wrong here? Maybe I'm missing
>>>> something?
>>>
>>> Yes, denx mail server is broken and randomly crashes when receiving /
>>> processing email. It just bounce back with server stacktrace or what.
>>> I tried to resend patches to ML which did not appeared on patchwork.
>>> But I cannot do more. So you can try to download patches from patchwork
>>> or from github.
>>
>> Okay, I understood the issues with the DENX mail server. Sorry about
>> this.
>>
>> But: Please re-read my lines above. The patches on github are less than
>> the patches sent to the list. There are *more* patches sent to the list
>> (or to me directly) than in your github branch.
> 
> Ou, so there are more patches on the list than on github? Strange
> because I sent exactly same patches to ML and on github and some patches
> were not correctly delivered to mail, therefore number of mail patches
> could be less than on github.
> 
>> So my question is, why are less patches in your github branch? Or did
>> you try to re-send with this smaller amount of patches and this did not
>> work because of the crashing mail server?
> 
> I cannot understand how it is possible. There should be 59 patches. I
> have not created / sent more patches. If there is missing some patch on
> Github I can double check it...

Most likely I have fat-fingered myself something here. Please forget
about this. My fault.

Thanks,
Stefan

> 
>> Thanks,
>> Stefan
>>
>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>>
>>>>>        > Thanks,
>>>>>        > Stefan
>>>>>        >
>>>>>        > >
>>>>>        > > >
>>>>>        > > > Pali Rohár (59):
>>>>>        > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
>>>>>        > > >      kwbimage
>>>>>        > > >    tools: kwboot: Fix parsing SDIO kwbimage
>>>>>        > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
>>>>>        > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>>>>>        > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
>>>>>        > > >      kwbimage
>>>>>        > > >    tools: kwboot: Fix parsing SATA kwbimage
>>>>>        > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
>>>>>        > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>>>>>        > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>>>>>        > > >      BOOT_DEVICE_MMC2_2
>>>>>        > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
>>>>>       boot partition
>>>>>        > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>>>>>        > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
>>>>>       from SD card
>>>>>        > > >    tools: kwboot: Add more documentation references
>>>>>        > > >    tools: kwboot: Add image type documentation
>>>>>        > > >    tools: kwboot: Fix parsing UART image without data checksum
>>>>>        > > >    tools: kwboot: Validate optional kwbimage v1 headers
>>>>>        > > >    tools: kwboot: Add check that kwbimage contains DDR init code
>>>>>        > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
>>>>>        > > >    tools: kwboot: Show image type and error parsing reasons
>>>>>        > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>>>>>        > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
>>>>>        > > >    cmd: mvebu/bubt: Add support for reading image from the
>>>>>       SATA disk
>>>>>        > > >      partition
>>>>>        > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>>>>>        > > >    cmd: mvebu/bubt: Mark all local symbols as static
>>>>>        > > >    cmd: mvebu/bubt: Do not modify image in A8K
>>>>>       check_image_header()
>>>>>        > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
>>>>>        > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
>>>>>       Armada SoCs
>>>>>        > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>>>>>        > > >    cmd: mvebu/bubt: Fix warnings: unused variable
>>>>>       'secure_mode' and
>>>>>        > > >      'fuse_read_u64' defined but not used
>>>>>        > > >    cmd: mvebu/bubt: Enable command by default
>>>>>        > > >    tools: kwbimage: Fix dumping register set / DATA commands
>>>>>        > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>>>>>        > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>>>>>        > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
>>>>>        > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
>>>>>        > > >    tools: kwbimage: Fix endianity when printing kwbimage header
>>>>>        > > >    tools: kwbimage: Reject mkimage -F option
>>>>>        > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
>>>>>       images
>>>>>        > > >    tools: kwbimage: Print binary image offset as size
>>>>>        > > >    tools: kwbimage: Print image data offset when printing
>>>>>       kwbimage header
>>>>>        > > >    tools: kwbimage: Simplify add_secure_header_v1()
>>>>>        > > >    tools: kwbimage: Rename imagesz to dataoff
>>>>>        > > >    tools: kwbimage: Fix generating secure boot data image
>>>>>       signature
>>>>>        > > >    tools: kwbimage: Fix invalid secure boot header signature
>>>>>        > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
>>>>>       XIP images
>>>>>        > > >    tools: kwbimage: Add support for XIP SPI/NOR images
>>>>>        > > >    tools: mkimage: Print human readable error when -d is not
>>>>>       specified
>>>>>        > > >    tools: mkimage: Do not try to open datafile when it is skipped
>>>>>        > > >    tools: kwbimage: Add support for creating an image with no
>>>>>       data
>>>>>        > > >    arm: mvebu: Add support for generating NAND kwbimage
>>>>>        > > >    arm: mvebu: Add support for generating PEX kwbimage
>>>>>        > > >    arm: mvebu: Fix description of
>>>>>       MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>>>>>        > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>>>>>        > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
>>>>>        > > >    arm: mvebu: Remove A39x relicts
>>>>>        > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>>>>>        > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
>>>>>       U-Boot
>>>>>        > > >    arm: mvebu: Define SPL memory maps
>>>>>        > > >    doc/kwboot.1: Update example description
>>>>>        > > >
>>>>>        > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>>>>>        > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
>>>>>        > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>>>>>        > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>>>>>        > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
>>>>>       <http://kwbimage.cfg.in>           |   5 +
>>>>>        > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>>>>>        > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>>>>>        > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>>>>>        > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>>>>>        > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>>>>>        > > >   cmd/mvebu/Kconfig                             |  18 ++
>>>>>        > > >   cmd/mvebu/bubt.c                              | 253
>>>>>       ++++++++++++---
>>>>>        > > >   common/spl/Kconfig                            |   9 +
>>>>>        > > >   common/spl/spl_mmc.c                          |  12 +-
>>>>>        > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>>>>>        > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>>>>>        > > >   doc/kwboot.1                                  |   3 +-
>>>>>        > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
>>>>>        > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>>>>>        > > >   tools/kwbimage.c                              | 297
>>>>>       +++++++++++-------
>>>>>        > > >   tools/kwboot.c                                | 200
>>>>>       +++++++++++-
>>>>>        > > >   tools/mkimage.c                               |  11 +-
>>>>>        > > >   22 files changed, 768 insertions(+), 281 deletions(-)
>>>>>        > > >   copy configs/{clearfog_defconfig =>
>>>>>       clearfog_sata_defconfig} (98%)
>>>>>        > > >   copy configs/{db-88f6820-amc_defconfig =>
>>>>>       db-88f6820-amc_nand_defconfig} (92%)
>>>>>        > > >
>>>>>        > > > --
>>>>>        > > > 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 <mailto:sr@denx.de>
>>>>>
>>>>
>>>> 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
>>
>> 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

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 28 February 2023 11:10:21 Pali Rohár wrote:
> On Tuesday 28 February 2023 11:01:55 Stefan Roese wrote:
> > Hi Pali,
> > 
> > On 2/28/23 10:54, Pali Rohár wrote:
> > > On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote:
> > > > Hi Martin,
> > > > Hi Pali,
> > > > 
> > > > On 2/27/23 12:29, Martin Rowe wrote:
> > > > > On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org
> > > > > <mailto:pali@kernel.org>> wrote:
> > > > > 
> > > > >      On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
> > > > >       > Hi Pali,
> > > > >       >
> > > > >       > On 2/25/23 23:00, Pali Rohár wrote:
> > > > >       > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> > > > >       > > > This patch series contains various improvements and fixes for
> > > > >      existing
> > > > >       > > > logical errors. Boot phase was adjusted to match behavior of
> > > > >      Armada 385
> > > > >       > > > BootROM by inspecting and disassembling of BootROM binary
> > > > >      dump itself.
> > > > >       > > > Important information are included in documentation patch for
> > > > >      kwboot.
> > > > >       > > > Most of the changes are untested, hence this patch series is
> > > > >      just RFC.
> > > > >       > > > So please test changes before applying, idealy on SPI, SATA
> > > > >      and SD/MMC.
> > > > >       > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > >       > > > https://github.com/u-boot/u-boot/pull/275
> > > > >      <https://github.com/u-boot/u-boot/pull/275>
> > > > >       > >
> > > > >       > > Patches were tested on more boards and seems there is no
> > > > >      reported issue,
> > > > >       > > but other improvements.
> > > > >       > >
> > > > >       > > So do you need something to modify in this relatively big patch
> > > > >      series?
> > > > >       > > If it is not really needed I would like to not send it again
> > > > >      because
> > > > >       > > denx servers are not able to handle it. And it take me lot of
> > > > >      time to
> > > > >       > > send patches over emails to denx servers.
> > > > >       >
> > > > >       > I'm fine with applying the series as-is. I'm a bit hesitant
> > > > >      though, if
> > > > >       > it should be applied to master or to next. As Tom clearly
> > > > >      noticed, that
> > > > >       > only fixes should be added after rc2 this time.
> > > > >       >
> > > > >       > What is your thinking on this?
> > > > > 
> > > > >      Well, I do not know. AFAIK more patches here are fixing broken mvebu
> > > > >      boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
> > > > > 
> > > > > 
> > > > > A388 Clearfog was definitely broken prior to this patchset. There is
> > > > > quite a bit of churn that this has caused for some OpenWRT users [1] as
> > > > > well as for me. It would be nice to have a stable build for these
> > > > > boards.
> > > > > 
> > > > > [1] https://github.com/openwrt/openwrt/issues/11661
> > > > > <https://github.com/openwrt/openwrt/issues/11661>
> > > > 
> > > > Okay. Thanks for the explanation. So it makes sense to pull this
> > > > patchset at this stage IMHO.
> > > > 
> > > > BUT: While trying to apply the patches sent to me directly this fails at
> > > > this patch:
> > > > 
> > > > tools: kwbimage: Add support for XIP SPI/NOR images
> > > > 
> > > > I tried to fix this merge problem manually, but this looks a bit bogus.
> > > > That's why I followed your instruction to pull the patches directly from
> > > > github:
> > > > 
> > > > git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > > 
> > > > This works and all patches apply clean. But looking into the patches I
> > > > noticed, that these patches from github do not include all patches
> > > > sent to the list. refs/pull/275/merge:mvebu stops after
> > > > 
> > > > tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
> > > > 
> > > > This is the patch directly before the failing patch mentioned above.
> > > > 
> > > > Pali, could you please explain what went wrong here? Maybe I'm missing
> > > > something?
> > > 
> > > Yes, denx mail server is broken and randomly crashes when receiving /
> > > processing email. It just bounce back with server stacktrace or what.
> > > I tried to resend patches to ML which did not appeared on patchwork.
> > > But I cannot do more. So you can try to download patches from patchwork
> > > or from github.
> > 
> > Okay, I understood the issues with the DENX mail server. Sorry about
> > this.
> > 
> > But: Please re-read my lines above. The patches on github are less than
> > the patches sent to the list. There are *more* patches sent to the list
> > (or to me directly) than in your github branch.
> 
> Ou, so there are more patches on the list than on github? Strange
> because I sent exactly same patches to ML and on github and some patches
> were not correctly delivered to mail, therefore number of mail patches
> could be less than on github.
> 
> > So my question is, why are less patches in your github branch? Or did
> > you try to re-send with this smaller amount of patches and this did not
> > work because of the crashing mail server?
> 
> I cannot understand how it is possible. There should be 59 patches. I
> have not created / sent more patches. If there is missing some patch on
> Github I can double check it...

Github says that there are 59 commits too:
https://github.com/u-boot/u-boot/pull/275

And on patchwork are 59 too:
https://patchwork.ozlabs.org/project/uboot/list/?series=343058&state=*

So which patch is missing? Or what happened? Anyway, I am currently on
the mobile phone with slow internet, so it is harder for me to checkout
git and compare it with emails.

> 
> > Thanks,
> > Stefan
> > 
> > > 
> > > > Thanks,
> > > > Stefan
> > > > 
> > > > > 
> > > > >       > Thanks,
> > > > >       > Stefan
> > > > >       >
> > > > >       > >
> > > > >       > > >
> > > > >       > > > Pali Rohár (59):
> > > > >       > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
> > > > >       > > >      kwbimage
> > > > >       > > >    tools: kwboot: Fix parsing SDIO kwbimage
> > > > >       > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
> > > > >       > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> > > > >       > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
> > > > >       > > >      kwbimage
> > > > >       > > >    tools: kwboot: Fix parsing SATA kwbimage
> > > > >       > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
> > > > >       > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
> > > > >       > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> > > > >       > > >      BOOT_DEVICE_MMC2_2
> > > > >       > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
> > > > >      boot partition
> > > > >       > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> > > > >       > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
> > > > >      from SD card
> > > > >       > > >    tools: kwboot: Add more documentation references
> > > > >       > > >    tools: kwboot: Add image type documentation
> > > > >       > > >    tools: kwboot: Fix parsing UART image without data checksum
> > > > >       > > >    tools: kwboot: Validate optional kwbimage v1 headers
> > > > >       > > >    tools: kwboot: Add check that kwbimage contains DDR init code
> > > > >       > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
> > > > >       > > >    tools: kwboot: Show image type and error parsing reasons
> > > > >       > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> > > > >       > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
> > > > >       > > >    cmd: mvebu/bubt: Add support for reading image from the
> > > > >      SATA disk
> > > > >       > > >      partition
> > > > >       > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
> > > > >       > > >    cmd: mvebu/bubt: Mark all local symbols as static
> > > > >       > > >    cmd: mvebu/bubt: Do not modify image in A8K
> > > > >      check_image_header()
> > > > >       > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
> > > > >       > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
> > > > >      Armada SoCs
> > > > >       > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> > > > >       > > >    cmd: mvebu/bubt: Fix warnings: unused variable
> > > > >      'secure_mode' and
> > > > >       > > >      'fuse_read_u64' defined but not used
> > > > >       > > >    cmd: mvebu/bubt: Enable command by default
> > > > >       > > >    tools: kwbimage: Fix dumping register set / DATA commands
> > > > >       > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> > > > >       > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> > > > >       > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
> > > > >       > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
> > > > >       > > >    tools: kwbimage: Fix endianity when printing kwbimage header
> > > > >       > > >    tools: kwbimage: Reject mkimage -F option
> > > > >       > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
> > > > >      images
> > > > >       > > >    tools: kwbimage: Print binary image offset as size
> > > > >       > > >    tools: kwbimage: Print image data offset when printing
> > > > >      kwbimage header
> > > > >       > > >    tools: kwbimage: Simplify add_secure_header_v1()
> > > > >       > > >    tools: kwbimage: Rename imagesz to dataoff
> > > > >       > > >    tools: kwbimage: Fix generating secure boot data image
> > > > >      signature
> > > > >       > > >    tools: kwbimage: Fix invalid secure boot header signature
> > > > >       > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
> > > > >      XIP images
> > > > >       > > >    tools: kwbimage: Add support for XIP SPI/NOR images
> > > > >       > > >    tools: mkimage: Print human readable error when -d is not
> > > > >      specified
> > > > >       > > >    tools: mkimage: Do not try to open datafile when it is skipped
> > > > >       > > >    tools: kwbimage: Add support for creating an image with no
> > > > >      data
> > > > >       > > >    arm: mvebu: Add support for generating NAND kwbimage
> > > > >       > > >    arm: mvebu: Add support for generating PEX kwbimage
> > > > >       > > >    arm: mvebu: Fix description of
> > > > >      MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
> > > > >       > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
> > > > >       > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
> > > > >       > > >    arm: mvebu: Remove A39x relicts
> > > > >       > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
> > > > >       > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
> > > > >      U-Boot
> > > > >       > > >    arm: mvebu: Define SPL memory maps
> > > > >       > > >    doc/kwboot.1: Update example description
> > > > >       > > >
> > > > >       > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
> > > > >       > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
> > > > >       > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
> > > > >       > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
> > > > >       > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
> > > > >      <http://kwbimage.cfg.in>           |   5 +
> > > > >       > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
> > > > >       > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
> > > > >       > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
> > > > >       > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
> > > > >       > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
> > > > >       > > >   cmd/mvebu/Kconfig                             |  18 ++
> > > > >       > > >   cmd/mvebu/bubt.c                              | 253
> > > > >      ++++++++++++---
> > > > >       > > >   common/spl/Kconfig                            |   9 +
> > > > >       > > >   common/spl/spl_mmc.c                          |  12 +-
> > > > >       > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
> > > > >       > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
> > > > >       > > >   doc/kwboot.1                                  |   3 +-
> > > > >       > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
> > > > >       > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
> > > > >       > > >   tools/kwbimage.c                              | 297
> > > > >      +++++++++++-------
> > > > >       > > >   tools/kwboot.c                                | 200
> > > > >      +++++++++++-
> > > > >       > > >   tools/mkimage.c                               |  11 +-
> > > > >       > > >   22 files changed, 768 insertions(+), 281 deletions(-)
> > > > >       > > >   copy configs/{clearfog_defconfig =>
> > > > >      clearfog_sata_defconfig} (98%)
> > > > >       > > >   copy configs/{db-88f6820-amc_defconfig =>
> > > > >      db-88f6820-amc_nand_defconfig} (92%)
> > > > >       > > >
> > > > >       > > > --
> > > > >       > > > 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 <mailto:sr@denx.de>
> > > > > 
> > > > 
> > > > 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
> > 
> > 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 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Tuesday 28 February 2023 10:48:24 Pali Rohár wrote:
> On Monday 27 February 2023 17:17:31 Tony Dinh wrote:
> > Hi Pali,
> > 
> > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > >
> > > Hi Pali,
> > >
> > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > >
> > > > Hi Pali,
> > > > It is not related to this patch series (I also tested without the
> > > > patch series to confirm). But it is strange that I can no longer get
> > > > the configuration to boot from SPI. The 1st device in the boot order
> > > > is alway BOOTROM. The spl_boot_list is printed out below.
> > > >
> > > > <BEGIN LOG>
> > > > High speed PHY - Ended Successfully
> > > > mv_ddr: 14.0.0
> > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > > mv_ddr: completed successfully
> > > > board_boot_order spl_boot_list[0] = 15
> > > > Trying to boot from BOOTROM
> > > > Returning to BootROM (return address 0xffff05c4)...
> > > > BootROM: Image checksum verification PASSED
> > > > <END LOG>
> > > >
> > > > The SPL SPI configs (board Thecus N2350) are:
> > > > # grep SPL .config| grep SPI
> > > >
> > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > > > CONFIG_SPL_DM_SPI=y
> > > > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > > > CONFIG_SPL_SPI=y
> > > > CONFIG_SPL_DM_SPI_FLASH=y
> > > > CONFIG_SPL_SPI_FLASH_TINY=y
> > > > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > > > CONFIG_SPL_SPI_LOAD=y
> > > >
> > > > Did I miss something new lately?
> > > >
> > > > Thanks,
> > > > Tony
> > > >
> > > > Trying to boot from BOOTROM
> > > > Returning to BootROM (return address 0xffff05c4)...
> > > > BootROM: Image checksum verification PASSED
> > >
> > > It turns out that the board strapping register itself is the problem.
> > > boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> > > surely does not match what we expected for A38x  (#define
> > > BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> > > it fell to the default case, which is BOOTROM.
> > >
> > > <BEGIN LOG>
> > > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> > > 16:24:01 -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
> > > BOOTROM_REG=0x97001000 boot_device=0x9

Wait...

Stop here. BOOTROM_REG is the value of BOOTROM_ERR_REG register which is
mvebu register 0x182d0.

Boot strapping pins are available in the SAR_REG register which is mvebu
register 0x18600 and SPL prints it under name SAR_REG.

So above boot_device=9 is not strapping pin configuration but something
parsed from BOOTROM_ERR_REG.

So above 0x9 signal some A385 bootrom error and SPL in case case of any
error (value different from zero) always use bootrom for loading proper
u-boot. As it thinks that bootrom loaded u-boot via uart. Seems that
this assumption is incorrect.

Unfortunately upper four bits which above code parses from mvebu
register 0x182d0 are marked as reserved in functional specification.

So it is needed to inspect bootrom binary when it sets these bits...

> > > spl_boot_device boot_device = 15
> > > board_boot_order spl_boot_list[0] = 15
> > > Trying to boot from BOOTROM
> > > Returning to BootROM (return address 0xffff05c4)...
> > > BootROM: Image checksum verification PASSED
> > > <END LOG>
> > >
> > > Is there a chance this value 0x9 means something that we have not come across?
> > 
> > Found the answer in the A38x Hardware Specs. I've never noticed this
> > before. This board has the Sample at Reset set to boot from NAND!
> > 
> > "Table 48: Boot Device Mode Options
> > 0x9
> > BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
> > 4 Address cycles support per page, using MPP multiplexing option of
> > NAND 8 bits
> > 0x32
> > BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
> > Flash type, using MPP multiplexing option of SPI on MPP[25:22]"
> > 
> > So what we actually see here is the fall back to BootROM. And BootROM
> > still loads the image from SPI, ignoring that strapping. Am I confused
> > or correct? :)
> > 
> > Thanks,
> > Tony
> 
> I already wrote in some thread that in Hardware Specifications are
> documented all strapping pins options and u-boot has defined just few of
> them in header files. Beware that strapping pins are SoC specific and so
> you always need to look at the correct document.
> 
> About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart
> from bootrom to main u-boot and type of the SoC?

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,

On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 28 February 2023 10:48:24 Pali Rohár wrote:
> > On Monday 27 February 2023 17:17:31 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > >
> > > > Hi Pali,
> > > >
> > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > > >
> > > > > Hi Pali,
> > > > > It is not related to this patch series (I also tested without the
> > > > > patch series to confirm). But it is strange that I can no longer get
> > > > > the configuration to boot from SPI. The 1st device in the boot order
> > > > > is alway BOOTROM. The spl_boot_list is printed out below.
> > > > >
> > > > > <BEGIN LOG>
> > > > > High speed PHY - Ended Successfully
> > > > > mv_ddr: 14.0.0
> > > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > > > mv_ddr: completed successfully
> > > > > board_boot_order spl_boot_list[0] = 15
> > > > > Trying to boot from BOOTROM
> > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > BootROM: Image checksum verification PASSED
> > > > > <END LOG>
> > > > >
> > > > > The SPL SPI configs (board Thecus N2350) are:
> > > > > # grep SPL .config| grep SPI
> > > > >
> > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > > > > CONFIG_SPL_DM_SPI=y
> > > > > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > > > > CONFIG_SPL_SPI=y
> > > > > CONFIG_SPL_DM_SPI_FLASH=y
> > > > > CONFIG_SPL_SPI_FLASH_TINY=y
> > > > > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > > > > CONFIG_SPL_SPI_LOAD=y
> > > > >
> > > > > Did I miss something new lately?
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > > >
> > > > > Trying to boot from BOOTROM
> > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > BootROM: Image checksum verification PASSED
> > > >
> > > > It turns out that the board strapping register itself is the problem.
> > > > boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> > > > surely does not match what we expected for A38x  (#define
> > > > BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> > > > it fell to the default case, which is BOOTROM.
> > > >
> > > > <BEGIN LOG>
> > > > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> > > > 16:24:01 -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
> > > > BOOTROM_REG=0x97001000 boot_device=0x9
>
> Wait...
>
> Stop here. BOOTROM_REG is the value of BOOTROM_ERR_REG register which is
> mvebu register 0x182d0.
>
> Boot strapping pins are available in the SAR_REG register which is mvebu
> register 0x18600 and SPL prints it under name SAR_REG.

Ah, I see. Thanks Pali. I've jumped the gun too soon after seeing the
1st boot_device debug statement! Please see below.

>
> So above boot_device=9 is not strapping pin configuration but something
> parsed from BOOTROM_ERR_REG.
>
> So above 0x9 signal some A385 bootrom error and SPL in case case of any
> error (value different from zero) always use bootrom for loading proper
> u-boot. As it thinks that bootrom loaded u-boot via uart. Seems that
> this assumption is incorrect.
>
> Unfortunately upper four bits which above code parses from mvebu
> register 0x182d0 are marked as reserved in functional specification.
>
> So it is needed to inspect bootrom binary when it sets these bits...

I think I understand the problem now. The strapping is for Spi 1,
which is 0x34, but it has not been defined in u-boot yet. We have only
Spi 0 defined in the code, which is 0x32.

A38x Hardware Specs
0x34
BootROM Enabled, Boot from SPI: Controller #1, 24 address bits, NOR
Flash type, using MPP multiplexing option of SPI on MPP[59:56]

/arch/arm/mach-mvebu/include/mach/soc.h
#define BOOT_FROM_SPI 0x32

Here is the boot log. This time I have the SAR_REG printed out.

<BEGIN LOG>
BootROM - 1.73
Booting from SPI flash

U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 -
13:13:39 -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
BOOTROM_REG=0x97001000 boot_device=0x9
get_boot_device boot_device 0
SAR_REG=0xcb00934c boot_device=0x34
spl_boot_device boot_device = 15
board_boot_order spl_boot_list[0] = 15
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
BootROM: Image checksum verification PASSED


U-Boot 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 - 13:13:39 -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... SF: Detected mx25l3205d with page
size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

Model: Thecus N2350
Net:
Warning: ethernet@70000 (eth0) using random MAC address - 16:55:96:55:52:5e
eth0: ethernet@70000
Hit any key to stop autoboot:  0
<END LOG>

I guess we can add this to /arch/arm/mach-mvebu/include/mach/soc.h and
make sure the case is added to the switch statement in
arch/arm/mach-mvebu/cpu.c. Let me try this test.

Thanks,
Tony

> > > > spl_boot_device boot_device = 15
> > > > board_boot_order spl_boot_list[0] = 15
> > > > Trying to boot from BOOTROM
> > > > Returning to BootROM (return address 0xffff05c4)...
> > > > BootROM: Image checksum verification PASSED
> > > > <END LOG>
> > > >
> > > > Is there a chance this value 0x9 means something that we have not come across?
> > >
> > > Found the answer in the A38x Hardware Specs. I've never noticed this
> > > before. This board has the Sample at Reset set to boot from NAND!
> > >
> > > "Table 48: Boot Device Mode Options
> > > 0x9
> > > BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
> > > 4 Address cycles support per page, using MPP multiplexing option of
> > > NAND 8 bits
> > > 0x32
> > > BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
> > > Flash type, using MPP multiplexing option of SPI on MPP[25:22]"
> > >
> > > So what we actually see here is the fall back to BootROM. And BootROM
> > > still loads the image from SPI, ignoring that strapping. Am I confused
> > > or correct? :)
> > >
> > > Thanks,
> > > Tony
> >
> > I already wrote in some thread that in Hardware Specifications are
> > documented all strapping pins options and u-boot has defined just few of
> > them in header files. Beware that strapping pins are SoC specific and so
> > you always need to look at the correct document.
> >
> > About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart
> > from bootrom to main u-boot and type of the SoC?

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Pali Rohár]

On Tuesday 28 February 2023 13:51:24 Tony Dinh wrote:
> Hi Pali,
> 
> On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 28 February 2023 10:48:24 Pali Rohár wrote:
> > > On Monday 27 February 2023 17:17:31 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > > >
> > > > > Hi Pali,
> > > > >
> > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > > > >
> > > > > > Hi Pali,
> > > > > > It is not related to this patch series (I also tested without the
> > > > > > patch series to confirm). But it is strange that I can no longer get
> > > > > > the configuration to boot from SPI. The 1st device in the boot order
> > > > > > is alway BOOTROM. The spl_boot_list is printed out below.
> > > > > >
> > > > > > <BEGIN LOG>
> > > > > > High speed PHY - Ended Successfully
> > > > > > mv_ddr: 14.0.0
> > > > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > > > > mv_ddr: completed successfully
> > > > > > board_boot_order spl_boot_list[0] = 15
> > > > > > Trying to boot from BOOTROM
> > > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > > BootROM: Image checksum verification PASSED
> > > > > > <END LOG>
> > > > > >
> > > > > > The SPL SPI configs (board Thecus N2350) are:
> > > > > > # grep SPL .config| grep SPI
> > > > > >
> > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > > > > > CONFIG_SPL_DM_SPI=y
> > > > > > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > > > > > CONFIG_SPL_SPI=y
> > > > > > CONFIG_SPL_DM_SPI_FLASH=y
> > > > > > CONFIG_SPL_SPI_FLASH_TINY=y
> > > > > > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > > > > > CONFIG_SPL_SPI_LOAD=y
> > > > > >
> > > > > > Did I miss something new lately?
> > > > > >
> > > > > > Thanks,
> > > > > > Tony
> > > > > >
> > > > > > Trying to boot from BOOTROM
> > > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > > BootROM: Image checksum verification PASSED
> > > > >
> > > > > It turns out that the board strapping register itself is the problem.
> > > > > boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> > > > > surely does not match what we expected for A38x  (#define
> > > > > BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> > > > > it fell to the default case, which is BOOTROM.
> > > > >
> > > > > <BEGIN LOG>
> > > > > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> > > > > 16:24:01 -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
> > > > > BOOTROM_REG=0x97001000 boot_device=0x9
> >
> > Wait...
> >
> > Stop here. BOOTROM_REG is the value of BOOTROM_ERR_REG register which is
> > mvebu register 0x182d0.
> >
> > Boot strapping pins are available in the SAR_REG register which is mvebu
> > register 0x18600 and SPL prints it under name SAR_REG.
> 
> Ah, I see. Thanks Pali. I've jumped the gun too soon after seeing the
> 1st boot_device debug statement! Please see below.

Perfect!

> >
> > So above boot_device=9 is not strapping pin configuration but something
> > parsed from BOOTROM_ERR_REG.
> >
> > So above 0x9 signal some A385 bootrom error and SPL in case case of any
> > error (value different from zero) always use bootrom for loading proper
> > u-boot. As it thinks that bootrom loaded u-boot via uart. Seems that
> > this assumption is incorrect.
> >
> > Unfortunately upper four bits which above code parses from mvebu
> > register 0x182d0 are marked as reserved in functional specification.
> >
> > So it is needed to inspect bootrom binary when it sets these bits...
> 
> I think I understand the problem now. The strapping is for Spi 1,
> which is 0x34, but it has not been defined in u-boot yet. We have only
> Spi 0 defined in the code, which is 0x32.
> 
> A38x Hardware Specs
> 0x34
> BootROM Enabled, Boot from SPI: Controller #1, 24 address bits, NOR
> Flash type, using MPP multiplexing option of SPI on MPP[59:56]
> 
> /arch/arm/mach-mvebu/include/mach/soc.h
> #define BOOT_FROM_SPI 0x32
> 
> Here is the boot log. This time I have the SAR_REG printed out.

Ok, this looks correct. BootROM prints that boots from SPI and SPL just
needs correct bootstrap detection.

I would propose to rather define some macro e.g.
BOOT_FROM_IS_SPI(boot_device)
which returns true if boot_device is any SPI option as defined in HW
spec. And not just two options.

> <BEGIN LOG>
> BootROM - 1.73
> Booting from SPI flash
> 
> U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 -
> 13:13:39 -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
> BOOTROM_REG=0x97001000 boot_device=0x9
> get_boot_device boot_device 0
> SAR_REG=0xcb00934c boot_device=0x34
> spl_boot_device boot_device = 15
> board_boot_order spl_boot_list[0] = 15
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> BootROM: Image checksum verification PASSED
> 
> 
> U-Boot 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 - 13:13:39 -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... SF: Detected mx25l3205d with page
> size 256 Bytes, erase size 4 KiB, total 4 MiB
> *** Warning - bad CRC, using default environment
> 
> Model: Thecus N2350
> Net:
> Warning: ethernet@70000 (eth0) using random MAC address - 16:55:96:55:52:5e
> eth0: ethernet@70000
> Hit any key to stop autoboot:  0
> <END LOG>
> 
> I guess we can add this to /arch/arm/mach-mvebu/include/mach/soc.h and
> make sure the case is added to the switch statement in
> arch/arm/mach-mvebu/cpu.c. Let me try this test.
> 
> Thanks,
> Tony
> 
> > > > > spl_boot_device boot_device = 15
> > > > > board_boot_order spl_boot_list[0] = 15
> > > > > Trying to boot from BOOTROM
> > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > BootROM: Image checksum verification PASSED
> > > > > <END LOG>
> > > > >
> > > > > Is there a chance this value 0x9 means something that we have not come across?
> > > >
> > > > Found the answer in the A38x Hardware Specs. I've never noticed this
> > > > before. This board has the Sample at Reset set to boot from NAND!
> > > >
> > > > "Table 48: Boot Device Mode Options
> > > > 0x9
> > > > BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
> > > > 4 Address cycles support per page, using MPP multiplexing option of
> > > > NAND 8 bits
> > > > 0x32
> > > > BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
> > > > Flash type, using MPP multiplexing option of SPI on MPP[25:22]"
> > > >
> > > > So what we actually see here is the fall back to BootROM. And BootROM
> > > > still loads the image from SPI, ignoring that strapping. Am I confused
> > > > or correct? :)
> > > >
> > > > Thanks,
> > > > Tony
> > >
> > > I already wrote in some thread that in Hardware Specifications are
> > > documented all strapping pins options and u-boot has defined just few of
> > > them in header files. Beware that strapping pins are SoC specific and so
> > > you always need to look at the correct document.
> > >
> > > About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart
> > > from bootrom to main u-boot and type of the SoC?

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Pali Rohár]

On Tuesday 28 February 2023 11:16:03 Stefan Roese wrote:
> Hi Pali,
> 
> On 2/28/23 11:10, Pali Rohár wrote:
> > On Tuesday 28 February 2023 11:01:55 Stefan Roese wrote:
> > > Hi Pali,
> > > 
> > > On 2/28/23 10:54, Pali Rohár wrote:
> > > > On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote:
> > > > > Hi Martin,
> > > > > Hi Pali,
> > > > > 
> > > > > On 2/27/23 12:29, Martin Rowe wrote:
> > > > > > On Mon, 27 Feb 2023 at 08:04, Pali Rohár <pali@kernel.org
> > > > > > <mailto:pali@kernel.org>> wrote:
> > > > > > 
> > > > > >       On Monday 27 February 2023 08:44:30 Stefan Roese wrote:
> > > > > >        > Hi Pali,
> > > > > >        >
> > > > > >        > On 2/25/23 23:00, Pali Rohár wrote:
> > > > > >        > > On Tuesday 21 February 2023 21:18:26 Pali Rohár wrote:
> > > > > >        > > > This patch series contains various improvements and fixes for
> > > > > >       existing
> > > > > >        > > > logical errors. Boot phase was adjusted to match behavior of
> > > > > >       Armada 385
> > > > > >        > > > BootROM by inspecting and disassembling of BootROM binary
> > > > > >       dump itself.
> > > > > >        > > > Important information are included in documentation patch for
> > > > > >       kwboot.
> > > > > >        > > > Most of the changes are untested, hence this patch series is
> > > > > >       just RFC.
> > > > > >        > > > So please test changes before applying, idealy on SPI, SATA
> > > > > >       and SD/MMC.
> > > > > >        > > > Nevertheless all patches on github passed CI testing in this PR:
> > > > > >        > > > https://github.com/u-boot/u-boot/pull/275
> > > > > >       <https://github.com/u-boot/u-boot/pull/275>
> > > > > >        > >
> > > > > >        > > Patches were tested on more boards and seems there is no
> > > > > >       reported issue,
> > > > > >        > > but other improvements.
> > > > > >        > >
> > > > > >        > > So do you need something to modify in this relatively big patch
> > > > > >       series?
> > > > > >        > > If it is not really needed I would like to not send it again
> > > > > >       because
> > > > > >        > > denx servers are not able to handle it. And it take me lot of
> > > > > >       time to
> > > > > >        > > send patches over emails to denx servers.
> > > > > >        >
> > > > > >        > I'm fine with applying the series as-is. I'm a bit hesitant
> > > > > >       though, if
> > > > > >        > it should be applied to master or to next. As Tom clearly
> > > > > >       noticed, that
> > > > > >        > only fixes should be added after rc2 this time.
> > > > > >        >
> > > > > >        > What is your thinking on this?
> > > > > > 
> > > > > >       Well, I do not know. AFAIK more patches here are fixing broken mvebu
> > > > > >       boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment?
> > > > > > 
> > > > > > 
> > > > > > A388 Clearfog was definitely broken prior to this patchset. There is
> > > > > > quite a bit of churn that this has caused for some OpenWRT users [1] as
> > > > > > well as for me. It would be nice to have a stable build for these
> > > > > > boards.
> > > > > > 
> > > > > > [1] https://github.com/openwrt/openwrt/issues/11661
> > > > > > <https://github.com/openwrt/openwrt/issues/11661>
> > > > > 
> > > > > Okay. Thanks for the explanation. So it makes sense to pull this
> > > > > patchset at this stage IMHO.
> > > > > 
> > > > > BUT: While trying to apply the patches sent to me directly this fails at
> > > > > this patch:
> > > > > 
> > > > > tools: kwbimage: Add support for XIP SPI/NOR images
> > > > > 
> > > > > I tried to fix this merge problem manually, but this looks a bit bogus.
> > > > > That's why I followed your instruction to pull the patches directly from
> > > > > github:
> > > > > 
> > > > > git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
> > > > > 
> > > > > This works and all patches apply clean. But looking into the patches I
> > > > > noticed, that these patches from github do not include all patches
> > > > > sent to the list. refs/pull/275/merge:mvebu stops after
> > > > > 
> > > > > tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
> > > > > 
> > > > > This is the patch directly before the failing patch mentioned above.
> > > > > 
> > > > > Pali, could you please explain what went wrong here? Maybe I'm missing
> > > > > something?
> > > > 
> > > > Yes, denx mail server is broken and randomly crashes when receiving /
> > > > processing email. It just bounce back with server stacktrace or what.
> > > > I tried to resend patches to ML which did not appeared on patchwork.
> > > > But I cannot do more. So you can try to download patches from patchwork
> > > > or from github.
> > > 
> > > Okay, I understood the issues with the DENX mail server. Sorry about
> > > this.
> > > 
> > > But: Please re-read my lines above. The patches on github are less than
> > > the patches sent to the list. There are *more* patches sent to the list
> > > (or to me directly) than in your github branch.
> > 
> > Ou, so there are more patches on the list than on github? Strange
> > because I sent exactly same patches to ML and on github and some patches
> > were not correctly delivered to mail, therefore number of mail patches
> > could be less than on github.
> > 
> > > So my question is, why are less patches in your github branch? Or did
> > > you try to re-send with this smaller amount of patches and this did not
> > > work because of the crashing mail server?
> > 
> > I cannot understand how it is possible. There should be 59 patches. I
> > have not created / sent more patches. If there is missing some patch on
> > Github I can double check it...
> 
> Most likely I have fat-fingered myself something here. Please forget
> about this. My fault.

Ok. So do you have all patches in the correct form?

> Thanks,
> Stefan
> 
> > 
> > > Thanks,
> > > Stefan
> > > 
> > > > 
> > > > > Thanks,
> > > > > Stefan
> > > > > 
> > > > > > 
> > > > > >        > Thanks,
> > > > > >        > Stefan
> > > > > >        >
> > > > > >        > >
> > > > > >        > > >
> > > > > >        > > > Pali Rohár (59):
> > > > > >        > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
> > > > > >        > > >      kwbimage
> > > > > >        > > >    tools: kwboot: Fix parsing SDIO kwbimage
> > > > > >        > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
> > > > > >        > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> > > > > >        > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
> > > > > >        > > >      kwbimage
> > > > > >        > > >    tools: kwboot: Fix parsing SATA kwbimage
> > > > > >        > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
> > > > > >        > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
> > > > > >        > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> > > > > >        > > >      BOOT_DEVICE_MMC2_2
> > > > > >        > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
> > > > > >       boot partition
> > > > > >        > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> > > > > >        > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
> > > > > >       from SD card
> > > > > >        > > >    tools: kwboot: Add more documentation references
> > > > > >        > > >    tools: kwboot: Add image type documentation
> > > > > >        > > >    tools: kwboot: Fix parsing UART image without data checksum
> > > > > >        > > >    tools: kwboot: Validate optional kwbimage v1 headers
> > > > > >        > > >    tools: kwboot: Add check that kwbimage contains DDR init code
> > > > > >        > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
> > > > > >        > > >    tools: kwboot: Show image type and error parsing reasons
> > > > > >        > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> > > > > >        > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
> > > > > >        > > >    cmd: mvebu/bubt: Add support for reading image from the
> > > > > >       SATA disk
> > > > > >        > > >      partition
> > > > > >        > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
> > > > > >        > > >    cmd: mvebu/bubt: Mark all local symbols as static
> > > > > >        > > >    cmd: mvebu/bubt: Do not modify image in A8K
> > > > > >       check_image_header()
> > > > > >        > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
> > > > > >        > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
> > > > > >       Armada SoCs
> > > > > >        > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> > > > > >        > > >    cmd: mvebu/bubt: Fix warnings: unused variable
> > > > > >       'secure_mode' and
> > > > > >        > > >      'fuse_read_u64' defined but not used
> > > > > >        > > >    cmd: mvebu/bubt: Enable command by default
> > > > > >        > > >    tools: kwbimage: Fix dumping register set / DATA commands
> > > > > >        > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> > > > > >        > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> > > > > >        > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
> > > > > >        > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
> > > > > >        > > >    tools: kwbimage: Fix endianity when printing kwbimage header
> > > > > >        > > >    tools: kwbimage: Reject mkimage -F option
> > > > > >        > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
> > > > > >       images
> > > > > >        > > >    tools: kwbimage: Print binary image offset as size
> > > > > >        > > >    tools: kwbimage: Print image data offset when printing
> > > > > >       kwbimage header
> > > > > >        > > >    tools: kwbimage: Simplify add_secure_header_v1()
> > > > > >        > > >    tools: kwbimage: Rename imagesz to dataoff
> > > > > >        > > >    tools: kwbimage: Fix generating secure boot data image
> > > > > >       signature
> > > > > >        > > >    tools: kwbimage: Fix invalid secure boot header signature
> > > > > >        > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
> > > > > >       XIP images
> > > > > >        > > >    tools: kwbimage: Add support for XIP SPI/NOR images
> > > > > >        > > >    tools: mkimage: Print human readable error when -d is not
> > > > > >       specified
> > > > > >        > > >    tools: mkimage: Do not try to open datafile when it is skipped
> > > > > >        > > >    tools: kwbimage: Add support for creating an image with no
> > > > > >       data
> > > > > >        > > >    arm: mvebu: Add support for generating NAND kwbimage
> > > > > >        > > >    arm: mvebu: Add support for generating PEX kwbimage
> > > > > >        > > >    arm: mvebu: Fix description of
> > > > > >       MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
> > > > > >        > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
> > > > > >        > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
> > > > > >        > > >    arm: mvebu: Remove A39x relicts
> > > > > >        > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
> > > > > >        > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
> > > > > >       U-Boot
> > > > > >        > > >    arm: mvebu: Define SPL memory maps
> > > > > >        > > >    doc/kwboot.1: Update example description
> > > > > >        > > >
> > > > > >        > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
> > > > > >        > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
> > > > > >        > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
> > > > > >        > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
> > > > > >        > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
> > > > > >       <http://kwbimage.cfg.in>           |   5 +
> > > > > >        > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
> > > > > >        > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
> > > > > >        > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
> > > > > >        > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
> > > > > >        > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
> > > > > >        > > >   cmd/mvebu/Kconfig                             |  18 ++
> > > > > >        > > >   cmd/mvebu/bubt.c                              | 253
> > > > > >       ++++++++++++---
> > > > > >        > > >   common/spl/Kconfig                            |   9 +
> > > > > >        > > >   common/spl/spl_mmc.c                          |  12 +-
> > > > > >        > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
> > > > > >        > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
> > > > > >        > > >   doc/kwboot.1                                  |   3 +-
> > > > > >        > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
> > > > > >        > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
> > > > > >        > > >   tools/kwbimage.c                              | 297
> > > > > >       +++++++++++-------
> > > > > >        > > >   tools/kwboot.c                                | 200
> > > > > >       +++++++++++-
> > > > > >        > > >   tools/mkimage.c                               |  11 +-
> > > > > >        > > >   22 files changed, 768 insertions(+), 281 deletions(-)
> > > > > >        > > >   copy configs/{clearfog_defconfig =>
> > > > > >       clearfog_sata_defconfig} (98%)
> > > > > >        > > >   copy configs/{db-88f6820-amc_defconfig =>
> > > > > >       db-88f6820-amc_nand_defconfig} (92%)
> > > > > >        > > >
> > > > > >        > > > --
> > > > > >        > > > 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 <mailto:sr@denx.de>
> > > > > > 
> > > > > 
> > > > > 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
> > > 
> > > 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
> 
> 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 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Pali,

On Tue, Feb 28, 2023 at 2:19 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 28 February 2023 13:51:24 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Feb 28, 2023 at 10:52 AM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Tuesday 28 February 2023 10:48:24 Pali Rohár wrote:
> > > > On Monday 27 February 2023 17:17:31 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > > > >
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh <mibodhi@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Pali,
> > > > > > > It is not related to this patch series (I also tested without the
> > > > > > > patch series to confirm). But it is strange that I can no longer get
> > > > > > > the configuration to boot from SPI. The 1st device in the boot order
> > > > > > > is alway BOOTROM. The spl_boot_list is printed out below.
> > > > > > >
> > > > > > > <BEGIN LOG>
> > > > > > > High speed PHY - Ended Successfully
> > > > > > > mv_ddr: 14.0.0
> > > > > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> > > > > > > mv_ddr: completed successfully
> > > > > > > board_boot_order spl_boot_list[0] = 15
> > > > > > > Trying to boot from BOOTROM
> > > > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > > > BootROM: Image checksum verification PASSED
> > > > > > > <END LOG>
> > > > > > >
> > > > > > > The SPL SPI configs (board Thecus N2350) are:
> > > > > > > # grep SPL .config| grep SPI
> > > > > > >
> > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y
> > > > > > > CONFIG_SPL_DM_SPI=y
> > > > > > > CONFIG_SPL_SPI_FLASH_SUPPORT=y
> > > > > > > CONFIG_SPL_SPI=y
> > > > > > > CONFIG_SPL_DM_SPI_FLASH=y
> > > > > > > CONFIG_SPL_SPI_FLASH_TINY=y
> > > > > > > # CONFIG_SPL_SPI_FLASH_MTD is not set
> > > > > > > CONFIG_SPL_SPI_LOAD=y
> > > > > > >
> > > > > > > Did I miss something new lately?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Tony
> > > > > > >
> > > > > > > Trying to boot from BOOTROM
> > > > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > > > BootROM: Image checksum verification PASSED
> > > > > >
> > > > > > It turns out that the board strapping register itself is the problem.
> > > > > > boot_device=0x9 was printed out in arch/arm/mach-mvebu/cpu.c. It
> > > > > > surely does not match what we expected for A38x  (#define
> > > > > > BOOT_FROM_SPI 0x32). Actually 0x9 is not defined in cpu.c at all. So
> > > > > > it fell to the default case, which is BOOTROM.
> > > > > >
> > > > > > <BEGIN LOG>
> > > > > > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 27 2023 -
> > > > > > 16:24:01 -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
> > > > > > BOOTROM_REG=0x97001000 boot_device=0x9
> > >
> > > Wait...
> > >
> > > Stop here. BOOTROM_REG is the value of BOOTROM_ERR_REG register which is
> > > mvebu register 0x182d0.
> > >
> > > Boot strapping pins are available in the SAR_REG register which is mvebu
> > > register 0x18600 and SPL prints it under name SAR_REG.
> >
> > Ah, I see. Thanks Pali. I've jumped the gun too soon after seeing the
> > 1st boot_device debug statement! Please see below.
>
> Perfect!
>
> > >
> > > So above boot_device=9 is not strapping pin configuration but something
> > > parsed from BOOTROM_ERR_REG.
> > >
> > > So above 0x9 signal some A385 bootrom error and SPL in case case of any
> > > error (value different from zero) always use bootrom for loading proper
> > > u-boot. As it thinks that bootrom loaded u-boot via uart. Seems that
> > > this assumption is incorrect.
> > >
> > > Unfortunately upper four bits which above code parses from mvebu
> > > register 0x182d0 are marked as reserved in functional specification.
> > >
> > > So it is needed to inspect bootrom binary when it sets these bits...
> >
> > I think I understand the problem now. The strapping is for Spi 1,
> > which is 0x34, but it has not been defined in u-boot yet. We have only
> > Spi 0 defined in the code, which is 0x32.
> >
> > A38x Hardware Specs
> > 0x34
> > BootROM Enabled, Boot from SPI: Controller #1, 24 address bits, NOR
> > Flash type, using MPP multiplexing option of SPI on MPP[59:56]
> >
> > /arch/arm/mach-mvebu/include/mach/soc.h
> > #define BOOT_FROM_SPI 0x32
> >
> > Here is the boot log. This time I have the SAR_REG printed out.
>
> Ok, this looks correct. BootROM prints that boots from SPI and SPL just
> needs correct bootstrap detection.
>

So it works by just adding the bootstrap detection BOOT_FROM_SPI _1
(0x34) to the switch statement. Please see the log below.

<BEGIN LOG>
BootROM - 1.73
Booting from SPI flash

U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 -
16:18:28 -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
BOOTROM_REG=0x97001000 boot_device=0x9
get_boot_device boot_device 0
SAR_REG=0xcb00934c boot_device=0x34
spl_boot_device boot_device = 8
board_boot_order spl_boot_list[0] = 8
Trying to boot from SPI
spl_spi_load_image sf_bus = 0 sf_cs = 0
spi_flash_probe spi_flash


U-Boot 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 - 16:18:28 -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... SF: Detected mx25l3205d with page
size 256 Bytes, erase size 4 KiB, total 4 MiB
*** Warning - bad CRC, using default environment

Model: Thecus N2350
Net:
Warning: ethernet@70000 (eth0) using random MAC address - a2:7d:47:5b:4a:dc
eth0: ethernet@70000
Hit any key to stop autoboot:  0
N2350 > sf probe 0:0
SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total 4 MiB
N2350 >
<END LOG>

I think the SPI uclass logic is a bit misleading. The SPI device is
assigned bus 0 chip 0, it just means that it is the 1st bus it
detected the SPI flash on. It has no relation to SPI controller 0 or
1.

> I would propose to rather define some macro e.g.
> BOOT_FROM_IS_SPI(boot_device)
> which returns true if boot_device is any SPI option as defined in HW
> spec. And not just two options.

Not sure how to handle this cleanly yet!  BOOT_FROM_SPI is defined in
the #ifdef for each SoC (Armada 38x, Armada XP,...) and then used as a
case in the switch statement (for NAND, SPI, SATA....).

Thanks,
Tony

>
> > <BEGIN LOG>
> > BootROM - 1.73
> > Booting from SPI flash
> >
> > U-Boot SPL 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 -
> > 13:13:39 -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
> > BOOTROM_REG=0x97001000 boot_device=0x9
> > get_boot_device boot_device 0
> > SAR_REG=0xcb00934c boot_device=0x34
> > spl_boot_device boot_device = 15
> > board_boot_order spl_boot_list[0] = 15
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> > BootROM: Image checksum verification PASSED
> >
> >
> > U-Boot 2023.04-rc2-tld-1-00089-g3fe03f96fc-dirty (Feb 28 2023 - 13:13:39 -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... SF: Detected mx25l3205d with page
> > size 256 Bytes, erase size 4 KiB, total 4 MiB
> > *** Warning - bad CRC, using default environment
> >
> > Model: Thecus N2350
> > Net:
> > Warning: ethernet@70000 (eth0) using random MAC address - 16:55:96:55:52:5e
> > eth0: ethernet@70000
> > Hit any key to stop autoboot:  0
> > <END LOG>
> >
> > I guess we can add this to /arch/arm/mach-mvebu/include/mach/soc.h and
> > make sure the case is added to the switch statement in
> > arch/arm/mach-mvebu/cpu.c. Let me try this test.
> >
> > Thanks,
> > Tony
> >
> > > > > > spl_boot_device boot_device = 15
> > > > > > board_boot_order spl_boot_list[0] = 15
> > > > > > Trying to boot from BOOTROM
> > > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > > > BootROM: Image checksum verification PASSED
> > > > > > <END LOG>
> > > > > >
> > > > > > Is there a chance this value 0x9 means something that we have not come across?
> > > > >
> > > > > Found the answer in the A38x Hardware Specs. I've never noticed this
> > > > > before. This board has the Sample at Reset set to boot from NAND!
> > > > >
> > > > > "Table 48: Boot Device Mode Options
> > > > > 0x9
> > > > > BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B,
> > > > > 4 Address cycles support per page, using MPP multiplexing option of
> > > > > NAND 8 bits
> > > > > 0x32
> > > > > BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR
> > > > > Flash type, using MPP multiplexing option of SPI on MPP[25:22]"
> > > > >
> > > > > So what we actually see here is the fall back to BootROM. And BootROM
> > > > > still loads the image from SPI, ignoring that strapping. Am I confused
> > > > > or correct? :)
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > >
> > > > I already wrote in some thread that in Hardware Specifications are
> > > > documented all strapping pins options and u-boot has defined just few of
> > > > them in header files. Beware that strapping pins are SoC specific and so
> > > > you always need to look at the correct document.
> > > >
> > > > About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart
> > > > from bootrom to main u-boot and type of the SoC?

Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

Hi Pali,

On 2/28/23 23:41, Pali Rohár wrote:

<snip>

>>>> So my question is, why are less patches in your github branch? Or did
>>>> you try to re-send with this smaller amount of patches and this did not
>>>> work because of the crashing mail server?
>>>
>>> I cannot understand how it is possible. There should be 59 patches. I
>>> have not created / sent more patches. If there is missing some patch on
>>> Github I can double check it...
>>
>> Most likely I have fat-fingered myself something here. Please forget
>> about this. My fault.
> 
> Ok. So do you have all patches in the correct form?

Yes. All fine.

Thanks,
Stefan

>> Thanks,
>> Stefan
>>
>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Stefan
>>>>>>
>>>>>>>
>>>>>>>         > Thanks,
>>>>>>>         > Stefan
>>>>>>>         >
>>>>>>>         > >
>>>>>>>         > > >
>>>>>>>         > > > Pali Rohár (59):
>>>>>>>         > > >    tools: kwbimage: Fix generating, verifying and extracting SDIO
>>>>>>>         > > >      kwbimage
>>>>>>>         > > >    tools: kwboot: Fix parsing SDIO kwbimage
>>>>>>>         > > >    arm: mvebu: spl: Fix parsing SDIO kwbimage
>>>>>>>         > > >    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>>>>>>>         > > >    tools: kwbimage: Fix generating, verifying and extracting SATA
>>>>>>>         > > >      kwbimage
>>>>>>>         > > >    tools: kwboot: Fix parsing SATA kwbimage
>>>>>>>         > > >    arm: mvebu: spl: Fix parsing SATA kwbimage
>>>>>>>         > > >    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>>>>>>>         > > >    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>>>>>>>         > > >      BOOT_DEVICE_MMC2_2
>>>>>>>         > > >    arm: mvebu: spl: Load proper U-Boot from selected eMMC
>>>>>>>        boot partition
>>>>>>>         > > >    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>>>>>>>         > > >    arm: mvebu: spl: Fix support for loading U-Boot proper
>>>>>>>        from SD card
>>>>>>>         > > >    tools: kwboot: Add more documentation references
>>>>>>>         > > >    tools: kwboot: Add image type documentation
>>>>>>>         > > >    tools: kwboot: Fix parsing UART image without data checksum
>>>>>>>         > > >    tools: kwboot: Validate optional kwbimage v1 headers
>>>>>>>         > > >    tools: kwboot: Add check that kwbimage contains DDR init code
>>>>>>>         > > >    tools: kwboot: Fix patching of SPI/NOR XIP images
>>>>>>>         > > >    tools: kwboot: Show image type and error parsing reasons
>>>>>>>         > > >    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>>>>>>>         > > >    cmd: mvebu/bubt: Add support for writing image to SATA disk
>>>>>>>         > > >    cmd: mvebu/bubt: Add support for reading image from the
>>>>>>>        SATA disk
>>>>>>>         > > >      partition
>>>>>>>         > > >    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>>>>>>>         > > >    cmd: mvebu/bubt: Mark all local symbols as static
>>>>>>>         > > >    cmd: mvebu/bubt: Do not modify image in A8K
>>>>>>>        check_image_header()
>>>>>>>         > > >    cmd: mvebu/bubt: Check also A8K boot image checksum
>>>>>>>         > > >    cmd: mvebu/bubt: Set correct default image name for 32-bit
>>>>>>>        Armada SoCs
>>>>>>>         > > >    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>>>>>>>         > > >    cmd: mvebu/bubt: Fix warnings: unused variable
>>>>>>>        'secure_mode' and
>>>>>>>         > > >      'fuse_read_u64' defined but not used
>>>>>>>         > > >    cmd: mvebu/bubt: Enable command by default
>>>>>>>         > > >    tools: kwbimage: Fix dumping register set / DATA commands
>>>>>>>         > > >    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>>>>>>>         > > >    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>>>>>>>         > > >    tools: kwbimage: Fix dumping NAND_BLKSZ
>>>>>>>         > > >    tools: kwbimage: Fix generating of kwbimage v0 header checksum
>>>>>>>         > > >    tools: kwbimage: Fix endianity when printing kwbimage header
>>>>>>>         > > >    tools: kwbimage: Reject mkimage -F option
>>>>>>>         > > >    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
>>>>>>>        images
>>>>>>>         > > >    tools: kwbimage: Print binary image offset as size
>>>>>>>         > > >    tools: kwbimage: Print image data offset when printing
>>>>>>>        kwbimage header
>>>>>>>         > > >    tools: kwbimage: Simplify add_secure_header_v1()
>>>>>>>         > > >    tools: kwbimage: Rename imagesz to dataoff
>>>>>>>         > > >    tools: kwbimage: Fix generating secure boot data image
>>>>>>>        signature
>>>>>>>         > > >    tools: kwbimage: Fix invalid secure boot header signature
>>>>>>>         > > >    tools: mkimage: Do not fill legacy_img_hdr for non-legacy
>>>>>>>        XIP images
>>>>>>>         > > >    tools: kwbimage: Add support for XIP SPI/NOR images
>>>>>>>         > > >    tools: mkimage: Print human readable error when -d is not
>>>>>>>        specified
>>>>>>>         > > >    tools: mkimage: Do not try to open datafile when it is skipped
>>>>>>>         > > >    tools: kwbimage: Add support for creating an image with no
>>>>>>>        data
>>>>>>>         > > >    arm: mvebu: Add support for generating NAND kwbimage
>>>>>>>         > > >    arm: mvebu: Add support for generating PEX kwbimage
>>>>>>>         > > >    arm: mvebu: Fix description of
>>>>>>>        MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>>>>>>>         > > >    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>>>>>>>         > > >    arm: mvebu: clearfog: Add defconfig for SATA booting
>>>>>>>         > > >    arm: mvebu: Remove A39x relicts
>>>>>>>         > > >    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>>>>>>>         > > >    arm: mvebu: Define env_sf_get_env_addr() also for Proper
>>>>>>>        U-Boot
>>>>>>>         > > >    arm: mvebu: Define SPL memory maps
>>>>>>>         > > >    doc/kwboot.1: Update example description
>>>>>>>         > > >
>>>>>>>         > > >   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>>>>>>>         > > >   arch/arm/mach-mvebu/Makefile                  |  13 +
>>>>>>>         > > >   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>>>>>>>         > > >   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>>>>>>>         > > >   arch/arm/mach-mvebu/kwbimage.cfg.in
>>>>>>>        <http://kwbimage.cfg.in>           |   5 +
>>>>>>>         > > >   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>>>>>>>         > > >   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>>>>>>>         > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>>>>>>>         > > >   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>>>>>>>         > > >   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>>>>>>>         > > >   cmd/mvebu/Kconfig                             |  18 ++
>>>>>>>         > > >   cmd/mvebu/bubt.c                              | 253
>>>>>>>        ++++++++++++---
>>>>>>>         > > >   common/spl/Kconfig                            |   9 +
>>>>>>>         > > >   common/spl/spl_mmc.c                          |  12 +-
>>>>>>>         > > >   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>>>>>>>         > > >   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>>>>>>>         > > >   doc/kwboot.1                                  |   3 +-
>>>>>>>         > > >   doc/mvebu/cmd/bubt.txt                        |  25 +-
>>>>>>>         > > >   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>>>>>>>         > > >   tools/kwbimage.c                              | 297
>>>>>>>        +++++++++++-------
>>>>>>>         > > >   tools/kwboot.c                                | 200
>>>>>>>        +++++++++++-
>>>>>>>         > > >   tools/mkimage.c                               |  11 +-
>>>>>>>         > > >   22 files changed, 768 insertions(+), 281 deletions(-)
>>>>>>>         > > >   copy configs/{clearfog_defconfig =>
>>>>>>>        clearfog_sata_defconfig} (98%)
>>>>>>>         > > >   copy configs/{db-88f6820-amc_defconfig =>
>>>>>>>        db-88f6820-amc_nand_defconfig} (92%)
>>>>>>>         > > >
>>>>>>>         > > > --
>>>>>>>         > > > 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 <mailto:sr@denx.de>
>>>>>>>
>>>>>>
>>>>>> 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
>>>>
>>>> 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
>>
>> 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

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 RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes

[Stefan Roese]

On 2/21/23 21:18, Pali Rohár wrote:
> This patch series contains various improvements and fixes for existing
> logical errors. Boot phase was adjusted to match behavior of Armada 385
> BootROM by inspecting and disassembling of BootROM binary dump itself.
> Important information are included in documentation patch for kwboot.
> Most of the changes are untested, hence this patch series is just RFC.
> So please test changes before applying, idealy on SPI, SATA and SD/MMC.
> Nevertheless all patches on github passed CI testing in this PR:
> https://github.com/u-boot/u-boot/pull/275
> 
> Pali Rohár (59):
>    tools: kwbimage: Fix generating, verifying and extracting SDIO
>      kwbimage
>    tools: kwboot: Fix parsing SDIO kwbimage
>    arm: mvebu: spl: Fix parsing SDIO kwbimage
>    cmd: mvebu/bubt: Fix parsing SDIO kwbimage
>    tools: kwbimage: Fix generating, verifying and extracting SATA
>      kwbimage
>    tools: kwboot: Fix parsing SATA kwbimage
>    arm: mvebu: spl: Fix parsing SATA kwbimage
>    cmd: mvebu/bubt: Fix parsing SATA kwbimage
>    arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
>      BOOT_DEVICE_MMC2_2
>    arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
>    spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
>    arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
>    tools: kwboot: Add more documentation references
>    tools: kwboot: Add image type documentation
>    tools: kwboot: Fix parsing UART image without data checksum
>    tools: kwboot: Validate optional kwbimage v1 headers
>    tools: kwboot: Add check that kwbimage contains DDR init code
>    tools: kwboot: Fix patching of SPI/NOR XIP images
>    tools: kwboot: Show image type and error parsing reasons
>    cmd: mvebu/bubt: Add support for selecting eMMC HW partition
>    cmd: mvebu/bubt: Add support for writing image to SATA disk
>    cmd: mvebu/bubt: Add support for reading image from the SATA disk
>      partition
>    cmd: mvebu/bubt: Rename variable image_size to hdr_size
>    cmd: mvebu/bubt: Mark all local symbols as static
>    cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
>    cmd: mvebu/bubt: Check also A8K boot image checksum
>    cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
>    cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
>    cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and
>      'fuse_read_u64' defined but not used
>    cmd: mvebu/bubt: Enable command by default
>    tools: kwbimage: Fix dumping register set / DATA commands
>    tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
>    tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
>    tools: kwbimage: Fix dumping NAND_BLKSZ
>    tools: kwbimage: Fix generating of kwbimage v0 header checksum
>    tools: kwbimage: Fix endianity when printing kwbimage header
>    tools: kwbimage: Reject mkimage -F option
>    tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
>    tools: kwbimage: Print binary image offset as size
>    tools: kwbimage: Print image data offset when printing kwbimage header
>    tools: kwbimage: Simplify add_secure_header_v1()
>    tools: kwbimage: Rename imagesz to dataoff
>    tools: kwbimage: Fix generating secure boot data image signature
>    tools: kwbimage: Fix invalid secure boot header signature
>    tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
>    tools: kwbimage: Add support for XIP SPI/NOR images
>    tools: mkimage: Print human readable error when -d is not specified
>    tools: mkimage: Do not try to open datafile when it is skipped
>    tools: kwbimage: Add support for creating an image with no data
>    arm: mvebu: Add support for generating NAND kwbimage
>    arm: mvebu: Add support for generating PEX kwbimage
>    arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
>    arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
>    arm: mvebu: clearfog: Add defconfig for SATA booting
>    arm: mvebu: Remove A39x relicts
>    arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
>    arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
>    arm: mvebu: Define SPL memory maps
>    doc/kwboot.1: Update example description
> 
>   arch/arm/mach-mvebu/Kconfig                   |  23 +-
>   arch/arm/mach-mvebu/Makefile                  |  13 +
>   arch/arm/mach-mvebu/cpu.c                     |  11 +-
>   arch/arm/mach-mvebu/include/mach/cpu.h        |  21 ++
>   arch/arm/mach-mvebu/kwbimage.cfg.in           |   5 +
>   .../serdes/a38x/high_speed_env_spec.c         |   4 +-
>   .../serdes/a38x/high_speed_env_spec.h         |   4 +-
>   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c |  14 +-
>   arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  30 --
>   arch/arm/mach-mvebu/spl.c                     |  84 +++--
>   cmd/mvebu/Kconfig                             |  18 ++
>   cmd/mvebu/bubt.c                              | 253 ++++++++++++---
>   common/spl/Kconfig                            |   9 +
>   common/spl/spl_mmc.c                          |  12 +-
>   ...rfog_defconfig => clearfog_sata_defconfig} |   2 +-
>   ...efconfig => db-88f6820-amc_nand_defconfig} |   6 +-
>   doc/kwboot.1                                  |   3 +-
>   doc/mvebu/cmd/bubt.txt                        |  25 +-
>   drivers/mtd/nand/raw/Kconfig                  |   4 +-
>   tools/kwbimage.c                              | 297 +++++++++++-------
>   tools/kwboot.c                                | 200 +++++++++++-
>   tools/mkimage.c                               |  11 +-
>   22 files changed, 768 insertions(+), 281 deletions(-)
>   copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
>   copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)
> 

Applied to u-boot-marvell/next

Thanks,
Stefan

Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting

[Tony Dinh]

Hi Stefan,

On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Stefan,
>
> On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese <sr@denx.de> wrote:
> >
> > Hi Tony,
> >
> > On 2/27/23 01:11, Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár <pali@kernel.org> wrote:
> > >>
> > >> On Saturday 25 February 2023 20:56:10 Tony Dinh wrote:
> > >>> Hi Martin,
> > >>>
> > >>> On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > >>>>
> > >>>>>>> I'm not sure how to run proper timing tests on the process, but
> > >>>>>>> stopwatch timing just between seeing "Trying to boot" and "U-Boot
> > >>>>>>> 2023.04-rc2" showed the return to BootROM under 1 second, and the
> > >>>>>>> direct from SPI around 4 seconds. I thought the goal of loading from
> > >>>>>>> SPI directly was speed, but returning to BootROM is significantly
> > >>>>>>> faster on this board.
> > >>>>>>
> > >>>>>> You should check SPI speed in DTS file and also in the defconfig.
> > >>>>>
> > >>>>> I think we have probably seen this slowdown before. There is a TODO in
> > >>>>> the way the DTS nodes are parsed by DM uclass. So this config must be
> > >>>>> set in defconfig to get around that bug:
> > >>>>> CONFIG_SF_DEFAULT_SPEED=50000000
> > >>>>
> > >>>> That works and is much faster now. I'll submit it in a V2 for these
> > >>>> two patches once Pali's mvebu changes are accepted. Only question I
> > >>>> have is: should the faster speed be applied to all three defconfigs?
> > >>>> CONFIG_SF_DEFAULT_SPEED=1000000 (50x less) is implicitly added to the
> > >>>> MMC and SATA configs at the moment.
> > >>>
> > >>> This is only a workaround to get the SPI probe to work correctly. The
> > >>> real fix should be in spi_flash_probe()
> > >>> ./common/spl/spl_spi.c
> > >>>          flash = spi_flash_probe(sf_bus, sf_cs,
> > >>>                                  CONFIG_SF_DEFAULT_SPEED,
> > >>>                                  CONFIG_SF_DEFAULT_MODE);
> > >>> If spi_flash_probe() failed to get SPI max_hz from the DTS, the
> > >>> fallback is CONFIG_SF_DEFAULT_SPEED.
> > >>>
> > >>> IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and
> > >>> CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or
> > >>> some other common place. And when we will have fixed the DTS parsing
> > >>> problem, they can be removed.
> > >>>
> > >>> I'd like to hear from Stefan and Pali if this approach sounds good.
> > >>>
> > >>> All the best,
> > >>> Tony
> > >>
> > >> Well, the maximal SPI speed depends on the wiring. You can have on the
> > >> board some SPI device which does not support high frequency.
> > >>
> > >> But having some sane defaults in Kconfig for mvebu makes sense.
> >
> > Agreed.
> >
> > > The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig
> > > does not specify it. I think the sane default value is 10_000_000
> > > (grepping the Armada* DTS files showing the slowest spi-max-frequency
> > > is 10_000_000). While a big improvement, it is not fast enough for
> > > many other boards. So we still need to define it in those board
> > > defconfigs (before fixing that bug), or use return to BootROM.
> >
> > I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU.
> > Not sure if this should be done in drivers/mtd/spi/Kconfig, as this
> > currently has no platform- / board- specific configurations. Perhaps
> > it can be done in a mach-mvebu Kconfig file instead?
>
> Yes, I think it should be done in mach-mvebu Kconfig, too. I will run
> some tests.

I sent in the patch that should go into u-boot-marvell/next.

Thanks,
Tony

kwbimage config file documentation (Was: Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes)

[Pali Rohár]

On Saturday 25 February 2023 01:18:26 Martin Rowe wrote:
>  - taken a look at the kwbimage documentation, but I don't think I can
> be of much help there

It should be pretty straightforward. Looking at how is documentation for
other format written (in the same manpage ./doc/mkimage.1), then looking
at existing kwbimage config files (find . -name "kwbimage.*cfg") and
looking into tools/kwbimage.c source code into functions which parses
config file (image_create_config_parse_oneline) and generate config file
(kwbimage_generate_config).