Re: [PATCH] CI: Update test/nokia_rx51_test.sh to use prebuilt images
On Tuesday 21 February 2023 11:22:29 Tom Rini wrote: > From: Pali Rohár > > Now that the Dockerfile creates images which have the binaries we > require included, have CI make symlinks for them and update the existing > script to support this. > > Signed-off-by: Tom Rini > --- > Pali, since you posted this in a thread as untested, can you please > reply with a S-o-b tag? I tweaked it slightly while testing. Thanks. If it works fine then OK. Signed-off-by: Pali Rohár > --- > .azure-pipelines.yml| 9 - > .gitlab-ci.yml | 11 +-- > test/nokia_rx51_test.sh | 24 > 3 files changed, 33 insertions(+), 11 deletions(-) > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml > index 8327edf87aa1..30025ff7517e 100644 > --- a/.azure-pipelines.yml > +++ b/.azure-pipelines.yml > @@ -2,7 +2,7 @@ variables: >windows_vm: windows-2019 >ubuntu_vm: ubuntu-22.04 >macos_vm: macOS-12 > - ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-10Feb2023 > + ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 ># Add '-u 0' options for Azure pipelines, otherwise we get "permission ># denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", ># since our $(ci_runner_image) user is not root. > @@ -187,6 +187,13 @@ stages: >options: $(container_option) > steps: >- script: | > + mkdir nokia_rx51_tmp > + ln -s /opt/nokia/u-boot-gen-combined nokia_rx51_tmp/ > + ln -s /opt/nokia/qemu-n900.tar.gz nokia_rx51_tmp/ > + ln -s /opt/nokia/kernel_2.6.28-20103103+0m5_armel.deb > nokia_rx51_tmp/ > + ln -s /opt/nokia/libc6_2.5.1-1eglibc27+0m5_armel.deb > nokia_rx51_tmp/ > + ln -s /opt/nokia/busybox_1.10.2.legal-1osso30+0m5_armel.deb > nokia_rx51_tmp/ > + ln -s /opt/nokia/qemu-system-arm nokia_rx51_tmp/ >export PATH=/opt/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin:$PATH >test/nokia_rx51_test.sh > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index c3ceca2974d3..e320a24ef31e 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -2,7 +2,7 @@ > > # Grab our configured image. The source for this is found > # in the u-boot tree at tools/docker/Dockerfile > -image: trini/u-boot-gitlab-ci-runner:jammy-20230126-10Feb2023 > +image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 > > # We run some tests in different order, to catch some failures quicker. > stages: > @@ -213,7 +213,14 @@ Run binman, buildman, dtoc, Kconfig and patman > testsuites: > Run tests for Nokia RX-51 (aka N900): >stage: testsuites >script: > -- export PATH=/opt/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin:$PATH; > +- mkdir nokia_rx51_tmp; > + ln -s /opt/nokia/u-boot-gen-combined nokia_rx51_tmp/; > + ln -s /opt/nokia/qemu-n900.tar.gz nokia_rx51_tmp/; > + ln -s /opt/nokia/kernel_2.6.28-20103103+0m5_armel.deb nokia_rx51_tmp/; > + ln -s /opt/nokia/libc6_2.5.1-1eglibc27+0m5_armel.deb nokia_rx51_tmp/; > + ln -s /opt/nokia/busybox_1.10.2.legal-1osso30+0m5_armel.deb > nokia_rx51_tmp/; > + ln -s /opt/nokia/qemu-system-arm nokia_rx51_tmp/; > + export PATH=/opt/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin:$PATH; >test/nokia_rx51_test.sh > > # Check for any pylint regressions > diff --git a/test/nokia_rx51_test.sh b/test/nokia_rx51_test.sh > index a516ec2967c3..dca9ef3027b7 100755 > --- a/test/nokia_rx51_test.sh > +++ b/test/nokia_rx51_test.sh > @@ -83,8 +83,10 @@ echo > > # Download qflasher and nolo images > # This is proprietary qemu flasher tool with first stage images, but license > allows non-commercial redistribution > -wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz > -tar -xf qemu-n900.tar.gz > +if ! test -f qflasher || ! test -f xloader-qemu.bin || ! test -f > secondary-qemu.bin; then > + test -f qemu-n900.tar.gz || wget -c > http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz > + tar -xf qemu-n900.tar.gz > +fi > > # Download Maemo script u-boot-gen-combined > if ! test -f u-boot-gen-combined; then > @@ -94,16 +96,22 @@ if ! test -f u-boot-gen-combined; then > fi > > # Download Maemo fiasco kernel > -wget -c > http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb > -dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28 > +if ! test -d kernel_2.6.28; then > + test -f kernel_2.6.28-20103103+0m5_armel.deb || wget -c > http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb > + dpkg -x
[PATCH RFC u-boot-mvebu 01/59] tools: kwbimage: Fix generating, verifying and extracting SDIO kwbimage
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
---
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 0x. */
if (main_hdr->blockid == IBR_HDR_PEX_ID)
main_hdr->srcaddr = cpu_to_le32(0x);
@@ -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 0x. */
if (main_hdr->blockid == IBR_HDR_PEX_ID)
main_hdr->srcaddr = cpu_to_le32(0x);
@@ -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 0x.
* 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 == 0x)
offset = header_size;
--
2.20.1
[PATCH RFC u-boot-mvebu 08/59] cmd: mvebu/bubt: Fix parsing SATA kwbimage
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
---
cmd/mvebu/bubt.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 6bb84da03ed6..2bcdf145f64a 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -738,14 +738,8 @@ static int check_image_header(void)
offset = le32_to_cpu(hdr->srcaddr);
size = le32_to_cpu(hdr->blocksize);
- if (hdr->blockid == 0x78) { /* SATA id */
- if (offset < 1) {
- printf("Error: Bad A38x image srcaddr.\n");
- return -ENOEXEC;
- }
- offset -= 1;
+ if (hdr->blockid == 0x78) /* SATA id */
offset *= 512;
- }
if (offset % 4 != 0 || size < 4 || size % 4 != 0) {
printf("Error: Bad A38x image blocksize.\n");
--
2.20.1
[PATCH RFC u-boot-mvebu 02/59] tools: kwboot: Fix parsing SDIO kwbimage
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
---
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 == 0x)
hdr->srcaddr = cpu_to_le32(hdrsz);
--
2.20.1
[PATCH RFC u-boot-mvebu 04/59] cmd: mvebu/bubt: Fix parsing SDIO kwbimage
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
---
cmd/mvebu/bubt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 1efbe2e607ca..6bb84da03ed6 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -747,9 +747,6 @@ static int check_image_header(void)
offset *= 512;
}
- if (hdr->blockid == 0xAE) /* SDIO id */
- offset *= 512;
-
if (offset % 4 != 0 || size < 4 || size % 4 != 0) {
printf("Error: Bad A38x image blocksize.\n");
return -ENOEXEC;
--
2.20.1
[PATCH RFC u-boot-mvebu 06/59] tools: kwboot: Fix parsing SATA kwbimage
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
---
tools/kwboot.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 188f944263fa..bf410520de63 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1888,10 +1888,7 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
switch (hdr->blockid) {
case IBR_HDR_SATA_ID:
- if (srcaddr < 1)
- goto err;
-
- hdr->srcaddr = cpu_to_le32((srcaddr - 1) * 512);
+ hdr->srcaddr = cpu_to_le32(srcaddr * 512);
break;
case IBR_HDR_PEX_ID:
--
2.20.1
[PATCH RFC u-boot-mvebu 09/59] arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2
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
---
arch/arm/mach-mvebu/spl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 6a398612628e..e14c7a9c6cf2 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -169,9 +169,7 @@ int spl_parse_board_header(struct spl_image_info *spl_image,
}
if (IS_ENABLED(CONFIG_SPL_MMC) &&
- (bootdev->boot_device == BOOT_DEVICE_MMC1 ||
-bootdev->boot_device == BOOT_DEVICE_MMC2 ||
-bootdev->boot_device == BOOT_DEVICE_MMC2_2) &&
+ (bootdev->boot_device == BOOT_DEVICE_MMC1) &&
mhdr->blockid != IBR_HDR_SDIO_ID) {
printf("ERROR: Wrong blockid (0x%x) in SDIO kwbimage\n",
mhdr->blockid);
--
2.20.1
[PATCH RFC u-boot-mvebu 26/59] cmd: mvebu/bubt: Check also A8K boot image checksum
Signed-off-by: Pali Rohár
---
cmd/mvebu/bubt.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 1b08ca9298c2..74ea037dda98 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -725,9 +725,8 @@ static int check_image_header(void)
{
struct mvebu_image_header *hdr =
(struct mvebu_image_header *)get_load_addr();
- u32 header_len = hdr->prolog_size;
u32 checksum;
- u32 checksum_ref = hdr->prolog_checksum;
+ u32 checksum_ref;
/*
* For now compare checksum, and magic. Later we can
@@ -739,8 +738,17 @@ static int check_image_header(void)
return -ENOEXEC;
}
- checksum = do_checksum32((u32 *)hdr, header_len);
+ checksum_ref = hdr->prolog_checksum;
+ checksum = do_checksum32((u32 *)hdr, hdr->prolog_size);
checksum -= hdr->prolog_checksum;
+ if (checksum != checksum_ref) {
+ printf("Error: Bad Prolog checksum. 0x%x != 0x%x\n",
+ checksum, checksum_ref);
+ return -ENOEXEC;
+ }
+
+ checksum_ref = hdr->boot_image_checksum;
+ checksum = do_checksum32((u32 *)((u8 *)hdr + hdr->prolog_size),
hdr->boot_image_size);
if (checksum != checksum_ref) {
printf("Error: Bad Image checksum. 0x%x != 0x%x\n",
checksum, checksum_ref);
--
2.20.1
[PATCH RFC u-boot-mvebu 18/59] tools: kwboot: Fix patching of SPI/NOR XIP images
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
---
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(0x)) {
kwboot_printv("Patching destination and execution
addresses from SPI/NOR XIP area to DDR area 0x0080\n");
- hdr->destaddr = cpu_to_le32(0x0080);
- hdr->execaddr = cpu_to_le32(0x0080);
+ hdr->destaddr = cpu_to_le32(0x0080 +
le32_to_cpu(hdr->srcaddr));
+ hdr->execaddr = cpu_to_le32(0x0080 +
le32_to_cpu(hdr->execaddr));
}
break;
}
--
2.20.1
[PATCH RFC u-boot-mvebu 24/59] cmd: mvebu/bubt: Mark all local symbols as static
There is no need to export these local functions and structures.
Signed-off-by: Pali Rohár
---
cmd/mvebu/bubt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 72ed87b89ec3..820d342ae100 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -687,7 +687,7 @@ enum bubt_devices {
BUBT_MAX_DEV
};
-struct bubt_dev bubt_devs[BUBT_MAX_DEV] = {
+static struct bubt_dev bubt_devs[BUBT_MAX_DEV] = {
{"tftp", tftp_read_file, NULL, is_tftp_active},
{"usb", usb_read_file, NULL, is_usb_active},
{"mmc", mmc_read_file, mmc_burn_image, is_mmc_active},
@@ -707,7 +707,7 @@ static int bubt_write_file(struct bubt_dev *dst, size_t
image_size)
}
#if defined(CONFIG_ARMADA_8K)
-u32 do_checksum32(u32 *start, int32_t len)
+static u32 do_checksum32(u32 *start, int32_t len)
{
u32 sum = 0;
u32 *startp = start;
@@ -1140,7 +1140,7 @@ static int bubt_is_dev_active(struct bubt_dev *dev)
return 1;
}
-struct bubt_dev *find_bubt_dev(char *dev_name)
+static struct bubt_dev *find_bubt_dev(char *dev_name)
{
int dev;
@@ -1168,7 +1168,7 @@ struct bubt_dev *find_bubt_dev(char *dev_name)
#endif
#endif /* DEFAULT_BUBT_DST */
-int do_bubt_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+static int do_bubt_cmd(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
{
struct bubt_dev *src, *dst;
size_t image_size;
--
2.20.1
[PATCH RFC u-boot-mvebu 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
[PATCH RFC u-boot-mvebu 07/59] arm: mvebu: spl: Fix parsing SATA kwbimage
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
---
arch/arm/mach-mvebu/spl.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index b238ba2f5d99..6a398612628e 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -182,19 +182,10 @@ int spl_parse_board_header(struct spl_image_info
*spl_image,
/*
* For SATA srcaddr is specified in number of sectors.
-* The main header is must be stored at sector number 1.
-* This expects that sector size is 512 bytes and recalculates
-* data offset to bytes relative to the main header.
+* This expects that sector size is 512 bytes.
*/
- if (IS_ENABLED(CONFIG_SPL_SATA) && mhdr->blockid == IBR_HDR_SATA_ID) {
- if (spl_image->offset < 1) {
- printf("ERROR: Wrong srcaddr (0x%08x) in SATA
kwbimage\n",
- spl_image->offset);
- return -EINVAL;
- }
- spl_image->offset -= 1;
+ if (IS_ENABLED(CONFIG_SPL_SATA) && mhdr->blockid == IBR_HDR_SATA_ID)
spl_image->offset *= 512;
- }
if (spl_image->offset % 4 != 0) {
printf("ERROR: Wrong srcaddr (0x%08x) in kwbimage\n",
--
2.20.1
[PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition
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
---
cmd/mvebu/bubt.c | 53 ++
doc/mvebu/cmd/bubt.txt | 21 -
2 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 2bcdf145f64a..4bad9a69527c 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
#ifdef CONFIG_BLK
struct blk_desc *blk_desc;
#endif
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ u8 part;
+ u8 orig_part;
+#endif
+
mmc = find_mmc_device(mmc_dev_num);
if (!mmc) {
printf("No SD/MMC/eMMC card found\n");
@@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
return err;
}
+#ifdef CONFIG_BLK
+ blk_desc = mmc_get_blk_desc(mmc);
+ if (!blk_desc) {
+ printf("Error - failed to obtain block descriptor\n");
+ return -ENODEV;
+ }
+#endif
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+ orig_part = blk_desc->hwpart;
+#else
+ orig_part = mmc->block_dev.hwpart;
+#endif
+
+ part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+ if (part == 7)
+ part = 0;
+
+#ifdef CONFIG_BLK
+ err = blk_dselect_hwpart(blk_desc, part);
+#else
+ err = mmc_switch_part(mmc, part);
+#endif
+
+ if (err) {
+ printf("Error - MMC partition switch failed\n");
+ return err;
+ }
+#endif
+
/* SD reserves LBA-0 for MBR and boots from LBA-1,
* MMC/eMMC boots from LBA-0
*/
@@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
if (image_size % mmc->write_bl_len)
blk_count += 1;
- blk_desc = mmc_get_blk_desc(mmc);
- if (!blk_desc) {
- printf("Error - failed to obtain block descriptor\n");
- return -ENODEV;
- }
blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
(void *)get_load_addr());
#else
@@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
start_lba, blk_count,
(void *)get_load_addr());
#endif /* CONFIG_BLK */
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+ err = blk_dselect_hwpart(blk_desc, orig_part);
+#else
+ err = mmc_switch_part(mmc, orig_part);
+#endif
+ if (err)
+ printf("Error - MMC failed to switch back to original
partition\n");
+#endif
+
if (blk_written != blk_count) {
printf("Error - written %#lx blocks\n", blk_written);
return -ENOSPC;
diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
index 6051243f1165..1fe1f07dd187 100644
--- a/doc/mvebu/cmd/bubt.txt
+++ b/doc/mvebu/cmd/bubt.txt
@@ -14,8 +14,7 @@ Examples:
Notes:
- For the TFTP interface set serverip and ipaddr.
-- To burn image to SD/eMMC device, the target is defined
- by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
+- To burn image to SD/eMMC device, the target is defined by HW partition.
Bubt command details (burn image step by-step)
--
@@ -40,10 +39,20 @@ Notes:
Number 0 is used for user data partition and should not be utilized for
storing
boot images and U-Boot environment in RAW mode since it will break file
system
structures usually located here.
- The default boot partition is BOOT0. It is selected by the following
parameter:
- CONFIG_SYS_MMC_ENV_PART=1
- Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
- Please never use partition number 0 here!
+
+ Currently configured boot partition can be printed by command:
+ # mmc partconf 0
+ (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
+
+ Change it to BOOT0:
+ # mmc partconf 0 0 1 1
+
+ Change it to BOOT1:
+ # mmc partconf 0 0 2 2
+
+ Change it to user data:
+ # mmc partconf 0 0 7 0
+
- The partition number is ignored if the target device is SD card.
- The boot image offset starts at block 0 for eMMC and block 1 for SD devices.
The block 0 on SD devices is left for MBR storage.
--
2.20.1
[PATCH RFC u-boot-mvebu 29/59] cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and 'fuse_read_u64' defined but not used
'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
---
cmd/mvebu/bubt.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 74ea037dda98..49797b23144b 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -984,7 +984,7 @@ static int check_image_header(void)
}
#endif
-#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_32BIT)
+#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_38X)
static u64 fuse_read_u64(u32 bank)
{
u32 val[2];
@@ -1013,7 +1013,10 @@ static inline u8 maj3(u8 val)
static int bubt_check_boot_mode(const struct bubt_dev *dst)
{
#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_32BIT)
- int mode, secure_mode;
+ int mode;
+#if defined(CONFIG_ARMADA_3700) || defined(CONFIG_ARMADA_38X)
+ int secure_mode;
+#endif
#if defined(CONFIG_ARMADA_3700)
const struct tim_boot_flash_sign *boot_modes = tim_boot_flash_signs;
const struct common_tim_data *hdr =
--
2.20.1
[PATCH RFC u-boot-mvebu 28/59] cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
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 --- cmd/mvebu/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig index 9f6ad2d1dd16..029f722096b1 100644 --- a/cmd/mvebu/Kconfig +++ b/cmd/mvebu/Kconfig @@ -18,6 +18,10 @@ if CMD_MVEBU_BUBT choice prompt "Flash for image" + default MVEBU_SPI_BOOT if MVEBU_SPL_BOOT_DEVICE_SPI + default MVEBU_NAND_BOOT if MVEBU_SPL_BOOT_DEVICE_NAND + default MVEBU_MMC_BOOT if MVEBU_SPL_BOOT_DEVICE_MMC + default MVEBU_SATA_BOOT if MVEBU_SPL_BOOT_DEVICE_SATA default MVEBU_SPI_BOOT config MVEBU_NAND_BOOT -- 2.20.1
[PATCH RFC u-boot-mvebu 13/59] tools: kwboot: Add more documentation references
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 --- tools/kwboot.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/tools/kwboot.c b/tools/kwboot.c index bf410520de63..aae7393aeef6 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -15,6 +15,12 @@ * Processor, and High-Definition Video Decoder: Functional Specifications" * August 3, 2011. Chapter 5 "BootROM Firmware" * https://web.archive.org/web/20120130172443/https://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf + * - "88F6665, 88F6660, 88F6658, 88F6655, 88F6655F, 88F6650, 88F6650F, 88F6610, + * and 88F6610F Avanta LP Family Integrated Single/Dual CPU Ecosystem for + * Gateway (GW), Home Gateway Unit (HGU), and Single Family Unit (SFU) + * Functional Specifications" Doc. No. MV-S108952-00, Rev. A. November 7, 2013. + * Chapter 7 "Boot Flow" + * CONFIDENTIAL, no public documentation available * - "88F6710, 88F6707, and 88F6W11: ARMADA(R) 370 SoC: Functional Specifications" * May 26, 2014. Chapter 6 "BootROM Firmware". * https://web.archive.org/web/20140617183701/https://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf @@ -22,6 +28,15 @@ * Multi-Core ARMv7 Based SoC Processors: Functional Specifications" * May 29, 2014. Chapter 6 "BootROM Firmware". * https://web.archive.org/web/20180829171131/https://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf + * - "BobCat2 Control and Management Subsystem Functional Specifications" + * Doc. No. MV-S109400-00, Rev. A. December 4, 2014. + * Chapter 1.6 BootROM Firmware + * CONFIDENTIAL, no public documentation available + * - "AlleyCat3 and PONCat3 Highly Integrated 1/10 Gigabit Ethernet Switch + * Control and Management Subsystem: Functional Specifications" + * Doc. No. MV-S109693-00, Rev. A. May 20, 2014. + * Chapter 1.6 BootROM Firmware + * CONFIDENTIAL, no public documentation available * - "ARMADA(R) 375 Value-Performance Dual Core CPU System on Chip: Functional * Specifications" Doc. No. MV-S109377-00, Rev. A. September 18, 2013. * Chapter 7 "Boot Sequence" @@ -35,6 +50,10 @@ * System on Chip Functional Specifications" Doc. No. MV-S109896-00, Rev. B. * December 22, 2015. Chapter 7 "Boot Flow" * CONFIDENTIAL, no public documentation available + * - "Marvell boot image parser", Marvell U-Boot 2013.01, version 18.06. September 17, 2015. + * https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/hdrparser.c + * - "Marvell doimage Tool", Marvell U-Boot 2013.01, version 18.06. August 30, 2015. + * https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/doimage.c */ #include "kwbimage.h" -- 2.20.1
[PATCH RFC u-boot-mvebu 12/59] arm: mvebu: spl: Fix support for loading U-Boot proper from SD card
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
---
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/spl.c | 40 -
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5303b1cbb965..2863babefbe3 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -331,6 +331,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
imply SPL_LIBDISK_SUPPORT
imply SPL_MMC
select SUPPORT_EMMC_BOOT if SPL_MMC
+ select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC
select SPL_BOOTROM_SUPPORT
config MVEBU_SPL_BOOT_DEVICE_SATA
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 0a809e91349c..02528e025d8c 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -33,14 +33,27 @@
#endif
/*
- * When loading U-Boot via SPL from eMMC (in Marvell terminology SDIO), the
- * kwbimage main header is stored at sector 0. U-Boot SPL needs to parse this
- * header and figure out at which sector the U-Boot proper binary is stored.
- * Partition booting is therefore not supported and
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
- * and CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET need to point to the
- * kwbimage main header.
+ * When loading U-Boot via SPL from eMMC, the kwbimage main header is stored at
+ * sector 0 and either on HW boot partition or on data partition. Choice of HW
+ * partition depends on what is configured in eMMC EXT_CSC register.
+ * When loading U-Boot via SPL from SD card, the kwbimage main header is stored
+ * at sector 1.
+ * Therefore MBR/GPT partition booting, fixed sector number and fixed eMMC HW
+ * partition number are unsupported due to limitation of Marvell BootROM.
+ * Correct sector number must be determined as runtime in mvebu SPL code based
+ * on the detected boot source. Otherwise U-Boot SPL would not be able to load
+ * U-Boot proper.
+ * Runtime mvebu SPL sector calculation code expects:
+ * - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0
+ * - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0
*/
#ifdef CONFIG_SPL_MMC
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT
+#error CONFIG_SYS_MMCSD_FS_BOOT is unsupported
+#endif
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
+#error CONFIG_SYS_MMCSD_FS_BOOT_PARTITION is unsupported
+#endif
#ifdef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG is unsupported
#endif
@@ -50,10 +63,14 @@
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
#endif
-#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) &&
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR != 0
+#ifndef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR must be enabled for SD/eMMC
boot support
+#endif
+#if !defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR) || \
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR != 0
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR must be set to 0
#endif
-#if defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET) && \
+#if !defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET) || \
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET != 0
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET must be set to 0
#endif
@@ -104,7 +121,12 @@ struct kwbimage_main_hdr_v1 {
#ifdef CONFIG_SPL_MMC
u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
- return MMCSD_MODE_EMMCBOOT;
+ return IS_SD(mmc) ? MMCSD_MODE_RAW : MMCSD_MODE_EMMCBOOT;
+}
+unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc,
+ unsigned long raw_sect)
+{
+ return IS_SD(mmc) ? 1 : 0;
}
#endif
--
2.20.1
[PATCH RFC u-boot-mvebu 49/59] tools: kwbimage: Add support for creating an image with no data
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
---
tools/kwbimage.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 7ebb625d03b9..309657a5637b 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1887,7 +1887,9 @@ static void kwbimage_set_header(void *ptr, struct stat
*sbuf, int ifd,
* Do not use sbuf->st_size as it contains size with padding.
* We need original image data size, so stat original file.
*/
- if (stat(params->datafile, &s)) {
+ if (params->skipcpy) {
+ s.st_size = 0;
+ } else if (stat(params->datafile, &s)) {
fprintf(stderr, "Could not stat data file %s: %s\n",
params->datafile, strerror(errno));
exit(EXIT_FAILURE);
@@ -2106,6 +2108,8 @@ static int kwbimage_verify_header(unsigned char *ptr, int
image_size,
return 0;
}
+static int kwbimage_align_size(int bootfrom, int alloc_len, struct stat s);
+
static int kwbimage_generate(struct image_tool_params *params,
struct image_type_params *tparams)
{
@@ -2124,7 +2128,9 @@ static int kwbimage_generate(struct image_tool_params
*params,
exit(EXIT_FAILURE);
}
- if (stat(params->datafile, &s)) {
+ if (params->skipcpy) {
+ s.st_size = 0;
+ } else if (stat(params->datafile, &s)) {
fprintf(stderr, "Could not stat data file %s: %s\n",
params->datafile, strerror(errno));
exit(EXIT_FAILURE);
@@ -2195,6 +2201,22 @@ static int kwbimage_generate(struct image_tool_params
*params,
tparams->header_size = alloc_len;
tparams->hdr = hdr;
+ /*
+* This function should return aligned size of the datafile.
+* When skipcpy is set (datafile is skipped) then return value of this
+* function is ignored, so we have to put required kwbimage aligning
+* into the preallocated header size.
+*/
+ if (params->skipcpy) {
+ tparams->header_size += kwbimage_align_size(bootfrom,
alloc_len, s);
+ return 0;
+ } else {
+ return kwbimage_align_size(bootfrom, alloc_len, s);
+ }
+}
+
+static int kwbimage_align_size(int bootfrom, int alloc_len, struct stat s)
+{
/*
* The resulting image needs to be 4-byte aligned. At least
* the Marvell hdrparser tool complains if its unaligned.
@@ -2510,7 +2532,7 @@ static int kwbimage_check_params(struct image_tool_params
*params)
return 1;
}
- return (params->dflag && (params->fflag || params->lflag)) ||
+ return (params->dflag && (params->fflag || params->lflag ||
params->skipcpy)) ||
(params->fflag) ||
(params->lflag && (params->dflag || params->fflag));
}
--
2.20.1
[PATCH RFC u-boot-mvebu 30/59] cmd: mvebu/bubt: Enable command by default
This makes updating of u-boot/firmware on Marvell boards easier. Signed-off-by: Pali Rohár --- cmd/mvebu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig index 029f722096b1..e83a98294912 100644 --- a/cmd/mvebu/Kconfig +++ b/cmd/mvebu/Kconfig @@ -3,6 +3,7 @@ depends on ARCH_MVEBU config CMD_MVEBU_BUBT bool "bubt" + default y select SHA256 if ARMADA_3700 select SHA512 if ARMADA_3700 select DOS_PARTITION if ARMADA_3700 -- 2.20.1
[PATCH RFC u-boot-mvebu 54/59] arm: mvebu: clearfog: Add defconfig for SATA booting
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
---
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=0x4030
CONFIG_SPL_SERIAL=y
--
2.20.1
[PATCH RFC u-boot-mvebu 39/59] tools: kwbimage: Print binary image offset as size
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
---
tools/kwbimage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index eb99ac944d24..a5de9855aa56 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1914,9 +1914,9 @@ static void kwbimage_print_header(const void *ptr)
printf("BIN Img Size: ");
genimg_print_size(opt_hdr_v1_size(ohdr) - 12 -
4 * ohdr->data[0]);
- printf("BIN Img Offs: %08x\n",
- (unsigned)((uint8_t *)ohdr - (uint8_t *)mhdr) +
- 8 + 4 * ohdr->data[0]);
+ printf("BIN Img Offs: ");
+ genimg_print_size(((uint8_t *)ohdr - (uint8_t *)mhdr) +
+ 8 + 4 * ohdr->data[0]);
}
}
--
2.20.1
[PATCH RFC u-boot-mvebu 45/59] tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images
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
---
tools/mkimage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 30c6df77081f..955a1f39a419 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -842,7 +842,9 @@ copy_file (int ifd, const char *datafile, int pad)
exit (EXIT_FAILURE);
}
- if (params.xflag) {
+ if (params.xflag &&
+ (((params.type > IH_TYPE_INVALID) && (params.type <
IH_TYPE_FLATDT)) ||
+(params.type == IH_TYPE_KERNEL_NOLOAD) || (params.type ==
IH_TYPE_FIRMWARE_IVT))) {
unsigned char *p = NULL;
/*
* XIP: do not append the struct legacy_img_hdr at the
--
2.20.1
[PATCH RFC u-boot-mvebu 59/59] doc/kwboot.1: Update example description
Mention fact about changing baudrate back when -B is used. Signed-off-by: Pali Rohár --- 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 520 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 520 -t /dev/ttyUSB0 -- 2.20.1
[PATCH RFC u-boot-mvebu 22/59] cmd: mvebu/bubt: Add support for reading image from the SATA disk partition
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
---
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-sourceThe source to load image from [tftp, usb, mmc].
Default = " DEFAULT_BUBT_SRC "\n"
+ "\t-sourceThe 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
- - sourceSource to load image from [tftp, usb]. default
= tftp
+ - sourceSource to load image from [tftp, usb, mmc,
sata]. default = tftp
Examples:
bubt- Burn flash-image.bin from tftp to
active flash
--
2.20.1
[PATCH RFC u-boot-mvebu 43/59] tools: kwbimage: Fix generating secure boot data image signature
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
---
tools/kwbimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index b32f845b7e2d..a8a59c154b9c 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1355,7 +1355,7 @@ static int add_secure_header_v1(struct image_tool_params
*params, uint8_t *image
if (kwb_sign_csk_with_kak(params, secure_hdr, csk))
return 1;
- if (kwb_sign_and_verify(csk, image_ptr, image_size,
+ if (kwb_sign_and_verify(csk, image_ptr, image_size - 4,
&secure_hdr->imgsig, "image") < 0)
return 1;
--
2.20.1
[PATCH RFC u-boot-mvebu 56/59] arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping
Signed-off-by: Pali Rohár
---
arch/arm/mach-mvebu/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 1f8cdf8744e6..c5089a91c747 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -25,7 +25,7 @@ static const struct mbus_win windows[] = {
{ MBUS_SPI_BASE, MBUS_SPI_SIZE,
CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_SPIFLASH },
- /* NOR */
+ /* BootROM */
{ MBUS_BOOTROM_BASE, MBUS_BOOTROM_SIZE,
CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_BOOTROM },
--
2.20.1
[PATCH RFC u-boot-mvebu 47/59] tools: mkimage: Print human readable error when -d is not specified
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
---
tools/mkimage.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 955a1f39a419..c53768f8d8de 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -568,6 +568,11 @@ int main(int argc, char **argv)
}
if ((params.type != IH_TYPE_MULTI) && (params.type != IH_TYPE_SCRIPT)) {
+ if (!params.datafile) {
+ fprintf(stderr, "%s: Option -d with image data file was
not specified\n",
+ params.cmdname);
+ exit(EXIT_FAILURE);
+ }
dfd = open(params.datafile, O_RDONLY | O_BINARY);
if (dfd < 0) {
fprintf(stderr, "%s: Can't open %s: %s\n",
--
2.20.1
[PATCH RFC u-boot-mvebu 53/59] arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting
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=0x4
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
---
...-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=0x1
CONFIG_ENV_OFFSET=0x10
CONFIG_ENV_SECT_SIZE=0x4
@@ -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=5000
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=0x4
CONFIG_SYS_NAND_ONFI_DETECTION=y
+CONFIG_SYS_NAND_PAGE_SIZE=0x1000
CONFIG_SF_DEFAULT_BUS=1
CONFIG_SPI_FLASH_BAR=y
CONFIG_SPI_FLASH_MACRONIX=y
--
2.20.1
[PATCH RFC u-boot-mvebu 32/59] tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p -1'
option")
Signed-off-by: Pali Rohár
---
tools/kwbimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 1719b0415da1..a6f6f1578c79 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2182,7 +2182,7 @@ static int kwbimage_generate_config(void *ptr, struct
image_tool_params *params)
fprintf(f, "NAND_ECC_MODE %s\n",
image_nand_ecc_mode_name(mhdr0->nandeccmode));
if (mhdr->blockid == IBR_HDR_NAND_ID)
- fprintf(f, "NAND_PAGE_SIZE 0x%x\n",
(unsigned)mhdr->nandpagesize);
+ fprintf(f, "NAND_PAGE_SIZE 0x%x\n",
(unsigned)le16_to_cpu(mhdr->nandpagesize));
if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID)
fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize);
--
2.20.1
[PATCH RFC u-boot-mvebu 41/59] tools: kwbimage: Simplify add_secure_header_v1()
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
---
tools/kwbimage.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 5f62ed159c4b..857af6a438a4 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1322,16 +1322,14 @@ static int kwb_sign_csk_with_kak(struct
image_tool_params *params,
return 0;
}
-static int add_secure_header_v1(struct image_tool_params *params, uint8_t *ptr,
- int payloadsz, size_t headersz, uint8_t *image,
+static int add_secure_header_v1(struct image_tool_params *params, uint8_t
*image_ptr,
+ size_t image_size, uint8_t *header_ptr, size_t
headersz,
struct secure_hdr_v1 *secure_hdr)
{
struct image_cfg_element *e_jtagdelay;
struct image_cfg_element *e_boxid;
struct image_cfg_element *e_flashid;
RSA *csk = NULL;
- unsigned char *image_ptr;
- size_t image_size;
struct sig_v1 tmp_sig;
bool specialized_img = image_get_spezialized_img();
@@ -1357,14 +1355,11 @@ static int add_secure_header_v1(struct
image_tool_params *params, uint8_t *ptr,
if (kwb_sign_csk_with_kak(params, secure_hdr, csk))
return 1;
- image_ptr = ptr + headersz;
- image_size = payloadsz - headersz;
-
if (kwb_sign_and_verify(csk, image_ptr, image_size,
&secure_hdr->imgsig, "image") < 0)
return 1;
- if (kwb_sign_and_verify(csk, image, headersz, &tmp_sig, "header") < 0)
+ if (kwb_sign_and_verify(csk, header_ptr, headersz, &tmp_sig, "header")
< 0)
return 1;
secure_hdr->hdrsig = tmp_sig;
@@ -1533,8 +1528,8 @@ static void *image_create_v1(size_t *imagesz, struct
image_tool_params *params,
&datai, delay);
}
- if (secure_hdr && add_secure_header_v1(params, ptr, payloadsz +
headersz,
- headersz, image, secure_hdr))
+ if (secure_hdr && add_secure_header_v1(params, ptr + headersz,
payloadsz,
+ image, headersz, secure_hdr))
return NULL;
*imagesz = headersz;
--
2.20.1
[PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD400 to 0xF400
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
---
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 0xF110
#define MBUS_PCI_IO_SIZE ((MBUS_PCI_MAX_PORTS * 64) << 10)
+#ifdef CONFIG_SPL_BUILD
+#define MBUS_SPI_BASE 0xD400
+#define MBUS_SPI_SIZE (64 << 20)
+#else
#define MBUS_SPI_BASE 0xF400
#define MBUS_SPI_SIZE (8 << 20)
+#endif
#define MBUS_DFX_BASE 0xF600
#define MBUS_DFX_SIZE (1 << 20)
#define MBUS_BOOTROM_BASE 0xF800
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 0xD400 - 0xD7FF 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 *)0xD400 + CONFIG_ENV_OFFSET;
-}
-#endif
-
void board_init_f(ulong dummy)
{
int ret;
--
2.20.1
[PATCH RFC u-boot-mvebu 58/59] arm: mvebu: Define SPL memory maps
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
---
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 0x8800
+#define MBUS_PCI_MEM_SIZE ((3 * 128) << 20)
+#else
+#define MBUS_PCI_MEM_BASE 0x8000
+#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 0xF110
#define MBUS_PCI_IO_SIZE ((MBUS_PCI_MAX_PORTS * 64) << 10)
+#endif
#ifdef CONFIG_SPL_BUILD
#define MBUS_SPI_BASE 0xD400
#define MBUS_SPI_SIZE (64 << 20)
@@ -78,10 +88,16 @@ enum cpu_attrib {
#define MBUS_SPI_BASE 0xF400
#define MBUS_SPI_SIZE (8 << 20)
#endif
+#ifndef CONFIG_SPL_BUILD
#define MBUS_DFX_BASE 0xF600
#define MBUS_DFX_SIZE (1 << 20)
+#endif
#define MBUS_BOOTROM_BASE 0xF800
+#ifdef CONFIG_SPL_BUILD
+#define MBUS_BOOTROM_SIZE (128 << 20)
+#else
#define MBUS_BOOTROM_SIZE (8 << 20)
+#endif
struct mbus_win {
u32 base;
--
2.20.1
[PATCH RFC u-boot-mvebu 14/59] tools: kwboot: Add image type documentation
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 --- tools/kwboot.c | 62 ++ 1 file changed, 62 insertions(+) diff --git a/tools/kwboot.c b/tools/kwboot.c index aae7393aeef6..7a7dd5bf3d7b 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -54,6 +54,68 @@ * https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/hdrparser.c * - "Marvell doimage Tool", Marvell U-Boot 2013.01, version 18.06. August 30, 2015. * https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2013.01-armada-18.06/tools/marvell/doimage_mv/doimage.c + * + * Storage location / offset of different image types: + * - IBR_HDR_SPI_ID (0x5A): + * SPI image can be stored at any 2 MB aligned offset in the first 16 MB of + * SPI-NOR or parallel-NOR. Despite the type name it really can be stored on + * parallel-NOR and cannot be stored on other SPI devices, like SPI-NAND. + * So it should have been named NOR image, not SPI image. This image type + * supports XIP - Execute In Place directly from NOR memory. + * + * - IBR_HDR_NAND_ID (0x8B): + * NAND image can be stored either at any 2 MB aligned offset in the first + * 16 MB of SPI-NAND or at any blocksize aligned offset in the first 64 MB + * of parallel-NAND. + * + * - IBR_HDR_PEX_ID (0x9C): + * PEX image is used for booting from PCI Express device. Source address + * stored in image is ignored by BootROM. It is not the BootROM who parses + * or loads data part of the PEX image. BootROM just configures SoC to the + * PCIe endpoint mode and let the PCIe device on the other end of the PCIe + * link (which must be in Root Complex mode) to load kwbimage into SoC's + * memory and tell BootROM physical address. + * + * - IBR_HDR_UART_ID (0x69): + * UART image can be transfered via xmodem protocol over first UART. + * + * - IBR_HDR_I2C_ID (0x4D): + * It is unknown for what kind of storage is used this image. It is not + * specified in any document from References section. + * + * - IBR_HDR_SATA_ID (0x78): + * SATA image can be stored at sector 1 (after the MBR table), sector 34 + * (after the GPT table) or at any next sector which is aligned to 2 MB and + * is in the first 16 MB of SATA disk. Note that source address in SATA image + * is stored in sector unit and not in bytes like for any other images. + * Unfortunately sector size is disk specific, in most cases it is 512 bytes + * but there are also Native 4K SATA disks which have 4096 bytes long sectors. + * + * - IBR_HDR_SDIO_ID (0xAE): + * SDIO image can be stored on different medias: + * - SD(SC) card + * - SDHC/SDXC card + * - eMMC HW boot partition + * - eMMC user data partition / MMC card + * It cannot be stored on SDIO card despite the image name. + * + * For SD(SC)/SDHC/SDXC cards, image can be stored at the same locations as + * the SATA image (sector 1, sector 34 or any 2 MB aligned sector) but within + * the first 64 MB. SDHC and SDXC cards have fixed 512 bytes long sector size. + * Old SD(SC) cards unfortunately can have also different sector sizes, mostly + * 1024 bytes long sector sizes and also can be changed at runtime. + * + * For MMC-compatible devices, image can be stored at offset 0 or at offset + * 2 MB. If MMC device supports HW boot partitions then image must be stored + * on the HW partition as is configured in the EXT_CSC register (it can be + * either boot or user data). + * + * Note that source address for SDIO image is stored in byte unit, like for + * any other images (except SATA). Marvell Functional Specifications for + * A38x and A39x SoCs say that source address is in sector units, but this + * is purely incorrect information. A385 BootROM really expects source address + * for SDIO images in bytes and also Marvell tools generate SDIO image with + * source address in byte units. */ #include "kwbimage.h" -- 2.20.1
[PATCH RFC u-boot-mvebu 17/59] tools: kwboot: Add check that kwbimage contains DDR init code
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
---
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) < 0x4000 ||
+le32_to_cpu(hdr->destaddr) + le32_to_cpu(hdr->blocksize) >
0x40034000)) {
+ fprintf(stderr, "Image does not contain DDR init code needed
for UART booting\n");
+ goto err;
+ }
+
is_secure = kwboot_img_is_secure(img);
if (hdr->blockid != IBR_HDR_UART_ID) {
--
2.20.1
[PATCH RFC u-boot-mvebu 34/59] tools: kwbimage: Fix dumping NAND_BLKSZ
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
---
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 0x1\n"); /* large page NAND
flash = 64 kB block size */
+ else
+ fprintf(f, "NAND_BLKSZ 0x4000\n"); /* small page NAND
flash = 16 kB block size */
+ }
if (mhdr->blockid == IBR_HDR_NAND_ID && (version != 0 || is_v0_ext))
fprintf(f, "NAND_BADBLK_LOCATION 0x%x\n",
(unsigned)mhdr->nandbadblklocation);
--
2.20.1
[PATCH RFC u-boot-mvebu 19/59] tools: kwboot: Show image type and error parsing reasons
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
---
tools/kwboot.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index cb31d5b858ce..7c666486f31f 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1976,6 +1976,21 @@ _inject_baudrate_change_code(void *img, size_t *size,
int for_data,
}
}
+static const char *
+kwboot_img_type(uint8_t blockid)
+{
+ switch (blockid) {
+ case IBR_HDR_I2C_ID: return "I2C";
+ case IBR_HDR_SPI_ID: return "SPI";
+ case IBR_HDR_NAND_ID: return "NAND";
+ case IBR_HDR_SATA_ID: return "SATA";
+ case IBR_HDR_PEX_ID: return "PEX";
+ case IBR_HDR_UART_ID: return "UART";
+ case IBR_HDR_SDIO_ID: return "SDIO";
+ default: return "unknown";
+ }
+}
+
static int
kwboot_img_patch(void *img, size_t *size, int baudrate)
{
@@ -1989,8 +2004,10 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
hdr = img;
- if (*size < sizeof(struct main_hdr_v1))
+ if (*size < sizeof(struct main_hdr_v1)) {
+ fprintf(stderr, "Invalid image header size\n");
goto err;
+ }
image_ver = kwbimage_version(img);
if (image_ver != 0 && image_ver != 1) {
@@ -2000,12 +2017,18 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
hdrsz = kwbheader_size(hdr);
- if (*size < hdrsz)
+ if (*size < hdrsz) {
+ fprintf(stderr, "Invalid image header size\n");
goto err;
+ }
+
+ kwboot_printv("Detected kwbimage v%d with %s boot signature\n",
image_ver, kwboot_img_type(hdr->blockid));
csum = kwboot_hdr_csum8(hdr) - hdr->checksum;
- if (csum != hdr->checksum)
+ if (csum != hdr->checksum) {
+ fprintf(stderr, "Image has invalid header checksum stored in
image header\n");
goto err;
+ }
srcaddr = le32_to_cpu(hdr->srcaddr);
@@ -2028,9 +2051,15 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
break;
}
- if (hdrsz > le32_to_cpu(hdr->srcaddr) ||
- *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
+ if (hdrsz > le32_to_cpu(hdr->srcaddr)) {
+ fprintf(stderr, "Image has invalid data offset stored in image
header\n");
+ goto err;
+ }
+
+ if (*size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize)) {
+ fprintf(stderr, "Image has invalid data size stored in image
header\n");
goto err;
+ }
for_each_opt_hdr_v1 (ohdr, hdr) {
if (!opt_hdr_v1_valid_size(ohdr, (const uint8_t *)hdr + hdrsz))
{
--
2.20.1
[PATCH RFC u-boot-mvebu 23/59] cmd: mvebu/bubt: Rename variable image_size to hdr_size
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
---
cmd/mvebu/bubt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index df6b73c6a172..72ed87b89ec3 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -905,12 +905,12 @@ static int check_image_header(void)
u32 offset, size;
const struct a38x_main_hdr_v1 *hdr =
(struct a38x_main_hdr_v1 *)get_load_addr();
- const size_t image_size = a38x_header_size(hdr);
+ const size_t hdr_size = a38x_header_size(hdr);
- if (!image_size)
+ if (!hdr_size)
return -ENOEXEC;
- checksum = image_checksum8(hdr, image_size);
+ checksum = image_checksum8(hdr, hdr_size);
checksum -= hdr->checksum;
if (checksum != hdr->checksum) {
printf("Error: Bad A38x image header checksum. 0x%x != 0x%x\n",
@@ -944,7 +944,7 @@ static int check_image_header(void)
#if defined(CONFIG_ARMADA_38X)
static int a38x_image_is_secure(const struct a38x_main_hdr_v1 *hdr)
{
- u32 image_size = a38x_header_size(hdr);
+ const size_t hdr_size = a38x_header_size(hdr);
struct a38x_opt_hdr_v1 *ohdr;
u32 ohdr_size;
@@ -965,7 +965,7 @@ static int a38x_image_is_secure(const struct
a38x_main_hdr_v1 *hdr)
break;
ohdr = (struct a38x_opt_hdr_v1 *)((u8 *)ohdr + ohdr_size);
- if ((u8 *)ohdr >= (u8 *)hdr + image_size)
+ if ((u8 *)ohdr >= (u8 *)hdr + hdr_size)
break;
} while (1);
--
2.20.1
[PATCH RFC u-boot-mvebu 52/59] arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options
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 --- arch/arm/mach-mvebu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 5abcdc4972ab..ba40c59f4a95 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -313,7 +313,7 @@ choice depends on SPL config MVEBU_SPL_BOOT_DEVICE_SPI - bool "SPI NOR flash" + bool "NOR flash (SPI or parallel)" imply ENV_IS_IN_SPI_FLASH imply SPL_DM_SPI imply SPL_SPI_FLASH_SUPPORT @@ -327,7 +327,7 @@ config MVEBU_SPL_BOOT_DEVICE_NAND select SPL_BOOTROM_SUPPORT config MVEBU_SPL_BOOT_DEVICE_MMC - bool "SDIO/MMC card" + bool "eMMC or SD card" imply ENV_IS_IN_MMC # GPIO needed for eMMC/SD card presence detection imply SPL_DM_GPIO -- 2.20.1
[PATCH RFC u-boot-mvebu 55/59] arm: mvebu: Remove A39x relicts
Signed-off-by: Pali Rohár
---
.../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_BASE0x20
-#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_
[PATCH RFC u-boot-mvebu 44/59] tools: kwbimage: Fix invalid secure boot header signature
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
---
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 0x. */
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 o
[PATCH RFC u-boot-mvebu 40/59] tools: kwbimage: Print image data offset when printing kwbimage header
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
---
tools/kwbimage.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a5de9855aa56..5f62ed159c4b 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1929,6 +1929,12 @@ static void kwbimage_print_header(const void *ptr)
printf("Data Size:");
genimg_print_size(le32_to_cpu(mhdr->blocksize) - sizeof(uint32_t));
+ printf("Data Offset: ");
+ if (mhdr->blockid == IBR_HDR_SATA_ID)
+ printf("%u Sector%s (LBA)\n", le32_to_cpu(mhdr->srcaddr),
+ le32_to_cpu(mhdr->srcaddr) != 1 ? "s" : "");
+ else
+ genimg_print_size(le32_to_cpu(mhdr->srcaddr));
printf("Load Address: %08x\n", le32_to_cpu(mhdr->destaddr));
printf("Entry Point: %08x\n", le32_to_cpu(mhdr->execaddr));
}
--
2.20.1
[PATCH RFC u-boot-mvebu 31/59] tools: kwbimage: Fix dumping register set / DATA commands
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
---
tools/kwbimage.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 67b45503e466..1719b0415da1 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2148,6 +2148,7 @@ static int kwbimage_generate_config(void *ptr, struct
image_tool_params *params)
struct ext_hdr_v0 *ehdr0;
struct bin_hdr_v0 *bhdr0;
struct opt_hdr_v1 *ohdr;
+ int regset_count;
int params_count;
unsigned offset;
int is_v0_ext;
@@ -2232,18 +2233,20 @@ static int kwbimage_generate_config(void *ptr, struct
image_tool_params *params)
cur_idx++;
} else if (ohdr->headertype == OPT_HDR_V1_REGISTER_TYPE) {
regset_hdr = (struct register_set_hdr_v1 *)ohdr;
- for (i = 0;
-i < opt_hdr_v1_size(ohdr) - sizeof(struct
opt_hdr_v1) -
-sizeof(regset_hdr->data[0].last_entry);
-i++)
+ if (opt_hdr_v1_size(ohdr) > sizeof(*ohdr))
+ regset_count = (opt_hdr_v1_size(ohdr) -
sizeof(*ohdr)) /
+
sizeof(regset_hdr->data[0].entry);
+ else
+ regset_count = 0;
+ for (i = 0; i < regset_count; i++)
fprintf(f, "DATA 0x%08x 0x%08x\n",
le32_to_cpu(regset_hdr->data[i].entry.address),
le32_to_cpu(regset_hdr->data[i].entry.value));
- if (opt_hdr_v1_size(ohdr) - sizeof(struct opt_hdr_v1) >=
- sizeof(regset_hdr->data[0].last_entry)) {
- if (regset_hdr->data[0].last_entry.delay)
+ if (regset_count > 0) {
+ if
(regset_hdr->data[regset_count-1].last_entry.delay !=
+ REGISTER_SET_HDR_OPT_DELAY_SDRAM_SETUP)
fprintf(f, "DATA_DELAY %u\n",
-
(unsigned)regset_hdr->data[0].last_entry.delay);
+
(unsigned)regset_hdr->data[regset_count-1].last_entry.delay);
else
fprintf(f, "DATA_DELAY SDRAM_SETUP\n");
}
--
2.20.1
[PATCH RFC u-boot-mvebu 51/59] arm: mvebu: Add support for generating PEX kwbimage
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 --- arch/arm/mach-mvebu/Kconfig | 4 arch/arm/mach-mvebu/Makefile | 3 +++ 2 files changed, 7 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 5e9480aed291..5abcdc4972ab 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -345,6 +345,10 @@ config MVEBU_SPL_BOOT_DEVICE_SATA imply SPL_LIBDISK_SUPPORT select SPL_BOOTROM_SUPPORT +config MVEBU_SPL_BOOT_DEVICE_PEX + bool "PCI Express" + select SPL_BOOTROM_SUPPORT + config MVEBU_SPL_BOOT_DEVICE_UART bool "UART" select SPL_BOOTROM_SUPPORT diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index 4b7b9ff8b2f2..00014375e7fb 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -59,6 +59,9 @@ endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),) KWB_CFG_BOOT_FROM=sata endif +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_PEX),) + KWB_CFG_BOOT_FROM=pex +endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),) KWB_CFG_BOOT_FROM=uart endif -- 2.20.1
[PATCH RFC u-boot-mvebu 38/59] tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images
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
---
tools/kwbimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 0c3b40d075e9..eb99ac944d24 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2185,7 +2185,7 @@ static int kwbimage_generate_config(void *ptr, struct
image_tool_params *params)
if (mhdr->blockid == IBR_HDR_NAND_ID)
fprintf(f, "NAND_PAGE_SIZE 0x%x\n",
(unsigned)le16_to_cpu(mhdr->nandpagesize));
- if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID) {
+ if (mhdr->blockid == IBR_HDR_NAND_ID && (version != 0 || is_v0_ext ||
mhdr->nandblocksize != 0)) {
if (mhdr->nandblocksize != 0) /* block size explicitly set in
64 kB unit */
fprintf(f, "NAND_BLKSZ 0x%x\n",
(unsigned)mhdr->nandblocksize * 64*1024);
else if (le16_to_cpu(mhdr->nandpagesize) > 512)
--
2.20.1
[PATCH RFC u-boot-mvebu 36/59] tools: kwbimage: Fix endianity when printing kwbimage header
All fields in kwbimage header are in little endian format.
Signed-off-by: Pali Rohár
---
tools/kwbimage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 1128c934dda9..97be3bed79cb 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1928,9 +1928,9 @@ static void kwbimage_print_header(const void *ptr)
}
printf("Data Size:");
- genimg_print_size(mhdr->blocksize - sizeof(uint32_t));
- printf("Load Address: %08x\n", mhdr->destaddr);
- printf("Entry Point: %08x\n", mhdr->execaddr);
+ genimg_print_size(le32_to_cpu(mhdr->blocksize) - sizeof(uint32_t));
+ printf("Load Address: %08x\n", le32_to_cpu(mhdr->destaddr));
+ printf("Entry Point: %08x\n", le32_to_cpu(mhdr->execaddr));
}
static int kwbimage_check_image_types(uint8_t type)
--
2.20.1
[PATCH RFC u-boot-mvebu 16/59] tools: kwboot: Validate optional kwbimage v1 headers
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
---
tools/kwboot.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index da840864b565..c8c7a8d24658 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1939,6 +1939,7 @@ static int
kwboot_img_patch(void *img, size_t *size, int baudrate)
{
struct main_hdr_v1 *hdr;
+ struct opt_hdr_v1 *ohdr;
uint32_t srcaddr;
uint8_t csum;
size_t hdrsz;
@@ -1990,6 +1991,13 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
*size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
goto err;
+ for_each_opt_hdr_v1 (ohdr, hdr) {
+ if (!opt_hdr_v1_valid_size(ohdr, (const uint8_t *)hdr + hdrsz))
{
+ fprintf(stderr, "Invalid optional image header\n");
+ goto err;
+ }
+ }
+
/*
* The 32-bit data checksum is optional for UART image. If it is not
* present (checksum detected as invalid) then grow data part of the
--
2.20.1
[PATCH RFC u-boot-mvebu 48/59] tools: mkimage: Do not try to open datafile when it is skipped
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
---
tools/mkimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index c53768f8d8de..19c139f402c9 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -567,7 +567,7 @@ int main(int argc, char **argv)
exit (retval);
}
- if ((params.type != IH_TYPE_MULTI) && (params.type != IH_TYPE_SCRIPT)) {
+ if (!params.skipcpy && params.type != IH_TYPE_MULTI && params.type !=
IH_TYPE_SCRIPT) {
if (!params.datafile) {
fprintf(stderr, "%s: Option -d with image data file was
not specified\n",
params.cmdname);
--
2.20.1
[PATCH RFC u-boot-mvebu 03/59] arm: mvebu: spl: Fix parsing SDIO kwbimage
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
---
arch/arm/mach-mvebu/spl.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 424599286e5e..b238ba2f5d99 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -196,14 +196,6 @@ int spl_parse_board_header(struct spl_image_info
*spl_image,
spl_image->offset *= 512;
}
- /*
-* For SDIO (eMMC) srcaddr is specified in number of sectors.
-* This expects that sector size is 512 bytes and recalculates
-* data offset to bytes.
-*/
- if (IS_ENABLED(CONFIG_SPL_MMC) && mhdr->blockid == IBR_HDR_SDIO_ID)
- spl_image->offset *= 512;
-
if (spl_image->offset % 4 != 0) {
printf("ERROR: Wrong srcaddr (0x%08x) in kwbimage\n",
spl_image->offset);
--
2.20.1
[PATCH RFC u-boot-mvebu 15/59] tools: kwboot: Fix parsing UART image without data checksum
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
---
tools/kwboot.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7a7dd5bf3d7b..da840864b565 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1990,8 +1990,18 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
*size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize))
goto err;
- if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img))
- goto err;
+ /*
+* The 32-bit data checksum is optional for UART image. If it is not
+* present (checksum detected as invalid) then grow data part of the
+* image for the checksum, so it can be inserted there.
+*/
+ if (kwboot_img_csum32(img) != *kwboot_img_csum32_ptr(img)) {
+ if (hdr->blockid != IBR_HDR_UART_ID) {
+ fprintf(stderr, "Image has invalid data checksum\n");
+ goto err;
+ }
+ kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
+ }
is_secure = kwboot_img_is_secure(img);
@@ -2256,6 +2266,7 @@ main(int argc, char **argv)
KWBOOT_XM_BLKSZ +
sizeof(kwboot_baud_code) +
sizeof(kwboot_baud_code_data_jump) +
+sizeof(uint32_t) +
KWBOOT_XM_BLKSZ;
if (imgpath) {
--
2.20.1
[PATCH RFC u-boot-mvebu 10/59] arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition
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
---
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/spl.c | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 594e9a03d901..5303b1cbb965 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -330,6 +330,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
imply SPL_GPIO
imply SPL_LIBDISK_SUPPORT
imply SPL_MMC
+ select SUPPORT_EMMC_BOOT if SPL_MMC
select SPL_BOOTROM_SUPPORT
config MVEBU_SPL_BOOT_DEVICE_SATA
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index e14c7a9c6cf2..0a809e91349c 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -41,6 +41,12 @@
* kwbimage main header.
*/
#ifdef CONFIG_SPL_MMC
+#ifdef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
+#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG is unsupported
+#endif
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
+#error CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION is unsupported
+#endif
#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
#error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
#endif
@@ -98,7 +104,7 @@ struct kwbimage_main_hdr_v1 {
#ifdef CONFIG_SPL_MMC
u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
{
- return MMCSD_MODE_RAW;
+ return MMCSD_MODE_EMMCBOOT;
}
#endif
--
2.20.1
[PATCH RFC u-boot-mvebu 50/59] arm: mvebu: Add support for generating NAND kwbimage
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 --- arch/arm/mach-mvebu/Kconfig | 13 + arch/arm/mach-mvebu/Makefile| 10 ++ arch/arm/mach-mvebu/kwbimage.cfg.in | 5 + drivers/mtd/nand/raw/Kconfig| 4 +++- 4 files changed, 31 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index 2863babefbe3..5e9480aed291 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -321,6 +321,11 @@ config MVEBU_SPL_BOOT_DEVICE_SPI imply SPL_SPI select SPL_BOOTROM_SUPPORT +config MVEBU_SPL_BOOT_DEVICE_NAND + bool "NAND flash (SPI or parallel)" + select MTD_RAW_NAND + select SPL_BOOTROM_SUPPORT + config MVEBU_SPL_BOOT_DEVICE_MMC bool "SDIO/MMC card" imply ENV_IS_IN_MMC @@ -346,6 +351,14 @@ config MVEBU_SPL_BOOT_DEVICE_UART endchoice +config MVEBU_SPL_NAND_BADBLK_LOCATION + hex "NAND Bad block indicator location" + depends on MVEBU_SPL_BOOT_DEVICE_NAND + range 0x0 0x1 + help + Value 0x0 = SLC flash = BBI at page 0 or page 1 + Value 0x1 = MLC flash = BBI at last page in the block + config MVEBU_EFUSE bool "Enable eFuse support" depends on HAVE_MVEBU_EFUSE diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile index a23511b113bb..4b7b9ff8b2f2 100644 --- a/arch/arm/mach-mvebu/Makefile +++ b/arch/arm/mach-mvebu/Makefile @@ -50,6 +50,9 @@ KWB_REPLACE += BOOT_FROM ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI),) KWB_CFG_BOOT_FROM=spi endif +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),) + KWB_CFG_BOOT_FROM=nand +endif ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),) KWB_CFG_BOOT_FROM=sdio endif @@ -60,6 +63,13 @@ ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),) KWB_CFG_BOOT_FROM=uart endif +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND),) +KWB_REPLACE += NAND_PAGE_SIZE NAND_BLKSZ NAND_BADBLK_LOCATION +KWB_CFG_NAND_PAGE_SIZE = $(CONFIG_SYS_NAND_PAGE_SIZE) +KWB_CFG_NAND_BLKSZ = $(CONFIG_SYS_NAND_BLOCK_SIZE) +KWB_CFG_NAND_BADBLK_LOCATION = $(CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION) +endif + ifneq ($(CONFIG_SECURED_MODE_IMAGE),) KWB_REPLACE += CSK_INDEX KWB_CFG_CSK_INDEX = $(CONFIG_SECURED_MODE_CSK_INDEX) diff --git a/arch/arm/mach-mvebu/kwbimage.cfg.in b/arch/arm/mach-mvebu/kwbimage.cfg.in index ccb09975817e..90cf00c5b984 100644 --- a/arch/arm/mach-mvebu/kwbimage.cfg.in +++ b/arch/arm/mach-mvebu/kwbimage.cfg.in @@ -11,6 +11,11 @@ VERSION 1 # Boot Media configurations #@BOOT_FROM +# NAND configuration +#@NAND_PAGE_SIZE +#@NAND_BLKSZ +#@NAND_BADBLK_LOCATION + # Enable BootROM output via DEBUG flag on SoCs which require it #@DEBUG diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 8aaba8b1a2cf..8aaf135ab45d 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -550,7 +550,8 @@ comment "Generic NAND options" config SYS_NAND_BLOCK_SIZE hex "NAND chip eraseblock size" - depends on ARCH_SUNXI || SPL_NAND_SUPPORT || TPL_NAND_SUPPORT + depends on ARCH_SUNXI || SPL_NAND_SUPPORT || TPL_NAND_SUPPORT || \ + MVEBU_SPL_BOOT_DEVICE_NAND depends on !NAND_MXS && !NAND_DENALI_DT && !NAND_LPC32XX_MLC && \ !NAND_FSL_IFC && !NAND_MT7621 help @@ -576,6 +577,7 @@ config SYS_NAND_PAGE_SIZE hex "NAND chip page size" depends on ARCH_SUNXI || NAND_OMAP_GPMC || NAND_LPC32XX_SLC || \ SPL_NAND_SIMPLE || (NAND_MXC && SPL_NAND_SUPPORT) || \ + MVEBU_SPL_BOOT_DEVICE_NAND || \ (NAND_ATMEL && SPL_NAND_SUPPORT) || SPL_GENERATE_ATMEL_PMECC_HEADER depends on !NAND_MXS && !NAND_DENALI_DT && !NAND_LPC32XX_MLC && !NAND_MT7621 help -- 2.20.1
[PATCH RFC u-boot-mvebu 25/59] cmd: mvebu/bubt: Do not modify image in A8K check_image_header()
Change checksum verification code so it does require to modify image.
Signed-off-by: Pali Rohár
---
cmd/mvebu/bubt.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 820d342ae100..1b08ca9298c2 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -739,18 +739,14 @@ static int check_image_header(void)
return -ENOEXEC;
}
- /* The checksum value is discarded from checksum calculation */
- hdr->prolog_checksum = 0;
-
checksum = do_checksum32((u32 *)hdr, header_len);
+ checksum -= hdr->prolog_checksum;
if (checksum != checksum_ref) {
printf("Error: Bad Image checksum. 0x%x != 0x%x\n",
checksum, checksum_ref);
return -ENOEXEC;
}
- /* Restore the checksum before writing */
- hdr->prolog_checksum = checksum_ref;
printf("Image checksum...OK!\n");
return 0;
--
2.20.1
[PATCH RFC u-boot-mvebu 37/59] tools: kwbimage: Reject mkimage -F option
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 --- tools/kwbimage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 97be3bed79cb..0c3b40d075e9 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -2440,7 +2440,7 @@ static int kwbimage_check_params(struct image_tool_params *params) } return (params->dflag && (params->fflag || params->lflag)) || - (params->fflag && (params->dflag || params->lflag)) || + (params->fflag) || (params->lflag && (params->dflag || params->fflag)) || (params->xflag); } -- 2.20.1
[PATCH RFC u-boot-mvebu 42/59] tools: kwbimage: Rename imagesz to dataoff
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
---
tools/kwbimage.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 857af6a438a4..b32f845b7e2d 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -962,7 +962,7 @@ static size_t image_headersz_v0(int *hasext)
return image_headersz_align(headersz, image_get_bootfrom());
}
-static void *image_create_v0(size_t *imagesz, struct image_tool_params *params,
+static void *image_create_v0(size_t *dataoff, struct image_tool_params *params,
int payloadsz)
{
struct image_cfg_element *e;
@@ -1050,7 +1050,7 @@ static void *image_create_v0(size_t *imagesz, struct
image_tool_params *params,
main_hdr->checksum = image_checksum8(image,
sizeof(struct main_hdr_v0));
- *imagesz = headersz;
+ *dataoff = headersz;
return image;
}
@@ -1385,7 +1385,7 @@ static void finish_register_set_header_v1(uint8_t **cur,
uint8_t **next_ext,
*datai = 0;
}
-static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
+static void *image_create_v1(size_t *dataoff, struct image_tool_params *params,
uint8_t *ptr, int payloadsz)
{
struct image_cfg_element *e;
@@ -1532,7 +1532,7 @@ static void *image_create_v1(size_t *imagesz, struct
image_tool_params *params,
image, headersz, secure_hdr))
return NULL;
- *imagesz = headersz;
+ *dataoff = headersz;
/* Fill the real header size without padding into the main header */
headersz = sizeof(*main_hdr);
@@ -1811,7 +1811,7 @@ static void kwbimage_set_header(void *ptr, struct stat
*sbuf, int ifd,
FILE *fcfg;
void *image = NULL;
int version;
- size_t headersz = 0;
+ size_t dataoff = 0;
size_t datasz;
uint32_t checksum;
struct stat s;
@@ -1862,11 +1862,11 @@ static void kwbimage_set_header(void *ptr, struct stat
*sbuf, int ifd,
*/
case -1:
case 0:
- image = image_create_v0(&headersz, params, datasz + 4);
+ image = image_create_v0(&dataoff, params, datasz + 4);
break;
case 1:
- image = image_create_v1(&headersz, params, ptr, datasz + 4);
+ image = image_create_v1(&dataoff, params, ptr, datasz + 4);
break;
default:
@@ -1884,12 +1884,12 @@ static void kwbimage_set_header(void *ptr, struct stat
*sbuf, int ifd,
free(image_cfg);
/* Build and add image data checksum */
- checksum = cpu_to_le32(image_checksum32((uint8_t *)ptr + headersz,
+ checksum = cpu_to_le32(image_checksum32((uint8_t *)ptr + dataoff,
datasz));
- memcpy((uint8_t *)ptr + headersz + datasz, &checksum, sizeof(uint32_t));
+ memcpy((uint8_t *)ptr + dataoff + datasz, &checksum, sizeof(uint32_t));
/* Finally copy the header into the image area */
- memcpy(ptr, image, headersz);
+ memcpy(ptr, image, dataoff);
free(image);
}
--
2.20.1
[PATCH RFC u-boot-mvebu 05/59] tools: kwbimage: Fix generating, verifying and extracting SATA kwbimage
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
---
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 0x. */
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 0x. */
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 0x.
@@ -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 == 0x)
offset = header_size;
--
2.20.1
[PATCH RFC u-boot-mvebu 11/59] spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
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
---
common/spl/Kconfig | 9 +
common/spl/spl_mmc.c | 12 +++-
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index d774c930a80b..fdee0bd06936 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -815,8 +815,17 @@ config SPL_MMC
this option to build the drivers in drivers/mmc as part of an SPL
build.
+config SYS_MMCSD_FS_BOOT
+ bool "MMC FS Boot mode"
+ depends on SPL_MMC
+ default y if !ARCH_MVEBU
+ help
+ Enable MMC FS Boot mode. Partition is selected by option
+ SYS_MMCSD_FS_BOOT_PARTITION.
+
config SYS_MMCSD_FS_BOOT_PARTITION
int "MMC Boot Partition"
+ depends on SYS_MMCSD_FS_BOOT
default 1
help
Partition on the MMC to load U-Boot from when the MMC is being
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index e4135b204875..bd5e6adf1ea6 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -272,7 +272,7 @@ int spl_start_uboot(void)
}
#endif
-#ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT
static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev,
struct mmc *mmc,
@@ -341,14 +341,6 @@ static int spl_mmc_do_fs_boot(struct spl_image_info
*spl_image,
return err;
}
-#else
-static int spl_mmc_do_fs_boot(struct spl_image_info *spl_image,
- struct spl_boot_device *bootdev,
- struct mmc *mmc,
- const char *filename)
-{
- return -ENOSYS;
-}
#endif
u32 __weak spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
@@ -481,6 +473,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
return err;
#endif
/* If RAW mode fails, try FS mode. */
+#ifdef CONFIG_SYS_MMCSD_FS_BOOT
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
@@ -489,6 +482,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
return err;
break;
+#endif
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
default:
puts("spl: mmc: wrong boot mode\n");
--
2.20.1
[PATCH RFC u-boot-mvebu 21/59] cmd: mvebu/bubt: Add support for writing image to SATA disk
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
---
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
#include
#include
+#include
#include
#include
#include
@@ -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_tstart_lba;
+ lbaint_tblk_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 %#
[PATCH RFC u-boot-mvebu 27/59] cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs
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 --- cmd/mvebu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig index 8f30a0c22be3..9f6ad2d1dd16 100644 --- a/cmd/mvebu/Kconfig +++ b/cmd/mvebu/Kconfig @@ -60,6 +60,7 @@ endchoice config MVEBU_UBOOT_DFLT_NAME string "Default image name for bubt command" + default BUILD_TARGET if ARMADA_32BIT && BUILD_TARGET != "" default "flash-image.bin" help This option should contain a default file name to be used with -- 2.20.1
[PATCH RFC u-boot-mvebu 33/59] tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
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
---
tools/kwbimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a6f6f1578c79..4e9ba5ddfae2 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2187,7 +2187,7 @@ static int kwbimage_generate_config(void *ptr, struct
image_tool_params *params)
if (version != 0 && mhdr->blockid == IBR_HDR_NAND_ID)
fprintf(f, "NAND_BLKSZ 0x%x\n", (unsigned)mhdr->nandblocksize);
- if (mhdr->blockid == IBR_HDR_NAND_ID && (mhdr->nandbadblklocation != 0
|| is_v0_ext))
+ if (mhdr->blockid == IBR_HDR_NAND_ID && (version != 0 || is_v0_ext))
fprintf(f, "NAND_BADBLK_LOCATION 0x%x\n",
(unsigned)mhdr->nandbadblklocation);
if (version == 0 && mhdr->blockid == IBR_HDR_SATA_ID)
--
2.20.1
[PATCH RFC u-boot-mvebu 35/59] tools: kwbimage: Fix generating of kwbimage v0 header checksum
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
---
tools/kwbimage.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index b6deb978f611..1128c934dda9 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1009,8 +1009,6 @@ static void *image_create_v0(size_t *imagesz, struct
image_tool_params *params,
e = image_find_option(IMAGE_CFG_NAND_BADBLK_LOCATION);
if (e)
main_hdr->nandbadblklocation = e->nandbadblklocation;
- main_hdr->checksum = image_checksum8(image,
-sizeof(struct main_hdr_v0));
/*
* For SATA srcaddr is specified in number of sectors.
@@ -1049,6 +1047,9 @@ static void *image_create_v0(size_t *imagesz, struct
image_tool_params *params,
sizeof(struct ext_hdr_v0));
}
+ main_hdr->checksum = image_checksum8(image,
+sizeof(struct main_hdr_v0));
+
*imagesz = headersz;
return image;
}
--
2.20.1
[PATCH RFC u-boot-mvebu 46/59] tools: kwbimage: Add support for XIP SPI/NOR images
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
0x 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 0xE800-0xEFFF by BootROM.
Armada SoCs use kwbimage v1 format and have SPI address space mapped to
physical memory at 0xD400-0xD7FF and Device bus address space (used
for parallel NOR) at 0xD800-0xDFFF.
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
---
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 >= 0xE800 && params->addr < 0xEFFF &&
+ params->ep >= 0xE800 && params->ep < 0xEFFF) {
+ /* Load and Execute address is in SPI address space (kwbimage
v0) */
+ startaddr = 0xE800;
+ } else if (version != 0 &&
+ params->addr >= 0xD400 && params->addr < 0xD7FF &&
+ params->ep >= 0xD400 && params->ep < 0xD7FF) {
+ /* Load and Execute address is in SPI address space (kwbimage
v1) */
+ startaddr = 0xD400;
+ } else if (version != 0 &&
+ params->addr >= 0xD800 && params->addr < 0xDFFF &&
+ params->ep >= 0xD800 && params->ep < 0xDFFF) {
+ /* Load and Execute address is in Device bus space (kwbimage
v1) */
+ startaddr = 0xD800;
+ } 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 0x and
+* execaddr relative to the start of XIP memory address space.
+*/
+ main_hdr->destaddr = cpu_to_le32(0x);
+
+ 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(0x);
+ if (params->xflag) {
+ if (!image_fill_xip_header(main_hdr, params)) {
+ free(image);
+ return NULL;
+ }
+ *dataoff = le32_t
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 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-p...@kernel.org > > When I applied the patches set there were some rejections. > > # patch -p1 < > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch > ... FAILED ... > > > I'm on the latest master branch (just did a git pull today). Could > some patches be out of order? > > Thanks, > Tony Well, that is because DENX mail server is broken and it crashed during processing antispam filter on my some of my patches. So some patches are missing in archive and then applying dependent patches failed. So ignore patchwork and email patches. Rather fetch changes from the mentioned github pull request https://github.com/u-boot/u-boot/pull/275 You can do it via git command (it fetch it to the new mvebu branch): git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 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 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-p...@kernel.org > > > > > > When I applied the patches set there were some rejections. > > > > > > # patch -p1 < > > > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch > > > > > ... > > FAILED > > ... > > > > > > > > > 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 > > All the best, > Tony Thanks for testing! Anyway do you have some A38x board which can boot from SD/MMC, SATA or NAND? This is what is needed to test too. I see that Pogo boots from NAND but it does not use SPL.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hello! Thank you for testing.
On Wednesday 22 February 2023 11:59:35 Martin Rowe wrote:
> Pali,
>
> Good news:
>
> A388 Clearfog Base (SD card model):
> - MMC from SD card works
> - UART works
> - SATA with new defconfig works
> - SPI (if you select MVEBU_SPL_BOOT_DEVICE_SPI yourself) works
Could you send a patch which adds appropriate defconfig file for SPI
boot? So this configuration would be tested in U-Boot CI automatically.
> A388 Clearfog Pro (eMMC model):
> - MMC from eMMC works, but still requires the dts to be patched for
> eMMC (included at bottom)
Have you tried booting from eMMC boot partition or eMMC user data
partition? Because all 3 options should work, but I'm not fully sure if
BootROM choose partition from eMMC register or if tries all 3 in some
order. This is something which needs to be checked and verified.
> I tried eMMC both with and without the dts patched, but only the
> patched version boots. I am not easily able to test the other boot
> methods on the Pro, but they're the same as the Base. Let me know if
> you need any extra data/outputs.
Could you try to use SolidRun eMMC patch which SolidRun has for years in
its repository?
https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
Probably same functionality is needed to implement also into
board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
other boards how they use CONFIG_OF_BOARD_FIXUP.
And if ... you can try to put this logic in board_late_init() function.
For inspiration look into Espressobin board which deactivates eMMC at
runtime by checking existence of eMMC:
https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
> Also, the extra/updated comments with these changes are great! Thanks.
There is still missing documentation for kwbimage config file format.
It should be in "kwbimage" section of ./doc/mkimage.1 file but there is
only placeholder... It would be nice if somebody can take it and write
it.
> Tested-by: Martin Rowe
>
> Martin
>
> 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 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 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 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-p...@kernel.org
> > > > >
> > > > > When I applied the patches set there were some rejections.
> > > > >
> > > > > # patch -p1 <
> > > > > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > >
> > > > ...
> > > > FAILED
> > > > ...
> > > > >
> > > > >
> > > > > I'm on the latest master branch
Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition
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
> > ---
> > 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
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Wednesday 22 February 2023 21:20:58 Martin Rowe wrote: > Hi > > > Could you send a patch which adds appropriate defconfig file for SPI > > boot? So this configuration would be tested in U-Boot CI automatically. > > Will do. Does it need to be the same as the other defconfigs > otherwise? I suggest putting the environment in SPI as well if u-boot > is already there (default is MMC). Yes, it makes sense. > > Have you tried booting from eMMC boot partition or eMMC user data > > partition? Because all 3 options should work, but I'm not fully sure if > > BootROM choose partition from eMMC register or if tries all 3 in some > > order. This is something which needs to be checked and verified. > > I only tested from boot0, but will test the others as well. I've only > ever seen it fallback, but I'll check the new changes and see if they > can select the boot device. Ok. When testing, ensure that you erase uboots from other partitions or check that it boots the correct version from the correction partition. > > Could you try to use SolidRun eMMC patch which SolidRun has for years in > > its repository? > > > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99 > > > > Probably same functionality is needed to implement also into > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for > > other boards how they use CONFIG_OF_BOARD_FIXUP. > > > > And if ... you can try to put this logic in board_late_init() function. > > For inspiration look into Espressobin board which deactivates eMMC at > > runtime by checking existence of eMMC: > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c > > This is still on my TODO from earlier discussions. > > > There is still missing documentation for kwbimage config file format. > > It should be in "kwbimage" section of ./doc/mkimage.1 file but there is > > only placeholder... It would be nice if somebody can take it and write > > it. > > I'm not sure if I have the expertise for this, but can take a look as well. > > Martin Ok.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 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 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 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-p...@kernel.org > > > > > > > > > > When I applied the patches set there were some rejections. > > > > > > > > > > # patch -p1 < > > > > > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch > > > > > > > > > ... > > > > FAILED > > > > ... > > > > > > > > > > > > > > > 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 > > > > > > All the best, > > > Tony > > > > Thanks for testing! Anyway do you have some A38x board which can boot > > from SD/MMC, SATA or NAND? This is what is needed to test too. I see > > that Pogo boots from NAND but it does not use SPL. > > I have only one A38x board with NAND: the Thecus N2350. I am creating > a new defconfig and will see if I can boot it from the NAND flash. Ok. And do you have some switch on this board which instruct BootROM to really boot from NAND? > By the way, I'm having this build error that CFG_SYS_NAND_BASE is not > defined. What should it be for A38x? is it the same for Kirkwood? > > All the best, > Tony Is SYS_NAND_BASE really needed? If yet then I think it should be macro MVEBU_NAND_BASE. But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is memory mapping of NAND device via mbus. On Armada devices is not NAND device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu registers. So I'm quite not sure if it would work. So lets try with MVEBU_NAND_BASE.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 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 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 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
> > > > > > > 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-p...@kernel.org
> > > > > > >
> > > > > > > When I applied the patches set there were some rejections.
> > > > > > >
> > > > > > > # patch -p1 <
> > > > > > > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch
> > > > > > >
> > > > > > ...
> > > > > > FAILED
> > > > > > ...
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > >
> > > > > All the best,
> > > > > Tony
> > > >
> > > > Thanks for testing! Anyway do you have some A38x board which can boot
> > > > from SD/MMC, SATA or NAND? This is what is needed to test too. I see
> > > > that Pogo boots from NAND but it does not use SPL.
> > >
> > > I have only one A38x board with NAND: the Thecus N2350. I am creating
> > > a new defconfig and will see if I can boot it from the NAND flash.
> >
> > Ok. And do you have some switch on this board which instruct BootROM to
> > really boot from NAND?
>
> No switch that I can see. So I'm going to erase the u-boot image in
> SPI to let the BootROM try booting from NAND.
BootROM on 32-bit mvebu SoCs always boots from the location configured
by strapping pins. So if you do not have any switch (or possible
soldered zero-ohm resistors) on the board then I doubt that BootROM will
try to boot from NAND.
> >
> > > By the way, I'm having this build error that CFG_SYS_NAND_BASE is not
> > > defined. What should it be for A38x? is it the same for Kirkwood?
> > >
> > > All the best,
> > > Tony
> >
> > Is SYS_NAND_BASE really needed? If yet then I think it should be macro
> > MVEBU_NAND_BASE.
>
> The build error looks like this:
> drivers/mtd/nand/raw/nand.c:15:34: error: ‘CFG_SYS_NAND_BASE’
> undeclared here (not in a function); did you mean
> ‘CFG_SYS_PL310_BASE’?
>15 | #define CFG_SYS_NAND_BASE_LIST { CFG_SYS_NAND_BASE }
>
I see... Maybe you can try to enable SYS_NAND_SELF_INIT.
> >
> > But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is
> > memory mapping of NAND device via mbus. On Armada devices is not NAND
> > device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu
> > registers. So I'm quite not sure if it would work.
> >
> > So lets try with MVEBU_NAND_BASE.
>
> OK.
>
> Thanks,
> Tony
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 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 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 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 > > > > > > > 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 > > > > > > > > > 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-p...@kernel.org > > > > > > > > > > > > > > > > > > When I applied the patches set there were some rejections. > > > > > > > > > > > > > > > > > > # patch -p1 < > > > > > > > > > /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch > > > > > > > > > > > > > > > > > ... > > > > > > > > FAILED > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 >
Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition
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
> > > > ---
> > > >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
>
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Wednesday 22 February 2023 11:59:35 Martin Rowe wrote: > A388 Clearfog Base (SD card model): > - MMC from SD card works > - UART works > - SATA with new defconfig works > - SPI (if you select MVEBU_SPL_BOOT_DEVICE_SPI yourself) works > A388 Clearfog Pro (eMMC model): > - MMC from eMMC works, but still requires the dts to be patched for > eMMC (included at bottom) Could you test also bubt command for upgrading u-boot on all those variants? So to ensure that upgrading u-boot would work correctly.
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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
> BootROM: Bad header at offset 0020
> 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@7 (eth1) using random MAC address - ae:50:98:34:2e:3e
> eth1: ethernet@7
> Warning: ethernet@3 (eth2) using random MAC address - 0a:66:2b:f7:45:09
> , eth2: ethernet@3
> Warning: ethernet@34000 (eth3) using random MAC address - d2:8e:11:7e:64:c0
> , eth3: ethernet@34000
> Hit any key to stop autoboot: 0
> =>
> =
>
> > > > Could you try to use SolidRun eMMC patch which SolidRun has for years in
> > > > its repository?
> > > >
> > > > https://github.com/SolidRun/u-boot/commit/19a96f7c40a8fc1d0a6546ac2418d966e5840a99
> > > >
> > > > Probably same functionality is needed to implement also into
> > > > board_fix_fdt() function enabled by CONFIG_OF_BOARD_FIXUP. Look for
> > > > other boards how they use CONFIG_OF_BOARD_FIXUP.
> > > >
> > > > And if ... you can try to put this logic in board_late_init() function.
> > > > For inspiration look into Espressobin board which deactivates eMMC at
> > > > runtime by checking existence of eMMC:
> > > > https://source.denx.de/u-boot/u-boot/-/blob/master/board/Marvell/mvebu_armada-37xx/board.c
>
> I've not been able to get this to work. I enable CONFIG_OF_BOARD_FIXUP
> in my config and add the following to
> board/solidrun/clearfog/clearfog.c:
> +int board_fix_fdt(void *blob)
> + {
> + int offset;
> + offset = fdt_path_offset(blob, "/soc/internal-regs/sdhci@d8000");
> + if (offset >= 0) {
> + printf("offset");
> + fdt_delprop(blob, offset, "cd-gpios");
> + fdt_setprop_empty(blob, offset, "non-removable");
> + }
> + return 0;
> +}
> Then I boot from MMC and get the following:
> ===
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Friday 24 February 2023 06:27:49 Martin Rowe wrote: > > > boot0 - zeroed > > > boot1 - u-boot (with local version 'boot1') > > > user - u-boot (with local version 'user') > > Can you check if boot_ack argument has some effect on the initial > > choice? Or if completely disabling boot partitions (boot_enable to 0) > > have some effect? > > boot_ack doesn't appear to do anything. I can only set 0 or 1 and > there's no noticeable change to the boot process. Ok. > Setting `mmc partconf 0 0 0 0` with the same setup as described above > results in the same BootROM fallback from BOOT0 to BOOT1, then SPL in > BOOT1 loads u-boot from the user area, which is identical to the `mmc > partconf 0 0 7 0` flow. Ok. > > If really EXT_CSD[179] register is completely ignored we may change SPL > > to always boot from BOOT0 (when eMMC with boot partitions is used) and > > if it fails then fallback to BootROM booting. > > Is there a way of knowing where the SPL was loaded from? I was trying to figure it out but it looks like that bootrom stores this information into variable on the bootrom stack. So I think that this is impossible. > Because it > would make sense to me that if SPL was loaded from BOOT1 to try and > load u-boot from BOOT1 as well, or from BOOT0 if SPL was loaded from > BOOT0, etc. Having u-boot loaded from a different location is not what > I expected and seems like it would cause a lot of confusion, > especially in a failed A/B rollout. Exactly, I want to avoid it. > BootROM seems to completely ignore > the setting, so I agree that SPL should ignore it as well, but > hardcoding BOOT0 (or even setting the partition as a compile-time > option) is probably not a great outcome. It is a solution and nice trick to how to fix it. Reason is that if SPL fails to load U-Boot from selected partition then it fallbacks to the BootROM, which loads U-Boot from the correct location. So if we hardcode partition to BOOT0 then it obviously works correctly when SPL+U-Boot is on BOOT0. And if it is stored on BOOT1 or USER then BootROM already has to fail load it from BOOT0, which means that on BOOT0 is not valid U-Boot and when SPL tries to load main U-Boot from BOOT0 it fails too, and it returns control to the BootROM which knows that it should load it from BOOT0. And this would work also for DATA. > Two observations that might help here: > 1. After reset, running `mmc partconf 0` always shows PARTITION_ACCESS > is set to 0x0, even it it was set to something else prior to reset Ok, so access permissions are reset. I do not know if this is in MMC standard or not. > 2. With the same setup as described above and `mmc partconf 0 0 1 1` > the SPL eventually times out trying to load from the zeroed BOOT0 and > returns to BootROM, which results in u-boot being loaded from BOOT1: Access permissions can disable access to particular partition. So it makes sense that it timeouts. And BootROM can always load and run main u-boot from the correct location. We are using SPL for loading main u-boot because this is way how it was first implemented and return to bootrom was broken in the past. Anyway, if you completely disable MMC support in SPL then SPL just returns control to BootROM which loads main U-Boot. Reading main u-boot via BootROM is slower as from SPL for SPI-NOR booting because SPL can use faster SPI transfers than BootROM. So this is the reason why we want in SPL to use native load method and not just BootROM. But maybe for MMC it would make sense? > = > BootROM - 1.73 > > Booting from MMC > BootROM: Bad header at offset > BootROM: Bad header at offset 0020 > 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 0x05c4)... > 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 Enviro
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 > --- > 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 00..31b1e9fce8 > --- /dev/null > +++ b/configs/clearfog_spi_defconfig When generating this patch, use git options -M, -C and --find-copies-harder. It will detect that you created this file as copy from other file and generate better diff.
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
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
> ---
> .../{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=0x0080
> +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=0xff
> CONFIG_TARGET_CLEARFOG=y
> -CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y
> +CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog"
> CONFIG_SPL_TEXT_BASE=0x4030
> +CONFIG_SPL_MMC=y
> CONFIG_SPL_SERIAL=y
> CONFIG_SPL_STACK=0x4002c000
> CONFIG_SPL=y
> CONFIG_DEBUG_UART_BASE=0xf1012000
> CONFIG_DEBUG_UART_CLOCK=25000
> +CONFIG_SPL_LIBDISK_SUPPORT=y
> +# CONFIG_SPL_SPI is not set
Any reason to disable it?
> CONFIG_SYS_LOAD_ADDR=0x80
> CONFIG_DEBUG_UART=y
> CONFIG_AHCI=y
> @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SPL_I2C_EEPROM=y
> CONFIG_MMC_BROKEN_CD=y
> +CONFIG_SPL_DM_MMC=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_SDMA=y
> --
> 2.39.2
>
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 11:47:07 Martin Rowe wrote: > > While I haven't tested this patchset - I have tested SPI booting with > > v2022.01 after applying lots of patches. > > I found that the magic value reported by bootrom when booting from SPI will > > be 0x34 on clearfog. > > The current sources only handle 0x32, hence having or not having SPL_SPI > > will always lead to returning to the bootrom. > > > > Please consider pulling in this patch: > > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > > I can send it separately if you like. > > Tested with the patch on a Clearfog Base: > == Without SPL_SPI same return to BootROM > ... > mv_ddr: completed successfully > Trying to boot from BOOTROM > Returning to BootROM (return address 0x05c4)... > BootROM: Image checksum verification PASSED > > > U-Boot 2023.04-rc2... > == With SPL_SPI loads directly from SPI > ... > mv_ddr: completed successfully > Trying to boot from SPI > > > U-Boot 2023.04-rc2... > == > > I'm not sure how to run proper timing tests on the process, but > stopwatch timing just between seeing "Trying to boot" and "U-Boot > 2023.04-rc2" showed the return to BootROM under 1 second, and the > direct from SPI around 4 seconds. I thought the goal of loading from > SPI directly was speed, but returning to BootROM is significantly > faster on this board. You should check SPI speed in DTS file and also in the defconfig. > > which I have tested by adding these config options: > > I tested the new spi_defconfig with and without SPL_SPI; no other changes
Re: [PATCH] CI: Update test/nokia_rx51_test.sh to use prebuilt images
On Saturday 25 February 2023 13:23:33 Tom Rini wrote: > On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote: > > > From: Pali Rohár > > > > Now that the Dockerfile creates images which have the binaries we > > require included, have CI make symlinks for them and update the existing > > script to support this. > > > > Signed-off-by: Tom Rini > > Signed-off-by: Pali Rohár > > Reviewed-by: Simon Glass > > Applied to u-boot/next, thanks! > > -- > Tom Maybe you wanted this in master to make CI reliable also for master branch?
Re: [PATCH RFC u-boot-mvebu 57/59] arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot
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 wrote:
> >
> > Proper U-Boot moves SPI0 CS0 Flash mapping from 0xD400 to 0xF400
> > 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
> > ---
> > 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 0xF110
> > #define MBUS_PCI_IO_SIZE ((MBUS_PCI_MAX_PORTS * 64) << 10)
> > +#ifdef CONFIG_SPL_BUILD
> > +#define MBUS_SPI_BASE 0xD400
> > +#define MBUS_SPI_SIZE (64 << 20)
> > +#else
> > #define MBUS_SPI_BASE 0xF400
> > #define MBUS_SPI_SIZE (8 << 20)
> > +#endif
> > #define MBUS_DFX_BASE 0xF600
> > #define MBUS_DFX_SIZE (1 << 20)
> > #define MBUS_BOOTROM_BASE 0xF800
> > 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 0xD400 - 0xD7FF 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 *)0xD400 + CONFIG_ENV_OFFSET;
> > -}
> > -#endif
> > -
> > void board_init_f(ulong dummy)
> > {
> > int ret;
> > --
> > 2.20.1
> >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Saturday 25 February 2023 01:18:26 Martin Rowe wrote: > > When generating this patch, use git options -M, -C and > > --find-copies-harder. It will detect that you created this file as copy > > from other file and generate better diff. > > Will do. > > This thread has gotten quite long! I've: > - tested all the boot modes and bubt update types > - created the SPI defconfig, > - fixed the eMMC detection by enabling MMC_BROKEN_CD Thanks! > - taken a look at the kwbimage documentation, but I don't think I can > be of much help there > I'm also able to help test any new changes for the MMC boot flow. Is > there anything else that I've missed that I can help with while I've > got it all setup? > > Martin I think that the remaining part is to patch linux DTB file at runtime for emmc support. So if u-boot mmc device is of eMMC type then fixup linux dtb file and others do nothing.
Re: [PATCH] CI: Update test/nokia_rx51_test.sh to use prebuilt images
On Saturday 25 February 2023 13:48:25 Tom Rini wrote: > On Sat, Feb 25, 2023 at 07:35:28PM +0100, Pali Rohár wrote: > > On Saturday 25 February 2023 13:23:33 Tom Rini wrote: > > > On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote: > > > > > > > From: Pali Rohár > > > > > > > > Now that the Dockerfile creates images which have the binaries we > > > > require included, have CI make symlinks for them and update the existing > > > > script to support this. > > > > > > > > Signed-off-by: Tom Rini > > > > Signed-off-by: Pali Rohár > > > > Reviewed-by: Simon Glass > > > > > > Applied to u-boot/next, thanks! > > > > > > -- > > > Tom > > > > Maybe you wanted this in master to make CI reliable also for master branch? > > I'm trying to follow my own "just fixes, really" rule. I don't know > _why_ Azure fails out randomly, but I don't think bumping the containers > for just this, right now, is a fix, exactly. > > -- > Tom Ok!
Re: [PATCH] arm: mvebu: Enable NAND flash for Thecus N2350 board
On Friday 24 February 2023 19:23:23 Tony Dinh wrote: > Enable 512MB PXA3XX NAND flash when u-boot is running. > > Signed-off-by: Tony Dinh Acked-by: Pali Rohár > --- > > configs/n2350_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configs/n2350_defconfig b/configs/n2350_defconfig > index b85ef0dfeb..247533ebb8 100644 > --- a/configs/n2350_defconfig > +++ b/configs/n2350_defconfig > @@ -69,6 +69,9 @@ CONFIG_SYS_64BIT_LBA=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_MVTWSI=y > CONFIG_MTD=y > +CONFIG_MTD_RAW_NAND=y > +CONFIG_NAND_PXA3XX=y > +CONFIG_SYS_NAND_ONFI_DETECTION=y > CONFIG_SF_DEFAULT_SPEED=5000 > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_SPI_FLASH_STMICRO=y > -- > 2.30.2 >
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
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 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 > --- > 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=0x0080 > 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=0xff > CONFIG_TARGET_CLEARFOG=y > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > CONFIG_SPL_TEXT_BASE=0x4030 > CONFIG_SPL_SERIAL=y > +CONFIG_SPL_STACK=0x4002c000 > CONFIG_SPL=y > CONFIG_DEBUG_UART_BASE=0xf1012000 > CONFIG_DEBUG_UART_CLOCK=25000 > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > 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=0xff > CONFIG_BOOTDELAY=3 > CONFIG_USE_PREBOOT=y > CONFIG_SYS_CONSOLE_INFO_QUIET=y > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > -CONFIG_SPL_STACK=0x4002c000 > CONFIG_SPL_I2C=y > CONFIG_SYS_MAXARGS=32 > CONFIG_CMD_TLV_EEPROM=y > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > CONFIG_CMD_TFTPPUT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > -CONFIG_CMD_MVEBU_BUBT=y > CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_MIN_ENTRIES=128 > CONFIG_ARP_TIMEOUT=200 > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y > CONFIG_SYS_I2C_MVTWSI=y > CONFIG_I2C_EEPROM=y > CONFIG_SPL_I2C_EEPROM=y > +CONFIG_MMC_BROKEN_CD=y > CONFIG_SUPPORT_EMMC_BOOT=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > -- > 2.39.2 >
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 11:51:28 Josua Mayer wrote: > While I haven't tested this patchset Are you going to test it? > I have tested SPI booting with > v2022.01 after applying lots of patches. > I found that the magic value reported by bootrom when booting from SPI will > be 0x34 on clearfog. > The current sources only handle 0x32, hence having or not having SPL_SPI > will always lead to returning to the bootrom. > > Please consider pulling in this patch: > https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445cda03d > I can send it separately if you like. There are lot of more strapping boot options for SPI and for other peripherals. All are described in the A38x Hardware Specifications document, publicly available and linked from the Linux ARM Marvell documentation. Maybe it would make sense to rework this code to handle all combinations and not just selected one? > which I have tested by adding these config options: > > |CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI=y # CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC is > not set # CONFIG_SPL_MMC is not set CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI=y CONFIG_SPL_SPI_FLASH_TINY=y CONFIG_SPL_SPI_LOAD=y > CONFIG_SYS_SPI_U_BOOT_OFFS=0x0 # CONFIG_ENV_IS_IN_MMC is not set > CONFIG_ENV_IS_IN_SPI_FLASH=y # CONFIG_ENV_SECT_SIZE_AUTO is not set # > CONFIG_USE_ENV_SPI_BUS is not set # CONFIG_USE_ENV_SPI_CS is not set # > CONFIG_USE_ENV_SPI_MAX_HZ is not set # CONFIG_USE_ENV_SPI_MODE is not set # > CONFIG_ENV_SPI_EARLY is not set CONFIG_ENV_ADDR=0x0| > > > > > CONFIG_SYS_LOAD_ADDR=0x80 > > > > CONFIG_DEBUG_UART=y > > > > CONFIG_AHCI=y > > > > @@ -59,6 +63,7 @@ CONFIG_SYS_I2C_MVTWSI=y > > > > CONFIG_I2C_EEPROM=y > > > > CONFIG_SPL_I2C_EEPROM=y > > > > CONFIG_MMC_BROKEN_CD=y > > > > +CONFIG_SPL_DM_MMC=y > > > > CONFIG_SUPPORT_EMMC_BOOT=y > > > > CONFIG_MMC_SDHCI=y > > > > CONFIG_MMC_SDHCI_SDMA=y > > > > -- > > > > 2.39.2 > > > >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
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 > > 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 > > > --- > > 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=0x0080 > > 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=0xff > > CONFIG_TARGET_CLEARFOG=y > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > CONFIG_SPL_TEXT_BASE=0x4030 > > CONFIG_SPL_SERIAL=y > > +CONFIG_SPL_STACK=0x4002c000 > > CONFIG_SPL=y > > CONFIG_DEBUG_UART_BASE=0xf1012000 > > CONFIG_DEBUG_UART_CLOCK=25000 > > @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 > > 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=0xff > > CONFIG_BOOTDELAY=3 > > CONFIG_USE_PREBOOT=y > > CONFIG_SYS_CONSOLE_INFO_QUIET=y > > @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 > > CONFIG_SPL_BSS_MAX_SIZE=0x4000 > > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > > # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set > > -CONFIG_SPL_STACK=0x4002c000 > > CONFIG_SPL_I2C=y > > CONFIG_SYS_MAXARGS=32 > > CONFIG_CMD_TLV_EEPROM=y > > @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y > > CONFIG_CMD_TFTPPUT=y > > CONFIG_CMD_CACHE=y > > CONFIG_CMD_TIME=y > > -CONFIG_CMD_MVEBU_BUBT=y > > CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_MIN_ENTRIES=128 > > CONFIG_ARP_TIMEOUT=200 > > @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y > > CONFIG_SYS_I2C_MVTWSI=y > > CONFIG_I2C_EEPROM=y > > CONFIG_SPL_I2C_EEPROM=y > > +CONFIG_MMC_BROKEN_CD=y > > CONFIG_SUPPORT_EMMC_BOOT=y > > CONFIG_MMC_SDHCI=y > > CONFIG_MMC_SDHCI_SDMA=y > > -- > > 2.39.2 > >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
On Sunday 26 February 2023 01:56:23 Martin Rowe wrote: > On Sat, 25 Feb 2023 at 21:16, Pali Rohár wrote: > > I think that the remaining part is to patch linux DTB file at runtime > > for emmc support. So if u-boot mmc device is of eMMC type then fixup > > linux dtb file and others do nothing. > > One question I didn't think of when suggesting this: does runtime > patching the kernel's dtb break signed/verified booting I do not think so. Signature verification should be done before patching. > The reason I > ask is because we now only need to patch the kernel dtb, not the > u-boot one. If we needed to do both, then it would make sense to > handle them in the same way through u-boot. The barrier to creating a > patched kernel dtb file on its own is very low, so I'm not sure adding > some "magic" to u-boot to make it work is the best solution, > especially if it might break verified boot.
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: > Hi Martin, > > On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe 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=5000 > > > > 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=100 (50x less) is implicitly added to the > > MMC and SATA configs at the moment. > > This is only a workaround to get the SPI probe to work correctly. The > real fix should be in spi_flash_probe() > ./common/spl/spl_spi.c > flash = spi_flash_probe(sf_bus, sf_cs, > CONFIG_SF_DEFAULT_SPEED, > CONFIG_SF_DEFAULT_MODE); > If spi_flash_probe() failed to get SPI max_hz from the DTS, the > fallback is CONFIG_SF_DEFAULT_SPEED. > > IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and > CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or > some other common place. And when we will have fixed the DTS parsing > problem, they can be removed. > > I'd like to hear from Stefan and Pali if this approach sounds good. > > All the best, > Tony Well, the maximal SPI speed depends on the wiring. You can have on the board some SPI device which does not support high frequency. But having some sane defaults in Kconfig for mvebu makes sense.
Re: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection
On Sunday 26 February 2023 01:45:16 Martin Rowe wrote: > On Sat, 25 Feb 2023 at 22:14, Pali Rohár 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 > > > > > > 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 > > > > > > > --- > > > > 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=0x0080 > > > > 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=0xff > > > > CONFIG_TARGET_CLEARFOG=y > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y > > > > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > > > > CONFIG_SPL_TEXT_BASE=0x4030 > > > > CONFIG_SPL_SERIAL=y > > > > +CONFIG_
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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() > > >tool
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
On Monday 27 February 2023 17:17:31 Tony Dinh wrote: > Hi Pali, > > On Mon, Feb 27, 2023 at 4:42 PM Tony Dinh wrote: > > > > Hi Pali, > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > On Mon, Feb 27, 2023 at 1:57 PM Tony Dinh wrote: > > > > > > > > Hi Stefan, > > > > > > > > On Sun, Feb 26, 2023 at 11:40 PM Stefan Roese 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 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 > > > > > >>> 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=5000 > > > > > >>>> > > > > > >>>> 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=100 (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
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 > <mailto:p...@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 S
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 > > > <mailto:p...@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 fail
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 > > > > <mailto:p...@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
Re: [PATCH] README.mpc85xx-sd-spi-boot: Suggest the NXP boot format github repo
On Friday 13 January 2023 09:10:18 Fabio Estevam wrote: > On Fri, Jan 13, 2023 at 4:53 AM Pali Rohár wrote: > > > > you can browse it online at: > > > -https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/boot-format > > > +https://github.com/nxp-qoriq-yocto-sdk/boot-format > > > > This "new" repo contains old broken version of boot-format which is > > missing important commits and fixes. > > Priyanka, can anyone at NXP fix this? Leo Li, could you look at NXP boot-format github repository and import latest version from codeaurora? I see that github repository is missing more commits which are on codeaurora.
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
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 wrote: > > > > > > Hi Pali, > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh 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. > > > > > > > > > > > > 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 0x05c4)... > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > 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 0x05c4)... > > > > 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. > > > > > > > > > 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 0x05c4)... > > > BootROM: Image checksum verification PASSED > > > > > > > > > Is there a chance this value 0x9 means something that we have not come > > > across? > > > > Found the answer in the A38x Hardware Specs. I've never noticed this > > before. This board has the Sample at Reset set to boot from NAND! > > > > "Table 48: Boot Device Mode Options > > 0x9 > > BootROM Enabled, Boot from NAND: 8 bits width, with page size of 512B, > > 4 Address cycles support per page, using MPP multiplexing option of > > NAND 8 bits > > 0x32 > > BootROM Enabled, Boot from SPI: Controller #0, 24 address bits, NOR > > Flash type, using MPP multiplexing option of SPI on MPP[25:22]" > > > > So what we actually see here is the fall back to BootROM. And BootROM > > still loads the image from SPI, ignoring that strapping. Am I confused > > or correct? :) > > > > Thanks, > > Tony > > I already wrote in some thread that in Hardware Specifications are > documented all strapping pins options and u-boot has defined just few of > them in header files. Beware that strapping pins are SoC specific and so > you always need to look at the correct document. > > About parallel-NAND vs SPI-NOR, could you send the whole bootlog on uart > from bootrom to main u-boot and type of the SoC?
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
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 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 wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > On Mon, Feb 27, 2023 at 3:41 PM Tony Dinh 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. > > > > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > > > > > > > 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 0x05c4)... > > > > > > 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. > > > > > > > > > > > > > > > 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 cas
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
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 > > > > > <mailto:p...@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> > > > > > > &
Re: [PATCH v2] board: rockchip: Add rk3588 evb
Hello! I'm not rockchip maintainer, so please do not send me rockchip
patches unless it is something for which I really should take an
attention.
On Thursday 02 March 2023 15:12:57 Kever Yang wrote:
> rk3588 evb1 v10 is a evalution board from Rockchip, it is a dev board for
> rockchip and also a reference board for board vendors.
>
> Hardware:
> SoC: RK3588
> DRAM: LPDDR4X 8GB
> Debug: UART2 via USB
> PCIe: 3x4 *1
> SATA *2
> HDMI out *2
> HDMI IN *1
> USB2.0 Host *2
> USB3.0 Host *1
> Type C *1
> MIPI DSI panel
>
> dts Sync from Linux v6.2.
>
> Signed-off-by: Kever Yang
> ---
>
> Changes in v2:
> - Use the same dts name as kernel
>
> arch/arm/dts/Makefile| 1 +
> arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi | 21
> arch/arm/dts/rk3588-evb1-v10.dts | 129 +++
> arch/arm/mach-rockchip/rk3588/Kconfig| 7 ++
> board/rockchip/evb_rk3588/Kconfig| 15 +++
> board/rockchip/evb_rk3588/MAINTAINERS| 7 ++
> board/rockchip/evb_rk3588/Makefile | 6 ++
> board/rockchip/evb_rk3588/evb-rk3588.c | 39 +++
> configs/evb-rk3588_defconfig | 69
> doc/board/rockchip/rockchip.rst | 10 ++
> include/configs/evb_rk3588.h | 15 +++
> 11 files changed, 319 insertions(+)
> create mode 100644 arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3588-evb1-v10.dts
> create mode 100644 board/rockchip/evb_rk3588/Kconfig
> create mode 100644 board/rockchip/evb_rk3588/MAINTAINERS
> create mode 100644 board/rockchip/evb_rk3588/Makefile
> create mode 100644 board/rockchip/evb_rk3588/evb-rk3588.c
> create mode 100644 configs/evb-rk3588_defconfig
> create mode 100644 include/configs/evb_rk3588.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index c160e884bf6..f854c092893 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -171,6 +171,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
>
> dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> rk3588-edgeble-neu6a-io.dtb \
> + rk3588-evb1-v10.dtb \
> rk3588-rock-5b.dtb
>
> dtb-$(CONFIG_ROCKCHIP_RV1108) += \
> diff --git a/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
> b/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
> new file mode 100644
> index 000..bd2e2594863
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-evb1-v10-u-boot.dtsi
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
> + */
> +
> +#include "rk3588-u-boot.dtsi"
> +
> +/ {
> + aliases {
> + mmc0 = &sdmmc;
> + mmc1 = &sdhci;
> + };
> +
> + chosen {
> + u-boot,spl-boot-order = &sdhci;
> + };
> +};
> +
> +&sdhci {
> + bootph-all;
> +};
> diff --git a/arch/arm/dts/rk3588-evb1-v10.dts
> b/arch/arm/dts/rk3588-evb1-v10.dts
> new file mode 100644
> index 000..b91af0204db
> --- /dev/null
> +++ b/arch/arm/dts/rk3588-evb1-v10.dts
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "rk3588.dtsi"
> +
> +/ {
> + model = "Rockchip RK3588 EVB1 V10 Board";
> + compatible = "rockchip,rk3588-evb1-v10", "rockchip,rk3588";
> +
> + aliases {
> + mmc0 = &sdhci;
> + serial2 = &uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + power-supply = <&vcc12v_dcin>;
> + pwms = <&pwm2 0 25000 0>;
> + };
> +
> + vcc12v_dcin: vcc12v-dcin-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc12v_dcin";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1200>;
> + regulator-max-microvolt = <1200>;
> + };
> +
> + vcc5v0_sys: vcc5v0-sys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + vin-supply = <&vcc12v_dcin>;
> + };
> +};
> +
> +&gmac0 {
> + clock_in_out = "output";
> + phy-handle = <&rgmii_phy>;
> + phy-mode = "rgmii-rxid";
> + pinctrl-0 = <&gmac0_miim
> + &gmac0_tx_bus2
> + &gmac0_rx_bus2
> + &gmac0_rgmii_clk
> + &gmac0_rgmii_bus>;
> + pinctrl-names = "default";
> + rx_delay = <0x00>;
> + tx_delay = <0x43>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + status = "okay";
> +
> + hym8563: rtc@51 {
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #c
Re: [PATCH] doc: Add documentation for CZ.NIC Turris routers
Ping again? Or silence means no care from CZ.NIC side? On Tuesday 31 January 2023 19:53:23 Pali Rohár wrote: > Gentle ping? Does CZ.NIC care about Turris routers and u-boot support? > > On Monday 07 November 2022 21:28:31 Pali Rohár wrote: > > Hello! Just beware of these two commits which renamed files mentioned in > > patch > > https://source.denx.de/u-boot/u-boot/-/commit/87ac4b4b4ca5f00e2ddcdac41c9dc691ab2aecf1 > > https://source.denx.de/u-boot/u-boot/-/commit/d8fa0a76681af3ecea3941f5c743332dd76c7543 > > So documentation in v2 now needs to be updated to address those renamed > > files. > > > > On Tuesday 01 November 2022 23:10:00 Josef Schlehofer wrote: > > > Hey Pali, > > > > > > Thanks for letting me know about it! > > > > > > I will prepare new version tomorrow and send it as v2. > > > > > > Regards, > > > Josef > > > > > > On 01. 11. 22 23:07, Pali Rohár wrote: > > > > + Lukáš and Josef from CZ.NIC > > > > > > > > On Monday 03 October 2022 22:25:05 Pali Rohár wrote: > > > > > + Štěpán from CZ.NIC. Please look at the Heinrich comments below and > > > > > prepare a new version with fixes... I will let it to you right now. > > > > > > > > > > On Monday 26 September 2022 13:30:02 Heinrich Schuchardt wrote: > > > > > > On 9/23/22 13:36, Pali Rohár wrote: > > > > > > > This patch adds a new documentation for all released CZ.NIC > > > > > > > Turris routers. > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > --- > > > > > > >doc/board/CZ.NIC/index.rst | 9 + > > > > > > >doc/board/CZ.NIC/turris.rst | 323 > > > > > > > > > > > > > >doc/board/index.rst | 1 + > > > > > > >3 files changed, 333 insertions(+) > > > > > > >create mode 100644 doc/board/CZ.NIC/index.rst > > > > > > >create mode 100644 doc/board/CZ.NIC/turris.rst > > > > > > > > > > > > > > diff --git a/doc/board/CZ.NIC/index.rst > > > > > > > b/doc/board/CZ.NIC/index.rst > > > > > > > new file mode 100644 > > > > > > > index ..19ec6af2f389 > > > > > > > --- /dev/null > > > > > > > +++ b/doc/board/CZ.NIC/index.rst > > > > > > > @@ -0,0 +1,9 @@ > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > + > > > > > > > +CZ.NIC > > > > > > > +== > > > > > > > + > > > > > > > +.. toctree:: > > > > > > > + :maxdepth: 2 > > > > > > > + > > > > > > > + turris > > > > > > > diff --git a/doc/board/CZ.NIC/turris.rst > > > > > > > b/doc/board/CZ.NIC/turris.rst > > > > > > > new file mode 100644 > > > > > > > index ..b82dea4e0786 > > > > > > > --- /dev/null > > > > > > > +++ b/doc/board/CZ.NIC/turris.rst > > > > > > > @@ -0,0 +1,323 @@ > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > + > > > > > > > +CZ.NIC Turris routers > > > > > > > += > > > > > > > + > > > > > > > +CZ.NIC develops open source Turris routers: Turris 1.0, Turris > > > > > > > 1.1, Turris Omnia, and Turris Mox. This document describes a > > > > > > > U-Boot deployment (compilation, flashing, resetting) on these > > > > > > > routers. > > > > > > > + > > > > > > > +Turris 1.x > > > > > > > +-- > > > > > > > + > > > > > > > +Turris 1.0 and Turris 1.1 boards contain Freescale P2020 CPUs > > > > > > > with two PowerPC e500v2 cores which BootROM (or CPU directly) can > > > > > > > load and boot U-Boot bootloader from various locations. For > > > > > > > Turris 1.x boards, only Flash NOR and SD cards are supported. > > > > > > > P2020 CPU cannot download bootloader via UART like other > > > > > >
[PATCH RFC u-boot-mvebu 1/2] tools: kwboot: Fix MMC HW boot partitions info
Boot configuration stored in EXT_CSC register is completely ignored by BootROM.
Fixes: fa03279e198d ("tools: kwboot: Add image type documentation")
Signed-off-by: Pali Rohár
---
tools/kwboot.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7c666486f31f..1844d7291fe0 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -106,9 +106,9 @@
* 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).
+ * 2 MB. If MMC device supports HW boot partitions then image is read from
+ * partitions in following order: Boot 0, Boot 1, User Data partition.
+ * Boot configuration stored in EXT_CSC register is completely ignored.
*
* Note that source address for SDIO image is stored in byte unit, like for
* any other images (except SATA). Marvell Functional Specifications for
--
2.20.1
