October 2023 - U-Boot

[RFC PATCH 0/5] Move video memory reservation for SPL at the end of RAM
by Devarsh Thakkar 26 Oct '23

26 Oct '23

Move video memory reservation for SPL at end of RAM so that it does not interefere with reservations for next stage so that the next stage need not have holes in between for passed regions and instead it can maintain continuity in reservations. Also catch the bloblist before starting reservations to avoid the same problem. While at it, also fill missing fields in video handoff struct before passing it to next stage. This is as per discussions at : For moving SPL framebuffer reservation at end of RAM: https://lore.kernel.org/all/CAPnjgZ3xSoe_G3yrqwuAvoiVjUfZ+YQgkOR0ZTVXGT9VK8… For filling missing video handoff fields : https://lore.kernel.org/all/CAPnjgZ1Hs0rNf0JDirp6YPsOQ5=QqQSP9g9qRwLoOASUV8… *** SUBJECT HERE *** Devarsh Thakkar (5): arm: mach-k3: common: Reserve video memory from end of the RAM board: ti: am62x: evm: Remove video_setup from spl_board_init common/board_f: Catch bloblist before starting resevatinos video: Skip framebuffer reservation if already reserved video: Fill video handoff in video post probe arch/arm/mach-k3/common.c | 21 +++++++++++++++++++++ board/ti/am62x/evm.c | 18 ------------------ common/board_f.c | 36 +++++++++++++++++++++++++++++++++--- drivers/video/video-uclass.c | 33 +++++++++++++++++++++++---------- 4 files changed, 77 insertions(+), 31 deletions(-) -- 2.34.1

3 9

Starting kernel invokes "Synchronous Abort" - rk3328
by Konstantin Kletschke 26 Oct '23

26 Oct '23

Dear u-boot community, I have a rockchip rk3328 Board here I am trying to boot linux kernel upon. It is a Dusun DSGW-210 which seems to resemble the setup board=evb_rk3328 board_name=evb_rk3328 Dusun offers a SDK which they claim to be working in their system, the rootfs can be a debian or a buildroot one. I can not compile it (Host needs to be darn old, I got stuck realizing python2 with ftdi libs is required). Reagardeless I want to port their stuff to yocto linux anyway and since the u-boot an kernel config resemble vanilla evb_rk3328 setup and config I thought it should not be too hard. But it is. For me. I used the JeffyCN yocto meta layer, compiled it and flashed the images. And voila, u-boot seems to work fine! When U-boot starts the kernel I get "Synchronous Abort" handler, esr 0x02000000 The output looks this way: => boot Could not find misc partition ANDROID: reboot reason: "(none)" Not AVB images, AVB skip Booting IMAGE kernel at 0x00280000 with fdt at 0x08300000... Fdt Ramdisk skip relocation No misc partition ## Booting Android Image at 0x0027f800 ... Kernel: 0x00280000 - 0x00af2957 (8651 KiB) ## Flattened Device Tree blob at 0x08300000 Booting using the fdt blob at 0x08300000 XIP Kernel Image from 0x00280000 to 0x00280000 ... OK kernel loaded at 0x00280000, end = 0x00af2957 Using Device Tree in place at 0000000008300000, end 00000000083156fd WARNING: could not set reg FDT_ERR_BADOFFSET. ## reserved-memory: drm-logo@00000000: addr=7df00000 size=b8000 Adding bank: 0x00200000 - 0x08400000 (size: 0x08200000) Adding bank: 0x0a200000 - 0x80000000 (size: 0x75e00000) == DO RELOCATE == Kernel from 0x00280000 to 0x00200000 Total: 126428.23/126891.316 ms Starting kernel ... "Synchronous Abort" handler, esr 0x02000000 The decoded stackdump looks like this: ./scripts/stacktrace.sh stackdump SYMBOL File: ./u-boot.sym Call trace: PC: [< ffffffff8278f004 >] LR: [< 00201d90 >] do_bootm_linux+0x5c/0x74 /home/konsti/Dusun/yocto-JeffyCN/build/tmp/work/dsgw_210-poky-linux/u-boot-rockchip/1_2017.09-r0/git/arch/arm/lib/bootm.c:498 Stack: [< ffffffff8278f004 >] [< 0021757c >] boot_selected_os+0x48/0x80 [< 00216fbc >] do_bootm_states+0x8d0/0x950 [< 00226c44 >] android_bootloader_boot_kernel+0x15c/0x250 [< 00227918 >] android_bootloader_boot_flow+0x2a0/0x2a4 [< 00207970 >] do_boot_android+0xd0/0xf8 [< 0022c104 >] cmd_process+0xdc/0x10c [< 00215284 >] run_list_real+0x6e4/0x728 [< 00215438 >] parse_stream_outer+0x170/0x66c [< 00214b88 >] parse_string_outer+0xcc/0xe4 [< 0021513c >] run_list_real+0x59c/0x728 [< 00215438 >] parse_stream_outer+0x170/0x66c [< 00214b4c >] parse_string_outer+0x90/0xe4 [< 0022b628 >] run_command_list+0x50/0x90 [< 00215ad8 >] autoboot_command+0x40/0x114 [< 00213984 >] main_loop+0x58/0x68 [< 00216150 >] run_main_loop+0xc/0x10 [< 0027c46c >] initcall_run_list+0x58/0x94 [< 00216364 >] board_init_r+0x20/0x24 [< 00201940 >] relocation_return+0x4/0x0 PC Surrounding Instructions: ./make.sh: line 418: -D: command not found I kindly ask, what could be the culprit? What should I do next to further debug the issue? What I especiall wonder is what does "WARNING: could not set reg FDT_ERR_BADOFFSET." mean, is this harmful or leading to the root cause? I have full boot logs for the working Dusun u-boot and my u-boot available, is it from interest or helpful to post them here completely to compare? Also I found one - may be significant - difference: My u-boot says: Model: Rockchip RK3328 EVB MPIDR: 0x80000000 PreSerial: 2, raw, 0xff130000 DRAM: 2 GiB Sysmem: init Relocation Offset: 7da71000 Relocation fdt: 7bc664a8 - 7bc67ce2 CR: M/C/I Using default environment The Dusun u-boot says: Model: Rockchip RK3328 EVB MPIDR: 0x80000000 PreSerial: 2, raw, 0xff130000 DRAM: 2 GiB Sysmem: init Relocation Offset: 7da71000 Relocation fdt: 7bc664a8 - 7bc67ce2 CR: M/C/I Using default environment Is the difference in "Relocation Offset" my problem? Other Addresses appearing look similair in my u-boot like the Dusun u-boot (kernel load addr, RAM banks added, device tree addresses...). Kind Regards Konstantin Kletschke -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Strasse 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletschke(a)inside-m2m.de http://www.inside-m2m.de Gesch"aftsf"uhrung: Michael Emmert, Derek Uhlig HRB: 111204, AG Hannover

1 1

[RESEND PATCH] board: ti: common: board_detect: Fix EEPROM offset read for 1-byte
by Prasanth Babu Mantena 26 Oct '23

26 Oct '23

EEPROM detection logic in ti_i2c_eeprom_get() involves reading the total size followed by reading 1-byte size with an offset 1. This commit fixes the header matching issue in commit 9f393a2d7af8 ("board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte"). In the previous commit, the value with one offset is being read into offset_test, but the pointer used to match was still ep. After reading with an offset 1, the second byte of the header is compared with the 1-byte data read from EEPROM. This is taken care by comparing proper first byte value from the header. Signed-off-by: Prasanth Babu Mantena <p-mantena(a)ti.com> Fixes: 9f393a2d7af8 (board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte) --- Resending due to incorrect patch tag last time. board/ti/common/board_detect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c index 9a53884c98..17fe8f8069 100644 --- a/board/ti/common/board_detect.c +++ b/board/ti/common/board_detect.c @@ -128,7 +128,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr, rc = dm_i2c_read(dev, 0x1, &offset_test, sizeof(offset_test)); - if (*((u32 *)ep) != (header & 0xFF)) + if (offset_test != ((header >> 8) & 0xFF)) one_byte_addressing = false; /* Corrupted data??? */ -- 2.39.0

5 5

Setting PMIC regulator voltage in U-Boot SPL, to specify DDR voltage
by Chris Richardson 26 Oct '23

26 Oct '23

Hi, I'm working on a board with an Allwinner H6 that uses an AXP805 PMIC. I'm using DDR3-1600, which requires 1.4V. In my boot.cmd, I am doing the following - regulator dev dcdce regulator value 1400000 regulator enable To set the voltage to 1.4V in U-Boot proper, this avoids memory issues, such as random resets. However what I would like to do is to set the regulator voltage in U-Boot SPL, so that the voltage would be set ideally before memory size detection etc. To do this I thought I needed to enable features such as 'CONFIG_SPL_DM'. I've listed the main configuration I used below - ... CONFIG_DM=y CONFIG_SPL=y CONFIG_SPL_DM=y CONFIG_MACH_SUN50I_H6=y CONFIG_SUNXI_DRAM_H6_DDR3_1333=y CONFIG_DRAM_CLK=648 CONFIG_SYS_I2C_MVTWSI=y CONFIG_SPL_I2C=y CONFIG_DM_I2C=y CONFIG_CMD_I2C=y CONFIG_POWER=y CONFIG_POWER_I2C=y CONFIG_PMIC_CHILDREN=y CONFIG_DM_PMIC=y CONFIG_SPL_DM_PMIC=y CONFIG_PMIC_AXP=y CONFIG_SPL_PMIC_AXP=y CONFIG_CMD_PMIC=y CONFIG_CMD_REGULATOR=y CONFIG_AXP_PMIC_BUS=y CONFIG_DM_REGULATOR=y CONFIG_SPL_DM_REGULATOR=y CONFIG_CMD_REGULATOR=y CONFIG_REGULATOR_AXP=y CONFIG_SPL_REGULATOR_AXP=y ... Currently I am overflowing SRAM - aarch64-linux-gnu-ld.bfd: address 0x2a868 of u-boot-spl section `.text' is not within region `.sram' aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram' aarch64-linux-gnu-ld.bfd: address 0x2a868 of u-boot-spl section `.text' is not within region `.sram' aarch64-linux-gnu-ld.bfd: address 0x2a868 of u-boot-spl section `.text' is not within region `.sram' aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 22296 bytes I'm just wondering if anyone has any suggestions? Also I wasn't sure, if I can get the AXP PMIC supported in SPL, how I'd set the voltage in U-Boot SPL? Many thanks Chris Blue Chip Technology Ltd is a company registered in England and Wales. Registered number: 03110403 Registered office: Chowley Oak Lane, Chester, CH3 9EX.

1 0

[PATCH] mmc: tmio: Disable 1/1024 clock divider on Renesas R-Car platforms
by Marek Vasut 26 Oct '23

26 Oct '23

The R-Car Gen3 SD_CLK_CTRL register does not use BIT(16) to implement divider 1/1024, instead BIT(16) is reserved bit and divider 1/1024 is not supported. The divider 1/1024 is specific to Socionext variant of the IP, as is indicated by Linux commit: 0196c8db8363 ("mmc: tmio: move tmio_mmc_set_clock() to platform hook") " Socionext (and Panasonic) uses bit 10 (CLKSEL) for 1/1. Also, newer versions of UniPhier SoC variants use bit 16 for 1/1024. " Do not set the TMIO_SD_CAP_DIV1024 on Renesas R-Car platforms even if the IP VERSION register does exist, and indicates IP version is newer or equal to version 1.0 . The IP version 1.0 or newer does not imply presence of the 1/1024 divider. Since the TMIO driver is used exactly by two supported platforms, that is Renesas R-Car and Socionext UniPhier, it is OK to check whether the TMIO_SD_CAP_RCAR capability is not set to identify the UniPhier platform and add the capability only on that platform. Fixes: 58c35b17aa8f ("mmc: matsushita-common: Always check controller version") Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: Jaehoon Chung <jh80.chung(a)samsung.com> Cc: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> Cc: Paul Barker <paul.barker.ct(a)bp.renesas.com> Cc: Peng Fan <peng.fan(a)nxp.com> --- drivers/mmc/tmio-common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c index 83eaf361f0c..890c496b535 100644 --- a/drivers/mmc/tmio-common.c +++ b/drivers/mmc/tmio-common.c @@ -759,7 +759,8 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks) dev_dbg(dev, "version %x\n", priv->version); if (priv->version >= 0x10) { priv->caps |= TMIO_SD_CAP_DMA_INTERNAL; - priv->caps |= TMIO_SD_CAP_DIV1024; + if (!(priv->caps & TMIO_SD_CAP_RCAR)) + priv->caps |= TMIO_SD_CAP_DIV1024; } if (fdt_get_property(gd->fdt_blob, dev_of_offset(dev), "non-removable", -- 2.42.0

3 2

[PATCH] mmc: tmio: Always check for errors after receiving an IRQ
by Marek Vasut 26 Oct '23

26 Oct '23

Unconditionally check for errors even after successful reception of IRQ flag, since the hardware may set both an IRQ completion flag and an error flag at the same time. This mode of failure happens in case of an error during transfer, in which case the hardware may set the expected IRQ completion flag as well as error flags. The later is currently not checked by the driver and such an error is not detected. Improve the error detection. Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: Jaehoon Chung <jh80.chung(a)samsung.com> Cc: Nobuhiro Iwamatsu <iwamatsu(a)nigauri.org> Cc: Peng Fan <peng.fan(a)nxp.com> --- drivers/mmc/tmio-common.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c index d1e26815996..83eaf361f0c 100644 --- a/drivers/mmc/tmio-common.c +++ b/drivers/mmc/tmio-common.c @@ -122,7 +122,10 @@ static int tmio_sd_wait_for_irq(struct udevice *dev, struct mmc_cmd *cmd, long wait = 1000000; int ret; - while (!(tmio_sd_readl(priv, reg) & flag)) { + while (true) { + if (tmio_sd_readl(priv, reg) & flag) + return tmio_sd_check_error(dev, cmd); + if (wait-- < 0) { dev_err(dev, "timeout\n"); return -ETIMEDOUT; -- 2.42.0

2 1

[REGRESSION] imx: spl_imx_romapi: boot loops
by Marcel Ziswiler 26 Oct '23

26 Oct '23

Hi On our weekly master upstream CI build we noticed Verdin iMX8M Plus boot looping. Bisecting pointed to the following commit: commit 4b4472438f5a ("imx: spl_imx_romapi: avoid tricky use of spl_load_simple_fit() to get full FIT size") It looks like this introduced a regression. Before and after console output (with DEBUG defined in arch/arm/mach-imx/spl_imx_romapi.c) below: Any comments? Cheers Marcel Before: U-Boot SPL 2023.10-00969-g9960d4a5402-dirty (Oct 24 2023 - 09:20:03 +0200) Training FAILED DDR configured as single rank SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) Trying to boot from BOOTROM Boot Stage: Primary boot Find img info 0x4802b000, size 1044 Need continue download 1024 Download 932864, Total size 934544 NOTICE: Do not release JR0 to NS as it can be used by HAB NOTICE: BL31: v2.9(release):v2.9.0-619-g5f01b0b11 NOTICE: BL31: Built : 11:08:02, Sep 6 2023 U-Boot 2023.10-00969-g9960d4a5402-dirty (Oct 24 2023 - 09:20:03 +0200) CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz) [snip] After (e.g. commit 4b4472438f5 or master): U-Boot SPL 2024.01-rc1-dirty (Oct 24 2023 - 09:28:26 +0200) Training FAILED DDR configured as single rank SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout) Trying to boot from BOOTROM Boot Stage: Primary boot Find img info 0x4802b000, size 1044 Need continue download 1024 downloading another 0xc9000 bytes downloading another 0x1ae00 bytes => this crash/resets and boot loops forever

3 10

[PATCH] smbios: arm64: Allow table to be written at a fixed addr
by Simon Glass 26 Oct '23

26 Oct '23

U-Boot typically sets up its malloc() pool near the top of memory. On ARM64 systems this can result in an SMBIOS table above 4GB which is not supported by SMBIOSv2. Work around this problem by providing a new option to choose an address just below 4GB, if needed. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- lib/Kconfig | 17 +++++++++++++++++ lib/efi_loader/efi_smbios.c | 12 ++++++++++++ 2 files changed, 29 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index f6ca559897e7..a77f2f3e9089 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -994,6 +994,23 @@ config GENERATE_SMBIOS_TABLE See also SMBIOS_SYSINFO which allows SMBIOS values to be provided in the devicetree. +config SMBIOS_TABLE_FIXED + bool "Place the SMBIOS table at a special address" + depends on GENERATE_SMBIOS_TABLE && ARM64 && SMBIOS && EFI_LOADER + default y + help + Use this option to place the SMBIOS table at a fixed address. + + U-Boot typically sets up its malloc() pool near the top of memory. On + ARM64 systems this can result in an SMBIOS table above 4GB which is + not supported by SMBIOSv2. This option works around this problem by + chosing an address just below 4GB, if needed. + +config SMBIOS_TABLE_FIXED_ADDR + hex "Fixed address for use for SMBIOS table" + depends on SMBIOS_TABLE_FIXED + default 0xffff0000 + endmenu config LIB_RATIONAL diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c index 48446f654d9b..84ea027ea48c 100644 --- a/lib/efi_loader/efi_smbios.c +++ b/lib/efi_loader/efi_smbios.c @@ -61,6 +61,18 @@ static int install_smbios_table(void) return log_msg_ret("mem", -ENOMEM); addr = map_to_sysmem(buf); + + /* + * Deal with a fixed address if needed. For simplicity we assume that + * the SMBIOS-table size is <64KB and that the malloc region does not + * straddle the 4GB boundary. + */ + if (IS_ENABLED(CONFIG_SMBIOS_TABLE_FIXED) && addr >= SZ_4G - SZ_64K) { + addr = IF_ENABLED_INT(CONFIG_SMBIOS_TABLE_FIXED, + CONFIG_SMBIOS_TABLE_FIXED_ADDR); + log_warning("Forcing SMBIOS table to address %lx\n", addr); + } + if (!write_smbios_table(addr)) { log_err("Failed to write SMBIOS table\n"); return log_msg_ret("smbios", -EINVAL); -- 2.42.0.655.g421f12c284-goog

5 18

[PATCH v6 1/3] dt-bindings: mtd: partitions: Add binman compatible
by Simon Glass 25 Oct '23

25 Oct '23

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 2d13bbd69adb..b9441eec979a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3542,6 +3542,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.42.0.758.gaed0368e0e-goog

1 2

[PATCH v4 1/3] dt-bindings: mtd: partitions: Add binman compatible
by Simon Glass 25 Oct '23

25 Oct '23

Add a compatible string for binman, so we can extend fixed-partitions in various ways. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- 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 | 63 +++++++++++++++++++ .../bindings/mtd/partitions/partitions.yaml | 1 + MAINTAINERS | 5 ++ 3 files changed, 69 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..7d6c8bd738f5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml @@ -0,0 +1,63 @@ +# 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> + +select: false + +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… + +allOf: + - $ref: /schemas/mtd/partitions/fixed-partitions.yaml# + +properties: + compatible: + const: binman + +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 c934244acc31..ebc8158fe67d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3536,6 +3536,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.42.0.609.gbb76f46606-goog

3 8