March 2021 - U-Boot

[PATCH v3 0/6] Add rt-thread art-pi board support
by dillon.minfei＠gmail.com 31 Mar '21

31 Mar '21

From: dillon min <dillon.minfei(a)gmail.com> These patches aim to adds u-boot support on art-pi board. the board resources: - stm32h750xbh6 128k flash, 1024k sram - 32MiB sdram - 16MiB spi flash - 8MiB qspi flash - onboard wifi, bt, fm the detail board information can be found at: https://art-pi.gitee.io/website/ --- changes in v3: two mirror changes in [PATCH v3 2/6], others same to version 2 - remove "for STMicroelectronics." from arch/arm/dts/stm32h750-pinctrl.dtsi - correct misspelling parameters you can found detail patch v2 information at link: https://patchwork.ozlabs.org/project/uboot/list/?series=236009 changes in v2: - fix wrong author/date in previous submit - sync with kernel device tree files - add st,stm32h750-pinctrl in doc and pinctrl driver *** BLURB HERE *** dillon min (6): ARM: dts: stm32: split sdram pin & timing parameter into specific board dts ARM: dts: stm32: Add RT-Thread art-pi board support board: Add rt-thread art-pi board support ram: stm32: fix strsep failed on read only memory dt-bindings: pinctrl: stm32: Add st,stm32h750-pinctrl for stm32h750 soc pinctrl: stm32: Add st,stm32h750-pinctrl compatible string arch/arm/dts/Makefile | 3 +- arch/arm/dts/stm32h7-pinctrl.dtsi | 340 +++++++++++++++++++++ arch/arm/dts/stm32h7-u-boot.dtsi | 100 +----- arch/arm/dts/stm32h743-pinctrl.dtsi | 307 +------------------ arch/arm/dts/stm32h743.dtsi | 168 +++++++++- arch/arm/dts/stm32h743i-disco-u-boot.dtsi | 98 ++++++ arch/arm/dts/stm32h743i-eval-u-boot.dtsi | 98 ++++++ arch/arm/dts/stm32h750-pinctrl.dtsi | 11 + arch/arm/dts/stm32h750.dtsi | 5 + arch/arm/dts/stm32h750i-art-pi-u-boot.dtsi | 81 +++++ arch/arm/dts/stm32h750i-art-pi.dts | 188 ++++++++++++ arch/arm/mach-stm32/stm32h7/Kconfig | 4 + board/st/stm32h750-art-pi/Kconfig | 19 ++ board/st/stm32h750-art-pi/MAINTAINERS | 7 + board/st/stm32h750-art-pi/Makefile | 6 + board/st/stm32h750-art-pi/stm32h750-art-pi.c | 58 ++++ configs/stm32h750-art-pi_defconfig | 51 ++++ .../pinctrl/st,stm32-pinctrl.txt | 1 + drivers/pinctrl/pinctrl_stm32.c | 1 + drivers/ram/stm32_sdram.c | 3 + include/configs/stm32h750-art-pi.h | 48 +++ include/dt-bindings/memory/stm32-sdram.h | 2 + 22 files changed, 1198 insertions(+), 401 deletions(-) create mode 100644 arch/arm/dts/stm32h7-pinctrl.dtsi create mode 100644 arch/arm/dts/stm32h750-pinctrl.dtsi create mode 100644 arch/arm/dts/stm32h750.dtsi create mode 100644 arch/arm/dts/stm32h750i-art-pi-u-boot.dtsi create mode 100644 arch/arm/dts/stm32h750i-art-pi.dts create mode 100644 board/st/stm32h750-art-pi/Kconfig create mode 100644 board/st/stm32h750-art-pi/MAINTAINERS create mode 100644 board/st/stm32h750-art-pi/Makefile create mode 100644 board/st/stm32h750-art-pi/stm32h750-art-pi.c create mode 100644 configs/stm32h750-art-pi_defconfig create mode 100644 include/configs/stm32h750-art-pi.h -- 2.7.4

3 10

[PATCH 1/1] efi_loader: Uart device path missing break
by Heinrich Schuchardt 31 Mar '21

31 Mar '21

In the devicepath node to text conversion for Uart nodes a break statement is missing. Indicated by Coverity Scan CID 330038 Fixes: 62df6e9c9994 ("efi_loader: Uart device path") Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_device_path_to_text.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index 43554cd771..675e80bcb8 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -126,8 +126,10 @@ static char *dp_msging(char *s, struct efi_device_path *dp) switch (uart->stop_bits) { case 2: s += sprintf(s, "1.5)"); + break; default: s += sprintf(s, "%d)", uart->stop_bits); + break; } break; } -- 2.30.2

1 1

[PATCH 1/1] efi_loader: typo 'devide path'
by Heinrich Schuchardt 31 Mar '21

31 Mar '21

Fix a typo in helloworld.efi. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/helloworld.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c index 5c8b7a96f9..3f215e2a46 100644 --- a/lib/efi_loader/helloworld.c +++ b/lib/efi_loader/helloworld.c @@ -181,7 +181,7 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle, (void **)&device_path); if (ret != EFI_SUCCESS) { con_out->output_string - (con_out, L"Missing devide path for device handle\r\n"); + (con_out, L"Missing device path for device handle\r\n"); goto out; } con_out->output_string(con_out, L"Boot device: "); -- 2.31.0

1 0

[PATCH] ls1012a: use default scan_dev_for_boot
by Mian Yousaf Kaukab 31 Mar '21

31 Mar '21

From: Mian Yousaf Kaukab <ykaukab(a)suse.de> scan_dev_for_efi is supposed to be called from scan_dev_for_boot. However, this call is missing for ls1012a boards. As a result EFI boot doesn’t work. Fix this issue by removing custom definition of scan_dev_for_boot and use the default definition instead. Signed-off-by: Mian Yousaf Kaukab <ykaukab(a)suse.de> --- include/configs/ls1012a2g5rdb.h | 7 ------- include/configs/ls1012afrdm.h | 7 ------- include/configs/ls1012afrwy.h | 7 ------- include/configs/ls1012aqds.h | 7 ------- include/configs/ls1012ardb.h | 7 ------- 5 files changed, 35 deletions(-) diff --git a/include/configs/ls1012a2g5rdb.h b/include/configs/ls1012a2g5rdb.h index bbc3ffd7f0d3..9962b9872af5 100644 --- a/include/configs/ls1012a2g5rdb.h +++ b/include/configs/ls1012a2g5rdb.h @@ -61,13 +61,6 @@ "run scan_dev_for_boot; " \ "fi; " \ "done\0" \ - "scan_dev_for_boot=" \ - "echo Scanning ${devtype} " \ - "${devnum}:${distro_bootpart}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run scan_dev_for_scripts; " \ - "done;" \ - "\0" \ "boot_a_script=" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${scriptaddr} ${prefix}${script}; " \ diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h index 8de20e3ff450..02dd59892bcc 100644 --- a/include/configs/ls1012afrdm.h +++ b/include/configs/ls1012afrdm.h @@ -47,13 +47,6 @@ "run scan_dev_for_boot; " \ "fi; " \ "done\0" \ - "scan_dev_for_boot=" \ - "echo Scanning ${devtype} " \ - "${devnum}:${distro_bootpart}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run scan_dev_for_scripts; " \ - "done;" \ - "\0" \ "installer=load usb 0:2 $load_addr " \ "/flex_installer_arm64.itb; " \ "bootm $load_addr#$board\0" \ diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h index 29c344c63a95..ba152834d5ac 100644 --- a/include/configs/ls1012afrwy.h +++ b/include/configs/ls1012afrwy.h @@ -80,13 +80,6 @@ "run scan_dev_for_boot; " \ "fi; " \ "done\0" \ - "scan_dev_for_boot=" \ - "echo Scanning ${devtype} " \ - "${devnum}:${distro_bootpart}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run scan_dev_for_scripts; " \ - "done;" \ - "\0" \ "boot_a_script=" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${scriptaddr} ${prefix}${script}; " \ diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h index c4c9b7f5019f..36be8f42c978 100644 --- a/include/configs/ls1012aqds.h +++ b/include/configs/ls1012aqds.h @@ -131,13 +131,6 @@ "run scan_dev_for_boot; " \ "fi; " \ "done\0" \ - "scan_dev_for_boot=" \ - "echo Scanning ${devtype} " \ - "${devnum}:${distro_bootpart}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run scan_dev_for_scripts; " \ - "done;" \ - "\0" \ "boot_a_script=" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${scriptaddr} ${prefix}${script}; " \ diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h index 94e742ee8446..582945b2ab19 100644 --- a/include/configs/ls1012ardb.h +++ b/include/configs/ls1012ardb.h @@ -79,13 +79,6 @@ "run scan_dev_for_boot; " \ "fi; " \ "done\0" \ - "scan_dev_for_boot=" \ - "echo Scanning ${devtype} " \ - "${devnum}:${distro_bootpart}...; " \ - "for prefix in ${boot_prefixes}; do " \ - "run scan_dev_for_scripts; " \ - "done;" \ - "\0" \ "boot_a_script=" \ "load ${devtype} ${devnum}:${distro_bootpart} " \ "${scriptaddr} ${prefix}${script}; " \ -- 2.26.2

2 1

[PATCH] doc: mmc man-page
by Jaehoon Chung 30 Mar '21

30 Mar '21

Provide a man-pages for the mmc command. Signed-off-by: Jaehoon Chung <jh80.chung(a)samsung.com> --- doc/usage/index.rst | 1 + doc/usage/mmc.rst | 182 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 183 insertions(+) create mode 100644 doc/usage/mmc.rst diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 6c59bbadab45..15c682ceface 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -30,6 +30,7 @@ Shell commands load loady mbr + mmc pstore qfw sbi diff --git a/doc/usage/mmc.rst b/doc/usage/mmc.rst new file mode 100644 index 000000000000..00a21a6e12e7 --- /dev/null +++ b/doc/usage/mmc.rst @@ -0,0 +1,182 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +mmc command +============ + +Synopsis +-------- + +:: + + mmc info + mmc read addr blk# cnt + mmc write addr blk# cnt + mmc erase blk# cnt + mmc rescan + mmc part + mmc dev [dev] [part] + mmc list + mmc wp + mmc bootbus <dev> <boot_bus_width> <reset_boot_bus_width> <boot_mode> + mmc bootpart-resize <dev> <dev part size MB> <RPMB part size MB> + mmc partconf <dev> [boot_ack boot_partition partition_access] + mmc rst-function <dev> <value> + +Description +----------- + +The mmc command is used to control MMC(eMMC/SD) device. + +The *mmc info* command displays information (Manufacturer ID, OEM, Name, Bus Speed, Mode, ...) of MMC device. + +The *mmc read* command reads raw data to memory address from MMC device with block offset and count. + +The *mmc write* command writes raw data to MMC device from memory address with block offset and count. + addr + memory address + blk# + start block offset + cnt + block count + +The *mmc erase* command erases MMC device from block offset until count. + blk# + start block offset + cnt + block count + +The *mmc rescan* command scans the available MMC device. + +The *mmc part* command displays the list available partition on current mmc device. + +The *mmc dev* command shows or set current mmc device. + dev + device number to change + part + partition number to change + +The *mmc list* command displays the list available devices. + +The *mmc wp* command enables "power on write protect" function for boot partitions. + +The *mmc bootbus* command sets the BOOT_BUS_WIDTH field. + BOOTU_BUS_WIDTH[177] is one of EXT_CSD register. (*Refer to eMMC specification*) + +The *mmc partconf* command shows or changes PARTITION_CONFIG field. + boot_ack + boot acknowledge value + boot_partition + boot partition to enable for boot + 0x0 + Device not boot enabled(default) + 0x1 + Boot partition1 enabled for boot + 0x2 + Boot partition2 enabled for boot + 0x7 + User area enabled for boot + others + Reserved + partition_access + partitions to access + +The *mmc-bootpart-resize* command changes sizes of boot and RPMB partitions. + dev + device number + boot part size MB + target size of boot partition + RPMB part size MB + target size of RPMB partition + +The *mmc rst-function* command changes the RST_n_FUNCTION field. + **WARNING**: This is a write-once field. (*Refer to eMMC specification*) + RST_n_FUNCTION[162] is one of EXT_CSD register. (Readable and Writable once) + 0x0 + RST_n signal is temporarily disabled (default) + 0x1 + RST_n signal is permanently enabled + 0x2 + RST_n signal is permanently disabled + 0x3 + Reserved + + +Example +------- + +The *mmc info* command displays device's capabilities: +:: + + => mmc info + Device: EXYNOS DWMMC + Manufacturer ID: 45 + OEM: 100 + Name: SDW16 + Bus Speed: 52000000 + Mode: MMC DDR52 (52MHz) + Rd Block Len: 512 + MMC version 5.0 + High Capacity: Yes + Capacity: 14.7 GiB + Bus Width: 8-bit DDR + Erase Group Size: 512 KiB + HC WP Group Size: 8 MiB + User Capacity: 14.7 GiB WRREL + Boot Capacity: 4 MiB ENH + RPMB Capacity: 4 MiB ENH + Boot area 0 is not write protected + Boot area 1 is not write protected + +The raw data can be read/written via *mmc read/write* command: +:: + + => mmc read 0x40000000 0x5000 0x100 + MMC read: dev # 0, block # 20480, count 256 ... 256 blocks read: OK + + => mmc write 0x40000000 0x5000 0x10 + MMC write: dev # 0, block # 20480, count 256 ... 256 blocks written: OK + +The partition list can be shown via *mmc part* command: +:: + + => mmc part + Partition Map for MMC device 0 -- Partition Type: DOS + + Part Start Sector Num Sectors UUID Type + 1 8192 131072 dff8751a-01 0e Boot + 2 139264 6291456 dff8751a-02 83 + 3 6430720 1048576 dff8751a-03 83 + 4 7479296 23298048 dff8751a-04 05 Extd + 5 7481344 307200 dff8751a-05 83 + 6 7790592 65536 dff8751a-06 83 + 7 7858176 16384 dff8751a-07 83 + 8 7876608 22900736 dff8751a-08 83 + +The current device can be shown or set via *mmc dev* command: +:: + + => mmc dev + switch to partitions #0, OK + mmc0(part0) is current device + => mmc dev 2 0 + switch to partitions #0, OK + mmc2 is current device + +The list of available devices can be shown via *mmc list* command: +:: + + => mmc list + mmc list + EXYNOS DWMMC: 0 (eMMC) + EXYNOS DWMMC: 2 (SD) + +Configuration +------------- + +The mmc command is only available if CONFIG_CMD_MMC=y. +Some commands need to enable more configuration. + +write, erase + CONFIG_MMC_WRITE +bootbus, bootpart-resize, partconf, rst-function + CONFIG_SUPPORT_EMMC_BOOT=y -- 2.29.0

2 2

[PATCH v2] efi_loader: Change ptr arithmetics tcg eventlog buffer
by Ilias Apalodimas 30 Mar '21

30 Mar '21

Although ptr arithmetics are allowed with extensions in gcc, they are not allowed by the C spec. So switch to (void *)(uintptr_t) instead Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> --- changes since v1: Switch over to uintptr as Alex suggested lib/efi_loader/efi_tcg2.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index 09046844c723..ed86a220fbd6 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -176,13 +176,14 @@ static efi_status_t tcg2_agile_log_append(u32 pcr_index, u32 event_type, struct tpml_digest_values *digest_list, u32 size, u8 event[]) { - void *log = event_log.buffer + event_log.pos; + void *log = (void *)((uintptr_t)event_log.buffer + event_log.pos); size_t pos; int i; u32 event_size; if (event_log.get_event_called) - log = event_log.final_buffer + event_log.final_pos; + log = (void *)((uintptr_t)event_log.final_buffer + + event_log.final_pos); /* * size refers to the length of event[] only, we need to check against @@ -197,24 +198,24 @@ static efi_status_t tcg2_agile_log_append(u32 pcr_index, u32 event_type, put_unaligned_le32(pcr_index, log); pos = offsetof(struct tcg_pcr_event2, event_type); - put_unaligned_le32(event_type, log + pos); + put_unaligned_le32(event_type, (void *)((uintptr_t)log + pos)); pos = offsetof(struct tcg_pcr_event2, digests); /* count */ - put_unaligned_le32(digest_list->count, log + pos); + put_unaligned_le32(digest_list->count, (void *)((uintptr_t)log + pos)); pos += offsetof(struct tpml_digest_values, digests); for (i = 0; i < digest_list->count; i++) { u16 hash_alg = digest_list->digests[i].hash_alg; u8 *digest = (u8 *)&digest_list->digests[i].digest; - put_unaligned_le16(hash_alg, log + pos); + put_unaligned_le16(hash_alg, (void *)((uintptr_t)log + pos)); pos += offsetof(struct tpmt_ha, digest); - memcpy(log + pos, digest, alg_to_len(hash_alg)); + memcpy((void *)((uintptr_t)log + pos), digest, alg_to_len(hash_alg)); pos += alg_to_len(hash_alg); } - put_unaligned_le32(size, log + pos); + put_unaligned_le32(size, (void *)((uintptr_t)log + pos)); pos += sizeof(u32); /* tcg_pcr_event2 event_size*/ - memcpy(log + pos, event, size); + memcpy((void *)((uintptr_t)log + pos), event, size); pos += size; /* make sure the calculated buffer is what we checked against */ @@ -1046,7 +1047,7 @@ static efi_status_t efi_init_event_log(void) put_unaligned_le32(0, &event_header->pcr_index); put_unaligned_le32(EV_NO_ACTION, &event_header->event_type); memset(&event_header->digest, 0, sizeof(event_header->digest)); - ret = create_specid_event(dev, event_log.buffer + sizeof(*event_header), + ret = create_specid_event(dev, (void *)((uintptr_t)event_log.buffer + sizeof(*event_header)), &spec_event_size); if (ret != EFI_SUCCESS) goto out; -- 2.31.0

2 1

[scan-admin@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
by Tom Rini 30 Mar '21

30 Mar '21

----- Forwarded message from scan-admin(a)coverity.com ----- Date: Mon, 29 Mar 2021 21:36:46 +0000 (UTC) From: scan-admin(a)coverity.com To: tom.rini(a)gmail.com Subject: New Defects reported by Coverity Scan for Das U-Boot Hi, Please find the latest report on new defect(s) introduced to Das U-Boot found with Coverity Scan. 1 new defect(s) introduced to Das U-Boot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 330038: Control flow issues (MISSING_BREAK) /lib/efi_loader/efi_device_path_to_text.c: 127 in dp_msging() ________________________________________________________________________________________________________ *** CID 330038: Control flow issues (MISSING_BREAK) /lib/efi_loader/efi_device_path_to_text.c: 127 in dp_msging() 121 case DEVICE_PATH_SUB_TYPE_MSG_UART: { 122 struct efi_device_path_uart *uart = 123 (struct efi_device_path_uart *)dp; 124 s += sprintf(s, "Uart(%lld,%d,%d,", uart->baud_rate, 125 uart->data_bits, uart->parity); 126 switch (uart->stop_bits) { >>> CID 330038: Control flow issues (MISSING_BREAK) >>> The case for value "2" is not terminated by a 'break' statement. 127 case 2: 128 s += sprintf(s, "1.5)"); 129 default: 130 s += sprintf(s, "%d)", uart->stop_bits); 131 } 132 break; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… To manage Coverity Scan email notifications for "tom.rini(a)gmail.com", click https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P… ----- End forwarded message ----- -- Tom

1 0

[RFC PATCH v1 0/3] psci: add support for SYSTEM_RESET2 and PSCI_FEATURES
by Igor Opaniuk 30 Mar '21

30 Mar '21

From: Igor Opaniuk <igor.opaniuk(a)foundries.io> This adds support for: * PSCI_FEATURES, introduced in PSCI 1.0. This provides API that allows discovering whether a specific PSCI function is implemented and its features. * SYSTEM_RESET2, introduced in PSCI 1.1, which extends existing SYSTEM_RESET. It provides support for vendor-specific resets, providing reset_type as an additional param. Also PSCI sysreset driver is refactored to use new API. CI: https://dev.azure.com/igoropaniuk/u-boot/_build/results?buildId=16&view=res… Igor Opaniuk (3): psci: add v1.0/v1.1 definitions from Linux psci: add features/reset2 support sysreset: psci: use psci driver exported functions drivers/firmware/psci.c | 70 ++++++++++++++++++++++++++++++++ drivers/sysreset/sysreset_psci.c | 8 +--- include/linux/psci.h | 31 ++++++++++++++ 3 files changed, 103 insertions(+), 6 deletions(-) -- 2.25.1

1 3

RE: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages
by raghu.ncstate＠icloud.com 30 Mar '21

30 Mar '21

Julius, Simon, It appears there are opinions you carry around UUID being complicated, bloated, code being an eyesore, parsing these lists early with MMU/Caches disabled, calculating checksums etc. While there is certainly a LOT of truth to those statements, these concerns need to be put into context and may not necessarily apply to all platforms running TF-A. Standardization and interoperability may be valued more on some platforms and some of the bloat and performance issues may be worth those tradeoffs. Some of these concerns may not even apply on powerful CPU’s and SoC’s with lots of memory. Also a quick grep for “uuid” in the TF-A repository shows that there is significant use of UUID’s for FIP, some SMC’s, secure partitions etc so use of UUID is not something new to TF-A. While there are many ways to solve the same problem, there are also potential dis-advantages to something like the mechanism pointed out below. For example, this is yet another solution to an already solved problem. If we use UEFI hob’s, the code and problem has been solved for decades and there is code re-use possible and that *potentially*(opinions may vary) is better for security as there have been eyes on it for long and is more stable.(I’m very aware UEFI is not the gold standard for security, but again, it is a blanket statement to say all UEFI code is bad). Does the method mentioned below allow you to create a dynamic list of arbitrary lengths and NOT lists of lengths decided at compile time? It appears that it is mainly being used on lists fixed at compile time. What about interoperability with UEFI? Coreboot is great for platforms/companies that use it but what about platforms that *must* use UEFI for various reasons? Do we need a conversion from the method below to a UEFI HOB if BL33 is UEFI? Clearly the solution below was tailored to coreboot. We can support multiple ways in the same code base through build and run time options and a platform should be free to make calls on whether the problems you mentioned below really apply or not. What is a pain to do(having co-ordination with multiple companies vs vendor defined tags/UUID’s) is also subjective and whether or not it is overstated is matter of opinion/context. I think it may be best to discuss this in the call and understand the requirements fully. It may turn out that what you have proposed below works anyway 😊 Thanks Raghu From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A Sent: Wednesday, March 24, 2021 7:44 PM To: Simon Glass <sjg(a)chromium.org> Cc: Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com>; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org>; tf-a(a)lists.trustedfirmware.org; U-Boot Mailing List <u-boot(a)lists.denx.de>; Paul Isaac's <paul.isaacs(a)linaro.org>; Ron Minnich <rminnich(a)google.com> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages Just want to point out that TF-A currently already supports a (very simple) mechanism like this: https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/… It's just a linked list of tagged elements. The tag space is split into TF-A-wide generic tags and SiP-specific tags (with plenty of room to spare if more areas need to be defined -- a 64-bit tag can fit a lot). This is currently being used by some platforms that run coreboot in place of BL1/BL2, to pass information from coreboot (BL2) to BL31. I would echo Simon's sentiment of keeping this as simple as possible and avoiding complicated and bloated data structures with UUIDs. You usually want to parse something like this as early as possible in the passed-to firmware stage, particularly if the structure encodes information about the debug console (like it does for the platforms I mentioned above). For example, in BL31 this basically means doing it right after moving from assembly to C in bl31_early_platform_setup2() to get the console up before running anything else. At that point in the BL31 initialization, the MMU and caches are disabled, so data accesses are pretty expensive and you don't want to spend a lot of parsing effort or calculate complicated checksums or the like. You just want something extremely simple where you ideally have to touch every data word only once. On Wed, Mar 24, 2021 at 5:06 PM Simon Glass via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > wrote: Hi Harb, On Wed, 24 Mar 2021 at 11:39, Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com <mailto:abdulhamid@os.amperecomputing.com> > wrote: Hello Folks, Appreciate the feedback and replies on this. Glad to see that there is interest in this topic. 😊 I try to address the comments/feedback from Francois and Simon below…. <mailto:francois.ozog@linaro.org> @François Ozog – happy to discuss this on a zoom call. I will make that time slot work, and will be available to attend April 8, 4pm CT. Note that I’m using the term “HOB” here more generically, as there are typically vendor specific structures beyond the resource descriptor HOB, which provides only a small subset of the information that needs to be passed between the boot phases. The whole point here is to provide mechanism to develop firmware that we can build ARM Server SoC’s that support *any* BL33 payload (e.g. EDK2, AptioV, CoreBoot, and maybe even directly boot strapping LinuxBoot at some point). In other-words, we are trying to come up with a TF-A that would be completely agnostic to the implementation of BL33 (i.e. BL33 is built completely independently by a separate entity – e.g. an ODM/OEM). Keep in mind, in the server/datacenter market segment we are not building vertically integrated systems with a single entity compiling firmware/software stacks like most folks in TF-A have become use to. There are two categories of higher level firmware code blobs in the server/datacenter model: 1. “SoC” or “silicon” firmware – in TF-A this may map to BL1, BL2, BL31, and *possibly* one or more BL32 instances 2. “Platform” or “board” firmware – in TF-A this may map to BL33 and *possibly* one or more BL32 instances. Even the platform firmware stack could be further fragmented by having multiple entities involved in delivering the entire firmware stack: IBVs, ODMs, OEMs, CSPs, and possibly even device vendor code. To support a broad range of platform designs with a broad range of memory devices, we need a crisp and clear contract between the SoC firmware that initializes memory (e.g. BL2) and how that platform boot firmware (e.g. BL33) gathers information about what memory that was initialized, at what speeds, NUMA topology, and many other relevant information that needs to be known and comprehended by the platform firmware and eventually by the platform software. I understand the versatility of DT, but I see two major problems with DT: * DT requires more complicated parsing to get properties, and even more complex to dynamically set properties – this HOB structures may need to be generated in boot phases where DDR is not available, and therefore we will be extremely memory constrained. * DT is probably overkill for this purpose – We really just want a list of pointers to simple C structures that code cast (e.g. JEDEC SPD data blob) I think that we should not mix the efforts around DT/ACPI specs with what we are doing here, because those specs and concepts were developed for a completely different purpose (i.e. abstractions needed for OS / RTOS software, and not necessarily suitable for firmware-to-firmware hand-offs). Frankly, I would personally push back pretty hard on defining SMC’s for something that should be one way information passing. Every SMC we add is another attack vector to the secure world and an increased burden on the folks that have to do security auditing and threat analysis. I see no benefit in exposing these boot/HOB/BOB structures at run-time via SMC calls. Please do let me know if you disagree and why. Look forward to discussing on this thread or on the call. <mailto:sjg@chromium.org> @Simon Glass - Thanks for the pointer to bloblist. I briefly reviewed and it seems like a good baseline for what we may be looking for. That being said, I would say that there is some benefit in having some kind of unique identifiers (e.g. UUID or some unique signature) so that we can tie standardized data structures (based on some future TBD specs) to a particular ID. For example, if the TPM driver in BL33 is looking for the TPM structure in the HOB/BOB list, and may not care about the other data blobs. The driver needs a way to identify and locate the blob it cares about. The tag is intended to serve that purpose, although perhaps it should switch from an auto-allocating enum to one with explicit values for each entry and a range for 'local' use. I guess we can achieve this with the tag, but the problem with tag when you have eco-system with a lot of parties doing parallel development, you can end up with tag collisions and folks fighting about who has rights to what tag values. We would need some official process for folks to register tags for whatever new structures we define, or maybe some tag range for vendor specific structures. This comes with a lot of pain and bureaucracy. On the other hand, UUID has been a proven way to make it easy to just define your own blobs with *either* standard or vendor specific structures without worry of ID collisions between vendors. True. I think the pain is overstated, though. In this case I think we actually want something that can be shared between projects and orgs, so some amount of coordination could be considered a benefit. It could just be a github pull request. I find the UUID unfriendly and not just to code size and eyesight! Trying to discover what GUIDs mean or are valid is quite tricky. E.g. see this code: #define FSP_HOB_RESOURCE_OWNER_TSEG_GUID \ EFI_GUID(0xd038747c, 0xd00c, 0x4980, \ 0xb3, 0x19, 0x49, 0x01, 0x99, 0xa4, 0x7d, 0x55) (etc.) static struct guid_name { efi_guid_t guid; const char *name; } guid_name[] = { { FSP_HOB_RESOURCE_OWNER_TSEG_GUID, "TSEG" }, { FSP_HOB_RESOURCE_OWNER_FSP_GUID, "FSP" }, { FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID, "SMM PEI SMRAM" }, { FSP_NON_VOLATILE_STORAGE_HOB_GUID, "NVS" }, { FSP_VARIABLE_NV_DATA_HOB_GUID, "Variable NVS" }, { FSP_GRAPHICS_INFO_HOB_GUID, "Graphics info" }, { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID1, "PCD database ea" }, { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID2, "PCD database 9b" }, (never figured out what those two are) { FSP_HOB_RESOURCE_OWNER_PEIM_DXE_GUID, "PEIM Init DXE" }, { FSP_HOB_RESOURCE_OWNER_ALLOC_STACK_GUID, "Alloc stack" }, { FSP_HOB_RESOURCE_OWNER_SMBIOS_MEMORY_GUID, "SMBIOS memory" }, { {}, "zero-guid" }, {} }; static const char *guid_to_name(const efi_guid_t *guid) { struct guid_name *entry; for (entry = guid_name; entry->name; entry++) { if (!guidcmp(guid, &entry->guid)) return entry->name; } return NULL; } Believe it or not it took a fair bit of effort to find just that small list, with nearly every one in a separate doc, from memory. We can probably debate whether there is any value in GUID/UUID or not during the call… but again, boblist seems like a reasonable starting point as an alternative to HOB. Indeed. There is certainly value in both approaches. Regards, Simon Thanks, --Harb From: François Ozog <francois.ozog(a)linaro.org <mailto:francois.ozog@linaro.org> > Sent: Tuesday, March 23, 2021 10:00 AM To: François Ozog <francois.ozog(a)linaro.org <mailto:francois.ozog@linaro.org> >; Ron Minnich <rminnich(a)google.com <mailto:rminnich@google.com> >; Paul Isaac's <paul.isaacs(a)linaro.org <mailto:paul.isaacs@linaro.org> > Cc: Simon Glass <sjg(a)chromium.org <mailto:sjg@chromium.org> >; Harb Abdulhamid OS <abdulhamid(a)os.amperecomputing.com <mailto:abdulhamid@os.amperecomputing.com> >; Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org <mailto:boot-architecture@lists.linaro.org> >; tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages +Ron Minnich <mailto:rminnich@google.com> +Paul Isaac's <mailto:paul.isaacs@linaro.org> Adding Ron and Paul because I think this interface should be also benefiting LinuxBoot efforts. On Tue, 23 Mar 2021 at 11:17, François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > wrote: Hi, I propose we cover the topic at the next Trusted Substrate <https://collaborate.linaro.org/display/TS/Trusted+Substrate+Home> zoom call <https://linaro-org.zoom.us/j/94563644892> on April 8th 4pm CET. The agenda: ABI between non-secure firmware and the rest of firmware (EL3, S-EL1, S-EL2, SCP) to adapt hardware description to some runtime conditions. runtime conditions here relates to DRAM size and topology detection, secure DRAM memory carvings, PSCI and SCMI interface publishing. For additional background on existing metadata: <https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2019.p…> UEFI Platform Initialization Specification Version 1.7, 5.5 Resource Descriptor HOB Out of the ResourceType we care about is EFI_RESOURCE_SYSTEM_MEMORY. This HOB lacks memory NUMA attachment or something that could be related to fill SRAT table for ACPI or relevant DT proximity domains. HOB is not consistent accros platforms: some platforms (Arm) lists memory from the booting NUMA node, other platforms (x86) lists all memory from all NUMA nodes. (At least this is the case on the two platforms I tested). There are two proposals to use memory structures from SPL/BLx up to the handover function (as defined in the Device Tree technical report <https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0X…> ) which can be U-boot (BL33 or just U-Boot in case of SPL/U-Boot scheme) or EDK2. I would propose we also discuss possibility of FF-A interface to actually query information or request actions to be done (this is a model actually used in some SoCs with proprietary SMC calls). Requirements (to be validated): - ACPI and DT hardware descriptions. - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot, TF-A/EDK2) - agnostic to boot framework (SPL/U-Boot, TF-A/U-Boot, TF-A/EDK2, TF-A/LinuxBoot) - at least allows complete DRAM description and "persistent" usage (reserved areas for secure world or other usages) - support secure world device assignment Cheers FF On Mon, 22 Mar 2021 at 19:56, Simon Glass <sjg(a)chromium.org <mailto:sjg@chromium.org> > wrote: Hi, Can I suggest using bloblist for this instead? It is lightweight, easier to parse, doesn't have GUIDs and is already used within U-Boot for passing info between SPL/U-Boot, etc. Docs here: https://github.com/u-boot/u-boot/blob/master/doc/README.bloblist Header file describes the format: https://github.com/u-boot/u-boot/blob/master/include/bloblist.h Full set of unit tests: https://github.com/u-boot/u-boot/blob/master/test/bloblist.c Regards, Simon On Mon, 22 Mar 2021 at 23:58, François Ozog <francois.ozog(a)linaro.org <mailto:francois.ozog@linaro.org> > wrote: > > +Boot Architecture Mailman List <boot-architecture(a)lists.linaro.org <mailto:boot-architecture@lists.linaro.org> > > > standardization is very much welcomed here and need to accommodate a very > diverse set of situations. > For example, TEE OS may need to pass memory reservations to BL33 or > "capture" a device for the secure world. > > I have observed a number of architectures: > 1) pass information from BLx to BLy in the form of a specific object > 2) BLx called by BLy by a platform specific SMC to get information > 3) BLx called by BLy by a platform specific SMC to perform Device Tree > fixups > > I also imagined a standardized "broadcast" FF-A call so that any firmware > element can either provide information or "do something". > > My understanding of your proposal is about standardizing on architecture 1) > with the HOB format. > > The advantage of the HOB is simplicity but it may be difficult to implement > schemes such as pruning a DT because device assignment in the secure world. > > In any case, it looks feasible to have TF-A and OP-TEE complement the list > of HOBs to pass information downstream (the bootflow). > > It would be good to start with building the comprehensive list of > information that need to be conveyed between firmware elements: > > information. | authoritative entity | reporting entity | information > exchanged: > dram | TFA | TFA | > <format to be detailed, NUMA topology to build the SRAT table or DT > equivalent?> > PSCI | SCP | TFA? | > SCMI | SCP or TEE-OS | TFA? TEE-OS?| > secure SRAM | TFA. | TFA. | > secure DRAM | TFA? TEE-OS? | TFA? TEE-OS? | > other? | | > | > > Cheers > > FF > > > On Mon, 22 Mar 2021 at 09:34, Harb Abdulhamid OS via TF-A < > tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > wrote: > > > Hello Folks, > > > > > > > > I'm emailing to start an open discussion about the adoption of a concept > > known as "hand-off blocks" or HOB to become a part of the TF-A Firmware > > Framework Architecture (FFA). This is something that is a pretty major > > pain point when it comes to the adoption of TF-A in ARM Server SoC’s > > designed to enable a broad range of highly configurable datacenter > > platforms. > > > > > > > > > > > > What is a HOB (Background)? > > > > --------------------------- > > > > UEFI PI spec describes a particular definition for how HOB may be used for > > transitioning between the PEI and DXE boot phases, which is a good > > reference point for this discussion, but not necessarily the exact solution > > appropriate for TF-A. > > > > > > > > A HOB is simply a dynamically generated data structure passed in between > > two boot phases. This is information that was obtained through discovery > > and needs to be passed forward to the next boot phase *once*, with no API > > needed to call back (e.g. no call back into previous firmware phase is > > needed to fetch this information at run-time - it is simply passed one time > > during boot). > > > > > > > > There may be one or more HOBs passed in between boot phases. If there are > > more than one HOB that needs to be passed, this can be in a form of a "HOB > > table", which (for example) could be a UUID indexed array of pointers to > > HOB structures, used to locate a HOB of interest (based on UUID). In such > > cases, instead of passing a single HOB, the boot phases may rely on passing > > the pointer to the HOB table. > > > > > > > > This has been extremely useful concept to employ on highly configurable > > systems that must rely on flexible discovery mechanisms to initialize and > > boot the system. This is especially helpful when you have multiple > > > > > > > > > > > > Why do we need HOBs in TF-A?: > > > > ----------------------------- > > > > It is desirable that EL3 firmware (e.g. TF-A) built for ARM Server SoC in > > a way that is SoC specific *but* platform agnostic. This means that a > > single ARM SoC that a SiP may deliver to customers may provide a single > > TF-A binary (e.g. BL1, BL2, BL31) that could be used to support a broad > > range of platform designs and configurations in order to boot a platform > > specific firmware (e.g. BL33 and possibly even BL32 code). In order to > > achieve this, the platform configuration must be *discovered* instead of > > statically compiled as it is today in TF-A via device tree based > > enumeration. The mechanisms of discovery may differ broadly depending on > > the relevant industry standard, or in some cases may have rely on SiP > > specific discovery flows. > > > > > > > > For example: On server systems that support a broad range DIMM memory > > population/topologies, all the necessary information required to boot is > > fully discovered via standard JEDEC Serial Presence Detect (SPD) over an > > I2C bus. Leveraging the SPD bus, may platform variants could be supported > > with a single TF-A binary. Not only is this information required to > > initialize memory in early boot phases (e.g. BL2), the subsequent boot > > phases will also need this SPD info to construct a system physical address > > map and properly initialize the MMU based on the memory present, and where > > the memory may be present. Subsequent boot phases (e.g. BL33 / UEFI) may > > need to generate standard firmware tables to the operating systems, such as > > SMBIOS tables describing DIMM topology and various ACPI tables (e.g. SLIT, > > SRAT, even NFIT if NVDIMM's are present). > > > > > > > > In short, it all starts with a standardized or vendor specific discovery > > flow in an early boot stage (e.g. BL1/BL2), followed by the passing of > > information to the next boot stages (e.g. BL31/BL32/BL33). > > > > > > > > Today, every HOB may be a vendor specific structure, but in the future > > there may be benefit of defining standard HOBs. This may be useful for > > memory discovery, passing the system physical address map, enabling TPM > > measured boot, and potentially many other common HOB use-cases. > > > > > > > > It would be extremely beneficial to the datacenter market segment if the > > TF-A community would adopt this concept of information passing between all > > boot phases as opposed to rely solely on device tree enumeration. This is > > not intended to replace device tree, rather intended as an alternative way > > to describe the info that must be discovered and dynamically generated. > > > > > > > > > > > > Conclusion: > > > > ----------- > > > > We are proposing that the TF-A community begin pursuing the adoption of > > HOBs as a mechanism used for information exchange between each boot stage > > (e.g. BL1->BL2, BL2->BL31, BL31->BL32, and BL31->BL33)? Longer term we > > want to explore standardizing some HOB structures for the BL33 phase (e.g. > > UEFI HOB structures), but initially would like to agree on this being a > > useful mechanism used to pass information between each boot stage. > > > > > > > > Thanks, > > > > --Harb > > > > > > > > > > > > > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > -- > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.ozog(a)linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org <mailto:boot-architecture@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/boot-architecture -- <https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…> François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 <mailto:francois.ozog@linaro.org> francois.ozog(a)linaro.org | Skype: ffozog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- <https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…> François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 <mailto:francois.ozog@linaro.org> francois.ozog(a)linaro.org | Skype: ffozog -- TF-A mailing list TF-A(a)lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 5

[PATCH v2 0/6] SPL: FIT: Fix some omissions of SPL_LOAD_FIT_FULL and bootm
by Alexandru Gagniuc 30 Mar '21

30 Mar '21

Although this series focuses on SPL_LOAD_FIT_FULL, some of the fixes will also apply to bootm, as they are sharing significant amounts of code. Originally SPL_LOAD_FIT_FULL could not start either a linux FIT or a u-boot image. It didn't even take FIT images generated automatically by mkimage, as part of the u-boot build!!! The goal is to at the very least, be able to boot autogenerated mkimage FITs. This brings us much more in line with SPL_LOAD_FIT, and the documentation. It's not perfect, and the fpga 'compatible =' support is still not implemented. That's all I currently have time for before someone notices I'm working on u-boot again. Changes since v1: - Update commit message of "spl: LOAD_FIT_FULL: Fix selection of the "fdt" node" Alexandru Gagniuc (6): spl: LOAD_FIT_FULL: Fix selection of the "fdt" node spl: LOAD_FIT_FULL: Do not hard-code os to IH_OS_U_BOOT spl: LOAD_FIT_FULL: Relocate FDT for u-boot payloads spl: LOAD_FIT_FULL: Support 'kernel' and 'firmware' properties image-fit: Accept IH_TYPE_FIRMWARE in fit_image_load() as valid image-fit: Accept OP-TEE images when booting a FIT common/image-fit.c | 4 ++++ common/spl/spl.c | 40 +++++++++++++++++++++++++++++++++------- 2 files changed, 37 insertions(+), 7 deletions(-) -- 2.26.3

1 6