April 2020 - U-Boot

[PATCH 1/3] stm32mp1: board: add support of CONFIG_ENV_IS_IN_MMC
by Patrick Delaunay 14 Apr '20

14 Apr '20

Add support of CONFIG_ENV_IS_IN_MMC in env_get_location, used for all mmc device (SD card and eMMC). The 2 configs CONFIG_ENV_IS_IN_MMC and CONFIG_ENV_IS_IN_EXT4 are incompatible. Add the weak function mmc_get_env_dev to select the mmc boot instance. Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- board/st/stm32mp1/stm32mp1.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c index c36e7655c0..effba41ad1 100644 --- a/board/st/stm32mp1/stm32mp1.c +++ b/board/st/stm32mp1/stm32mp1.c @@ -785,6 +785,11 @@ enum env_location env_get_location(enum env_operation op, int prio) return ENVL_UNKNOWN; switch (bootmode & TAMP_BOOT_DEVICE_MASK) { +#ifdef CONFIG_ENV_IS_IN_MMC + case BOOT_FLASH_SD: + case BOOT_FLASH_EMMC: + return ENVL_MMC; +#endif #ifdef CONFIG_ENV_IS_IN_EXT4 case BOOT_FLASH_SD: case BOOT_FLASH_EMMC: @@ -826,6 +831,15 @@ const char *env_ext4_get_dev_part(void) } #endif +#if defined(CONFIG_ENV_IS_IN_MMC) +int mmc_get_env_dev(void) +{ + u32 bootmode = get_bootmode(); + + return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1; +} +#endif + #ifdef CONFIG_SYS_MTDPARTS_RUNTIME #define MTDPARTS_LEN 256 -- 2.17.1

2 5

[PATCH V3] ARM: dts: stm32: Add KS8851-16MLL ethernet on FMC2
by Marek Vasut 14 Apr '20

14 Apr '20

Add DT entries, Kconfig entries and board-specific entries to configure FMC2 bus and make KS8851-16MLL on that bus accessible to U-Boot. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Patrick Delaunay <patrick.delaunay(a)st.com> Cc: Patrice Chotard <patrice.chotard(a)st.com> --- V2: Configure FMC2 nCS4 for SRAM as well V3: Adjust the register macros --- arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 68 ++++++++++++++++++++++ board/dhelectronics/dh_stm32mp1/board.c | 28 +++++++++ configs/stm32mp15_dhcom_basic_defconfig | 1 + 3 files changed, 97 insertions(+) diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi index 6c952a57ee..eba3588540 100644 --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi @@ -37,6 +37,12 @@ default-state = "on"; }; }; + + /* This is actually on FMC2, but we do not have bus driver for that */ + ksz8851: ks8851mll@64000000 { + compatible = "micrel,ks8851-mll"; + reg = <0x64000000 0x20000>; + }; }; &i2c4 { @@ -50,6 +56,68 @@ }; }; +&pinctrl { + /* These should bound to FMC2 bus driver, but we do not have one */ + pinctrl-0 = <&fmc_pins_b>; + pinctrl-1 = <&fmc_sleep_pins_b>; + pinctrl-names = "default", "sleep"; + + fmc_pins_b: fmc-0 { + pins1 { + pinmux = <STM32_PINMUX('D', 4, AF12)>, /* FMC_NOE */ + <STM32_PINMUX('D', 5, AF12)>, /* FMC_NWE */ + <STM32_PINMUX('B', 7, AF12)>, /* FMC_NL */ + <STM32_PINMUX('D', 14, AF12)>, /* FMC_D0 */ + <STM32_PINMUX('D', 15, AF12)>, /* FMC_D1 */ + <STM32_PINMUX('D', 0, AF12)>, /* FMC_D2 */ + <STM32_PINMUX('D', 1, AF12)>, /* FMC_D3 */ + <STM32_PINMUX('E', 7, AF12)>, /* FMC_D4 */ + <STM32_PINMUX('E', 8, AF12)>, /* FMC_D5 */ + <STM32_PINMUX('E', 9, AF12)>, /* FMC_D6 */ + <STM32_PINMUX('E', 10, AF12)>, /* FMC_D7 */ + <STM32_PINMUX('E', 11, AF12)>, /* FMC_D8 */ + <STM32_PINMUX('E', 12, AF12)>, /* FMC_D9 */ + <STM32_PINMUX('E', 13, AF12)>, /* FMC_D10 */ + <STM32_PINMUX('E', 14, AF12)>, /* FMC_D11 */ + <STM32_PINMUX('E', 15, AF12)>, /* FMC_D12 */ + <STM32_PINMUX('D', 8, AF12)>, /* FMC_D13 */ + <STM32_PINMUX('D', 9, AF12)>, /* FMC_D14 */ + <STM32_PINMUX('D', 10, AF12)>, /* FMC_D15 */ + <STM32_PINMUX('G', 9, AF12)>, /* FMC_NE2_FMC_NCE */ + <STM32_PINMUX('G', 12, AF12)>; /* FMC_NE4 */ + bias-disable; + drive-push-pull; + slew-rate = <3>; + }; + }; + + fmc_sleep_pins_b: fmc-sleep-0 { + pins { + pinmux = <STM32_PINMUX('D', 4, ANALOG)>, /* FMC_NOE */ + <STM32_PINMUX('D', 5, ANALOG)>, /* FMC_NWE */ + <STM32_PINMUX('B', 7, ANALOG)>, /* FMC_NL */ + <STM32_PINMUX('D', 14, ANALOG)>, /* FMC_D0 */ + <STM32_PINMUX('D', 15, ANALOG)>, /* FMC_D1 */ + <STM32_PINMUX('D', 0, ANALOG)>, /* FMC_D2 */ + <STM32_PINMUX('D', 1, ANALOG)>, /* FMC_D3 */ + <STM32_PINMUX('E', 7, ANALOG)>, /* FMC_D4 */ + <STM32_PINMUX('E', 8, ANALOG)>, /* FMC_D5 */ + <STM32_PINMUX('E', 9, ANALOG)>, /* FMC_D6 */ + <STM32_PINMUX('E', 10, ANALOG)>, /* FMC_D7 */ + <STM32_PINMUX('E', 11, ANALOG)>, /* FMC_D8 */ + <STM32_PINMUX('E', 12, ANALOG)>, /* FMC_D9 */ + <STM32_PINMUX('E', 13, ANALOG)>, /* FMC_D10 */ + <STM32_PINMUX('E', 14, ANALOG)>, /* FMC_D11 */ + <STM32_PINMUX('E', 15, ANALOG)>, /* FMC_D12 */ + <STM32_PINMUX('D', 8, ANALOG)>, /* FMC_D13 */ + <STM32_PINMUX('D', 9, ANALOG)>, /* FMC_D14 */ + <STM32_PINMUX('D', 10, ANALOG)>, /* FMC_D15 */ + <STM32_PINMUX('G', 9, ANALOG)>, /* FMC_NE2_FMC_NCE */ + <STM32_PINMUX('G', 12, ANALOG)>; /* FMC_NE4 */ + }; + }; +}; + &pmic { u-boot,dm-pre-reloc; }; diff --git a/board/dhelectronics/dh_stm32mp1/board.c b/board/dhelectronics/dh_stm32mp1/board.c index b663696983..be55242799 100644 --- a/board/dhelectronics/dh_stm32mp1/board.c +++ b/board/dhelectronics/dh_stm32mp1/board.c @@ -376,6 +376,32 @@ static void sysconf_init(void) #endif } +static void board_init_fmc2(void) +{ +#define STM32_FMC2_BCR1 0x0 +#define STM32_FMC2_BTR1 0x4 +#define STM32_FMC2_BWTR1 0x104 +#define STM32_FMC2_BCR(x) ((x) * 0x8 + STM32_FMC2_BCR1) +#define STM32_FMC2_BTR(x) ((x) * 0x8 + STM32_FMC2_BTR1) +#define STM32_FMC2_BWTR(x) ((x) * 0x8 + STM32_FMC2_BWTR1) + +#define RCC_MP_AHB6RSTCLRR 0x218 +#define RCC_MP_AHB6ENSETR 0x19c + + /* Set up FMC2 bus for KS8851-16MLL and X11 SRAM */ + writel(BIT(12), STM32_RCC_BASE + RCC_MP_AHB6RSTCLRR); + writel(BIT(12), STM32_RCC_BASE + RCC_MP_AHB6ENSETR); + + /* KS8851-16MLL */ + writel(0x000010db, STM32_FMC2_BASE + STM32_FMC2_BCR(1)); + writel(0xc0022222, STM32_FMC2_BASE + STM32_FMC2_BTR(1)); + /* AS7C34098 SRAM on X11 */ + writel(0x000010db, STM32_FMC2_BASE + STM32_FMC2_BCR(3)); + writel(0xc0022222, STM32_FMC2_BASE + STM32_FMC2_BTR(3)); + + setbits_le32(STM32_FMC2_BASE + STM32_FMC2_BCR1, BIT(31)); +} + /* board dependent setup after realloc */ int board_init(void) { @@ -399,6 +425,8 @@ int board_init(void) sysconf_init(); + board_init_fmc2(); + if (CONFIG_IS_ENABLED(CONFIG_LED)) led_default_state(); diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index 921dea242a..683f15e7d5 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -93,6 +93,7 @@ CONFIG_SPI_FLASH_MTD=y CONFIG_SPL_SPI_FLASH_MTD=y CONFIG_DM_ETH=y CONFIG_DWC_ETH_QOS=y +CONFIG_KS8851_MLL=y CONFIG_PHY=y CONFIG_PHY_STM32_USBPHYC=y CONFIG_PINCONF=y -- 2.25.1

4 10

Re: [PATCH v5 1/6] riscv: Add boot hartid to Device tree
by Heinrich Schuchardt 14 Apr '20

14 Apr '20

On 4/6/20 10:44 PM, Atish Patra wrote: > Linux booting protocol mandates that register "a0" contains the hartid. > However, U-boot can not pass the hartid via a0 during via standard UEFI > protocol. DT nodes are commonly used to pass such information to the OS. > > Add a DT node under chosen node to indicate the boot hartid. EFI stub > in Linux kernel will parse this node and pass it to the real kernel > in "a0" before jumping to it. > > Signed-off-by: Atish Patra <atish.patra(a)wdc.com> > Reviewed-by: Rick Chen <rick(a)andestech.com> > --- > arch/riscv/lib/bootm.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c > index fad16901c5f2..87cadad5016d 100644 > --- a/arch/riscv/lib/bootm.c > +++ b/arch/riscv/lib/bootm.c > @@ -28,6 +28,28 @@ __weak void board_quiesce_devices(void) > > int arch_fixup_fdt(void *blob) > { > +#ifdef CONFIG_EFI_LOADER > + int err; > + u32 size; > + int chosen_offset; > + > + size = fdt_totalsize(blob); > + err = fdt_open_into(blob, blob, size + 32); > + if (err < 0) { > + printf("Device Tree can't be expanded to accommodate new node"); > + return err; > + } > + chosen_offset = fdt_path_offset(blob, "/chosen"); > + if (chosen_offset < 0) { > + err = fdt_add_subnode(blob, 0, "chosen"); > + if (err < 0) { > + printf("chosen node can not be added\n"); > + return err; > + } > + } > + /* Overwrite the boot-hartid as U-Boot is the last stage BL */ > + fdt_setprop_u32(blob, chosen_offset, "boot-hartid", gd->arch.boot_hart); > +#endif > return 0; > } > > I have tested this on qemu-riscv64_defconfig by comparing the device tree before and after running helloworld.efi: => fdt addr $fdtcontroladdr => fdt print /chosen chosen { bootargs = ""; stdout-path = "/uart@10000000"; }; ... => dhcp $kernel_addr_r helloworld.efi => bootefi $kernel_addr_r ... => fdt addr 0x87F00000 => fdt print /chosen chosen { riscv,kernel-end = <0x00000000 0x00000000>; riscv,kernel-start = <0x00000000 0x00000000>; boot-hartid = <0x00000000>; bootargs = ""; stdout-path = "/uart@10000000"; }; The entry for boot-hardid seems to be ok. But the riscv,kernel-end and riscv,kernel-start values are just some dummy values introduced in: board/emulation/qemu-riscv/qemu-riscv.c:84 commit 897206c5cc5c ("riscv: qemu: clear kernel-start/-end in device tree as workaround for BBL)" @Lukas: Why are these values set to zero and not deleted (using fdt_delprop()) from the device tree? I cannot see that we need them when booting via UEFI. Tested-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de>

3 2

[PATCH 1/5] arm: dts: rockchip: rk3399: add and enable rng node
by Lin Jinhan 14 Apr '20

14 Apr '20

Add rng node in rk3399-u-boot.dtsi and enable it in rk3399-evb-u-boot.dtsi. Signed-off-by: Lin Jinhan <troy.lin(a)rock-chips.com> --- arch/arm/dts/rk3399-evb-u-boot.dtsi | 5 +++++ arch/arm/dts/rk3399-u-boot.dtsi | 6 ++++++ 2 files changed, 11 insertions(+) diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi b/arch/arm/dts/rk3399-evb-u-boot.dtsi index ccb33d34d1..5b50c5ba30 100644 --- a/arch/arm/dts/rk3399-evb-u-boot.dtsi +++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi @@ -11,3 +11,8 @@ u-boot,spl-boot-order = &sdhci, &sdmmc; }; }; + +&rng { + status = "okay"; +}; + diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi index 8b857ccfc7..757b8c10a2 100644 --- a/arch/arm/dts/rk3399-u-boot.dtsi +++ b/arch/arm/dts/rk3399-u-boot.dtsi @@ -25,6 +25,12 @@ clock-names = "pclk_ddr_mon"; }; + rng: rng@ff8b8000 { + compatible = "rockchip,cryptov1-rng"; + reg = <0x0 0xff8b8000 0x0 0x1000>; + status = "disabled"; + }; + dmc: dmc { u-boot,dm-pre-reloc; compatible = "rockchip,rk3399-dmc"; -- 2.17.1

4 14

[PATCH 0/4] P1010RDB: Add device tree support and enable DM PCIe driver
by Zhiqiang Hou 14 Apr '20

14 Apr '20

From: Hou Zhiqiang <Zhiqiang.Hou(a)nxp.com> This patch set is to add device tree support and enable U-Boot Driver Module PCIe driver on P1010RDB. Hou Zhiqiang (4): powerpc: Enable device tree support for P1010RDB powerpc: P1010RDB: Compile legacy PCIe routines conditionally powerpc: P1010RDB: Disable legacy PCIe driver when DM_PCI is enabled configs: P1010RDB: Enable PCIe driver arch/powerpc/dts/Makefile | 2 + arch/powerpc/dts/p1010rdb-pa.dts | 17 ++++++++ arch/powerpc/dts/p1010rdb-pa_36b.dts | 17 ++++++++ arch/powerpc/dts/p1010rdb-pb.dts | 17 ++++++++ arch/powerpc/dts/p1010rdb-pb_36b.dts | 17 ++++++++ arch/powerpc/dts/p1010rdb_32b.dtsi | 22 ++++++++++ arch/powerpc/dts/p1010rdb_36b.dtsi | 22 ++++++++++ arch/powerpc/dts/p1010si-post.dtsi | 46 ++++++++++++++++++++ arch/powerpc/dts/p1010si-pre.dtsi | 27 ++++++++++++ board/freescale/p1010rdb/p1010rdb.c | 4 +- configs/P1010RDB-PA_36BIT_NAND_defconfig | 7 ++- configs/P1010RDB-PA_36BIT_NOR_defconfig | 8 +++- configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 7 ++- configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 7 ++- configs/P1010RDB-PA_NAND_defconfig | 7 ++- configs/P1010RDB-PA_NOR_defconfig | 8 +++- configs/P1010RDB-PA_SDCARD_defconfig | 7 ++- configs/P1010RDB-PA_SPIFLASH_defconfig | 7 ++- configs/P1010RDB-PB_36BIT_NAND_defconfig | 7 ++- configs/P1010RDB-PB_36BIT_NOR_defconfig | 8 +++- configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 7 ++- configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 7 ++- configs/P1010RDB-PB_NAND_defconfig | 7 ++- configs/P1010RDB-PB_NOR_defconfig | 8 +++- configs/P1010RDB-PB_SDCARD_defconfig | 7 ++- configs/P1010RDB-PB_SPIFLASH_defconfig | 7 ++- include/configs/P1010RDB.h | 42 +++++++++++------- 27 files changed, 315 insertions(+), 34 deletions(-) create mode 100644 arch/powerpc/dts/p1010rdb-pa.dts create mode 100644 arch/powerpc/dts/p1010rdb-pa_36b.dts create mode 100644 arch/powerpc/dts/p1010rdb-pb.dts create mode 100644 arch/powerpc/dts/p1010rdb-pb_36b.dts create mode 100644 arch/powerpc/dts/p1010rdb_32b.dtsi create mode 100644 arch/powerpc/dts/p1010rdb_36b.dtsi create mode 100644 arch/powerpc/dts/p1010si-post.dtsi create mode 100644 arch/powerpc/dts/p1010si-pre.dtsi -- 2.17.1

1 4

[PATCH] arm: stm32mp: cleanup test on eth_env_set_enetaddr result
by Patrick Delaunay 14 Apr '20

14 Apr '20

Remove the unnecessary inversion on the eth_env_set_enetaddr() result which only make complex the code of setup_mac_address() and display an invalid value in the associated pr_err. Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- arch/arm/mach-stm32mp/cpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c index ea0bd94605..2a9b7c1987 100644 --- a/arch/arm/mach-stm32mp/cpu.c +++ b/arch/arm/mach-stm32mp/cpu.c @@ -491,8 +491,8 @@ __weak int setup_mac_address(void) return -EINVAL; } pr_debug("OTP MAC address = %pM\n", enetaddr); - ret = !eth_env_set_enetaddr("ethaddr", enetaddr); - if (!ret) + ret = eth_env_set_enetaddr("ethaddr", enetaddr); + if (ret) pr_err("Failed to set mac address %pM from OTP: %d\n", enetaddr, ret); #endif -- 2.17.1

3 2

[PATCH v1] colibri_t20: change maintainer
by Igor Opaniuk 14 Apr '20

14 Apr '20

From: Igor Opaniuk <igor.opaniuk(a)toradex.com> Take over maintainership for Colibri T20 module. Signed-off-by: Igor Opaniuk <igor.opaniuk(a)toradex.com> --- board/toradex/colibri_t20/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/toradex/colibri_t20/MAINTAINERS b/board/toradex/colibri_t20/MAINTAINERS index b251c000fe..2a8e6fb74b 100644 --- a/board/toradex/colibri_t20/MAINTAINERS +++ b/board/toradex/colibri_t20/MAINTAINERS @@ -1,5 +1,5 @@ COLIBRI_T20 -M: Lucas Stach <dev(a)lynxeye.de> +M: Igor Opaniuk <igor.opaniuk(a)toradex.com> S: Maintained F: board/toradex/colibri_t20/ F: include/configs/colibri_t20.h -- 2.17.1

2 2

[PATCH v5 1/5] cmd: mvebu: bubt: add A38x support
by Joel Johnson 14 Apr '20

14 Apr '20

Add support for Armada 38x devices in bubt flashing utility. This is based on (and streamlined from) the support in the SolidRun master-a38x vendor fork. Signed-off-by: Joel Johnson <mrjoel(a)lixil.net> Reviewed-by: Stefan Roese <sr(a)denx.de> --- v2 changes - none v3 changes - none v4 changes - none v5 changes - none --- cmd/mvebu/bubt.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c index 2041a7a29a..d399fb6da4 100644 --- a/cmd/mvebu/bubt.c +++ b/cmd/mvebu/bubt.c @@ -85,7 +85,29 @@ struct mvebu_image_info { u32 encrypt_start_offset; u32 encrypt_size; }; -#endif /* CONFIG_ARMADA_XXX */ +#elif defined(CONFIG_ARMADA_38X) /* A38X */ + +/* Structure of the main header, version 1 (Armada 370/38x/XP) */ +struct a38x_main_hdr_v1 { + u8 blockid; /* 0x0 */ + u8 flags; /* 0x1 */ + u16 reserved2; /* 0x2-0x3 */ + u32 blocksize; /* 0x4-0x7 */ + u8 version; /* 0x8 */ + u8 headersz_msb; /* 0x9 */ + u16 headersz_lsb; /* 0xA-0xB */ + u32 srcaddr; /* 0xC-0xF */ + u32 destaddr; /* 0x10-0x13 */ + u32 execaddr; /* 0x14-0x17 */ + u8 options; /* 0x18 */ + u8 nandblocksize; /* 0x19 */ + u8 nandbadblklocation; /* 0x1A */ + u8 reserved4; /* 0x1B */ + u16 reserved5; /* 0x1C-0x1D */ + u8 ext; /* 0x1E */ + u8 checksum; /* 0x1F */ +}; +#endif struct bubt_dev { char name[8]; @@ -621,7 +643,52 @@ static int check_image_header(void) return 0; } +#elif defined(CONFIG_ARMADA_38X) +static size_t a38x_header_size(const struct a38x_main_hdr_v1 *h) +{ + if (h->version == 1) + return (h->headersz_msb << 16) | le16_to_cpu(h->headersz_lsb); + + printf("Error: Invalid A38x image (header version 0x%x unknown)!\n", + h->version); + return 0; +} + +static uint8_t image_checksum8(const void *start, size_t len) +{ + u8 csum = 0; + const u8 *p = start; + + while (len) { + csum += *p; + ++p; + --len; + } + + return csum; +} +static int check_image_header(void) +{ + u8 checksum; + const struct a38x_main_hdr_v1 *hdr = + (struct a38x_main_hdr_v1 *)get_load_addr(); + const size_t image_size = a38x_header_size(hdr); + + if (!image_size) + return -ENOEXEC; + + checksum = image_checksum8(hdr, image_size); + checksum -= hdr->checksum; + if (checksum != hdr->checksum) { + printf("Error: Bad A38x image checksum. 0x%x != 0x%x\n", + checksum, hdr->checksum); + return -ENOEXEC; + } + + printf("Image checksum...OK!\n"); + return 0; +} #else /* Not ARMADA? */ static int check_image_header(void) { -- 2.25.0

2 5

[PATCH v1 u-boot-marvell 0/5] MVEBU ARM64 improvments + another Turris Mox patch
by Marek Behún 14 Apr '20

14 Apr '20

Hi, sorry for not sending these patches together with the others for Turris Mox, but these make changes to generic arm64 mvebu code, so I thought it would be better. Currently U-Boot on Turris Mox discovers RAM size by calling get_ram_size on the first gigabyte of memory. This is insufficient for new prototypes with 2 GB and 4 GB RAM. For the 2 GB variant it would be sufficient to simply call get_ram_size on the first 2 GB of memory, but the 4 GB variant is more problematic, because in order to support maximum usable RAM possible, ARM Trusted Firmware can change the default address of PCIe regions and also the DRAM memory windows are not consecutive. This series adds code that looks at how ATF configured CPU Address Decoder windows and accordingly changes mem_map regions for U-Boot's virtual memory, and accordingly reports RAM size in dram_init and RAM banks information in dram_init_banksize functions. The first patch moves Armada-8k specific code into Armada-8k specific directory. The second patch adds that looks at the configuration of CPU Address Decoder windows and does the above mentioned things. The third patch removes dram_init and dram_init_banksize in Turris Mox code so that the generic one which now works is used. The fourth patch adds a function which fixes the PCIe ranges property in the device-tree binary so that the driver will work even if ATF changed the address of PCIe window. The fifth patch calls this function on Turris Mox. It would be nice if someone tested these on other A3700 boards, like EspressoBIN. Marek Marek Behún (5): arm64: mvebu: armada-8k: move dram init code arm64: mvebu: a37xx: improve code determining memory info structures arm: mvebu: turris_mox: support devices with RAM > 1 GB arm64: mvebu: a37xx: add device-tree fixer for PCIe regions arm: mvebu: turris_mox: fix PCIe ranges in device tree arch/arm/mach-mvebu/arm64-common.c | 51 +---- arch/arm/mach-mvebu/armada3700/cpu.c | 304 ++++++++++++++++++++++--- arch/arm/mach-mvebu/armada8k/Makefile | 3 +- arch/arm/mach-mvebu/armada8k/dram.c | 52 +++++ arch/arm/mach-mvebu/include/mach/cpu.h | 11 + board/CZ.NIC/turris_mox/turris_mox.c | 27 +-- configs/turris_mox_defconfig | 2 +- 7 files changed, 361 insertions(+), 89 deletions(-) create mode 100644 arch/arm/mach-mvebu/armada8k/dram.c -- 2.24.1

3 14

[RFC 00/14] efi_loader: add capsule update support
by AKASHI Takahiro 14 Apr '20

14 Apr '20

Summary ======= 'UpdateCapsule' is one of runtime services defined in UEFI specification and its aim is to allow a caller to pass information to the firmware. This is mostly used to update firmware binary on devices by instructions from OS. In this patch series, all the related definitions and structures are given as UEFI specification describes and basic framework for capsule support is implemented. Currently supported types of capsule are * firmware update (Firmware Management Protocol or simply FMP) * variable update UpdateCapsule is a runtime services function, but is, at least initially, provided only before exiting boot services alike other runtime functions. This is because modifying storage which may be shared with OS must be carefully designed and there is no general assumption to do that as in the case of [Get/]SetVariable. Instead, any capsule can be handed over to the firmware as a file on a specific file system. In other words, we only support "capsules on disk" for now. Regarding firmware update, most of functionality is provided by FMP driver and it will be by nature system/platform-specific. So you can and should implement FMP drivers based on your system requirements. In this patch series, only a simple FMP driver based on FIT image for a single region is supported. (So it is "for reference only") See more details in "efi_loader: capsule: add simple firmware management protocol." Regarding variable update, the implementation here is based on a draft proposal[1] by Peter in Boot-arch ML. The specification should be discussed and finalized first. So the code doesn't fully implement Peter's idea. [1] https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.ht… Patch structure =============== Patch#1-#4: preparatory patches Patch#5-#11: main part of implementation Patch#12-#14: utilities and tests Test ==== * passed all the pytests which are included in this patch series on sandbox build. * passed Travis CI. Currently, my pytest requires the following prerequisite patch to run without errors: [2] https://lists.denx.de/pipermail/u-boot/2020-March/401726.html [3] https://lists.denx.de/pipermail/u-boot/2020-March/401727.html In addition, you have to enable CONFIG_ENV_IS_IN_SPI_FLASH and CONFIG_SPI_FLASH_SANDBOX to successfully run the test. Issues ====== * Timing of executing capsules-on-disk Currently, processing a capsule is triggered only as part of UEFI subsystem initialization. This means that, for example, firmware update, may not take place at system booting time and will potentially be delayed until a first call of any UEFI functions. TODO's ====== (May or may not be addressed in future versions of this series.) * capsule authentication * capsule dependency (dependency expression instruction set) * loading drivers in a capsule * handling RESET flag in a capsule and QeuryCapsuleCaps * full semantics of ESRT (EFI System Resource Table) * enabling capsule API at runtime * json capsule * recovery from update failure Changes ======= Initial release as RFC (March 17, 2020) AKASHI Takahiro (14): efi_loader: define OsIndicationsSupported flags efi_loader: define System Resource Table macros efi_loader: export a couple of protocol related functions efi_loader: correct a definition of struct efi_capsule_header efi_loader: define UpdateCapsule api efi_loader: capsule: add capsule_on_disk support efi_loader: capsule: add memory range capsule definitions efi_loader: capsule: support firmware update efi_loader: add simple firmware management protocol for FIT image efi_loader: capsule: support variable update efi_loader: variable: export variables table for runtime access cmd: add "efidebug capsule" command tools: add mkeficapsule command for UEFI capsule update test test/py: add efi capsule test cmd/efidebug.c | 234 +++++ include/efi_api.h | 214 ++++- include/efi_loader.h | 53 ++ lib/efi_loader/Kconfig | 65 ++ lib/efi_loader/Makefile | 2 + lib/efi_loader/efi_boottime.c | 29 +- lib/efi_loader/efi_capsule.c | 860 ++++++++++++++++++ lib/efi_loader/efi_firmware.c | 191 ++++ lib/efi_loader/efi_runtime.c | 104 ++- lib/efi_loader/efi_setup.c | 41 +- lib/efi_loader/efi_variable.c | 109 +++ test/py/tests/test_efi_capsule/conftest.py | 109 +++ test/py/tests/test_efi_capsule/defs.py | 21 + .../test_efi_capsule/test_capsule_firmware.py | 102 +++ .../test_efi_capsule/test_capsule_variable.py | 141 +++ test/py/tests/test_efi_capsule/uboot_env.its | 25 + tools/Makefile | 3 + tools/mkeficapsule.c | 501 ++++++++++ 18 files changed, 2744 insertions(+), 60 deletions(-) create mode 100644 lib/efi_loader/efi_capsule.c create mode 100644 lib/efi_loader/efi_firmware.c create mode 100644 test/py/tests/test_efi_capsule/conftest.py create mode 100644 test/py/tests/test_efi_capsule/defs.py create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware.py create mode 100644 test/py/tests/test_efi_capsule/test_capsule_variable.py create mode 100644 test/py/tests/test_efi_capsule/uboot_env.its create mode 100644 tools/mkeficapsule.c -- 2.25.1

4 48