October 2022 - U-Boot

Status of debug UART on am335x SoC
by Paul Barker 15 Oct '22

15 Oct '22

Hi folks, While looking into SPI boot failures on our am335x based boards I needed to enable the debug UART to understand where u-boot was getting stuck. I first enabled the following config options: * CONFIG_DEBUG_UART=y * CONFIG_DEBUG_UART_BASE=0x44e09000 * CONFIG_DEBUG_UART_CLOCK=48000000 * CONFIG_DEBUG_UART_OMAP=y * CONFIG_DEBUG_UART_SHIFT=2 * CONFIG_DEBUG_UART_ANNOUNCE=y With these options enabled the debug UART did not function, no output was printed at all. This was fixed by reverting commit 0dba45864b2a ("arm: Init the debug UART"), as was discussed in another recent thread [1]. [1]: https://lore.kernel.org/all/CAJs94EYv55QBjvqB94Bwy-wv2_u7tJ+AMP0Ho_XAC8eqjT… Has anyone had chance to look into this further? It would be good to get this fixed so that the debug UART can be used on these boards by simply enabling the correct config options. I'm happy to help look into this if anyone has any pointers on where to start. Thanks, -- Paul Barker Principal Software Engineer SanCloud Ltd e: paul.barker(a)sancloud.com w: https://sancloud.com/

2 1

U-Boot CONFIG_DM_SERIAL migration deadline
by Tom Rini 14 Oct '22

14 Oct '22

Hey all, I'm sending this email out to the main and custodian lists, and bcc'ing all of the listed maintainers for platforms that have a problem here. The migration deadline for switching from CONFIG_SERIAL to CONFIG_DM_SERIAL is the v2023.04 release. Now, per how I've behaved in the past, I'm not going to immediately remove these platforms. But it would be very good to jump on migrating them now, rather than waiting further. The full list (at least in so far as our Makefile check can determine) is: SBx81LIFKW SBx81LIFXCAT pogo_e02 pogo_v4 dns325 iconnect d2net_v2 net2big_v2 inetspace_v2 netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2 dreamplug guruplug openrd_base openrd_client openrd_ultimate sheevaplug ib62x0 dockstar goflexhome nas220 ds109 nsa310s mx23evk mx28evk imx28_xea imx28_xea_sb mx23_olinuxino vexpress_ca9x4 am43xx_evm_qspiboot am43xx_hs_evm_qspi ti816x_evm vinco bcm7260 bcm7445 ls1021aiot_qspi ls1021aiot_sdcard ls1021aqds_nand ls1021aqds_nor_SECURE_BOOT ls1021aqds_qspi ls1021aqds_sdcard_ifc ls1021aqds_sdcard_qspi ls1021atsn_qspi ls1021atsn_sdcard ls1021atwr_nor_SECURE_BOOT ls1021atwr_qspi ls1021atwr_sdcard_ifc ls1021atwr_sdcard_ifc_SECURE_BOOT ls1021atwr_sdcard_qspi mx51evk mx53loco usbarmory m53menlo udoo wandboard mx6qsabrelite nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s nitrogen6s1g imx6dl_mamoj dh_imx6 marsboard riotboard imx6dl_icore_nand imx6q_icore_nand imx6qdl_icore_mipi imx6qdl_icore_mmc imx6qdl_icore_nand imx6qdl_icore_rqs imx6ul_geam_mmc imx6ul_geam_nand imx6ul_isiot_emmc imx6ul_isiot_nand mx6memcal mx6sabreauto mx6sabresd mx6slevk mx6slevk_spinor mx6slevk_spl mx6sllevk mx6sllevk_plugin mx6sxsabreauto mx6sxsabresd mx6ul_14x14_evk mx6ul_9x9_evk mx6ull_14x14_evk mx6ull_14x14_evk_plugin mx6ulz_14x14_evk liteboard kontron-sl-mx6ul novena mx6cuboxi pico-imx6 pico-dwarf-imx6ul pico-hobbit-imx6ul pico-imx6ul pico-pi-imx6ul tqma6dl_mba6_mmc tqma6dl_mba6_spi tqma6q_mba6_mmc tqma6q_mba6_spi tqma6s_mba6_mmc tqma6s_mba6_spi udoo_neo cl-som-imx7 imx7_cm pico-dwarf-imx7d pico-hobbit-imx7d pico-imx7d pico-imx7d_bl33 pico-nymph-imx7d pico-pi-imx7d s5p4418_nanopi2 omap4_panda omap4_sdp4430 omap5_uevm ls1012afrdm_qspi ls1012afrdm_tfa ls1012afrwy_qspi ls1012afrwy_qspi_SECURE_BOOT ls1012afrwy_tfa ls1012afrwy_tfa_SECURE_BOOT ls1012aqds_qspi ls1012aqds_tfa ls1012aqds_tfa_SECURE_BOOT ls1012a2g5rdb_qspi ls1012a2g5rdb_tfa ls1012ardb_qspi ls1012ardb_qspi_SECURE_BOOT ls1012ardb_tfa ls1012ardb_tfa_SECURE_BOOT ls1028aqds_tfa ls1028aqds_tfa_SECURE_BOOT ls1028ardb_tfa ls1028ardb_tfa_SECURE_BOOT ls1043aqds ls1043aqds_nand ls1043aqds_nor_ddr3 ls1043aqds_qspi ls1043aqds_sdcard_ifc ls1043aqds_sdcard_qspi ls1043aqds_tfa ls1043aqds_tfa_SECURE_BOOT ls1043ardb ls1043ardb_nand ls1043ardb_nand_SECURE_BOOT ls1043ardb_sdcard ls1043ardb_sdcard_SECURE_BOOT ls1043ardb_SECURE_BOOT ls1043ardb_tfa ls1043ardb_tfa_SECURE_BOOT ls1046afrwy_tfa ls1046afrwy_tfa_SECURE_BOOT ls1046aqds ls1046aqds_nand ls1046aqds_qspi ls1046aqds_sdcard_ifc ls1046aqds_sdcard_qspi ls1046aqds_SECURE_BOOT ls1046aqds_tfa ls1046aqds_tfa_SECURE_BOOT ls1046ardb_emmc ls1046ardb_qspi ls1046ardb_qspi_SECURE_BOOT ls1046ardb_qspi_spl ls1046ardb_sdcard ls1046ardb_sdcard_SECURE_BOOT ls1046ardb_tfa ls1046ardb_tfa_SECURE_BOOT ls1088aqds ls1088aqds_qspi ls1088aqds_qspi_SECURE_BOOT ls1088aqds_sdcard_ifc ls1088aqds_sdcard_qspi ls1088aqds_tfa ls1088ardb_qspi ls1088ardb_qspi_SECURE_BOOT ls1088ardb_sdcard_qspi ls1088ardb_sdcard_qspi_SECURE_BOOT ls1088ardb_tfa ls1088ardb_tfa_SECURE_BOOT ls2080aqds ls2080aqds_nand ls2080aqds_qspi ls2080aqds_sdcard ls2080aqds_SECURE_BOOT ls2088aqds_tfa ls2080ardb ls2080ardb_nand ls2080ardb_SECURE_BOOT ls2081ardb ls2088ardb_qspi ls2088ardb_qspi_SECURE_BOOT ls2088ardb_tfa ls2088ardb_tfa_SECURE_BOOT ten64_tfa librem5 xtfpga MPC837XERDB MPC8548CDS MPC8548CDS_36BIT MPC8548CDS_legacy P1010RDB-PA_36BIT_NAND P1010RDB-PA_36BIT_NOR P1010RDB-PA_36BIT_SDCARD P1010RDB-PA_36BIT_SPIFLASH P1010RDB-PA_NAND P1010RDB-PA_NOR P1010RDB-PA_SDCARD P1010RDB-PA_SPIFLASH P1010RDB-PB_36BIT_NAND P1010RDB-PB_36BIT_NOR P1010RDB-PB_36BIT_SDCARD P1010RDB-PB_36BIT_SPIFLASH P1010RDB-PB_NAND P1010RDB-PB_NOR P1010RDB-PB_SDCARD P1010RDB-PB_SPIFLASH P1020RDB-PC P1020RDB-PC_36BIT P1020RDB-PC_36BIT_NAND P1020RDB-PC_36BIT_SDCARD P1020RDB-PC_36BIT_SPIFLASH P1020RDB-PC_NAND P1020RDB-PC_SDCARD P1020RDB-PC_SPIFLASH P1020RDB-PD P1020RDB-PD_NAND P1020RDB-PD_SDCARD P1020RDB-PD_SPIFLASH P2020RDB-PC P2020RDB-PC_36BIT P2020RDB-PC_36BIT_NAND P2020RDB-PC_36BIT_SDCARD P2020RDB-PC_36BIT_SPIFLASH P2020RDB-PC_NAND P2020RDB-PC_SDCARD P2020RDB-PC_SPIFLASH P2041RDB P2041RDB_NAND P2041RDB_SDCARD P2041RDB_SPIFLASH T1024RDB T1024RDB_NAND T1024RDB_SDCARD T1024RDB_SPIFLASH T1042D4RDB T1042D4RDB_NAND T1042D4RDB_SDCARD T1042D4RDB_SPIFLASH T2080QDS T2080QDS_NAND T2080QDS_SDCARD T2080QDS_SECURE_BOOT T2080QDS_SPIFLASH T2080QDS_SRIO_PCIE_BOOT T2080RDB T2080RDB_NAND T2080RDB_revD T2080RDB_revD_NAND T2080RDB_revD_SDCARD T2080RDB_revD_SPIFLASH T2080RDB_SDCARD T2080RDB_SPIFLASH T4240RDB T4240RDB_SDCARD And, phew, that is a lot. I am hopeful that a number of these could be handled quickly if for example some SoCs switched to "imply DM_SERIAL if SERIAL" or "select DM_SERIAL if SERIAL" rather than leaving it to individual boards to enable / select. -- Tom

2 4

[PATCH] Kconfig: distro: Use imply instead of select for CMD_FAT
by Jit Loon Lim 14 Oct '22

14 Oct '22

From: Tien Fong Chee <tien.fong.chee(a)intel.com> Using imply instead of select for CMD_FAT so overwritten is allowed in later configuration. Signed-off-by: Tien Fong Chee <tien.fong.chee(a)intel.com> --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 991b260182..71374980e9 100644 --- a/Kconfig +++ b/Kconfig @@ -201,7 +201,7 @@ config DISTRO_DEFAULTS select CMD_ENV_EXISTS select CMD_EXT2 select CMD_EXT4 - select CMD_FAT + imply CMD_FAT select CMD_FS_GENERIC select CMD_PART if PARTITIONS select CMD_PING if CMD_NET -- 2.26.2

3 5

[PATCH v2 00/39] efi: Improvements to U-Boot running on top of UEFI
by Simon Glass 14 Oct '22

14 Oct '22

At present U-Boot can be built as an EFI app, but it is really just for testing, with very few features. Instead, the payload build is used for booting on top of UEFI, where U-Boot takes over the machine immediately and supplies its own drivers. But the app could be made more useful. This series provides access to EFI block devices and the video console within U-Boot. It also restructures the app to make it possible to boot a kernel, although further work is needed to implement this. This can be thought of as making U-Boot perform a little like 'grub', in that it runs purely based on UEFI-provided services. Of course a lot more work is required, but this is a start. Note: It would be very useful to include qemu tests of the app and stub in CI. This is available at u-boot-dm/efi-working Changes in v2: - Add MAINTAINERS entry - Add a better boot command too - Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used - Add a sentence about what the patch does - Add a work-around to avoid a toolchain crash - Add new patch to drop the OF_EMBED warning for EFI - Add new patch to enable DM_ETH for the app - Add new patch to support the efi command in the app - Add new patch with maintainer entry - Add support for creating a partition table with a filesystem inside - Add support for running qemu with just a serial console (no display) - Drop mention of partitions from the commit message - Expand the commit message to make things clearer - Fix 'as' typo - Mention why this patch is included in this series - Put this patch first so that it is separated from the rest of the series - Show the correct interface type with 'part list' - Update commit message to mention that these function are x86-specific - Update commit message to mention why the data structure is like it is - Update commit message to mention why ulong is used - Update documentation - Update the commit message to explain things better - Use log_info() instead of printf() Simon Glass (39): RFC: efi: Drop code that doesn't work with driver model efi: Add a separate maintainer entry for the app x86: Keep symbol information in u-boot ELF file x86: Create a new header for EFI x86: Show some EFI info with the bdinfo command x86: Tidy up global_data pointer for 64-bit efi: Add a script for building and testing U-Boot on UEFI efi: Enable DM_ETH for the app efi: Drop the OF_EMBED warning for EFI x86: Create a 32/64-bit selection for the app efi: Create a 64-bit app x86: Don't duplicate global_ptr in 64-bit EFI app efi: Add a way to obtain boot services in the app efi: Add video support to the app efi: Add EFI uclass for media efi: Add a media/block driver for EFI block devices efi: Locate all block devices in the app patman: Use a ValueError exception if tools.Run() fails binman: Report an error if test files fail to compile binman: Support reading the offset of an ELF-file symbol binman: Allow timeout to occur in the image or its section binman: Tidy up comments on _DoTestFile() binman: Support updating the dtb in an ELF file efi: serial: Support arrow keys bloblist: Support allocating the bloblist x86: Allow booting a kernel from the EFI app x86: Don't process the kernel command line unless enabled x86: efi: Add room for the binman definition in the dtb efi: Add comments to struct efi_priv efi: Fix ll_boot_init() operation with the app efi: Add a few comments to the stub efi: Share struct efi_priv between the app and stub code efi: Move exit_boot_services into a function efi: Check for failure when initing the app efi: Mention that efi_info_get() is only used in the stub efi: Show when allocated pages are used efi: Allow easy selection of serial-only operation efi: Update efi_get_next_mem_desc() to avoid needing a map efi: Support the efi command in the app MAINTAINERS | 14 + Makefile | 10 +- arch/sandbox/dts/test.dts | 4 + arch/x86/config.mk | 4 +- arch/x86/cpu/efi/payload.c | 21 +- arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/cpu/u-boot-64.lds | 2 + arch/x86/cpu/x86_64/Makefile | 4 + arch/x86/cpu/x86_64/cpu.c | 32 +- arch/x86/cpu/x86_64/misc.c | 41 +++ arch/x86/dts/Makefile | 2 +- arch/x86/dts/efi-x86_app.dts | 4 + arch/x86/include/asm/efi.h | 39 +++ arch/x86/include/asm/global_data.h | 2 + arch/x86/include/asm/zimage.h | 3 - arch/x86/lib/Makefile | 1 + arch/x86/lib/bdinfo.c | 22 ++ arch/x86/lib/bootm.c | 11 +- arch/x86/lib/zimage.c | 14 +- board/efi/Kconfig | 15 +- board/efi/efi-x86_app/Kconfig | 6 +- board/efi/efi-x86_app/MAINTAINERS | 11 +- cmd/Makefile | 2 +- cmd/efi.c | 76 +++-- common/Kconfig | 15 +- common/bloblist.c | 16 +- common/board_f.c | 8 +- ..._app_defconfig => efi-x86_app32_defconfig} | 3 +- configs/efi-x86_app64_defconfig | 39 +++ disk/part.c | 5 +- doc/develop/bloblist.rst | 16 + doc/develop/uefi/u-boot_on_efi.rst | 74 ++++- drivers/block/Kconfig | 33 +++ drivers/block/Makefile | 4 + drivers/block/blk-uclass.c | 2 +- drivers/block/efi-media-uclass.c | 15 + drivers/block/efi_blk.c | 115 ++++++++ drivers/block/sb_efi_media.c | 20 ++ drivers/serial/serial_efi.c | 11 +- drivers/video/Kconfig | 2 +- drivers/video/efi.c | 45 ++- include/configs/efi-x86_app.h | 31 +- include/dm/uclass-id.h | 1 + include/efi.h | 123 +++++++- include/efi_api.h | 15 + include/init.h | 2 +- lib/efi/Kconfig | 34 ++- lib/efi/efi.c | 106 +++++++ lib/efi/efi_app.c | 276 +++++++++++++++++- lib/efi/efi_stub.c | 95 +++--- lib/efi_driver/Makefile | 2 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_device_path.c | 96 ++---- lib/efi_loader/efi_disk.c | 48 --- scripts/build-efi.sh | 188 ++++++++++++ test/dm/Makefile | 1 + test/dm/efi_media.c | 24 ++ tools/binman/binman.rst | 36 +++ tools/binman/cmdline.py | 2 + tools/binman/control.py | 11 + tools/binman/elf.py | 74 ++++- tools/binman/elf_test.py | 45 ++- tools/binman/ftest.py | 91 +++++- tools/binman/test/Makefile | 13 +- tools/binman/test/bss_data.c | 2 +- tools/binman/test/embed_data.c | 16 + tools/binman/test/embed_data.lds | 23 ++ tools/binman/test/u_boot_binman_embed.c | 13 + tools/binman/test/u_boot_binman_embed.lds | 29 ++ tools/binman/test/u_boot_binman_embed_sm.c | 13 + tools/patman/tools.py | 2 +- 71 files changed, 1841 insertions(+), 337 deletions(-) create mode 100644 arch/x86/cpu/x86_64/misc.c create mode 100644 arch/x86/include/asm/efi.h create mode 100644 arch/x86/lib/bdinfo.c rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (94%) create mode 100644 configs/efi-x86_app64_defconfig create mode 100644 drivers/block/efi-media-uclass.c create mode 100644 drivers/block/efi_blk.c create mode 100644 drivers/block/sb_efi_media.c create mode 100755 scripts/build-efi.sh create mode 100644 test/dm/efi_media.c create mode 100644 tools/binman/test/embed_data.c create mode 100644 tools/binman/test/embed_data.lds create mode 100644 tools/binman/test/u_boot_binman_embed.c create mode 100644 tools/binman/test/u_boot_binman_embed.lds create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c -- 2.33.0.685.g46640cef36-goog

4 73

[PATCH 0/5] Makefile: Deal with missing blobs consistently
by Simon Glass 14 Oct '22

14 Oct '22

Missing blobs should cause the build (with make) to fail, but at present success is returned. This is because binman currently produces an exit code of 0 in this case. Of course this is not correct, since the images cannot actually be used. This series fixes that and adjusts buildman to deal sensibly with the situation. It also includes a buildman patch to deal with N: entries in the MAINTAINER files and a few other minor niggles noticed along the way. Simon Glass (5): buildman: Handle the MAINTAINERS 'N' tag Makefile: Correct a missing FORCE on the binman rule doc: Correct the path to the Makefile documentation binman: Use an exit code when blobs are missing buildman: Detect binman reporting missing blobs Makefile | 2 +- scripts/Kbuild.include | 2 +- tools/binman/binman.rst | 4 ++++ tools/binman/cmdline.py | 3 +++ tools/binman/control.py | 7 ++++++- tools/buildman/boards.py | 11 +++++++++++ tools/buildman/builderthread.py | 6 +++++- 7 files changed, 31 insertions(+), 4 deletions(-) -- 2.38.0.rc2.412.g84df46c1b4-goog

4 14

Re: Question about uboot initialisation
by momo aubin 14 Oct '22

14 Oct '22

On Mon, 12 Sept 2022 at 17:07, Simon Glass <sjg(a)chromium.org> wrote: > Hi Aubin, > > On Mon, 12 Sept 2022 at 08:23, momo aubin <aubinno(a)gmail.com> wrote: > > > > Hi Simon, > > > > Thanks for your answer and explanations. > > > > The sequence of boot is : > > RBL->UBL->UBOOT->Kernel->ROOTFS. > > > > According to this sequence, ubl is the one who chooses which uboot needs > to be started, then writing the script means writing them inside ubl. > However, Ubl doesn't have access to the environment variable in order to > know which u-boot has been used first. > > > > My question is . > > Is it possible to choose another u-boot (u-boot2) inside the first > u-boot (u-boot1) ? > > Can you please try that reply again, without top posting? > > https://www.google.com/search?q=top+posting > > Regards, > Simon > > > > > > Regards, > > Aubin > > > > On Mon, 12 Sept 2022 at 15:35, Simon Glass <sjg(a)chromium.org> wrote: > >> > >> Hi Momo, > >> > >> On Sun, 11 Sept 2022 at 08:29, momo aubin <aubinno(a)gmail.com> wrote: > >> > > >> > Hi Simon, > >> > > >> > Thanks for getting back to me. > >> > > >> > How can I avoid top posting ? i'm a new > >> > >> You can do a web search for "top posting" which explains the issue > >> better than I can. > >> > >> > > >> > How uboot know that the kernel has started ? > >> > >> Generally it does not. U-Boot's job is typically over once it jumps to > >> the kernel. > >> > >> > If the system is blocked during the u-boot stage, is it possible to > restart all the systems ? > >> > It is possible to put a timer in the u-boot stage in case of the > kernel has not started , can the system reboot by choosing another u-boot ? > >> > >> You can use a watchdog timer to reboot the system. It can be set up in > >> U-Boot, then it Linux does not kick it in time, it will cause a > >> reboot. To choose another U-Boot, you would need to do some scripting, > >> or use mender. There is some work on VBE going on (U-Boot standard > >> boot) but it will take a while to all land. > >> > >> Regards, > >> SImon > >> > >> > >> > > >> > > >> > Thanks for your answer in advance. > >> > Aubin > >> > > >> > > >> > On Tue, 30 Aug 2022 at 04:30, Simon Glass <sjg(a)chromium.org> wrote: > >> >> > >> >> Hi Aubin, > >> >> > >> >> On Mon, 29 Aug 2022 at 01:40, momo aubin <aubinno(a)gmail.com> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > I got what is the 'dm tree' which is a driver model. This command > could be done only in uboot stage. but i got the situation in which the > initialisation of u-boot has not finished yet as showing in the following > picture. > >> >> > > >> >> > > >> >> > .i would like to know what is wrong in the initialisation ? > >> >> > >> >> Please try to avoid top posting. > >> >> > >> >> I think the best thing is to move to the latest U-Boot. You are about > >> >> 9 years behind! But as to your question, I am really not sure. If it > >> >> is a TI board, you could try asking them? > >> >> > >> >> Regards, > >> >> Simon > >> >> > >> >> > >> >> > > >> >> > Best Regard, > >> >> > Aubin > >> >> > > >> >> > On Mon, 29 Aug 2022 at 05:24, momo aubin <aubinno(a)gmail.com> > wrote: > >> >> >> > >> >> >> Hi Simon, > >> >> >> > >> >> >> Thanks for your answer. > >> >> >> > >> >> >> The script that you are telling it is Env.txt right ? > >> >> >> > >> >> >> What is a 'dm tree' ? Please could you provide me more infos > about this ? > >> >> >> > >> >> >> Thanks for your answer in advance. > >> >> >> > >> >> >> On Sat, 27 Aug 2022 at 02:21, Simon Glass <sjg(a)chromium.org> > wrote: > >> >> >>> > >> >> >>> Hi Aubin, > >> >> >>> > >> >> >>> On Fri, 26 Aug 2022 at 06:41, momo aubin <aubinno(a)gmail.com> > wrote: > >> >> >>> > > >> >> >>> > Dear all, > >> >> >>> > > >> >> >>> > > >> >> >>> > Is there any way that allows us to know that uboot has > initialised all his > >> >> >>> > peripherals before starting loading kernel ? > >> >> >>> > > >> >> >>> > The goal of this check is to reset the board in case of bad > initialisation > >> >> >>> > and choose a different uboot . > >> >> >>> > > >> >> >>> > Thanks for your answer in advance. > >> >> >>> > Aubin > >> >> >>> > >> >> >>> If there is a failure then it likely results in an error-return > code > >> >> >>> from board_init_f() or board_init_r(). These generally halt > U-Boot / > >> >> >>> cause a reboot. But this only covers the peripherals that U-Boot > sets > >> >> >>> up early, like serial, clocks, pinctrl, MMC, PCI, etc. > >> >> >>> > >> >> >>> U-Boot typically does not init a peripheral unless it is needed > for U-Boot. > >> >> >>> > >> >> >>> While U-Boot is running (e.g. a script) it may start up other > >> >> >>> peripherals (e.g. to read a kernel from USB) and in those cases > errors > >> >> >>> can be handled by the script. > >> >> >>> > >> >> >>> You can use 'dm tree' to see what devices have been probed > successfully. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Simon > Hi Simon, Thanks for your answer and explanations. The sequence of boot is : RBL->UBL->UBOOT->Kernel->ROOTFS. According to this sequence, ubl is the one who chooses which uboot needs to be started, then writing the script means writing them inside ubl. However, Ubl doesn't have access to the environment variable in order to know which u-boot has been used first. My question is . Is it possible to choose another u-boot (u-boot2) inside the first u-boot (u-boot1) ? Is this correct ? Regards, Aubin

2 4

[PATCH 0/3] cmd: source: Support specifying config name
by Sean Anderson 14 Oct '22

14 Oct '22

This series adds support for using configs with the source command. See the third patch for details. Sean Anderson (3): treewide: Use NULL for script image name cmd: source: Clean up a few lines cmd: source: Support specifying config name .../cmd_stm32prog/cmd_stm32prog.c | 2 +- boot/bootmeth_script.c | 2 +- cmd/source.c | 83 +++++++++++++------ doc/uImage.FIT/source_file_format.txt | 3 + drivers/usb/gadget/f_sdp.c | 2 +- include/image.h | 19 +++-- 6 files changed, 76 insertions(+), 35 deletions(-) -- 2.35.1.1320.gc452695387.dirty

2 6

[PATCH] cmd: clk: probe the clock before dump them
by Patrick Delaunay 14 Oct '22

14 Oct '22

The clock UCLASS need to be probed to allow availability of the private data (struct clk *), get in show_clks() with dev_get_clk_ptr() before use them. Without this patch the clock dump can cause crash because all the private data are not available before calling the API clk_get_rate(). It is the case for the SCMI clocks, priv->channel is needed for scmi_clk_get_rate() and it is initialized only in scmi_clk_probe(). This issue causes a crash for "clk dump" command on STM32MP135F-DK board for SCMI clock not yet probed. Fixes: 1a725e229096 ("clk: fix clock tree dump to properly dump out every registered clock") Signed-off-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> --- cmd/clk.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/cmd/clk.c b/cmd/clk.c index a483fd898122..9c58247935a3 100644 --- a/cmd/clk.c +++ b/cmd/clk.c @@ -21,8 +21,11 @@ static void show_clks(struct udevice *dev, int depth, int last_flag) struct clk *clkp, *parent; u32 rate; - clkp = dev_get_clk_ptr(dev); - if (device_get_uclass_id(dev) == UCLASS_CLK && clkp) { + clkp = NULL; + if (device_get_uclass_id(dev) == UCLASS_CLK && !device_probe(dev)) { + clkp = dev_get_clk_ptr(dev); + } + if (clkp) { parent = clk_get_parent(clkp); if (!IS_ERR(parent) && depth == -1) return; -- 2.25.1

2 1

U-Boot CONFIG_TIMER migration deadline
by Tom Rini 14 Oct '22

14 Oct '22

Hey all, I'm sending this email out to the main and custodian lists, and bcc'ing all of the listed maintainers for platforms that have a problem here. The migration deadline for switching from CONFIG_SYS_TIMER_RATE or CONFIG_SYS_TIMER_COUNTER and to using CONFIG_TIMER is the v2023.01 release. Now, per how I've behaved in the past, I'm not going to immediately remove these platforms. But it would be very good to jump on migrating them now, rather than waiting further. The full list (at least n so far as our Makefile check can determine) is: rpi rpi_0_w at91sam9g10ek_dataflash_cs0 at91sam9g10ek_dataflash_cs3 at91sam9g10ek_nandflash usb_a9263_dataflash ethernut5 meesc meesc_dataflash pm9261 pm9263 corvus smartweb axm taurus vexpress_ca9x4 vinco rpi_2 rpi_3_32b rpi_4_32b highbank alt blanche gose koelsch lager porter silk stout elgin-rv1108 evb-rv1108 socfpga_is1 socfpga_sr1500 socfpga_arria5 socfpga_cyclone5 socfpga_mcvevk socfpga_dbm_soc1 socfpga_socrates socfpga_secu1 socfpga_vining_fpga socfpga_de0_nano_soc socfpga_de1_soc socfpga_de10_nano socfpga_de10_standard socfpga_sockit dalmore cei-tk1-som jetson-tk1 nyan-big venice2 apalis-tk1 medcom-wide plutux tec paz00 trimslice harmony seaboard ventana colibri_t20 tec-ng beaver cardhu apalis_t30 colibri_t30 uniphier_ld4_sld8 uniphier_v7 cortina_presidio-asic-base cortina_presidio-asic-emmc cortina_presidio-asic-pnand r2dplus -- Tom

3 4

U-Boot CONFIG_DM_I2C migration deadline
by Tom Rini 14 Oct '22

14 Oct '22

Hey all, I'm sending this email out to the main and custodian lists, and bcc'ing all of the listed maintainers for platforms that have a problem here. The migration deadline for switching from CONFIG_SYS_I2C_LEGACY to CONFIG_DM_I2C was the v2022.04 release. Now, per how I've behaved in the past, I'm not going to immediately remove these platforms. But I will with v2024.04 at least, and depending on feedback I might start complaining loudly before then too. The full list (at least in so far as our Makefile check can determine) is: ethernut5 d2net_v2 net2big_v2 inetspace_v2 netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2 devkit3250 work_92105 am335x_shc am335x_shc_ict am335x_shc_netboot am335x_shc_sdboot cm_t43 chiliboard am335x_igep003x draco etamin rastaban thuban pxm2 rut am335x_sl50 am335x_baltos pg_wcom_expu1 pg_wcom_expu1_update pg_wcom_seli8 pg_wcom_seli8_update db-88f6720 db-88f6820-gp mx53loco usbarmory mx6qsabrelite nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s nitrogen6s1g cm_fx6 marsboard riotboard mx6sabreauto mx6sabresd novena vining_2000 udoo_neo cl-som-imx7 pico-dwarf-imx7d pico-hobbit-imx7d pico-imx7d pico-imx7d_bl33 pico-nymph-imx7d pico-pi-imx7d igep00x0 sniper omap3_beagle omap4_panda omap4_sdp4430 omap5_uevm vf610twr vf610twr_nand ls1088aqds ls1088aqds_qspi ls1088aqds_qspi_SECURE_BOOT ls1088aqds_sdcard_ifc ls1088aqds_sdcard_qspi ls1088ardb_qspi ls1088ardb_qspi_SECURE_BOOT ls1088ardb_sdcard_qspi ls1088ardb_sdcard_qspi_SECURE_BOOT ls2080aqds ls2080aqds_nand ls2080aqds_qspi ls2080aqds_sdcard ls2080aqds_SECURE_BOOT ls2080ardb ls2080ardb_nand ls2080ardb_SECURE_BOOT ls2081ardb ls2088ardb_qspi ls2088ardb_qspi_SECURE_BOOT M5235EVB M5235EVB_Flash32 eb_cpu5282 eb_cpu5282_internal M5208EVBE M5253DEMO M5275EVB astro_mcf5373l M53017EVB M5329AFEE M5329BFEE M5373EVB MPC837XERDB kmcoge5ne kmeter1 kmopti2 kmsupx5 kmtepr2 tuge1 tuxx1 -- Tom

1 0