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