August 2023 - U-Boot

[PATCH 1/1] lmb: description lmb_is_reserved, lmb_is_reserved_flags
by Heinrich Schuchardt 12 Aug '23

12 Aug '23

* provide a description for function lmb_is_reserved() * improve the description of funciton lmb_is_reserved_flags() Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- include/lmb.h | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/include/lmb.h b/include/lmb.h index 07bf22144e..0365c9ef1f 100644 --- a/include/lmb.h +++ b/include/lmb.h @@ -116,16 +116,32 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong align, phys_addr_t max_addr); phys_addr_t lmb_alloc_addr(struct lmb *lmb, phys_addr_t base, phys_size_t size); phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t addr); + +/** + * lmb_is_reserved_flags() - test if address is in reserved region + * + * The function checks if a reserved region comprising @addr exists. + * flag bits set that are set in @flags. + * + * @lmb: the logical memory block struct + * @addr: address to be tested + * Return: 1 if reservation exists, 0 otherwise + */ int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr); + /** - * lmb_is_reserved_flags - test if tha address is in reserved region with a bitfield flag + * lmb_is_reserved_flags() - test if address is in reserved region with flag bits set + * + * The function checks if a reserved region comprising @addr exists which has + * all flag bits set which are set in @flags. * * @lmb: the logical memory block struct * @addr: address to be tested - * @flags: flags bitfied to be tested - * Return: if not reserved or reserved without the requested flag else 1 + * @flags: bitmap with bits to be tested + * Return: 1 if matching reservation exists, 0 otherwise */ int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t addr, int flags); + long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size); void lmb_dump_all(struct lmb *lmb); -- 2.40.1

2 1

[PATCH v3 0/4] General regulator and pmic uclass improvements
by Svyatoslav Ryhel 12 Aug '23

12 Aug '23

This patchset derives from discussion of TPS65913 bringup and aims to cycle all regulator management inside uclass removing need of any board calls for regulators. My hw setup is Tegra 3 LG Optimus Vu P895 (PMIC is MAX77663) with native spl u-boot build. power: regulator: expand basic reference counter onto all uclass Commit is basically expansion of 4fcba5d ("regulator: implement basic reference counter") onto all regulators. My testing on hw has shown no issues so far with both pmic regulators and fixed regulators. Counting works as expected, dm test is set in test of regulator_set_enable_if_allowed. power: regulator-uclass: perform regulator setup inside uclass All regulators with always-on or boot-on are set to probe after bind which ensures that essential regulators are set. In the post probe regulator autoset is called so that correct regulator state according to device tree is reached. DM test is set by checking regulators data without pre-configuring them manually. --- Changes from v2: - dropped changes related to pmic (pmic regulator probing on pmic post bind) - regulator uclass changes are dropped to minimum to remain compatibility: - always-on and boot-on check is moved to post bind - regulator_autoset is called on post_probe - adjusted dm tests to pass with this changes Changes from v1: - adapted description of regulator_set_enable - remove uc_pdata->enable_count from post_probe - added tests from counter and regulators post_probe --- Svyatoslav Ryhel (4): power: regulator: expand basic reference counter onto all uclass test: dm: regulator: test counter in set_enable_if_allowed test power: regulator: Perform regulator setup inside uclass test: dm: regulator: provide test of auto setup drivers/power/regulator/regulator-uclass.c | 71 ++++++++++++++++++++-- drivers/power/regulator/regulator_common.c | 22 ------- drivers/power/regulator/regulator_common.h | 21 ------- include/power/regulator.h | 2 + test/dm/regulator.c | 27 +++++++- 5 files changed, 92 insertions(+), 51 deletions(-) -- 2.39.2

1 5

[PATCH v10 00/10] Enable EFI capsule generation through binman
by Sughosh Ganu 12 Aug '23

12 Aug '23

This patch series adds support for generation of EFI capsules as part of U-Boot build flow. The capsules can be generated as part of U-Boot build, and this is being achieved through binman, by adding a capsule entry type. The parameters needed for capsule generation are specified as properties under the capsule entry node. Changes have also been made to the efi capsule update feature testing setup on the sandbox variants. Currently, the capsule files and the keys for testing capsule authentication are generated after U-Boot has been built. As part of this patch series, the private and public keys along with the EFI Signature List(ESL) needed for testing the capsule update functionality on the sandbox plaform are placed in the board directory. The test logic has been changed so that the capsules which were generated as part of the test setup are now being generated as part of the build for sandbox platform. The document has been updated to reflect the above changes. Changes since V9: * s/u-boot/U-Boot/ * Add a link to the binman capsule entry type documentation as suggested by Simon Glass. Sughosh Ganu (10): binman: bintool: Build a tool from a list of commands nuvoton: npcm845-evb: Add a newline at the end of file sandbox: capsule: Add keys and certificates needed for capsule update testing sandbox: capsule: Enable EFI capsule module on sandbox variants btool: mkeficapsule: Add a bintool for EFI capsule generation binman: capsule: Add support for generating EFI capsules sandbox: binman: Add support for generating multiple images sandbox: capsule: Generate capsule related files through binman doc: Add documentation to highlight capsule generation related updates sandbox: trace: Increase trace buffer size .azure-pipelines.yml | 2 +- .gitlab-ci.yml | 2 +- arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- arch/sandbox/dts/sandbox.dts | 3 + arch/sandbox/dts/sandbox_capsule.dtsi | 315 ++++++++++++++++++ arch/sandbox/dts/sandbox_vpl.dtsi | 5 + arch/sandbox/dts/test.dts | 3 + board/sandbox/capsule_priv_key_bad.key | 28 ++ board/sandbox/capsule_priv_key_good.key | 28 ++ board/sandbox/capsule_pub_esl_good.esl | Bin 0 -> 831 bytes board/sandbox/capsule_pub_key_bad.crt | 19 ++ board/sandbox/capsule_pub_key_good.crt | 19 ++ configs/sandbox_noinst_defconfig | 2 + configs/sandbox_spl_defconfig | 2 + configs/sandbox_vpl_defconfig | 2 + doc/develop/uefi/uefi.rst | 17 + include/sandbox_efi_capsule.h | 21 ++ test/py/tests/test_efi_capsule/conftest.py | 155 +-------- .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- test/py/tests/test_trace.py | 2 +- tools/binman/bintool.py | 19 +- tools/binman/btool/mkeficapsule.py | 101 ++++++ tools/binman/entries.rst | 64 ++++ tools/binman/etype/efi_capsule.py | 143 ++++++++ tools/binman/ftest.py | 118 +++++++ tools/binman/test/311_capsule.dts | 21 ++ tools/binman/test/312_capsule_signed.dts | 23 ++ tools/binman/test/313_capsule_version.dts | 22 ++ tools/binman/test/314_capsule_signed_ver.dts | 24 ++ tools/binman/test/315_capsule_oemflags.dts | 22 ++ tools/binman/test/316_capsule_missing_key.dts | 22 ++ .../binman/test/317_capsule_missing_index.dts | 20 ++ .../binman/test/318_capsule_missing_guid.dts | 19 ++ 33 files changed, 1094 insertions(+), 187 deletions(-) create mode 100644 arch/sandbox/dts/sandbox_capsule.dtsi create mode 100644 board/sandbox/capsule_priv_key_bad.key create mode 100644 board/sandbox/capsule_priv_key_good.key create mode 100644 board/sandbox/capsule_pub_esl_good.esl create mode 100644 board/sandbox/capsule_pub_key_bad.crt create mode 100644 board/sandbox/capsule_pub_key_good.crt create mode 100644 include/sandbox_efi_capsule.h delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its create mode 100644 tools/binman/btool/mkeficapsule.py create mode 100644 tools/binman/etype/efi_capsule.py create mode 100644 tools/binman/test/311_capsule.dts create mode 100644 tools/binman/test/312_capsule_signed.dts create mode 100644 tools/binman/test/313_capsule_version.dts create mode 100644 tools/binman/test/314_capsule_signed_ver.dts create mode 100644 tools/binman/test/315_capsule_oemflags.dts create mode 100644 tools/binman/test/316_capsule_missing_key.dts create mode 100644 tools/binman/test/317_capsule_missing_index.dts create mode 100644 tools/binman/test/318_capsule_missing_guid.dts -- 2.34.1

2 11

[PATCH v2 1/2] schemas: Add firmware node schema
by Simon Glass 12 Aug '23

12 Aug '23

Add a motivation and purpose for this new proposed node. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- (no changes since v1) dtschema/schemas/firmware.yaml | 83 ++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 dtschema/schemas/firmware.yaml diff --git a/dtschema/schemas/firmware.yaml b/dtschema/schemas/firmware.yaml new file mode 100644 index 0000000..4439a70 --- /dev/null +++ b/dtschema/schemas/firmware.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-clause +# Copyright 2023 Google LLC +# + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: /firmware Node + +maintainers: + - Simon Glass <sjg(a)chromium.org> + +description: | + The '/firmware' node does not represent a real device, but serves as a place + for recording information about the main firmware used on the device, such as + a map of its contents. This is used by the Operating System (OS), user space + programs and possibly other firmware components. Data in the '/firmware' node + does not itself represent the hardware. + + Properties in this node should be common to (and used by) at least two + firmware projects, such as U-Boot and TF-A. Project-specific subnodes can be + used for properties which are specific to a single project. + + Purpose of '/firmware' node + --------------------------- + + Firmware has traditionally been fairly opaque to the OS, with the OS taking + no interest in its contents, version, layout or how it might be updated. This + is less than ideal, since firmware is an important part of the system and + visibility into its operation is every bit as important as visbility into the + OS and user-space programs within the system. + + The traditional approach has been to let firmware deal with firmware, and the + OS deal with everything else. Updating firmware has been handled by firmware. + For example, the UEFI spec defines a way for the OS to post a 'capsule' which + is discovered next time the system boots, permitting firmware updates. But + firmware updates in firmware are highly problematic. They require a reboot + and a sometimes-lengthy wait with a strange-looking interface unfamiliar + to most users. It seems better to make the update as transparent as possible + to the user. As an example of that, ChromeOS has full knowledge of the + firmware version and layout, updates it in the background from user space and + instantly selects the new firmware when the user reboots or logs out. + + A common objection to considering the system holistically is that some parts + of the system are inaccessible to the OS, such as a secure enclave. However + this does not preclude providing visibility into what is present in that + enclave. Firmware-version information is still useful. Firmware updates are + still needed and can still be initiated from user space. + + Another objection is that firmware should provide an interface to the OS, + while keeping its structure private. This thinking is largely driven by + extrapolating from how firmware has been handled in the 'BIOS' days. + It should be considered a degenerate case rather than the norm. As complexity + increases, it creates an artificial boundary between two pieces of the whole. + Mechanisms then need to be invented to cross this unnecessary chasm. An + example of this is Intel's Dynamic Platform and Thermal Framework (DPTF), + which consists of user-space, OS and firmware components all working towards + a shared goal. We need a standard description of these cross-system pieces. + + In order to 'teach the OS about firmware', we need a place to put this + information. That is the purpose of this node. + + In an Open Source world the entire model of firmware needs to adjust to be + more open, more visible and managed just like any other part of the system. + The major goal is to standardise how firmware is presented to the OS and user + space, so that common utilities can be used to manage the entire system, + including the firmware. For example, fwupd can look in this node for + information on how to update the firmware, similar to how VBE works. [1] + It is likely that other purposes will come to light over time. + + [1] https://github.com/fwupd/fwupd/tree/main/plugins/vbe + +properties: + $nodename: + const: firmware + + "#address-cells": true + "#size-cells": true + +additionalProperties: + type: object -- 2.41.0.487.g6d72f3e995-goog

2 4

[PATCH 1/2] schemas: Add firmware node schema
by Simon Glass 12 Aug '23

12 Aug '23

Add a motivation and purpose for this new proposed node. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- dtschema/schemas/firmware.yaml | 83 ++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 dtschema/schemas/firmware.yaml diff --git a/dtschema/schemas/firmware.yaml b/dtschema/schemas/firmware.yaml new file mode 100644 index 0000000..4439a70 --- /dev/null +++ b/dtschema/schemas/firmware.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-clause +# Copyright 2023 Google LLC +# + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: /firmware Node + +maintainers: + - Simon Glass <sjg(a)chromium.org> + +description: | + The '/firmware' node does not represent a real device, but serves as a place + for recording information about the main firmware used on the device, such as + a map of its contents. This is used by the Operating System (OS), user space + programs and possibly other firmware components. Data in the '/firmware' node + does not itself represent the hardware. + + Properties in this node should be common to (and used by) at least two + firmware projects, such as U-Boot and TF-A. Project-specific subnodes can be + used for properties which are specific to a single project. + + Purpose of '/firmware' node + --------------------------- + + Firmware has traditionally been fairly opaque to the OS, with the OS taking + no interest in its contents, version, layout or how it might be updated. This + is less than ideal, since firmware is an important part of the system and + visibility into its operation is every bit as important as visbility into the + OS and user-space programs within the system. + + The traditional approach has been to let firmware deal with firmware, and the + OS deal with everything else. Updating firmware has been handled by firmware. + For example, the UEFI spec defines a way for the OS to post a 'capsule' which + is discovered next time the system boots, permitting firmware updates. But + firmware updates in firmware are highly problematic. They require a reboot + and a sometimes-lengthy wait with a strange-looking interface unfamiliar + to most users. It seems better to make the update as transparent as possible + to the user. As an example of that, ChromeOS has full knowledge of the + firmware version and layout, updates it in the background from user space and + instantly selects the new firmware when the user reboots or logs out. + + A common objection to considering the system holistically is that some parts + of the system are inaccessible to the OS, such as a secure enclave. However + this does not preclude providing visibility into what is present in that + enclave. Firmware-version information is still useful. Firmware updates are + still needed and can still be initiated from user space. + + Another objection is that firmware should provide an interface to the OS, + while keeping its structure private. This thinking is largely driven by + extrapolating from how firmware has been handled in the 'BIOS' days. + It should be considered a degenerate case rather than the norm. As complexity + increases, it creates an artificial boundary between two pieces of the whole. + Mechanisms then need to be invented to cross this unnecessary chasm. An + example of this is Intel's Dynamic Platform and Thermal Framework (DPTF), + which consists of user-space, OS and firmware components all working towards + a shared goal. We need a standard description of these cross-system pieces. + + In order to 'teach the OS about firmware', we need a place to put this + information. That is the purpose of this node. + + In an Open Source world the entire model of firmware needs to adjust to be + more open, more visible and managed just like any other part of the system. + The major goal is to standardise how firmware is presented to the OS and user + space, so that common utilities can be used to manage the entire system, + including the firmware. For example, fwupd can look in this node for + information on how to update the firmware, similar to how VBE works. [1] + It is likely that other purposes will come to light over time. + + [1] https://github.com/fwupd/fwupd/tree/main/plugins/vbe + +properties: + $nodename: + const: firmware + + "#address-cells": true + "#size-cells": true + +additionalProperties: + type: object -- 2.41.0.255.g8b1d071c50-goog

3 8

[PATCH v2 0/3] Video: Keep fixed/gpio regulator counter in balance
by Svyatoslav Ryhel 12 Aug '23

12 Aug '23

The commit 4fcba5d556b4 ("regulator: implement basic reference counter") have made it more important to keep fixed/gpio regulators enable/disable state in balance. The regulator_set_enable_if_allowed function is more relaxed and will wrap all cases where the regulator is busy, already active, missing or if DM_REGULATOR is not enabled. These patches are an expansion of similar Jonas Karlman's patches. --- Changes from v1: - check return of regulator_set_enable_if_allowed for -ENOSYS to avoid error caused by disabled DM_REGULATOR (Jonas Karlman suggestion) --- Svyatoslav Ryhel (3): video: pwm_backlight: use regulator_set_enable_if_allowed video: simple_panel: use regulator_set_enable_if_allowed video: tegra20: dsi: use regulator_set_enable_if_allowed drivers/video/pwm_backlight.c | 13 ++++++------- drivers/video/simple_panel.c | 10 +++++----- drivers/video/tegra20/tegra-dsi.c | 8 +++----- 3 files changed, 14 insertions(+), 17 deletions(-) -- 2.39.2

1 3

[PATCH v1 0/3] Video: Keep fixed/gpio regulator counter in balance
by Svyatoslav Ryhel 12 Aug '23

12 Aug '23

The commit 4fcba5d556b4 ("regulator: implement basic reference counter") have made it more important to keep fixed/gpio regulators enable/disable state in balance. The regulator_set_enable_if_allowed function is more relaxed and will wrap all cases where the regulator is busy, already active, missing or if DM_REGULATOR is not enabled. These patches are an expansion of similar Jonas Karlman's patches. Svyatoslav Ryhel (3): video: pwm_backlight: use regulator_set_enable_if_allowed video: simple_panel: use regulator_set_enable_if_allowed video: tegra20: dsi: use regulator_set_enable_if_allowed drivers/video/pwm_backlight.c | 11 +++++------ drivers/video/simple_panel.c | 10 +++++----- drivers/video/tegra20/tegra-dsi.c | 8 +++----- 3 files changed, 13 insertions(+), 16 deletions(-) -- 2.39.2

2 4

[PATCH] rockchip: MAINTAINERS: fix board name for Radxa ROCK 4C+
by FUKAUMI Naoki 12 Aug '23

12 Aug '23

align with other ROCK series. Fixes: 2b506407c8 ("rockchip: Add MAINTAINERS entry for Radxa Rock 4C+") Signed-off-by: FUKAUMI Naoki <naoki(a)radxa.com> --- board/rockchip/evb_rk3399/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS index cb44bc9fda..c7e412b54e 100644 --- a/board/rockchip/evb_rk3399/MAINTAINERS +++ b/board/rockchip/evb_rk3399/MAINTAINERS @@ -80,7 +80,7 @@ F: configs/orangepi-rk3399_defconfig F: arch/arm/dts/rk3399-u-boot.dtsi F: arch/arm/dts/rk3399-orangepi-u-boot.dtsi -RADXA ROCK 4C+ +ROCK-4C+ M: FUKAUMI Naoki <naoki(a)radxa.com> S: Maintained F: configs/rock-4c-plus-rk3399_defconfig -- 2.39.2

2 1

[PATCH 0/2] Drop useless call to debug_uart_init
by Massimo Pegorer 12 Aug '23

12 Aug '23

Since commit 0dba45864b2a ("arm: Init the debug UART") function debug_uart_init is called in crt files _main before calling board_init_f. Therefore, there is no need to call it again inside board_init_f implementation as was done in arch/arm/mach-rockchip/spl.c. Remove also debug message related to debug uart initializazion in board_init_f. If an earliest-as-possible message after debug uart initialization is needed, enable DEBUG_UART_ANNOUNCE Kconfig option, instead. Massimo Pegorer (2): rockchip: spl: Drop useless call to debug_uart_init rockchip: spl: Drop out of scope debug message related to uart init arch/arm/mach-rockchip/spl.c | 13 ------------- 1 file changed, 13 deletions(-) -- 2.34.1

3 6

[PATCH] [*] fix RK3568 build under CONFIG_DISPLAY_CPUINFO flag
by Anton 12 Aug '23

12 Aug '23

--- arch/arm/include/asm/arch-rockchip/cru.h | 2 ++ arch/arm/include/asm/arch-rockchip/cru_rk3568.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-rockchip/cru.h b/arch/arm/include/asm/arch-rockchip/cru.h index 13ea4aba8e..9778790f34 100644 --- a/arch/arm/include/asm/arch-rockchip/cru.h +++ b/arch/arm/include/asm/arch-rockchip/cru.h @@ -15,6 +15,8 @@ # include <asm/arch-rockchip/cru_rk3288.h> #elif defined(CONFIG_ROCKCHIP_RK3399) # include <asm/arch-rockchip/cru_rk3399.h> +#elif defined(CONFIG_ROCKCHIP_RK3568) +#include <asm/arch-rockchip/cru_rk3568.h> #endif /* CRU_GLB_RST_ST */ diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h index 399f19ad21..76f1ad5510 100644 --- a/arch/arm/include/asm/arch-rockchip/cru_rk3568.h +++ b/arch/arm/include/asm/arch-rockchip/cru_rk3568.h @@ -106,6 +106,8 @@ struct rk3568_cru { unsigned int emmc_con[2];/* Address Offset: 0x0598 */ }; +#define rockchip_cru rk3568_cru + check_member(rk3568_cru, mode_con00, 0xc0); check_member(rk3568_cru, softrst_con[0], 0x400); -- 2.30.2

2 1