May 2021 - U-Boot

[PATCH v8 0/3] PE/COFF measurement support
by Masahisa Kojima 26 May '21

26 May '21

This patch series add the PE/COFF measurement support. Extending PCR and Event Log is tested with fTPM running as a OP-TEE TA. Unit test will be added in the separate series. Masahisa Kojima (3): lib: introduce HASH_CALCULATE option efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled efi_loader: add PE/COFF image measurement common/Kconfig.boot | 1 + include/efi_loader.h | 6 + include/efi_tcg2.h | 9 ++ include/tpm-v2.h | 18 +++ lib/Kconfig | 3 + lib/Makefile | 2 +- lib/efi_loader/Kconfig | 8 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_image_loader.c | 123 +++++++++++++++--- lib/efi_loader/efi_signature.c | 67 +--------- lib/efi_loader/efi_tcg2.c | 207 ++++++++++++++++++++++++++++-- lib/efi_loader/efi_var_common.c | 3 + 12 files changed, 356 insertions(+), 93 deletions(-) -- 2.17.1

3 9

mirroring u-boot mailing list on lore.kernel.org
by Rasmus Villemoes 26 May '21

26 May '21

Hi, When doing linux kernel work, the public-inbox archives at lore.kernel.org are really useful. - excellent search features - stable links of the form lore.kernel.org/<list>/<msg-id> - nice overview of threads - ability to, with the b4 tool, download patches or whole series by msg-id, and logic to compare those to previous versions With U-Boot, I often miss these features. I don't know if the kernel.org folks would be willing to host an archive of the u-boot mailing list, but it's not entirely unlikely - they do host a number of lists from the wider ecosystem (e.g. coccinelle, git) [1]. But do anybody see or have a problem with me sending a request to helpdesk(a)kernel.org to have it added [2]? Thanks, Rasmus [1] https://lore.kernel.org/lists.html [2] https://korg.docs.kernel.org/lore.html

5 9

[PORT] Help Porting U-BOOT master branch to GT90X V4 sun7i a20 tablet board
by Koray Bilir 25 May '21

25 May '21

hello to the u-boot community, last week i wanted to do some hardware hacking and came across one of my nameless chinese brand sun7i a20 tablets poked around in adb shell, mounted the NANDA partition and to my surprise it was running u-boot v2011 , so i wanted to put a linux kernel on there to see if it would boot unfortunately the u-boot was outdated and couldn't boot it, tl dr; i am trying to write a device tree file so i can successfully port U-BOOT v2021.07-rc2-00238-geb53b943be-dirty. So far I have "successfully" compiled a u-boot.bin although binman gives an error of "cant find u-boot.dtb" the u-boot.bin works fine on the device. Sorry for my rambling. I just wanna give the most information in one post. so far I was able to write a simple .dts file for my board to get the debug uart ports working. luckily I discovered some test points on the board that were for uart tx rx. I got the uart interface working. I don't have an ftdi at the moment so i'm using an arduino as an usb to serial passthrough long story short i was able to get the u boot shell working and I was able to interface with the device. since its my first time cross compiling, u-boot and also device tree files i need some guidance to where should i look, one question that i have is Is there any pre-made building environments that I can just run on a virtual machine, im currently using my laptop which has debian 10 on it to compile and i'm not sure if I did everything right to get my build environment working. I have access to the stock rom of my device so i cant brick it and also i have access to the source code of the u-boot 2011 version that was on the board from the factory. unfortunately this device has android 4.2.2 installed on it and i couldn't find any device tree files on it, i have the sysconfig.fex file that has the pinouts and config data on it So basically I'm trying to convert the sysconfig.fex to a dts file. my objectives right now are: setup ram correctly get nand working get sd/mmc working get usb working get 24bit lvds panel working get touchscreen working get audio working and finally get some sensors working that the board has I'm having no luck getting the nand and lvds panel working. I haven't tried sd/mmc , audio and touchscreen but i had usb working with some settings, i disabled it when i was debugging for other stuff. This gt90x v4 board is found in many nameless chinese tablets so I'm hoping this little project of mine can help others. also i see an unpopulated place that could take another nand chip , i'll have to try to see if it would work if any of you are interested in this or want to look at everything i got i can for the u-boot repository and commit my changes there and if any of you want to help you are more than welcome since this is my first time doing embedded stuff im learning as i go along so feel free to correct me. I can provide the source code of the 2011 u-boot that had everything working on the device and I can provide everything I have mentioned earlier (file wise). Let's get to the board details. ALLWINNER A20 SUN7I DUAL CORE CPU 2x NANYA MTT 256X16DDR3 V 1330 RAM CHIPS (device supposedly has 1gb of ram) TOSHIBA JP5415 TAIWAN 13359 A E / TC58TEG6DCJTA00 (8GB NAND) AXP209 0448CB 66K1 GSL3680 64A0D4281N REALTEK RTL8188ETV D700331 GD27 E203460 9INCH 1024X600 24BIT LVDS PANEL Thats all of the major components on the board that i can see, i'll have an image of the board down below. https://drive.google.com/drive/folders/17zZTsgPHKktV4VARHAxR8tpHS4P04U7x?us… I would be super happy if anyone is able to point me in the right direction or help me. -Koray

2 2

[PATCH 1/1] efi_loader: partition numbers are hexadecimal
by Heinrich Schuchardt 25 May '21

25 May '21

If we want to address partition 15 of virtio block device 11, we have to write: virtio b:f When calling sprintf() we must use %x for the device and partition numbers. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_disk.c | 4 ++-- lib/efi_loader/efi_var_file.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index 307d5d759b..988907ecb9 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -476,7 +476,7 @@ static efi_status_t efi_disk_add_dev( efi_system_partition.if_type = desc->if_type; efi_system_partition.devnum = desc->devnum; efi_system_partition.part = part; - EFI_PRINT("EFI system partition: %s %d:%d\n", + EFI_PRINT("EFI system partition: %s %x:%x\n", blk_get_if_type_name(desc->if_type), desc->devnum, part); } @@ -521,7 +521,7 @@ int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc, if (part_get_info(desc, part, &info)) continue; - snprintf(devname, sizeof(devname), "%s:%d", pdevname, + snprintf(devname, sizeof(devname), "%s:%x", pdevname, part); ret = efi_disk_add_dev(parent, dp, if_typename, desc, diskid, &info, part, NULL); diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c index b171d2d1a8..de076b8cbc 100644 --- a/lib/efi_loader/efi_var_file.c +++ b/lib/efi_loader/efi_var_file.c @@ -35,7 +35,7 @@ static efi_status_t __maybe_unused efi_set_blk_dev_to_system_partition(void) log_err("No EFI system partition\n"); return EFI_DEVICE_ERROR; } - snprintf(part_str, PART_STR_LEN, "%u:%u", + snprintf(part_str, PART_STR_LEN, "%x:%x", efi_system_partition.devnum, efi_system_partition.part); r = fs_set_blk_dev(blk_get_if_type_name(efi_system_partition.if_type), part_str, FS_TYPE_ANY); -- 2.32.0.rc0

1 0

[PATCH] efi_loader: Fix -Wextra warning for EFI TCG2
by Ilias Apalodimas 25 May '21

25 May '21

Compiling with -Wextra produces a number of (harmless) warnings for the EFI TCG2 protocol. Let's fix those in case we ever enable the flag on the EFI subsystem Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> --- lib/efi_loader/efi_tcg2.c | 40 +++++++++++++++++++++------------------ 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c index 39ef250bf9c4..39074f754772 100644 --- a/lib/efi_loader/efi_tcg2.c +++ b/lib/efi_loader/efi_tcg2.c @@ -53,7 +53,7 @@ struct digest_info { u16 hash_len; }; -const static struct digest_info hash_algo_list[] = { +static const struct digest_info hash_algo_list[] = { { TPM2_ALG_SHA1, EFI_TCG2_BOOT_HASH_ALG_SHA1, @@ -87,7 +87,7 @@ const static struct digest_info hash_algo_list[] = { */ static u32 alg_to_mask(u16 hash_alg) { - int i; + size_t i; for (i = 0; i < MAX_HASH_COUNT; i++) { if (hash_algo_list[i].hash_alg == hash_alg) @@ -106,7 +106,7 @@ static u32 alg_to_mask(u16 hash_alg) */ static u16 alg_to_len(u16 hash_alg) { - int i; + size_t i; for (i = 0; i < MAX_HASH_COUNT; i++) { if (hash_algo_list[i].hash_alg == hash_alg) @@ -119,7 +119,7 @@ static u16 alg_to_len(u16 hash_alg) static u32 tcg_event_final_size(struct tpml_digest_values *digest_list) { u32 len; - int i; + size_t i; len = offsetof(struct tcg_pcr_event2, digests); len += offsetof(struct tpml_digest_values, digests); @@ -145,7 +145,7 @@ static efi_status_t tcg2_pcr_extend(struct udevice *dev, u32 pcr_index, struct tpml_digest_values *digest_list) { u32 rc; - int i; + size_t i; for (i = 0; i < digest_list->count; i++) { u32 alg = digest_list->digests[i].hash_alg; @@ -178,7 +178,7 @@ static efi_status_t tcg2_agile_log_append(u32 pcr_index, u32 event_type, { void *log = (void *)((uintptr_t)event_log.buffer + event_log.pos); size_t pos; - int i; + size_t i; u32 event_size; if (event_log.get_event_called) @@ -400,7 +400,8 @@ static int tpm2_get_pcr_info(struct udevice *dev, u32 *supported_pcr, u8 response[TPM2_RESPONSE_BUFFER_SIZE]; struct tpml_pcr_selection pcrs; u32 ret, num_pcr; - int i, tpm_ret; + size_t i; + int tpm_ret; memset(response, 0, sizeof(response)); ret = tpm2_get_capability(dev, TPM2_CAP_PCRS, 0, response, 1); @@ -518,7 +519,7 @@ static efi_status_t tcg2_create_digest(const u8 *input, u32 length, u8 final[TPM2_SHA512_DIGEST_SIZE]; efi_status_t ret; u32 active; - int i; + size_t i; ret = __get_active_pcr_banks(&active); if (ret != EFI_SUCCESS) @@ -749,8 +750,7 @@ efi_tcg2_hash_log_extend_event(struct efi_tcg2_protocol *this, u64 flags, goto out; } - if (efi_tcg_event->header.pcr_index < 0 || - efi_tcg_event->header.pcr_index > TPM2_MAX_PCRS) { + if (efi_tcg_event->header.pcr_index > TPM2_MAX_PCRS) { ret = EFI_INVALID_PARAMETER; goto out; } @@ -810,9 +810,11 @@ out: * Return: status code */ static efi_status_t EFIAPI -efi_tcg2_submit_command(struct efi_tcg2_protocol *this, - u32 input_param_block_size, u8 *input_param_block, - u32 output_param_block_size, u8 *output_param_block) +efi_tcg2_submit_command(__maybe_unused struct efi_tcg2_protocol *this, + u32 __maybe_unused input_param_block_size, + u8 __maybe_unused *input_param_block, + u32 __maybe_unused output_param_block_size, + u8 __maybe_unused *output_param_block) { return EFI_UNSUPPORTED; } @@ -847,8 +849,8 @@ efi_tcg2_get_active_pcr_banks(struct efi_tcg2_protocol *this, * Return: status code */ static efi_status_t EFIAPI -efi_tcg2_set_active_pcr_banks(struct efi_tcg2_protocol *this, - u32 active_pcr_banks) +efi_tcg2_set_active_pcr_banks(__maybe_unused struct efi_tcg2_protocol *this, + u32 __maybe_unused active_pcr_banks) { return EFI_UNSUPPORTED; } @@ -866,8 +868,9 @@ efi_tcg2_set_active_pcr_banks(struct efi_tcg2_protocol *this, * Return: status code */ static efi_status_t EFIAPI -efi_tcg2_get_result_of_set_active_pcr_banks(struct efi_tcg2_protocol *this, - u32 *operation_present, u32 *response) +efi_tcg2_get_result_of_set_active_pcr_banks(__maybe_unused struct efi_tcg2_protocol *this, + u32 __maybe_unused *operation_present, + u32 __maybe_unused *response) { return EFI_UNSUPPORTED; } @@ -898,7 +901,8 @@ static efi_status_t create_specid_event(struct udevice *dev, void *buffer, size_t spec_event_size; efi_status_t ret = EFI_DEVICE_ERROR; u32 active, supported; - int err, i; + int err; + size_t i; /* * Create Spec event. This needs to be the first event in the log -- 2.31.1

1 0

[PATCH 1/1] efi_loader: path length in efi_dp_from_name()
by Heinrich Schuchardt 25 May '21

25 May '21

Before this patch efi_dp_from_name() only accommodated a maximum file path length of 31 characters. This leads to boot failures due to file name truncation. Allow arbitrary path lengths. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_device_path.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c index 4b20859b25..76c2f82fe6 100644 --- a/lib/efi_loader/efi_device_path.c +++ b/lib/efi_loader/efi_device_path.c @@ -1171,7 +1171,7 @@ efi_status_t efi_dp_from_name(const char *dev, const char *devnr, struct blk_desc *desc = NULL; struct disk_partition fs_partition; int part = 0; - char filename[32] = { 0 }; /* dp->str is u16[32] long */ + char *filename; char *s; if (path && !file) @@ -1198,12 +1198,17 @@ efi_status_t efi_dp_from_name(const char *dev, const char *devnr, if (!path) return EFI_SUCCESS; - snprintf(filename, sizeof(filename), "%s", path); + filename = calloc(1, strlen(path) + 1); + if (!filename) + return EFI_OUT_OF_RESOURCES; + + sprintf(filename, "%s", path); /* DOS style file path: */ s = filename; while ((s = strchr(s, '/'))) *s++ = '\\'; *file = efi_dp_from_file(desc, part, filename); + free(filename); if (!*file) return EFI_INVALID_PARAMETER; -- 2.32.0.rc0

1 0

sdhci_data_transfer: Trasnfer data timeout
by aregaard 25 May '21

25 May '21

Hi, I have made a custom board based on ARM A53. I use a NOR-flash, eMMC and DDR3. I can start the Uboot from NOR and communicate with the eMMC. But for some reason it is timing out the first time I connect to the eMMC. *(CLK =25MHz)* => run mmc_format eMMC: INT_STATUS = 00018000 eMMC: INT_STATUS = 00018001 sdhci_transfer_data: Transfer data timeout sdhci_transfer_data: Transfer data timeout After this part it can communicate: *(CLK = 50MHz)* success! Writing GPT: success! Saving Environment to SPI Flash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 4 KiB, total 16 MiB Erasing SPI flash...Writing to SPI flash...done Valid environment: 1 OK This Timeout might cause problems with the DDR3 (I am having problems with the Kernel not booting corretly). I think there is an issue with the communication with the eMMC and DDR, due to the timeout. What can generate the timing-out-issue? To make it clear; I can communicate with the eMMC. The first time it is really slow and is timing out with 25 MHz FLASH-clk. The second time it goes directly into sync: => run mmc_format success! Writing GPT: success! Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done Valid environment: 2 OK I sounds like a HW-issue, but what can cause this in the code? If I reset the system it is timing out again the first time. Kind Regards -- Sent from: http://u-boot.10912.n7.nabble.com/

2 1

[ANN] U-Boot v2021.07-rc3 released
by Tom Rini 25 May '21

25 May '21

Hey all, It's release day, and here's v2021.07-rc3. It's later in the day than I would have liked, but getting the LTO series in took a bit longer than I expected. At this point, for v2021.07 related removal series, I've posted DM_PCI and DM_USB series, and Anatolij just posted DM_VIDEO related series. That just leave DM_SPI_FLASH to sort out, but I think we'll be in OK shape there. In terms of a changelog, git log --merges v2021.07-rc2..v2021.07-rc3 contains what I've pulled but as always, better PR messages and tags will provide better results here. In keeping with my previous plans, I'm going to open -next with -rc4. I do have my reminders setup for doing -rc releases every other Monday from here on out and final release on July 5th, 2021. Thanks all! -- Tom

1 0

[PATCH] pylibfdt: Rework "avoid unused variable warning" lines
by Tom Rini 25 May '21

25 May '21

Clang has -Wself-assign enabled by default under -Wall and so when building with -Werror we would get an error here. Inspired by Linux kernel git commit a21151b9d81a ("tools/build: tweak unused value workaround") make use of the fact that both Clang and GCC support casting to `void` as the method to note that something is intentionally unused. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- scripts/dtc/pylibfdt/libfdt.i_shipped | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/dtc/pylibfdt/libfdt.i_shipped b/scripts/dtc/pylibfdt/libfdt.i_shipped index 1d69ad38e2e3..27c29ea2603a 100644 --- a/scripts/dtc/pylibfdt/libfdt.i_shipped +++ b/scripts/dtc/pylibfdt/libfdt.i_shipped @@ -1010,7 +1010,7 @@ typedef uint32_t fdt32_t; } $1 = (void *)PyByteArray_AsString($input); fdt = $1; - fdt = fdt; /* avoid unused variable warning */ + (void)fdt; /* avoid unused variable warning */ } /* Some functions do change the device tree, so use void * */ @@ -1021,7 +1021,7 @@ typedef uint32_t fdt32_t; } $1 = PyByteArray_AsString($input); fdt = $1; - fdt = fdt; /* avoid unused variable warning */ + (void)fdt; /* avoid unused variable warning */ } /* typemap used for fdt_get_property_by_offset() */ -- 2.17.1

1 1

[PATCH] stackprot: Make our test a bit more complex
by Tom Rini 25 May '21

25 May '21

With better compiler optimizations available, a compiler may see we do nothing with our buffer after calling memset and omit the call, thus causing us to not smash the stack. Add a comment to explain why we now also have a printf call, so that the test will pass as the memset will not be omitted. Reported-by: Marek Behún <marek.behun(a)nic.cz> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- cmd/stackprot_test.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/cmd/stackprot_test.c b/cmd/stackprot_test.c index 36f5bac8d230..1e26193e88b0 100644 --- a/cmd/stackprot_test.c +++ b/cmd/stackprot_test.c @@ -9,9 +9,16 @@ static int do_test_stackprot_fail(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { + /* + * In order to avoid having the compiler optimize away the stack smashing + * we need to do a little something here. + */ char a[128]; memset(a, 0xa5, 512); + + printf("We have smashed our stack as this should not exceed 128: sizeof(a) = %ld\n", strlen(a)); + return 0; } -- 2.17.1

1 1