October 2021 - U-Boot

[PATCH v2] bootstage: Add SPL support
by Marek Vasut 03 Nov '21

03 Nov '21

Allow usage of the bootstage facilities in SPL. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Simon Glass <sjg(a)chromium.org> --- V2: Fix multiple misuses of BOOTSTAGE vs SHOW_BOOT_PROGRESS --- arch/x86/cpu/cpu.c | 2 +- board/siemens/iot2050/board.c | 2 +- common/Kconfig.boot | 9 +++++++++ common/init/board_init.c | 2 +- common/spl/spl.c | 2 +- include/bootstage.h | 2 +- 6 files changed, 14 insertions(+), 5 deletions(-) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index 01dece5769c..86f53e78d24 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -178,7 +178,7 @@ int default_print_cpuinfo(void) return 0; } -#if CONFIG_IS_ENABLED(BOOTSTAGE) +#if CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS) void show_boot_progress(int val) { outb(val, POST_PORT); diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c index b2110978ae0..16ae2ffc174 100644 --- a/board/siemens/iot2050/board.c +++ b/board/siemens/iot2050/board.c @@ -250,7 +250,7 @@ void spl_board_init(void) { } -#if CONFIG_IS_ENABLED(LED) && CONFIG_IS_ENABLED(BOOTSTAGE) +#if CONFIG_IS_ENABLED(LED) && CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS) /* * Indicate any error or (accidental?) entering of CLI via the red status LED. */ diff --git a/common/Kconfig.boot b/common/Kconfig.boot index 9b84a8d005f..d0d0dbd09a3 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -696,6 +696,15 @@ config SHOW_BOOT_PROGRESS -150 common/cmd_nand.c Incorrect FIT image format 151 common/cmd_nand.c FIT image format OK +config SPL_SHOW_BOOT_PROGRESS + bool "Show boot progress in a board-specific manner" + depends on SPL + help + Defining this option allows to add some board-specific code (calling + a user-provided function show_boot_progress(int) that enables you to + show the system's boot progress on some display (for example, some + LEDs) on your board. For details see SHOW_BOOT_PROGRESS. + endmenu menu "Boot media" diff --git a/common/init/board_init.c b/common/init/board_init.c index 0965b96fa3a..eab5ee13953 100644 --- a/common/init/board_init.c +++ b/common/init/board_init.c @@ -166,7 +166,7 @@ void board_init_f_init_reserve(ulong base) board_init_f_init_stack_protection(); } -#if CONFIG_IS_ENABLED(BOOTSTAGE) +#if CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS) /* * Board-specific Platform code can reimplement show_boot_progress () if needed */ diff --git a/common/spl/spl.c b/common/spl/spl.c index be09c19351a..d95a29b3655 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -61,7 +61,7 @@ binman_sym_declare(ulong, spl, size); /* Define board data structure */ static struct bd_info bdata __attribute__ ((section(".data"))); -#if CONFIG_IS_ENABLED(BOOTSTAGE) +#if CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS) /* * Board-specific Platform code can reimplement show_boot_progress () if needed */ diff --git a/include/bootstage.h b/include/bootstage.h index f837a387c8c..8d1989ac0e5 100644 --- a/include/bootstage.h +++ b/include/bootstage.h @@ -220,7 +220,7 @@ enum bootstage_id { */ ulong timer_get_boot_us(void); -#if defined(USE_HOSTCC) || !CONFIG_IS_ENABLED(BOOTSTAGE) +#if defined(USE_HOSTCC) || !CONFIG_IS_ENABLED(SHOW_BOOT_PROGRESS) #define show_boot_progress(val) do {} while (0) #else /** -- 2.33.0

4 7

[PATCH 0/5] Board specific runtime determined default env
by Marek Behún 03 Nov '21

03 Nov '21

From: Marek Behún <marek.behun(a)nic.cz> Hello Simon, Stefan, Pali, this series adds support for board specific runtime determined default environment variables. IMPORTANT: This series depends on the series http://patchwork.ozlabs.org/project/uboot/list/?series=268452 Currently the env default [-a] command uses the default_environment[] buffer to get the default env variables. Sometimes it makes sense to have runtime determined default env settings. For example the ESPRESSObin board has 4 variants ([ddr3 vs ddr4] x [emmc vs sd]), and each uses different device tree. Thus the `fdtfile` env variable has different values for these 4 variants. (We can't set this variable via env_set() in some board init function, because then the user would be unable to overwrite it.) In order for the command env default fdtfile to work as the user would expect, we need to support overwriting default environment in runtime. Pali solved this for ESPRESSObin by declaring the default_environment[] buffer read-write, instead of read-only, and adding ad-hoc code into board_late_init() that writes into the default_environment[] buffer. This ad-hoc code works, but it would be better to have a generic API for this, since there are other boards which could benefit. The first 3 patches in this series fix and simplify code in env/common.c. The 4th patch adds support for board specific runtime determined default environment in such a way that if a board code defines function const char *board_special_default_env(unsigned i, const char **name); The default weak implementation of this function is trivial and just returns NULL. This function is to be defined in board code, and when defined, it must return the value of the i-th runtime determined default env variable, while storing its name into *name. For example: const char *board_special_default_env(unsigned i, const char **name) { switch (i) { case 0: *name = "board"; return is_ddr4() ? "my_board_ddr4" : "my_board"; case 1: *name = "fdtfile"; return is_ddr4() ? "my-board-ddr4.dtb" : "my-board.dtb"; default: return NULL; } The last patch (NOT TESTED) converts the ESPRESSObin ad-hoc code to use this API. Marek Marek Behún (5): env: Don't set ready flag if import failed in env_set_default() env: Fix env_get() when returning empty string using env_get_f() env: Simplify env_get_default() env: Add support for board specific special default environment arm: mvebu: Espressobin: Use new API for setting default env at runtime board/Marvell/mvebu_armada-37xx/board.c | 120 ++++++++++------ configs/mvebu_espressobin-88f3720_defconfig | 1 - env/common.c | 150 ++++++++++++++++---- include/configs/mvebu_armada-37xx.h | 17 +-- include/env_default.h | 2 - include/env_internal.h | 4 - 6 files changed, 199 insertions(+), 95 deletions(-) -- 2.32.0

3 20

[PATCH u-boot-marvell 0/5] kwboot fix for AXP + some others
by Marek Behún 03 Nov '21

03 Nov '21

From: Marek Behún <marek.behun(a)nic.cz> Hi Stefan, here are some more Pali's changes for kwboot, reviewed by me. The last one should fix boot on AXP. Marek Pali Rohár (5): tools: kwboot: Fix sending retry of last header packet tools: kwboot: Do not call tcdrain() after each sent packet tools: kwboot: Increase delay after changing baudrate in ARM code tools: kwboot: Replace ARM mov + movt instruction pair by mov + orr tools: kwboot: Do not use stack when setting baudrate back to default value tools/kwboot.c | 148 +++++++++++++++++++++++++++---------------------- 1 file changed, 83 insertions(+), 65 deletions(-) -- 2.32.0

2 11

[PATCH u-boot-marvell 00/13] Yet another kwboot improvements
by Marek Behún 03 Nov '21

03 Nov '21

From: Marek Behún <marek.behun(a)nic.cz> Hello Stefan, these are another improvements for kwboot, please apply only after series arm: mvebu: nandpagesize support for kwbimage v1 The main improvement is in patch 5, which changes where we inject the code for changing baudrate back to 115200 Baud after fast upload. Instead of injecting it before the main data image, we now inject it after. This is because there are some kwb images that upload at address 0, and injecting the code before that doesn't work, since there is no RAM mapped at 0xfffff000. Marek & Pali Pali Rohár (13): tools: kwboot: Initialize rfds to zero tools: kwboot: Fix initialization of tty device tools: kwboot: Reserve enough space for patching kwbimage in memory tools: kwboot: Validate 4-byte image data checksum tools: kwboot: Inject baudrate change back code after data part tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code tools: kwboot: Correctly set configuration of UART for BootROM messages tools: kwboot: Show verbose message when waiting for baudrate change magic tools: kwboot: Simplify code for aligning image header tools: kwboot: Do not modify kwbimage header before increasing its size tools: kwboot: Calculate real used space in kwbimage header when calling kwboot_img_grow_hdr() tools: kwboot: Change retry loop from decreasing to increasing tools: kwboot: Resend first 3 xmodem retry packets immediately tools/kwboot.c | 178 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 120 insertions(+), 58 deletions(-) -- 2.32.0

3 58

[PATCH 0/8] pci: pci_mvebu: Fix access to config space and PCIe Root Port
by Pali Rohár 03 Nov '21

03 Nov '21

This patch series fixes access to config space and fixes issues with the mysterious "Memory controller" PCI device (which is PCIe Root Port). Tested on Armada 385 Turris Omnia device which has 3 mPCIe slots. PCIe Root Port device is available for each slot on separate bus and has PCI Bridge class code as required by PCIe base specifications. => pci 0 Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x11ab 0x6820 Bridge device 0x04 => pci 1 Scanning PCI devices on bus 1 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 01.00.00 0x168c 0x003c Network controller 0x80 => pci 2 Scanning PCI devices on bus 2 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 02.00.00 0x11ab 0x6820 Bridge device 0x04 => pci 3 Scanning PCI devices on bus 3 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 03.00.00 0x168c 0x003c Network controller 0x80 => pci 4 Scanning PCI devices on bus 4 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 04.00.00 0x11ab 0x6820 Bridge device 0x04 => pci 5 Scanning PCI devices on bus 5 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 05.00.00 0x168c 0x002e Network controller 0x80 => pci 6 No such bus => U-Boot command "pci display.b 0.0.0 0 200" will display config space of the first PCIe Root Port device with the Type 1 PCI header as required by PCIe base specification. => pci display.b 0.0.0 0 200 00000000: ab 11 20 68 07 00 10 00 04 00 04 06 00 00 01 00 00000010: 00 00 00 00 00 00 00 00 00 01 01 00 01 f1 00 00 00000020: 00 c0 20 c0 01 10 01 00 00 00 00 00 00 00 00 00 00000030: 10 f1 0f f1 40 00 00 00 00 00 00 00 00 01 00 00 00000040: 01 50 03 06 00 00 00 00 00 00 00 00 00 00 00 00 00000050: 05 60 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00000060: 10 00 42 00 80 80 00 00 00 20 00 00 12 ac 07 00 00000070: 00 00 11 10 00 00 00 00 00 00 40 00 00 00 00 00 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000090: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000100: 01 00 01 00 00 00 00 00 00 00 00 00 10 00 06 00 00000110: 00 00 00 00 00 20 00 00 00 00 00 00 01 00 00 4a 00000120: 04 00 00 01 00 01 08 01 02 80 00 00 00 00 00 00 00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Pali Rohár (8): pci: pci_mvebu: Fix write_config() with PCI_SIZE_8 or PCI_SIZE_16 pci: pci_mvebu: Fix read_config() with PCI_SIZE_8 or PCI_SIZE_16 pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe Root Port) pci: pci_mvebu: Remove unused functions pci: pci_mvebu: Fix place of link up detection pci: pci_mvebu: Do not automatically enable bus mastering on PCI Bridge pci: pci_mvebu: Setup PCI controller to Root Complex mode pci: pci_mvebu: Fix comment about driver class name drivers/pci/pci_mvebu.c | 275 +++++++++++++++++++++++++++++----------- 1 file changed, 202 insertions(+), 73 deletions(-) -- 2.20.1

2 17

[PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call
by Bin Meng 03 Nov '21

03 Nov '21

set_promisc() call accepts the parameter of a bool type. Make it clear by using true instead of 1. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- net/dsa-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c index 694664d81b..dcefec03f4 100644 --- a/net/dsa-uclass.c +++ b/net/dsa-uclass.c @@ -282,7 +282,7 @@ static int dsa_port_probe(struct udevice *pdev) struct eth_ops *eth_ops = eth_get_ops(master); if (eth_ops->set_promisc) - eth_ops->set_promisc(master, 1); + eth_ops->set_promisc(master, true); return 0; } -- 2.25.1

3 17

[PATCH] net: tsec: mark tsec_set_promisc() as __maybe_unused
by Vladimir Oltean 03 Nov '21

03 Nov '21

Since the tsec driver supports both configurations with and without DM_ETH, and since the eth_ops :: set_promisc() method is only provided for DM_ETH, the implication is that builds with DM_ETH disabled will result in a 'defined but not used' warning. To silence those, mark the function as __maybe_unused. Fixes: 79ba3435f43d ("net: tsec: add support for promiscuous mode") Reported-by: Ramon Fried <rfried.dev(a)gmail.com> Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> --- drivers/net/tsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index 4354753cab9c..64bb42b0c006 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -156,7 +156,7 @@ static int tsec_mcast_addr(struct udevice *dev, const u8 *mcast_mac, int join) return 0; } -static int tsec_set_promisc(struct udevice *dev, bool enable) +static int __maybe_unused tsec_set_promisc(struct udevice *dev, bool enable) { struct tsec_private *priv = dev_get_priv(dev); struct tsec __iomem *regs = priv->regs; -- 2.25.1

2 1

[PATCH v2] imx: spl: fix imx8m secure boot
by Heiko Schocher 03 Nov '21

03 Nov '21

cherry-picked from NXP code: 719d665a87c6: ("MLK-20467 imx8m: Fix issue for booting signed image through uuu") which fixes secure boot on imx8m based boards. Problem was that FIT header and so IVT header too, was loaded to memallocated address. So the ivt header address coded in IVT itself does not fit with the real position. Signed-off-by: Heiko Schocher <hs(a)denx.de> --- replaces Series: https://lists.denx.de/pipermail/u-boot/2021-August/457308.html @Tim: could you please test this version on your hardware? azure build: https://dev.azure.com/hs0298/hs/_build/results?buildId=72&view=results Works on sdcard and QSPI NOR boot on phycore-imx8mp board. Changes in v2: - use code from NXP commit 719d665 as Ye Li suggested. arch/arm/mach-imx/spl.c | 14 ++++++++++++++ common/spl/spl_fit.c | 7 ++++++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 36033d611c..59c6c3752d 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -334,6 +334,20 @@ void board_spl_fit_post_load(const void *fit) } #endif +void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len) +{ + int align_len = ARCH_DMA_MINALIGN - 1; + + /* Some devices like SDP, NOR, NAND, SPI are using bl_len =1, so their fit address + * is different with SD/MMC, this cause mismatch with signed address. Thus, adjust + * the bl_len to align with SD/MMC. + */ + if (bl_len < 512) + bl_len = 512; + + return (void *)((CONFIG_SYS_TEXT_BASE - fit_size - bl_len - + align_len) & ~align_len); +} #endif #if defined(CONFIG_MX6) && defined(CONFIG_SPL_OS_BOOT) diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index f41abca0cc..a4337d3c88 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -538,6 +538,11 @@ static void *spl_get_fit_load_buffer(size_t size) return buf; } +__weak void *board_spl_fit_buffer_addr(ulong fit_size, int sectors, int bl_len) +{ + return spl_get_fit_load_buffer(sectors * bl_len); +} + /* * Weak default function to allow customizing SPL fit loading for load-only * use cases by allowing to skip the parsing/processing of the FIT contents @@ -631,7 +636,7 @@ static int spl_simple_fit_read(struct spl_fit_info *ctx, * For FIT with external data, data is not loaded in this step. */ sectors = get_aligned_image_size(info, size, 0); - buf = spl_get_fit_load_buffer(sectors * info->bl_len); + buf = board_spl_fit_buffer_addr(size, sectors, info->bl_len); count = info->read(info, sector, sectors, buf); ctx->fit = buf; -- 2.31.1

4 5

[RESEND PATCH] usb: mtu3: flush cache for the first GPD when allocate GPD ring
by Chunfeng Yun 03 Nov '21

03 Nov '21

When allocate the GPD ring, and tell its address to the controller, then the driver starts or resumes the QMU, the controller will try to access the first GPD, so need flush the first one to avoid wrong GPD status. Reported-by: Xin Lin <Xin.Lin(a)mediatek.com> Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com> --- drivers/usb/mtu3/mtu3_qmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/mtu3/mtu3_qmu.c b/drivers/usb/mtu3/mtu3_qmu.c index 95eaf6d236..e8dc0095ab 100644 --- a/drivers/usb/mtu3/mtu3_qmu.c +++ b/drivers/usb/mtu3/mtu3_qmu.c @@ -112,6 +112,7 @@ int mtu3_gpd_ring_alloc(struct mtu3_ep *mep) memset(gpd, 0, QMU_GPD_RING_SIZE); ring->dma = (dma_addr_t)gpd; gpd_ring_init(ring, gpd); + mtu3_flush_cache((uintptr_t)gpd, sizeof(*gpd)); return 0; } -- 2.25.1

2 6

[PATCH 0/2] sandbox: enable testing SYSRESET_WATCHDOG
by Heinrich Schuchardt 03 Nov '21

03 Nov '21

With CONFIG_SYSRESET_WATCHDOG=y the sandbox can use a watchdog based system reset. To make this work calling sandbox_wdt_expire_now() must lead to a reset. Further we need CONFIG_WDT_GPIO=n to actually call the right watchdog. Adjust the watchdog test to avoid a build error. With this change we can test the development suggested in [PATCH 0/4] Improved sysreset/watchdog uclass integration https://lists.denx.de/pipermail/u-boot/2021-August/458656.html Heinrich Schuchardt (2): test/dm: fix watchdog test sandbox: fix sandbox_wdt_expire_now() drivers/watchdog/sandbox_wdt.c | 1 + test/dm/wdt.c | 4 ++++ 2 files changed, 5 insertions(+) -- 2.32.0

3 7