[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Pali Rohár
pali at kernel.org
Sun Mar 19 19:20:14 CET 2023
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
> On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
> > On Sun, 5 Mar 2023 at 11:55, Pali Rohár <pali at kernel.org> wrote:
> >
> > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
> > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali at kernel.org> wrote:
> > > >
> > > > > Improve code for checking strapping pins which specifies boot mode
> > > source.
> > > > >
> > > > > Martin, could you test if Clearfog can be still configured into UART
> > > > > booting mode via HW switches and if it still works correctly? First
> > > > > patch is reverting UART related commit for Clearfog which I think it
> > > not
> > > > > needed anymore.
> > > > >
> > > >
> > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch
> > > that
> > > > you refactored in cpu.c/get_boot_device is all that gets processed. It
> > > > decides there is an error and returns BOOT_DEVICE_UART, probably because
> > > of
> > > > the invalid boot workaround for broken UART selection that you
> > > identified.
> > >
> > > Ok, so I figured out correctly how this invalid mode works.
> > >
> > > > UART only works if I use the clearfog_spi_defconfig or if I select
> > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or
> > > SATA
> > > > defconfigs. I get the same result without this patch series applied,
> > > though.
> > > >
> > > > The failed cases have the same output (other than kwboot header patching
> > > > output) until after sending boot image data is complete. The output stops
> > > > after:
> > > > ================================
> > > > 98 % [.................................................................
> > > > ]
> > > > Done
> > > > Finishing transfer
> > > > [Type Ctrl-\ + c to quit]
> > > > ================================
> > >
> > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just
> > > instruct mkimage what to put into kwbimage header.
> > >
> > > If I'm looking at the output correctly then SPL was booted, it correctly
> > > trained DDR RAM, returned back to bootrom, kwboot continued sending main
> > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot
> > > is complete. But then there is no output from main u-boot.
> > >
> > > > It looks like an unrelated issue with kwboot.c, which I was sure was
> > > > working after the last patches but I can no longer reproduce a successful
> > > > boot.
> > >
> > > Can you check that you are using _both_ mkimage and kwboot from version
> > > with applying _all_ my patches recently sent to ML? Because both mkimage
> > > and kwboot have fixes for SATA and SDIO images.
> > >
> >
> > I tested using the latest next branch which has those changes in it. Steps:
> > - Set UART boot mode on device
> > - make clean
> > - make clearfog_defconfig
> > - make
> > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
> >
> > For me it looks like that either mkimage generated incorrect image size
> > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size
> > > from kwbimage header and sent smaller image.
> > >
> >
> > <MMC output>
> > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
> > kwboot version 2023.04-rc4-00339-gcefd0449d6
> > Detected kwbimage v1 with SDIO boot signature
> > Patching image boot signature to UART
> > Aligning image header to Xmodem block size
> > Sending boot message. Please reboot the target...\
> > Sending boot image header (113408 bytes)...
> > 0 %
> > [......................................................................]
> > <snip>
> > 94 % [..............................................
> > ]
> > Done
> >
> > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31 +1000)
> > High speed PHY - Version: 2.0
> > EEPROM TLV detection failed: Using static config for Clearfog Pro.
> > Detected Device ID 6828
> > board SerDes lanes topology details:
> > | Lane # | Speed | Type |
> > --------------------------------
> > | 0 | 3 | SATA0 |
> > | 1 | 0 | SGMII1 |
> > | 2 | 5 | PCIe1 |
> > | 3 | 5 | USB3 HOST1 |
> > | 4 | 5 | PCIe2 |
> > | 5 | 0 | SGMII2 |
> > --------------------------------
> > High speed PHY - Ended Successfully
> > mv_ddr: 14.0.0
> > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > mv_ddr: completed successfully
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> >
> > Sending boot image data (474564 bytes)...
> > 0 %
> > [......................................................................]
> > <snip>
> > 98 % [....................................................................
> > ]
> > Done
> > Finishing transfer
> > [Type Ctrl-\ + c to quit]
> > </MMC output>
> >
> > <MMC sizes>
> > du -b u-boot*
> > 4996828 u-boot
> > 474304 u-boot.bin
> > 15155 u-boot.cfg
> > 19496 u-boot.dtb
> > 474304 u-boot-dtb.bin
> > 474368 u-boot-dtb.img
> > 474368 u-boot.img
> > 1721 u-boot.lds
> > 1069982 u-boot.map
> > 454808 u-boot-nodtb.bin
> > 1307712 u-boot.srec
> > 198841 u-boot.sym
> > 588288 u-boot-with-spl.kwb
> > </MMC sizes>
> >
> > If I make menuconfig and set the boot mode to UART before making I get:
> >
> > <UART output>
> > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
> > kwboot version 2023.04-rc4-00339-gcefd0449d6
> > Detected kwbimage v1 with UART boot signature
> > Aligning image header to Xmodem block size
> > Sending boot message. Please reboot the target...\
> > Sending boot image header (113408 bytes)...
> > 0 %
> > [......................................................................]
> > <snip>
> > 94 % [..............................................
> > ]
> > Done
> >
> > U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000)
> > High speed PHY - Version: 2.0
> > EEPROM TLV detection failed: Using static config for Clearfog Pro.
> > Detected Device ID 6828
> > board SerDes lanes topology details:
> > | Lane # | Speed | Type |
> > --------------------------------
> > | 0 | 3 | SATA0 |
> > | 1 | 0 | SGMII1 |
> > | 2 | 5 | PCIe1 |
> > | 3 | 5 | USB3 HOST1 |
> > | 4 | 5 | PCIe2 |
> > | 5 | 0 | SGMII2 |
> > --------------------------------
> > High speed PHY - Ended Successfully
> > mv_ddr: 14.0.0
> > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > mv_ddr: completed successfully
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0xffff05c4)...
> >
> > Sending boot image data (474404 bytes)...
> > 0 %
> > [......................................................................]
> > <snip>
> > 98 % [...................................................................
> > ]
> > Done
> > Finishing transfer
> > [Type Ctrl-\ + c to quit]
> >
> >
> > U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000)
> > </UART output>
> >
> > <UART sizes>
> > du -b u-boot*
> > 4997204 u-boot
> > 474400 u-boot.bin
> > 15103 u-boot.cfg
> > 19496 u-boot.dtb
> > 474400 u-boot-dtb.bin
> > 474464 u-boot-dtb.img
> > 474464 u-boot.img
> > 1721 u-boot.lds
> > 1070068 u-boot.map
> > 454904 u-boot-nodtb.bin
> > 1307988 u-boot.srec
> > 198886 u-boot.sym
> > 587904 u-boot-with-spl.kwb
> > </UART sizes>
> >
> > The difference is very small somewhere if that is the cause. Let me know if
> > there's other data I can get to help with this one.
>
> Difference should be only in the kwbimage header plus some aligning. It
> just proves what I wrote before "mkimage generated incorrect image size
> for SDIO image. Or kwboot incorrectly parsed that image size
> from kwbimage header and sent smaller image.".
>
> I will try to find a bug in mkimage or kwboot tool. Or you can try it
> too. As mmc booting is working fine from mmc I have felling that bug is
> in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could you try these changes?
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 309657a5637b..177084adf825 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext)
if (count > 0)
headersz += sizeof(struct register_set_hdr_v1) + 8 * count + 4;
+ /*
+ * For all images except UART, headersz stored in header itself should
+ * contains header size without padding. For UART image BootROM rounds
+ * down headersz to multiply of 128 bytes. Therefore align UART headersz
+ * to multiply of 128 bytes to ensure that remaining UART header bytes
+ * are not ignored by BootROM.
+ */
+ if (image_get_bootfrom() == IBR_HDR_UART_ID)
+ headersz = ALIGN(headersz, 128);
+
return headersz;
}
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1844d7291fe0..b40800c108fc 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
goto err;
}
kwboot_img_grow_data_right(img, size, sizeof(uint32_t));
+ /* Update the 32-bit data checksum */
+ *kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img);
}
if (!kwboot_img_has_ddr_init(img) &&
@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
kwboot_printv("Aligning image header to Xmodem block size\n");
kwboot_img_grow_hdr(img, size, grow);
+
+ /*
+ * kwbimage v1 contains header size field and for UART type it
+ * must be set to the aligned xmodem header size because BootROM
+ * rounds header size down to xmodem block size.
+ */
+ if (kwbimage_version(img) == 1) {
+ hdrsz += grow;
+ hdr->headersz_msb = hdrsz >> 16;
+ hdr->headersz_lsb = cpu_to_le16(hdrsz & 0xffff);
+ }
}
hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
> > >
> > > > > Also could you check if SATA booting is still working correctly?
> > > > >
> > > >
> > > > SATA works correctly.
> > >
> > > Perfect!
> > >
> > > >
> > > > > Tony, should address problems with SPI booting when it is configured to
> > > > > different configuration. In fourth commit I added all possible boot
> > > mode
> > > > > strapping pin configurations which are recognized by A385 bootrom (and
> > > > > not the only one described in the HW spec, which is incomplete).
> > > > >
> > > > > Stefan, do you have some AXP board with SATA boot source? Because I'm
> > > > > adding it for completeness in the last sixth patch.
> > > > >
> > > > > Pali Rohár (6):
> > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant
> > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant
> > > > > arm: mvebu: Convert BOOT_FROM_* constants to function macros
> > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros
> > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros
> > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros
> > > > >
> > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++-------
> > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 ++++++++++++++++----------
> > > > > 2 files changed, 35 insertions(+), 26 deletions(-)
> > > > >
> > > > > --
> > > > > 2.20.1
> > > > >
> > > > >
> > >
More information about the U-Boot
mailing list