November 2023 - U-Boot

[PATCH 0/2] bootstd: Fix a few minor bugs
by Simon Glass 02 Nov '23

02 Nov '23

This series fixes a few bugs noticed recently: - handling of certain command-line updates with 'bootflow cmdline' - support for 'bootflow read' in ChromeOS Simon Glass (2): bootstd: Handle a few special cases in cmdline_set_arg() bootstd: cros: Correct condition for read method boot/bootflow.c | 5 +++-- boot/bootmeth_cros.c | 8 ++++---- test/boot/bootflow.c | 20 ++++++++++++++++++++ 3 files changed, 27 insertions(+), 6 deletions(-) -- 2.42.0.758.gaed0368e0e-goog

2 4

[PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
by Mark Kettenis 02 Nov '23

02 Nov '23

Enable the bootflow based on this bootmeth if the BootOrder EFI variable is set. Signed-off-by: Mark Kettenis <kettenis(a)openbsd.org> --- ChangeLog: v2: - Initialize EFI subsystem to populate EFI variables boot/bootmeth_efi_mgr.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c index e9d973429f..e6c42d41fb 100644 --- a/boot/bootmeth_efi_mgr.c +++ b/boot/bootmeth_efi_mgr.c @@ -14,6 +14,8 @@ #include <bootmeth.h> #include <command.h> #include <dm.h> +#include <efi_loader.h> +#include <efi_variable.h> /** * struct efi_mgr_priv - private info for the efi-mgr driver @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, struct bootflow_iter *iter) static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow *bflow) { struct efi_mgr_priv *priv = dev_get_priv(dev); + efi_status_t ret; + efi_uintn_t size; + u16 *bootorder; if (priv->fake_dev) { bflow->state = BOOTFLOWST_READY; return 0; } - /* To be implemented */ + ret = efi_init_obj_list(); + if (ret) + return log_msg_ret("init", ret); + + /* Enable this method if the "BootOrder" UEFI exists. */ + bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, + &size); + if (bootorder) { + bflow->state = BOOTFLOWST_READY; + return 0; + } return -EINVAL; } -- 2.42.0

4 8

[PATCH 1/1] bootstd: BOOTDEV_SPI_FLASH requires BOOTSTD
by Heinrich Schuchardt 02 Nov '23

02 Nov '23

Compiling sandbox_defconfig with CONFIG_BOOTSTD=n fails: /usr/bin/ld: drivers/mtd/spi/sf_bootdev.o: in function `sf_get_bootflow': /drivers/mtd/spi/sf_bootdev.c:43:(.text+0x96): undefined reference to `bootmeth_set_bootflow' Add the missing Kconfig dependency. Fixes: Fixes: 0c1f4a9fb13a ("bootstd: Add a SPI flash bootdev") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- drivers/mtd/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index a9617c6c58..d3b1b21a47 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -82,6 +82,7 @@ if SPI_FLASH config BOOTDEV_SPI_FLASH bool "SPI Flash bootdev support" + depends on BOOTSTD help Enable a boot device for SPI flash. This allows reading a script from SPI flash so that it can be used to boot an Operating System. -- 2.40.1

3 2

[PATCH v3 0/3] bootcount: Replace I2C legacy implementation by driver model
by Philip Richard Oberfichtner 02 Nov '23

02 Nov '23

The generic I2C bootcounter driver does not yet adhere to driver model. This patchset intends to replace the legacy implementation. There are currently no upstream boards using the driver, so it should be safe to just remove it. For downstream users it should be straighforward to switch to the new implementation. Changes in v3: - Remove common.h #include Changes in v2: - Improved device tree handling by replacing address property with phandle - Addition of a generic i2c helper function Philip Richard Oberfichtner (3): bootcount: Remove legacy I2C driver i2c: Implement i2c_get_chip_by_phandle() bootcount: Add driver model I2C driver drivers/bootcount/Kconfig | 34 ++++----- drivers/bootcount/Makefile | 2 +- drivers/bootcount/bootcount_dm_i2c.c | 102 +++++++++++++++++++++++++++ drivers/bootcount/bootcount_i2c.c | 43 ----------- drivers/i2c/i2c-uclass.c | 75 ++++++++++++++++++++ include/i2c.h | 12 ++++ 6 files changed, 203 insertions(+), 65 deletions(-) create mode 100644 drivers/bootcount/bootcount_dm_i2c.c delete mode 100644 drivers/bootcount/bootcount_i2c.c -- 2.42.0

2 9

[PATCH v2] i2c: designware_i2c: adjust timing calculation
by Heinrich Schuchardt 02 Nov '23

02 Nov '23

In SPL probing of the designware_i2c device on the StarFive VisionFive 2 board fails with dw_i2c: mode 0, ic_clk 1000000, speed 100000, period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0 dw_i2c: bad counts. hcnt = -4 lcnt = 4 device_probe: i2c@12050000 failed to probe -22 When changing the offset for the high phase from 7 to 3 the device is probed correctly. This now matches the value from the Linux driver. Without this fix the memory size of the StarFive VisionFive 2 board cannot be read from EEPROM. Fixes: e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- v2: use the same timing offset at Linux provide a descriptive comment for the constant --- drivers/i2c/designware_i2c.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c index e54de42abc..215ce010cb 100644 --- a/drivers/i2c/designware_i2c.c +++ b/drivers/i2c/designware_i2c.c @@ -24,6 +24,17 @@ */ #define DW_I2C_COMP_TYPE 0x44570140 +/* + * This constant is used to calculate when during the clock high phase the data + * bit shall be read. The value was copied from the Linux v6.5 function + * i2c_dw_scl_hcnt() which provides the following explanation: + * + * "This is just an experimental rule: the tHD;STA period turned out to be + * proportinal to (_HCNT + 3). With this setting, we could meet both tHIGH and + * tHD;STA timing specs." + */ +#define T_HD_STA_OFFSET 3 + static int dw_i2c_enable(struct i2c_regs *i2c_base, bool enable) { u32 ena = enable ? IC_ENABLE_0B : 0; @@ -155,10 +166,10 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum i2c_speed_mode mode, /* * Back-solve for hcnt and lcnt according to the following equations: - * SCL_High_time = [(HCNT + IC_*_SPKLEN + 7) * ic_clk] + SCL_Fall_time + * SCL_High_time = [(HCNT + IC_*_SPKLEN + T_HD_STA_OFFSET) * ic_clk] + SCL_Fall_time * SCL_Low_time = [(LCNT + 1) * ic_clk] - SCL_Fall_time + SCL_Rise_time */ - hcnt = min_thigh_cnt - fall_cnt - 7 - spk_cnt; + hcnt = min_thigh_cnt - fall_cnt - T_HD_STA_OFFSET - spk_cnt; lcnt = min_tlow_cnt - rise_cnt + fall_cnt - 1; if (hcnt < 0 || lcnt < 0) { @@ -170,13 +181,13 @@ static int dw_i2c_calc_timing(struct dw_i2c *priv, enum i2c_speed_mode mode, * Now add things back up to ensure the period is hit. If it is off, * split the difference and bias to lcnt for remainder */ - tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1; + tot = hcnt + lcnt + T_HD_STA_OFFSET + spk_cnt + rise_cnt + 1; if (tot < period_cnt) { diff = (period_cnt - tot) / 2; hcnt += diff; lcnt += diff; - tot = hcnt + lcnt + 7 + spk_cnt + rise_cnt + 1; + tot = hcnt + lcnt + T_HD_STA_OFFSET + spk_cnt + rise_cnt + 1; lcnt += period_cnt - tot; }

2 2

[PATCH v2] i2c: nuvoton: remove standard mode only
by Jim Liu 02 Nov '23

02 Nov '23

first version is only support standard mode. remove this judgment to support standard/fast/fast plus mode. Signed-off-by: Jim Liu <JJLIU0(a)nuvoton.com> Changes for v2: - add commit message --- drivers/i2c/npcm_i2c.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/i2c/npcm_i2c.c b/drivers/i2c/npcm_i2c.c index ea4ef53256..b867b6c8e9 100644 --- a/drivers/i2c/npcm_i2c.c +++ b/drivers/i2c/npcm_i2c.c @@ -517,11 +517,6 @@ static int npcm_i2c_init_clk(struct npcm_i2c_bus *bus, u32 bus_freq) u32 sclfrq; u8 hldt, val; - if (bus_freq > I2C_FREQ_100K) { - printf("Support standard mode only\n"); - return -EINVAL; - } - /* SCLFRQ = T(SCL)/4/T(CLK) = FREQ(CLK)/4/FREQ(SCL) */ sclfrq = freq / (bus_freq * 4); if (sclfrq < SCLFRQ_MIN || sclfrq > SCLFRQ_MAX) -- 2.25.1

2 2

TF-A Hang on NXP i.MX 8M Plus QuadLite
by Marcel Ziswiler 02 Nov '23

02 Nov '23

Hi there We recently got our first batch of i.MX 8M Plus QuadLite based SoMs. While NXP downstream works just fine on them they just hang booting with latest upstream U-Boot (and TF-A). Replacing TF-A with the downstream NXP one made upstream U-Boot work as well. Further debugging TF-A showed imx_gpc_pm_domain_enable() to be the culprit. Looking more specifically I discovered the following so far downstream-only commit [1]. So it looks like in downstream NXP is limiting the to-be-enabled power management domains to HSIOMIX, USB1_PHY and USB2_PHY. Anybody knows why exactly this is done and why this got never upstreamed? Thank you very much for any insights into this matter. [1] https://github.com/nxp-imx/imx-atf/commit/47759cfca10b2286a218062915d4a2808… Cheers Marcel

1 0

[PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
by Yong-Xuan Wang 02 Nov '23

02 Nov '23

U-boot initially loads the kernel image to the kernel_addr_r, and subsequently relocates it to memory address 0x80200000. Setting kernel_addr_r to 0x80200000 can eliminate one copy operation. Signed-off-by: Yong-Xuan Wang <yongxuan.wang(a)sifive.com> --- include/configs/sifive-unmatched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 74150b7d4b..de8bfc1123 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -36,7 +36,7 @@ "name=system,size=-,bootable,type=${type_guid_gpt_system};" #define CFG_EXTRA_ENV_SETTINGS \ - "kernel_addr_r=0x84000000\0" \ + "kernel_addr_r=0x80200000\0" \ "kernel_comp_addr_r=0x88000000\0" \ "kernel_comp_size=0x4000000\0" \ "fdt_addr_r=0x8c000000\0" \ -- 2.17.1

2 5

[PATCH] doc: falcon: riscv: Falcon Mode boot on RISC-V
by Randolph 02 Nov '23

02 Nov '23

Add documentation to introduce the Falcon Mode on RISC-V In this mode, boot sequence is SPL -> OpenSBI -> Linux kernel. Signed-off-by: Randolph <randolph(a)andestech.com> --- doc/develop/falcon.rst | 159 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) diff --git a/doc/develop/falcon.rst b/doc/develop/falcon.rst index 2f25fc8532..75648c76d7 100644 --- a/doc/develop/falcon.rst +++ b/doc/develop/falcon.rst @@ -256,3 +256,162 @@ the following command: Falcon Mode was presented at the RMLL 2012. Slides are available at: http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf + +Falcon Mode Boot on RISC-V +-------------------------- + +Introduction +------------ + +In the RISC-V environment, OpenSBI is required to enable a supervisor to +execute certain privileged operations. The typical boot sequence on +RISC-V is SPL -> OpenSBI -> u-boot proper -> Linux kernel. SPL will load +and start the OpenSBI initializations, then OpenSBI will bring up the next +image, U-Boot proper. The OpenSBI binary must be prepared in advance of the +u-boot build process and it will be packed together with u-boot proper into +a file called u-boot.itb. + +The Falcon Mode is a distinct boot process for RISC-V platforms. Borrowing +ideas from the U-Boot Falcon Mode, it skips the U-Boot proper phase in the +normal boot process and allows OpenSBI to load and start the Linux kernel. +Its boot sequence is SPL -> OpenSBI -> Linux kernel. The OpenSBI binary and +Linux kernel binary must be prepared prior to the u-boot build process and +they will be packed together as linux.itb in this process. + +To enable the Falcon boot on RISC-V, CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT +is set. This configuration tells OpenSBI that Linux kernel is its next +OS image and makes it load and start the kernel afterwards. + +Note that the Falcon boot bypasses a lot of initializations by U-Boot. If the +Linux kernel expects hardware initializations by U-Boot, make sure to port the +relevant code to the SPL build process. + +Configurations +-------------- + +CONFIG_SPL_LOAD_FIT_ADDRESS + Specifies the address to load u-boot.itb in a normal boot. When the Falcon + boot is enabled, it specifies the load address of linux.itb. + +CONFIG_SYS_TEXT_BASE + Specifies the address of the text section for a u-boot proper in a normal + boot. When the falcon boot is enabled, it specifies the text section address + for the Linux kernel image. + +CONFIG_SPL_LOAD_FIT_OPENSBI_OS_BOOT + Activates the Falcon boot on RISC-V. + +Function that a board must implement +------------------------------------ + +Initially, SPL places the FDT blob right after the kernel. As the kernel does +not include the BSS section in its size calculation, SPL ends up placing the +FDT blob within the BSS section of the kernel. This may cause the FDT blob to +be cleared during kernel BSS initialization. To avoid the issue, be sure to +move the FDT blob out of the kernel first. + +void spl_perform_fixups(struct spl_image_info *spl_image) + required, necessary action to move the FDT blob out of the Linux kernel BSS section + +Example for Andes AE350 Board +----------------------------- + +A FDT blob is required to boot the Linux kernel from the SPL. Andes AE350 +platforms generally come with a builtin dtb. If you want to load a custom FDT +blob, follow the steps below: + +1. Load the custom FDT blob to SDRAM:: + + => fatload mmc 0:1 0x20000000 user_custom.dtb + +2. Set the SPI speed:: + + => sf probe 0:0 50000000 0 + +3. Erase sectors from the SPI Flash:: + + => sf erase 0xf0000 0x10000 + +4. Write the FDT blob to the erased sectors of the Flash:: + + => sf write 0x20000000 0xf0000 0x10000 + +Console Log of AE350 Falcon Boot +-------------------------------- + +U-Boot SPL 2023.01-00031-g777ecdea66 (Oct 31 2023 - 18:41:36 +0800) +Trying to boot from RAM + +OpenSBI v1.2-51-g7304e42 + ____ _____ ____ _____ + / __ \ / ____| _ \_ _| + | | | |_ __ ___ _ __ | (___ | |_) || | + | | | | '_ \ / _ \ '_ \ \___ \| _ < | | + | |__| | |_) | __/ | | |____) | |_) || |_ + \____/| .__/ \___|_| |_|_____/|____/_____| + | | + |_| + +Platform Name : andestech,ax25 +Platform Features : medeleg +Platform HART Count : 1 +Platform IPI Device : andes_plicsw +Platform Timer Device : andes_plmt @ 60000000Hz +Platform Console Device : uart8250 +Platform HSM Device : andes_smu +Platform PMU Device : andes_pmu +Platform Reboot Device : atcwdt200 +Platform Shutdown Device : --- +Firmware Base : 0x0 +Firmware Size : 196 KB +Runtime SBI Version : 1.0 + +Domain0 Name : root +Domain0 Boot HART : 0 +Domain0 HARTs : 0* +Domain0 Region00 : 0x0000000000000000-0x000000000003ffff () +Domain0 Region01 : 0x00000000e6000000-0x00000000e60fffff (I,R) +Domain0 Region02 : 0x00000000e6400000-0x00000000e67fffff (I) +Domain0 Region03 : 0x0000000000000000-0xffffffffffffffff (R,W,X) +Domain0 Next Address : 0x0000000001800000 +Domain0 Next Arg1 : 0x0000000001700000 +Domain0 Next Mode : S-mode +Domain0 SysReset : yes + +Boot HART ID : 0 +Boot HART Domain : root +Boot HART Priv Version : v1.11 +Boot HART Base ISA : rv64imafdcx +Boot HART ISA Extensions : none +Boot HART PMP Count : 8 +Boot HART PMP Granularity : 4 +Boot HART PMP Address Bits: 31 +Boot HART MHPM Count : 4 +Boot HART MHPM Bits : 64 +Boot HART MIDELEG : 0x0000000000000222 +Boot HART MEDELEG : 0x000000000000b109 +[ 0.000000] Linux version 6.1.47-09019-g0584b09ad862-dirty +[ 0.000000] OF: fdt: Ignoring memory range 0x0 - 0x1800000 +[ 0.000000] Machine model: andestech,ax25 +[ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '') +[ 0.000000] printk: bootconsole [sbi0] enabled +[ 0.000000] Disabled 4-level and 5-level paging +[ 0.000000] efi: UEFI not found. +[ 0.000000] Zone ranges: +[ 0.000000] DMA32 [mem 0x0000000001800000-0x000000003fffffff] +[ 0.000000] Normal empty +[ 0.000000] Movable zone start for each node +[ 0.000000] Early memory node ranges +[ 0.000000] node 0: [mem 0x0000000001800000-0x000000003fffffff] +[ 0.000000] Initmem setup node 0 [mem 0x0000000001800000-0x000000003fffffff] +[ 0.000000] SBI specification v1.0 detected +[ 0.000000] SBI implementation ID=0x1 Version=0x10002 +[ 0.000000] SBI TIME extension detected +[ 0.000000] SBI IPI extension detected +[ 0.000000] SBI RFENCE extension detected +[ 0.000000] SBI SRST extension detected +[ 0.000000] SBI HSM extension detected +[ 0.000000] riscv: base ISA extensions acim +[ 0.000000] riscv: ELF capabilities acim +[ 0.000000] percpu: Embedded 18 pages/cpu s35000 r8192 d30536 u73728 +[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 252500 -- 2.34.1

1 0

[PATCH v4 0/5] Add support for StarFive JH7110 TRNG driver
by Chanho Park 02 Nov '23

02 Nov '23

This patchset adds to support StarFive JH7110 TRNG driver. Due to lack of readl_relaxed API, the first patch tries to import the APIs(read/write_relaxed) from Linux kernel's implementation. The second patch adds the missing security clocks which are required by the trng IP. This IP can support 128-bit and 256-bit random number generation but this patch makes 256-bit default mode for convenience. Change from v3: - Patch #3: Make one call to generate random number according to 128 or 256 bits of entropy which is suggested by Heinrich. Changes from v2: - Patch #3: Add error handling codes of probe() which are suggested by Jaehoon Changes from v1: - Patch #3: Apply Heinrich's reviews and his codes - Patch #5: Add Heinrich's R-b tag Chanho Park (5): riscv: import read/write_relaxed functions clk: starfive: jh7110: Add security clocks rng: Add StarFive JH7110 RNG driver riscv: dts: jh7110: Add rng device tree node configs: visionfive2: Enable JH7110 RNG driver arch/riscv/dts/jh7110.dtsi | 10 + arch/riscv/include/asm/io.h | 45 ++++ configs/starfive_visionfive2_defconfig | 2 + drivers/clk/starfive/clk-jh7110.c | 10 + drivers/rng/Kconfig | 6 + drivers/rng/Makefile | 1 + drivers/rng/jh7110_rng.c | 274 +++++++++++++++++++++++++ 7 files changed, 348 insertions(+) create mode 100644 drivers/rng/jh7110_rng.c -- 2.39.2

2 9