December 2023 - U-Boot

[PATCH 00/33] doc: board: amlogic: spring clean-up of Amlogic docs
by Christian Hewitt 05 Apr '24

05 Apr '24

Amlogic documentation spans U-Boot support from 2015-current resulting in older content being harder to follow. And due to many international contributors the docs also contain grammar quirks. This series reworks all board documents to be more consistent. There is deliberate emphasis on using the amlogic-boot-fip repo for signing tasks as this is easier for most users to follow. The original/longer signing process (described as Manual Signing) has been tidied up. In the index.rst file I've dropped board names from the features table as this adds considerable width and makes adding new boards a fiddly process. I've appended the SoC type to the boader header so it shows in the TOC list to retain a reference between boards and the table. I've added missing board docs for GS-King-X, BPI-M5, BPI-CM4IO, and we split ODROID-HC4 into its own document. It originally followed the same process as the ODROID0-C4, but now has a separate defconfig to enable SPI-NOR and PCIe SATA support. Users occasionally follow the current doc and build U-Boot for the C4 which omits this and then struggle to figure out why SATA boot doesn't work when wiki/forums say it does. There are other minor cleanups and tweaks for clarity of simply more up-to-date information for a board or process. Please review and flag any omissions or issues! Christian Hewitt (33): doc: boards: amlogic: update documentation for index page doc: boards: amlogic: update documentation for boot-flow doc: boards: amlogic: update documentation for pre-generated-fip's doc: boards: amlogic: update documentation for Beelink GT-King doc: boards: amlogic: update documentation for Beelink GT-King Pro doc: boards: amlogic: update documentation for JetHub J100 doc: boards: amlogic: update documentation for JetHub J80 doc: boards: amlogic: update documentation for Khadas VIM doc: boards: amlogic: update documentation for Khadas VIM2 doc: boards: amlogic: update documentation for Khadas VIM3 doc: boards: amlogic: update documentation for Khadas VIM3L doc: boards: amlogic: update documentation for LaFrite doc: boards: amlogic: update documentation for LePotato doc: boards: amlogic: update documentation for NanoPi-K2 doc: boards: amlogic: update documentation for ODROID-C2 doc: boards: amlogic: update documentation for ODROID-C4 doc: boards: amlogic: update documentation for ODROID GO ULTRA doc: boards: amlogic: update documentation for ODROID-N2/N2+ doc: boards: amlogic: update documentation for ODROID-N2L doc: boards: amlogic: update documentation for P200 doc: boards: amlogic: update documentation for P201 doc: boards: amlogic: update documentation for Q200 doc: boards: amlogic: update documentation for Radxa Zero doc: boards: amlogic: update documentation for S400 doc: boards: amlogic: update documentation for SEI510 doc: boards: amlogic: update documentation for SEI610 doc: boards: amlogic: update documentation for U200 doc: boards: amlogic: update documentation for W400 doc: boards: amlogic: update documentation for WeTek Core2 doc: boards: amlogic: add documentation for BananaPi CM4IO doc: boards: amlogic: add documentation for BananaPi M5 doc: boards: amlogic: add documentation for GS-King-X doc: boards: amlogic: add documentation for ODROID-HC4 board/amlogic/beelink-s922x/MAINTAINERS | 3 +- board/amlogic/u200/MAINTAINERS | 1 - board/amlogic/w400/MAINTAINERS | 2 + doc/board/amlogic/bananapi-cm4io.rst | 152 ++++++++++++++++++++ doc/board/amlogic/bananapi-m5.rst | 141 +++++++++++++++++++ doc/board/amlogic/beelink-gskingx.rst | 121 ++++++++++++++++ doc/board/amlogic/beelink-gtking.rst | 120 ++++++++-------- doc/board/amlogic/beelink-gtkingpro.rst | 120 ++++++++-------- doc/board/amlogic/boot-flow.rst | 178 ++++++++++++------------ doc/board/amlogic/index.rst | 141 +++++++++---------- doc/board/amlogic/jethub-j100.rst | 66 ++++----- doc/board/amlogic/jethub-j80.rst | 46 +++--- doc/board/amlogic/khadas-vim.rst | 76 +++++----- doc/board/amlogic/khadas-vim2.rst | 76 +++++----- doc/board/amlogic/khadas-vim3.rst | 137 +++++++++--------- doc/board/amlogic/khadas-vim3l.rst | 137 +++++++++--------- doc/board/amlogic/libretech-ac.rst | 77 +++++----- doc/board/amlogic/libretech-cc.rst | 109 ++++++--------- doc/board/amlogic/nanopi-k2.rst | 93 +++++++------ doc/board/amlogic/odroid-c2.rst | 54 +++---- doc/board/amlogic/odroid-c4.rst | 117 ++++++++-------- doc/board/amlogic/odroid-go-ultra.rst | 25 +++- doc/board/amlogic/odroid-hc4.rst | 141 +++++++++++++++++++ doc/board/amlogic/odroid-n2.rst | 122 ++++++++-------- doc/board/amlogic/odroid-n2l.rst | 33 +++-- doc/board/amlogic/p200.rst | 87 +++++++----- doc/board/amlogic/p201.rst | 87 +++++++----- doc/board/amlogic/pre-generated-fip.rst | 138 +++++++++++------- doc/board/amlogic/q200.rst | 76 +++++----- doc/board/amlogic/radxa-zero.rst | 45 +++--- doc/board/amlogic/s400.rst | 89 ++++++------ doc/board/amlogic/sei510.rst | 113 ++++++++------- doc/board/amlogic/sei610.rst | 118 ++++++++-------- doc/board/amlogic/u200.rst | 113 ++++++++------- doc/board/amlogic/w400.rst | 115 ++++++++------- doc/board/amlogic/wetek-core2.rst | 83 ++++++----- 36 files changed, 2042 insertions(+), 1310 deletions(-) create mode 100644 doc/board/amlogic/bananapi-cm4io.rst create mode 100644 doc/board/amlogic/bananapi-m5.rst create mode 100644 doc/board/amlogic/beelink-gskingx.rst create mode 100644 doc/board/amlogic/odroid-hc4.rst -- 2.34.1

5 41

[PATCH] spi: dw: Use controller clock rate as maximum frequency
by Kunihiko Hayashi 05 Apr '24

05 Apr '24

Currently the controller driver has maximum frequency in plat->frequency that is specified by "spi-max-frequency" DT property in the controller node. This is special to U-Boot and doesn't exist to Linux. spi { spi-max-frequency = <A>; }; Usually the frequency should be specified by "spi-max-frequency" at the slave device node. spi { slave { spi-max-frequency = <B>; }; }; The final maximum frequency is set to the smaller value of the controller node (A) and the slave device node (B). Currently, if the property in the controller node is omitted, the default frequency is fixed at 500kHz. Even if the controller and the slave device allow the higher frequency than 500kHz, the maximum frequency can't exceed 500kHz. The upper limit of the maximum frequency should be determined by the clock rate of the controller clock. And this patch determines the maximum frequency based on the clock rate if the controller node property isn't specified. Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com> --- drivers/spi/designware_spi.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c index 1c7d0ca310b6..637ea57eba24 100644 --- a/drivers/spi/designware_spi.c +++ b/drivers/spi/designware_spi.c @@ -250,15 +250,13 @@ static int dw_spi_of_to_plat(struct udevice *bus) if (!plat->regs) return -EINVAL; - /* Use 500KHz as a suitable default */ + /* Specify fixed max-frequency as default */ plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", - 500000); + 0); if (dev_read_bool(bus, "spi-slave")) return -EINVAL; - dev_info(bus, "max-frequency=%d\n", plat->frequency); - return request_gpio_cs(bus); } @@ -362,12 +360,17 @@ static int dw_spi_probe(struct udevice *bus) u32 version; priv->regs = plat->regs; - priv->freq = plat->frequency; ret = dw_spi_get_clk(bus, &priv->bus_clk_rate); if (ret) return ret; + if (!plat->frequency) + plat->frequency = priv->bus_clk_rate; + + dev_info(bus, "max-frequency=%d\n", plat->frequency); + priv->freq = plat->frequency; + ret = dw_spi_reset(bus); if (ret) return ret; -- 2.25.1

2 2

[PATCH] net: phy: ncsi: fixed not nullify the pointers after free
by Jacky Chou 28 Mar '24

28 Mar '24

The issue occurs the UAF (use-after-free) to cause double free when do the realloc function for the pointers during the reinitialization NC-SI process, and it will cause the memory management occurs error. So, nullify these pointers after free. Signed-off-by: Jacky Chou <jacky_chou(a)aspeedtech.com> --- drivers/net/phy/ncsi.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/ncsi.c b/drivers/net/phy/ncsi.c index eb3fd65bb4..9689385884 100644 --- a/drivers/net/phy/ncsi.c +++ b/drivers/net/phy/ncsi.c @@ -619,9 +619,12 @@ static void ncsi_handle_aen(struct ip_udp_hdr *ip, unsigned int len) /* Link or configuration lost - just redo the discovery process */ ncsi_priv->state = NCSI_PROBE_PACKAGE_SP; - for (i = 0; i < ncsi_priv->n_packages; i++) + for (i = 0; i < ncsi_priv->n_packages; i++) { free(ncsi_priv->packages[i].channels); + ncsi_priv->packages[i].channels = NULL; + } free(ncsi_priv->packages); + ncsi_priv->packages = NULL; ncsi_priv->n_packages = 0; ncsi_priv->current_package = NCSI_PACKAGE_MAX; -- 2.34.1

2 1

[[PATCH v2]] riscv: add backtrace support
by Ben Dooks 28 Mar '24

28 Mar '24

When debugging, it is useful to have a backtrace to find out what is in the call stack as the previous function (RA) may not have been the culprit. Since this adds size to the build, do not add it by default and avoid putting it in the SPL build if not needed. Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- v2: - back to codethink email as sifive account is now gone - add option to build SPL with frame pointer (as suggested by Bo Gan <ganboing(a)gmail.com> --- arch/riscv/Kconfig | 20 ++++++++++++++++++++ arch/riscv/Makefile | 4 ++++ arch/riscv/cpu/start.S | 1 + arch/riscv/lib/interrupts.c | 35 +++++++++++++++++++++++++++++++++++ 4 files changed, 60 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 6771d8d919..a446166631 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -111,6 +111,26 @@ config ARCH_RV64I endchoice +config FRAMEPOINTER + bool "Build with frame pointer for stack unwinding" + help + Choose this option to use the frame pointer so the stack can be + unwound if needed. This is useful for tracing where faults came + from as the source may be several functions back + + If you say Y here, then the code size will be increased due to + having to store the fp. + +config SPL_FRAMEPOINTER + bool "Build SPL with frame pointer for stack unwinding" + help + Choose this option to use the frame pointer so the stack can be + unwound if needed. This is useful for tracing where faults came + from as the source may be several functions back + + If you say Y here, then the code size will be increased due to + having to store the fp. + choice prompt "Code Model" default CMODEL_MEDLOW diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 4963b5109b..0cb60c7c7e 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -45,6 +45,10 @@ endif ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \ -mcmodel=$(CMODEL) +ifeq ($(CONFIG_$(SPL_)FRAMEPOINTER),y) + ARCH_FLAGS += -fno-omit-frame-pointer +endif + PLATFORM_CPPFLAGS += $(ARCH_FLAGS) CFLAGS_EFI += $(ARCH_FLAGS) diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index 30cf674370..53de424378 100644 --- a/arch/riscv/cpu/start.S +++ b/arch/riscv/cpu/start.S @@ -419,6 +419,7 @@ call_board_init_r: */ mv a0, s3 /* gd_t */ mv a1, s4 /* dest_addr */ + mv s0, zero /* fp == NULL */ /* * jump to it ... diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c index e966afa7e3..db3d7e294b 100644 --- a/arch/riscv/lib/interrupts.c +++ b/arch/riscv/lib/interrupts.c @@ -53,6 +53,40 @@ static void show_regs(struct pt_regs *regs) #endif } +#if defined(CONFIG_FRAMEPOINTER) || defined(CONFIG_SPL_FRAMEPOINTER) +static void show_backtrace(struct pt_regs *regs) +{ + uintptr_t *fp = (uintptr_t *)regs->s0; + unsigned count = 0; + ulong ra; + + printf("backtrace:\n"); + + /* there are a few entry points where the s0 register is + * set to gd, so to avoid changing those, just abort if + * the value is the same */ + while (fp != NULL && fp != (uintptr_t *)gd) { + ra = fp[-1]; + printf("backtrace %2d: FP: " REG_FMT " RA: " REG_FMT, + count, (ulong)fp, ra); + + if (gd && gd->flags & GD_FLG_RELOC) + printf(" - RA: " REG_FMT " reloc adjusted\n", + ra - gd->reloc_off); + else + printf("\n"); + + fp = (uintptr_t *)fp[-2]; + count++; + } +} +#else +static void show_backtrace(struct pt_regs *regs) +{ + printf("No backtrace support enabled\n"); +} +#endif + /** * instr_len() - get instruction length * @@ -119,6 +153,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs *regs) epc - gd->reloc_off, regs->ra - gd->reloc_off); show_regs(regs); + show_backtrace(regs); show_code(epc); show_efi_loaded_images(epc); panic("\n"); -- 2.40.1

2 1

Re: [PATCH] mx6cuboxi: fix ethernet after synchronise device-tree
by Josua Mayer 28 Mar '24

28 Mar '24

Please hold off merging this patch until someone tested it, I can not do so this week. @Tom Can you confirm if this fixes the networking on your Cubox? Also note that the phy-handle property may or may not be required, I am not sure. sincerely Josua Mayer On Thu, Jul 28, 2022 at 7:05 AM Josua Mayer <josua(a)solid-run.com> wrote: > The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying > addresses. U-Boot needs to auto-detect which phy is actually present, > and at which address it is responding. > > Auto-detection from multiple phy nodes specified in device-tree does not > currently work correct. As a work-around merge all three possible phys > into one node with the special address 0xffffffff which indicates to the > generic phy driver to probe all addresses. > Also fixup this fake address before booting Linux, *if* booting with > U-Boot's internal dtb. > > Signed-off-by: Josua Mayer <josua(a)solid-run.com> > Fixes: d0399a46e7cd > --- > arch/arm/dts/imx6qdl-sr-som.dtsi | 30 +++++++++------------------- > board/solidrun/mx6cuboxi/mx6cuboxi.c | 6 +++++- > 2 files changed, 14 insertions(+), 22 deletions(-) > > diff --git a/arch/arm/dts/imx6qdl-sr-som.dtsi > b/arch/arm/dts/imx6qdl-sr-som.dtsi > index ce543e325c..2d7cbc26b3 100644 > --- a/arch/arm/dts/imx6qdl-sr-som.dtsi > +++ b/arch/arm/dts/imx6qdl-sr-som.dtsi > @@ -53,6 +53,7 @@ > &fec { > pinctrl-names = "default"; > pinctrl-0 = <&pinctrl_microsom_enet_ar8035>; > + phy-handle = <&phy>; > phy-mode = "rgmii-id"; > > /* > @@ -68,30 +69,17 @@ > #address-cells = <1>; > #size-cells = <0>; > > - /* > - * The PHY can appear at either address 0 or 4 due to the > - * configuration (LED) pin not being pulled sufficiently. > - */ > - ethernet-phy@0 { > - reg = <0>; > + phy: ethernet-phy@0 { > + /* > + * The PHY can appear either: > + * - AR8035: at address 0 or 4 > + * - ADIN1300: at address 1 > + * Actual address being detected at runtime. > + */ > + reg = <0xffffffff>; > qca,clk-out-frequency = <125000000>; > qca,smarteee-tw-us-1g = <24>; > - }; > - > - ethernet-phy@4 { > - reg = <4>; > - qca,clk-out-frequency = <125000000>; > - qca,smarteee-tw-us-1g = <24>; > - }; > - > - /* > - * ADIN1300 (som rev 1.9 or later) is always at address 1. > It > - * will be enabled automatically by U-Boot if detected. > - */ > - ethernet-phy@1 { > - reg = <1>; > adi,phy-output-clock = "125mhz-free-running"; > - status = "disabled"; > }; > }; > }; > diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c > b/board/solidrun/mx6cuboxi/mx6cuboxi.c > index debf4f6a3b..52172a03b1 100644 > --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c > +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c > @@ -446,7 +446,7 @@ static int find_ethernet_phy(void) > */ > int ft_board_setup(void *fdt, struct bd_info *bd) > { > - int node_phy0, node_phy1, node_phy4; > + int node_phy, node_phy0, node_phy1, node_phy4; > int ret, phy; > bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false; > enum board_type board; > @@ -478,6 +478,10 @@ int ft_board_setup(void *fdt, struct bd_info *bd) > return 0; > } > > + // update U-Boot's own unified phy node phy address, if present > + node_phy = fdt_path_offset(fdt, "/soc/bus@2100000/ethernet@2188000 > /mdio/phy"); > + ret = fdt_setprop_u32(fdt, node_phy, "reg", phy); > + > // update all phy nodes status > node_phy0 = fdt_path_offset(fdt, "/soc/bus@2100000 > /ethernet@2188000/mdio/ethernet-phy@0"); > ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? > "okay" : "disabled"); > -- > 2.37.1 > >

4 11

[BUG] fdt_pack_reg in common/fdt_support.c can cause crash from unaligned access
by David Virag 27 Mar '24

27 Mar '24

Hi, I'm trying to port U-Boot to a new board (Samsung JACKPOTLTE, ARMv8, Exynos7885) but when CONFIG_ARCH_FIXUP_FDT_MEMORY is enabled, the bootm command leads to an unaligned memory access, which results in a synchronous abort. After a long debugging session, I concluded that fdt_pack_reg in common/fdt_support.c writes to unaligned addresses in its for loop. In the case of address_cells being 2, and size_cells being 1, the buffer pointer gets incremented by 12 in each loop, making the second iteration (i=1) write a 64bit value to a non 64bit aligned address. Turning the alignment check enable bit (A) off in SCTLR makes the function work as intended. I couldn't find code that touches this bit, but I may have missed something. I don't think writing in two parts should be the fix, but something should be done about this. As far as I understand, any arm64 board that has this bit turned on, either from previous code or just the initial status of the bit after power on, could crash here. This is on top of the latest commit as of now (0beb649053b86b2cfd5cf55a0fc68bc2fe91a430) What should be done here? Best regards, David

4 6

[PATCH v6 0/3] BOOTP/DHCPv4 enhancements
by Sean Edmond 27 Mar '24

27 Mar '24

In our datacenter application, a single DHCP server is servicing 36000+ clients. Improvements are required to the DHCPv4 retransmission behavior to align with RFC and ensure less pressure is exerted on the server: - retransmission backoff interval maximum is configurable (environment variable bootpretransmitperiodmax) - initial retransmission backoff interval is configurable (environment variable bootpretransmitperiodinit) - transaction ID is kept the same for each BOOTP/DHCPv4 request (not recreated on each retry) For our application we'll use: - bootpretransmitperiodmax=16000 - bootpretransmitperiodinit=2000 A new configuration BOOTP_RANDOM_XID has been added to enable a randomized BOOTP/DHCPv4 transaction ID. Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous patch was accepted. A new patch fixes a possible double free() and addresses latest review comments. Changes in v6: - CMD_BOOTP should "depends on LIB_RAND || LIB_HW_RAND" Changes in v5: - add change log to individual patches - fix depends for BOOTP_RANDOM_XID: "depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)" Changes in v4: - rebase master and resolve conflicts - default y for BOOTP_PXE_DHCP_OPTION (feedback from review) - Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission improvements require rand()) Changes in v3: - add define for option 209 and rfc5071 reference - Set RETRANSMIT_PERIOD_MAX_MS=60000 - Add randomization factor to retransmission timeout - Add depends for BOOTP_RANDOM_XID Changes in v2: - use env_get_ulong() to get environment variables Sean Edmond (3): net: Enhancements for dhcp option 209 net: bootp: BOOTP/DHCPv4 retransmission improvements net: bootp: add config option BOOTP_RANDOM_XID cmd/Kconfig | 10 ++++++- cmd/pxe.c | 2 ++ net/bootp.c | 76 +++++++++++++++++++++++++++++++++++++++++------------ net/bootp.h | 2 ++ 4 files changed, 72 insertions(+), 18 deletions(-) -- 2.42.0

2 4

bugs with EFI "reserved" memory and LMB?
by Emanuele Ghidoli 25 Mar '24

25 Mar '24

Efi loader module have its own memory management that flags as reserved the area between ram_top to ram_end (currently where dt reserved-memory is falling). uboot lmb updates reserved-memory by adding these efi loader module areas (see lmb_reserve_common->efi_lmb_reserve). On our system (AM62xx SoC, 512MB RAM) we have some reserved-memory specified in the device tree (used for comunication with other microcontroller on the SoC, OPTEE, ...) falling in the DDR range between 456 and 512 MB. Normally U-Boot relocate itself at the end of DDR so it overlap this reserved-memory and this of course does not work [1]. In this case U-Boot prints the following errors: ERROR: reserving fdt memory region failed (addr=9c800000 size=300000) ERROR: reserving fdt memory region failed (addr=9cb00000 size=100000) ... ERROR: reserving fdt memory region failed (addr=9e800000 size=1800000) because U-Boot reserved area (lmb_flag LMB_NONE) overlaps with the FDT reserve memories (lmb_flag LMB_NOMAP). To fix this I moved the U-Boot relocation address, implementing board_get_usable_ram_top() and therefore setting gd->ram_top to a lower value with no overlap (448 MB). The memory map is: +---------------+ 512 MB |DT reserved-mem| +---------------+ 456 MB |free space | +---------------+ 448 MB (ram_top) | | |uboot | | | +---------------+ 0 MB This is working fine (the board is able to boot, no memory overlaps) ... however, in this configuration U-Boot we still have some errors prints while loading linux dtb: ERROR: reserving fdt memory region failed (addr=9cb00000 size=100000 flags=4) ERROR: reserving fdt memory region failed (addr=9cc00000 size=e00000 flags=4) ERROR: reserving fdt memory region failed (addr=9da00000 size=100000 flags=4) ERROR: reserving fdt memory region failed (addr=9db00000 size=c00000 flags=4) ERROR: reserving fdt memory region failed (addr=9e780000 size=80000 flags=4) ERROR: reserving fdt memory region failed (addr=9e800000 size=1800000 flags=4) And the reason of these error is complete different: The efi loader lmb memory reservation (lib/lmb.c:efi_lmb_reserve()) is wrongly reserving some area. 1) lib/lmb.c:lmb_reserve_common() reserve these memories: ~415M - 448M u-boot reserved area (lmb_flag LMB_NONE) 456M - 512M fdt reserved-memory (lmb_flag LMB_NOMAP) 2) lib/lmb.c:efi_lmb_reserve() reserve a region just before u-boot reserved area. This is not coalesced/merged with the u-boot reserved area because it is not contiguous. This is the reserved-memory array at this point: ~414M - ~414M efi loader reserved area (lmb_flag LMB_NONE) ~415M - 448M u-boot reserved area (lmb_flag LMB_NONE) 456M - 512M fdt reserved-memory (lmb_flag LMB_NOMAP) 3) lib/lmb.c:efi_lmb_reserve() reserve some more areas. In the last two steps efi loader add some reserved area that overlap u-boot and fdt reserved area BUT they are also contiguous to the "efi loader reserved area". The very last step reserve also area between ram_top (448M) to ram_end (512M) We fall in this condition (where we have overlapping areas!): ~414M - 512M efi loader reserved area (lmb_flag LMB_NONE) ~415M - 448M u-boot reserved area (lmb_flag LMB_NONE) 456M - 512M fdt reserved-memory (lmb_flag LMB_NOMAP) 4) Now, while loading the linux fdt the reserved-memory areas are checked toward efi loader reserved area, they overlap, BUT they have different lmb_flag. So we get the ERROR print. Hopefully this is clear, I undestand is not that obvious ... IMO we have two different bugs: - there is nothing that prevent that coalesced area may overlap other areas (while lmb module expect that there aren't overlapping areas) - efi loader (correctly) reserve between ram_top and ram_end BUT this area is reserved by fdt. One potential solution could be to override efi_add_known_memory() and set ram_top = ram_end, e.g. - efi_add_conventional_memory_map(ram_start, ram_end, ram_top); + efi_add_conventional_memory_map(ram_start, ram_end, ram_end); but this does not really seems like something that should ve overridden at the board level. Any suggestion? Emanuele

3 4

[PATCH 0/2] Reduce the complexity of add_map() and count_required_pts()
by Ying-Chun Liu (PaulLiu) 18 Mar '24

18 Mar '24

Reduce the complexity of add_map() and count_required_pts() to gain better performance. Marc Zyngier (2): arm64: Reduce add_map() complexity arm64: Reduce PT size estimation complexity arch/arm/cpu/armv8/cache_v8.c | 201 +++++++++++++--------------------- 1 file changed, 79 insertions(+), 122 deletions(-) -- 2.39.1

6 18

[PATCH v6 1/3] dt-bindings: mtd: partitions: Add binman compatible
by Simon Glass 14 Mar '24

14 Mar '24

Add a compatible string for binman, so we can extend fixed-partitions in various ways. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- (no changes since v5) Changes in v5: - Add #address/size-cells and parternProperties - Drop $ref to fixed-partitions.yaml - Drop 'select: false' Changes in v4: - Change subject line Changes in v3: - Drop fixed-partition additional compatible string - Drop fixed-partitions from the example - Mention use of compatible instead of label Changes in v2: - Drop mention of 'enhanced features' in fixed-partitions.yaml - Mention Binman input and output properties - Use plain partition@xxx for the node name .../bindings/mtd/partitions/binman.yaml | 68 +++++++++++++++++++ .../bindings/mtd/partitions/partitions.yaml | 1 + MAINTAINERS | 5 ++ 3 files changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml new file mode 100644 index 000000000000..329217550a98 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2023 Google LLC + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binman firmware layout + +maintainers: + - Simon Glass <sjg(a)chromium.org> + +description: | + The binman node provides a layout for firmware, used when packaging firmware + from multiple projects. It is based on fixed-partitions, with some + extensions, but uses 'compatible' to indicate the contents of the node, to + avoid perturbing or confusing existing installations which use 'label' for a + particular purpose. + + Binman supports properties used as inputs to the firmware-packaging process, + such as those which control alignment of partitions. This binding addresses + these 'input' properties. For example, it is common for the 'reg' property + (an 'output' property) to be set by Binman, based on the alignment requested + in the input. + + Once processing is complete, input properties have mostly served their + purpose, at least until the firmware is repacked later, e.g. due to a + firmware update. The 'fixed-partitions' binding should provide enough + information to read the firmware at runtime, including decompression if + needed. + + Documentation for Binman is available at: + + https://u-boot.readthedocs.io/en/latest/develop/package/binman.html + + with the current image-description format at: + + https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-d… + +properties: + compatible: + const: binman + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + "^partition(-.+|@[0-9a-f]+)$": + $ref: partition.yaml + +additionalProperties: false + +examples: + - | + partitions { + compatible = "binman"; + #address-cells = <1>; + #size-cells = <1>; + + partition@100000 { + label = "u-boot"; + reg = <0x100000 0xf00000>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml index 1dda2c80747b..849fd15d085c 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partitions.yaml @@ -15,6 +15,7 @@ maintainers: oneOf: - $ref: arm,arm-firmware-suite.yaml + - $ref: binman.yaml - $ref: brcm,bcm4908-partitions.yaml - $ref: brcm,bcm947xx-cfe-partitions.yaml - $ref: fixed-partitions.yaml diff --git a/MAINTAINERS b/MAINTAINERS index b294edaf5698..8704eefe6e2a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3550,6 +3550,11 @@ F: Documentation/filesystems/bfs.rst F: fs/bfs/ F: include/uapi/linux/bfs_fs.h +BINMAN +M: Simon Glass <sjg(a)chromium.org> +S: Supported +F: Documentation/devicetree/bindings/mtd/partitions/binman* + BITMAP API M: Yury Norov <yury.norov(a)gmail.com> R: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> -- 2.43.0.rc0.421.g78406f8d94-goog

3 20