December 2020 - U-Boot

[PATCH 1/1] efi_loader: don't set EFI_RT_SUPPORTED_UPDATE_CAPSULE
by Heinrich Schuchardt 09 Dec '20

09 Dec '20

The EFI_RT_PROPERTIES_TABLE configuration table indicates which runtime services are available at runtime. Even if CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y, we neither support UpdateCapsule() nor QueryCapsuleCapabilities() at runtime. Thus we should not set the corresponding flags EFI_RT_SUPPORTED_UPDATE_CAPSULE and EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES in RuntimeServicesSupported. Fixes: 2bc27ca8a04a ("efi_loader: define UpdateCapsule api") Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/efi_runtime.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c index 0b171c1ff7..93c9478b22 100644 --- a/lib/efi_loader/efi_runtime.c +++ b/lib/efi_loader/efi_runtime.c @@ -133,10 +133,6 @@ efi_status_t efi_init_runtime_supported(void) #ifdef CONFIG_EFI_HAVE_RUNTIME_RESET rt_table->runtime_services_supported |= EFI_RT_SUPPORTED_RESET_SYSTEM; #endif - if (IS_ENABLED(CONFIG_EFI_RUNTIME_UPDATE_CAPSULE)) - rt_table->runtime_services_supported |= - (EFI_RT_SUPPORTED_UPDATE_CAPSULE | - EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES); ret = efi_install_configuration_table(&efi_rt_properties_table_guid, rt_table); -- 2.29.2

1 0

[RFC] Testing EFI_CAPSULE_ON_DISK
by Heinrich Schuchardt 09 Dec '20

09 Dec '20

Hello Takahiro when I select EFI_CAPSULE_ON_DISK_EARLY this implies EFI_SETUP_EARLY. With EFI_SETUP_EARLY I cannot use PREBOOT to add a disk via the host command. So I do not see how the feature could be tested on the sandbox. I think we will have to enable dynamic binding of block devices to overcome this mutual blocking of features. What are your ideas? Best regards Heinrich

2 1

[PATCH 0/7] efi_loader: support EFI_LOAD_FILE_PROTOCOL
by Heinrich Schuchardt 08 Dec '20

08 Dec '20

According to the UEFI specification the LoadImage() boot service must support loading images via the EFI_LOAD_FILE_PROTOCOL and EFI_LOAD_FILE2_PROTOCOL. This series implements the support and adds a unit test. Heinrich Schuchardt (7): efi_loader: resequence functions in efi_boottime.c efi_loader: move EFI_LOAD_FILE2_PROTOCOL_GUID efi_loader: pass boot_policy to efi_load_image_from_path efi_loader: carve out efi_load_image_from_file() efi_loader: support EFI_LOAD_FILE_PROTOCOL efi_selftest: clean up Makefile efi_selftest: test EFI_LOAD_FILE_PROTOCOL include/efi_loader.h | 3 + lib/efi_loader/efi_boottime.c | 269 +++++++---- lib/efi_loader/efi_load_initrd.c | 3 - lib/efi_selftest/Makefile | 17 +- lib/efi_selftest/efi_selftest_load_file.c | 475 ++++++++++++++++++++ lib/efi_selftest/efi_selftest_load_initrd.c | 7 +- 6 files changed, 665 insertions(+), 109 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_load_file.c -- 2.29.2

1 7

Re: [PATCH 3/4] ARM: dts: stm32: Enable SDMMC3 on DH DRC02
by Patrick DELAUNAY 08 Dec '20

08 Dec '20

Hi Marek, > From: Marek Vasut <marex(a)denx.de> > Sent: mardi 1 décembre 2020 11:29 > > The DH DRC02 board has an on-board microSD slot, add DT properties to enable the slot. > > Signed-off-by: Marek Vasut <marex(a)denx.de> > Cc: Patrice Chotard <patrice.chotard(a)st.com> > Cc: Patrick Delaunay <patrick.delaunay(a)st.com> > --- > NOTE: Large part of this should be in the DHCOM SoM DT, however > a DT sync should only happen after Linux 5.10.y and U-Boot > 2021.01 are out. > --- > arch/arm/dts/stm32mp15xx-dhcom-drc02.dts | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts b/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts > index 5a237a3b7b..e8508aa4d5 100644 > --- a/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts > +++ b/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts > @@ -105,9 +105,18 @@ > * On DRC02, the SoM does not have SDIO WiFi. The pins > * are used for on-board microSD slot instead. > */ > - /delete-property/broken-cd; > - cd-gpios = <&gpioi 10 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; > + pinctrl-names = "default", "opendrain", "sleep"; > + pinctrl-0 = <&sdmmc3_b4_pins_a>; > + pinctrl-1 = <&sdmmc3_b4_od_pins_a>; > + pinctrl-2 = <&sdmmc3_b4_sleep_pins_a>; > + cd-gpios = <&gpioi 10 GPIO_ACTIVE_HIGH>; > disable-wp; > + st,neg-edge; > + bus-width = <4>;To: u-boot(a)lists.denx.de > Cc: Marek Vasut <marex(a)denx.de>; Patrice CHOTARD <patrice.chotard(a)st.com>; Patrick DELAUNAY <patrick.delaunay(a)st.com> > Subject: [PATCH 2/4] ARM: dts: stm32: Disable SDMMC1 CKIN feedback clock > Importance: High > > > + vmmc-supply = <&v3v3>; > + vqmmc-supply = <&v3v3>; > + mmc-ddr-3_3v; > + status = "okay"; > }; > > &spi1 { > -- > 2.29.2 > Reviewed-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Thanks Patrick

1 0

Re: [PATCH 2/4] ARM: dts: stm32: Disable SDMMC1 CKIN feedback clock
by Patrick DELAUNAY 08 Dec '20

08 Dec '20

Hi Marek, > From: Marek Vasut <marex(a)denx.de> > Sent: mardi 1 décembre 2020 11:29 > > The STM32MP1 DHCOM SoM can be built with either bus voltage level shifter or without one on the SDMMC1 interface. Because the SDMMC1 interface is limited to 50 MHz and hence SD high-speed anyway, disable the SD feedback clock to permit operation of the same U-Boot image on both SoM with and without voltage level shifter. > > Signed-off-by: Marek Vasut <marex(a)denx.de> > Cc: Patrice Chotard <patrice.chotard(a)st.com> > Cc: Patrick Delaunay <patrick.delaunay(a)st.com> > --- > arch/arm/dts/stm32mp15xx-dhcom.dtsi | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi b/arch/arm/dts/stm32mp15xx-dhcom.dtsi > index 9049245c5b..dafcce4323 100644 > --- a/arch/arm/dts/stm32mp15xx-dhcom.dtsi > +++ b/arch/arm/dts/stm32mp15xx-dhcom.dtsi > @@ -333,7 +333,6 @@ > disable-wp; > st,sig-dir; > st,neg-edge; > - st,use-ckin; > bus-width = <4>; > vmmc-supply = <&vdd_sd>; > status = "okay"; > -- > 2.29.2 > Reviewed-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Thanks Patrick

1 0

Re: [PATCH 4/4] ARM: dts: stm32: Add USB OTG ID pin on DH AV96
by Patrick DELAUNAY 08 Dec '20

08 Dec '20

Hi Marek, > From: Marek Vasut <marex(a)denx.de> > Sent: mardi 1 décembre 2020 11:29 > > Add USB OTG ID pin mux and switch the USB OTG port from peripheral to OTG mode. > > Signed-off-by: Marek Vasut <marex(a)denx.de> > Cc: Patrice Chotard <patrice.chotard(a)st.com> > Cc: Patrick Delaunay <patrick.delaunay(a)st.com> > --- > arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts > index 88f25d89b2..9b5dda318e 100644 > --- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts > +++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts > @@ -192,7 +192,8 @@ > }; > > &usbotg_hs { > - dr_mode = "peripheral"; > + pinctrl-0 = <&usbotg_hs_pins_a>; > + pinctrl-names = "default"; > phys = <&usbphyc_port1 0>; > phy-names = "usb2-phy"; > status = "okay"; > -- > 2.29.2 > Reviewed-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Thanks Patrick

1 0

[PATCH] string: Use memcpy() within memmove() when we can
by Patrick Delaunay 08 Dec '20

08 Dec '20

A common use of memmove() can be handled by memcpy(). Also memcpy() includes an optimization for large sizes: it copies a word at a time. So we can get a speed-up by calling memcpy() to handle our move in this case. Update memmove() to call also memcpy() if the source don't overlap the destination (src + count <= dest). Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- This patch allows to save 38ms for Kernel Image extraction (7327624 Bytes) from FIT loaded at 0xC2000000 for ARMV7 board STM32MP157C-EV1, and with kernel destination = Load Address: 0xc4000000, located after the FIT without overlap, compared with destination = Load Address: 0xc0008000. -> 14,332 us vs 52,239 in bootstage report In this case the memmove funtion is called in common/image.c::memmove_wd() to handle overlap. lib/string.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/string.c b/lib/string.c index ae7835f600..ef8ead976c 100644 --- a/lib/string.c +++ b/lib/string.c @@ -567,7 +567,7 @@ void * memmove(void * dest,const void *src,size_t count) { char *tmp, *s; - if (dest <= src) { + if (dest <= src || (src + count) <= dest) { memcpy(dest, src, count); } else { tmp = (char *) dest + count; -- 2.17.1

3 2

Re: [PATCH] ARM: dts: stm32: Switch to MCO2 for PHY 50 MHz clock
by Patrick DELAUNAY 08 Dec '20

08 Dec '20

Hi Marek, > From: Marek Vasut <marex(a)denx.de> > Sent: mardi 1 décembre 2020 11:35 > > The LAN8710i PHY currently uses 50 MHz clock direct from PLL4P. > To permit PLL4P to run at faster frequency, use MCO2 as a divider. > The PLL4P runs at 100 MHz, supplies MCO2 which divides it by 2 to 50MHz, and supplies the PHY with 50 MHz via pin PG2. The feedback clock are fed back in via pin PA1. > > Signed-off-by: Marek Vasut <marex(a)denx.de> > Cc: Patrice Chotard <patrice.chotard(a)st.com> > Cc: Patrick Delaunay <patrick.delaunay(a)st.com> > --- > NOTE: This is for next > --- > arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 25 +++++++++++++++++----- > arch/arm/dts/stm32mp15xx-dhcom.dtsi | 3 +-- > 2 files changed, 21 insertions(+), 7 deletions(-) > Reviewed-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Thanks Patrick

1 0

[PATCH] spl: fit: Prefer a malloc()'d buffer for loading images
by Alexandru Gagniuc 08 Dec '20

08 Dec '20

Fit images were loaded to a buffer provided by spl_get_load_buffer(). This may work when the FIT image is small and fits between the start of DRAM and SYS_TEXT_BASE. One problem with this approach is that the location of the buffer may be manipulated by changing the 'size' field of the FIT. A maliciously crafted FIT image could place the buffer over executable code and be able to take control of SPL. This is unacceptable for secure boot of signed FIT images. Another problem is with larger FIT images, usually containing one or more linux kernels. In such cases the buffer be be large enough so as to start before DRAM (Figure I). Trying to load an image in this case has undefined behavior. For example, on stm32mp1, the MMC controller hits a RX overrun error, and aborts loading. _________________ | FIT Image | | | /===================\ /=====================\ || DRAM || | DRAM | || || | | ||_________________|| SYS_TEXT_BASE | ___________________ | | | || FIT Image || | | || || | _________________ | SYS_SPL_MALLOC_START || _________________ || || malloc() data || ||| malloc() data ||| ||_________________|| |||_________________||| | | ||___________________|| | | | | Figure I Figure II One possibility that was analyzed was to remove the negative offset, such that the buffer starts at SYS_TEXT_BASE. This is not a proper solution because on a number of platforms, the malloc buffer() is placed at a fixed address, usually after SYS_TEXT_BASE. A large enough FIT image could cause the malloc()'d data to be overwritten (Figure II) when loading. /======================\ | DRAM | | | | | CONFIG_SYS_TEXT_BASE | | | | | ____________________ | CONFIG_SYS_SPL_MALLOC_START || malloc() data || || || || __________________ || ||| FIT Image ||| ||| ||| ||| ||| Figure III The solution proposed here is to replace the ad-hoc heuristics of spl_get_load_buffer() with malloc(). This provides two advantages: * Bounds checking of the buffer region * Guarantees the buffer does not conflict with other memory The first problem is solved by constraining the buffer such that it will not overlap currently executing code. This eliminates the chance of a malicious FIT being able to replace the executing SPL code prior to signature checking. The second problem is solved in conjunction with increasing CONFIG_SYS_SPL_MALLOC_SIZE. Since the SPL malloc() region is carefully crafted on a per-platform basis, the chances of memory conflicts are virtually eliminated. Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> --- Contingency plan: If the malloc() fails, the backup plan is to use spl_get_load_buffer() with the negative offset eliminated. This puts the buffer at CONFIG_SYS_TEXT_BASE as a final measure. We can't use the negative offset because that would re-introduce the first prooblem. Expected fallout: This only affects the FIT image loading path, so no breakage is expected for default configurations. Most configs have a sufficiently large SYS_SPL_MALLOC_SIZE, with the most common value at 1 MB. This adequate for the majority of u-boot FIT images. No significant breakage is expected. common/spl/spl_fit.c | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index a90d821c82..98a7531f72 100644 --- a/common/spl/spl_fit.c +++ b/common/spl/spl_fit.c @@ -472,6 +472,23 @@ static int spl_fit_image_get_os(const void *fit, int noffset, uint8_t *os) #endif } +/* + * The purpose of the FIT load buffer is to provide a memory location that is + * independent of the load address of any FIT component. + */ +static void *spl_get_fit_load_buffer(size_t size) +{ + void *buf; + + buf = malloc(size); + if (!buf) { + pr_err("Could not get FIT buffer of %lu bytes\n", (ulong)size); + pr_err("\tcheck CONFIG_SYS_SPL_MALLOC_SIZE\n"); + buf = spl_get_load_buffer(0, size); + } + return buf; +} + /* * Weak default function to allow customizing SPL fit loading for load-only * use cases by allowing to skip the parsing/processing of the FIT contents @@ -486,12 +503,12 @@ int spl_load_simple_fit(struct spl_image_info *spl_image, struct spl_load_info *info, ulong sector, void *fit) { int sectors; - ulong size; + ulong size, hsize; unsigned long count; struct spl_image_info image_info; int node = -1; int images, ret; - int base_offset, hsize, align_len = ARCH_DMA_MINALIGN - 1; + int base_offset; int index = 0; int firmware_node; @@ -507,24 +524,14 @@ int spl_load_simple_fit(struct spl_image_info *spl_image, /* * So far we only have one block of data from the FIT. Read the entire - * thing, including that first block, placing it so it finishes before - * where we will load the image. - * - * Note that we will load the image such that its first byte will be - * at the load address. Since that byte may be part-way through a - * block, we may load the image up to one block before the load - * address. So take account of that here by subtracting an addition - * block length from the FIT start position. - * - * In fact the FIT has its own load address, but we assume it cannot - * be before CONFIG_SYS_TEXT_BASE. + * thing, including that first block. * * For FIT with data embedded, data is loaded as part of FIT image. * For FIT with external data, data is not loaded in this step. */ - hsize = (size + info->bl_len + align_len) & ~align_len; - fit = spl_get_load_buffer(-hsize, hsize); sectors = get_aligned_image_size(info, size, 0); + hsize = sectors * info->bl_len; + fit = spl_get_fit_load_buffer(hsize); count = info->read(info, sector, sectors, fit); debug("fit read sector %lx, sectors=%d, dst=%p, count=%lu, size=0x%lx\n", sector, sectors, fit, count, size); -- 2.26.2

4 3

[PATCH 00/18] fs: fat: fix long name support
by Heinrich Schuchardt 08 Dec '20

08 Dec '20

Since long name support was added to U-Boot's implementation of the FAT file system corruption of the directories was observed when running the UEFI Self Certifification Test. The following problems are addressed by this series. * short names were not unique * long names directory entries were not deleted when a file was deleted * directory entries released by file deletion were not reused The first four patches are just resent to indicate the import sequence. The following problems need to be addressed in further patches: * When extending a file only available FAT entries after the last cluster of the file are considered. Available FAT entries before are ignored. * The case of no FAT entry found is not treated correctly. * The free FAT count is not updated on FAT32. * Some FAT related tests are not run on Gitlab CI. * Add tests to detect directory corruption. Heinrich Schuchardt (18): fs: fat: avoid NULL dereference when root dir is full fs: fat: directory entries starting with 0x05 fs: fat: use ATTR_ARCH instead of anonymous 0x20 fs: fat: correct first cluster for '..' fs: fat: export fat_next_cluster() fs: fat: create correct short names fs: fat: pass shortname to fill_dir_slot fs: fat: call set_name() only once fs: fat: generate unique short names fs: fat: dentry iterator for fill_dir_slot() fs: fat: set start cluster for root directory fs: fat: flush new directory cluster fs: fat: fat_find_empty_dentries() fs: fat: reuse deleted directory entries fs: fat: search file should not allocate cluster fs: fat: use constant DELETED_FLAG fs: fat: first dentry of long name in FAT iterator fs: fat: deletion of long file names fs/fat/fat.c | 133 ++++++++---- fs/fat/fat_write.c | 532 +++++++++++++++++++++++++++++++++------------ include/fat.h | 7 +- lib/Kconfig | 2 +- 4 files changed, 494 insertions(+), 180 deletions(-) -- 2.29.2

2 19