[PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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%)
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;
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);
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);
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;
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;
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:
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",
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");
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);
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
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");
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
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/applicati... + * - "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-... @@ -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-... + * - "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... + * - "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... */
#include "kwbimage.h"
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... * - "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... + * + * 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"
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) {
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
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
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) {
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; }
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)) {
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
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.
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
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
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
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
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
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:
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
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);
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;
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;
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);
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
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
'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 =
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
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"); }
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);
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)
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);
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; }
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)
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); }
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)
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]); } }
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)); }
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;
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); }
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;
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);
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
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)); }
/*
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",
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);
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)); }
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
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
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
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
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
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,
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 },
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;
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
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
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
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;
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
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@...
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
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@...
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
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@...
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
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@...
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.
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 = <µsom_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@...
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.
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/19a96f7c40a8fc1d0a6546ac2418d966e5...
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_armad...
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 = <µsom_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@...
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.
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/19a96f7c40a8fc1d0a6546ac2418d966e5...
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_armad...
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
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/19a96f7c40a8fc1d0a6546ac2418d966e5...
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_armad...
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.
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/19a96f7c40a8fc1d0a6546ac2418d966e5...
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_armad...
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.
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/19a96f7c40a8fc1d0a6546ac2418d966e5...
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_armad...
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...
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...
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.
[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
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.
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
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.
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.
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.
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).
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:
- 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.
- 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...
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!
[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
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
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
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.
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@...
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
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@...
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.
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@...
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
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@... > > 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
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@... > > > > 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
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@... > > > > > > 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
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%)
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
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
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
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
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
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
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
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
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
Hi Pali, Martin,
Am 25.02.23 um 10:48 schrieb Martin Rowe:
On Sat, 25 Feb 2023 at 07:41, Pali Rohárpali@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 Rowemartin.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/f4f8a69740a8415c05359e01e51650f445... 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
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/f4f8a69740a8415c05359e01e51650f445... 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
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/f4f8a69740a8415c05359e01e51650f445... 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
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/f4f8a69740a8415c05359e01e51650f445... 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
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.
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
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.
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,
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
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
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
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
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
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?
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?
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?
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?
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?
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
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/f4f8a69740a8415c05359e01e51650f445... 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
participants (5)
-
Josua Mayer -
Martin Rowe -
Pali Rohár -
Stefan Roese -
Tony Dinh