September 2020 - U-Boot

[PATCH] binman: Allow FIT binaries to have missing external blobs
by Simon Glass 01 Sep '20

01 Sep '20

At present if a FIT references a missing external blob, binman reports an error, even if the image is supposed to allow this. Propagate this setting down to the child sections of the FIT, so that the behaviour is consistent. This is a fix-up patch to: binman: Build FIT image subentries with the section etype and will be squashed into that. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- tools/binman/etype/fit.py | 15 ++++++++ tools/binman/ftest.py | 8 +++++ tools/binman/test/168_fit_missing_blob.dts | 41 ++++++++++++++++++++++ 3 files changed, 64 insertions(+) create mode 100644 tools/binman/test/168_fit_missing_blob.dts diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py index acba53aa92c..615b2fd8778 100644 --- a/tools/binman/etype/fit.py +++ b/tools/binman/etype/fit.py @@ -169,3 +169,18 @@ class Entry_fit(Entry): fdt.Sync(auto_resize=True) data = fdt.GetContents() return data + + def CheckMissing(self, missing_list): + """Check if any entries in this FIT have missing external blobs + + If there are missing blobs, the entries are added to the list + + Args: + missing_list: List of Entry objects to be added to + """ + for path, section in self._fit_sections.items(): + section.CheckMissing(missing_list) + + def SetAllowMissing(self, allow_missing): + for section in self._fit_sections.values(): + section.SetAllowMissing(allow_missing) diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py index 762535b5a74..e672967dbaa 100644 --- a/tools/binman/ftest.py +++ b/tools/binman/ftest.py @@ -3515,5 +3515,13 @@ class TestFunctional(unittest.TestCase): U_BOOT_DTB_DATA) self.assertEqual(expected, data) + def testFitExtblobMissingOk(self): + """Test a FIT with a missing external blob that is allowed""" + with test_util.capture_sys_output() as (stdout, stderr): + self._DoTestFile('168_fit_missing_blob.dts', + allow_missing=True) + err = stderr.getvalue() + self.assertRegex(err, "Image 'main-section'.*missing.*: blob-ext") + if __name__ == "__main__": unittest.main() diff --git a/tools/binman/test/168_fit_missing_blob.dts b/tools/binman/test/168_fit_missing_blob.dts new file mode 100644 index 00000000000..e007aa41d8a --- /dev/null +++ b/tools/binman/test/168_fit_missing_blob.dts @@ -0,0 +1,41 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/dts-v1/; + +/ { + #address-cells = <1>; + #size-cells = <1>; + + binman { + u-boot { + }; + fit { + description = "test-desc"; + #address-cells = <1>; + fit,fdt-list = "of-list"; + + images { + kernel { + description = "ATF BL31"; + type = "kernel"; + arch = "ppc"; + os = "linux"; + compression = "gzip"; + load = <00000000>; + entry = <00000000>; + hash-1 { + algo = "crc32"; + }; + hash-2 { + algo = "sha1"; + }; + blob-ext { + filename = "missing"; + }; + }; + }; + }; + u-boot-nodtb { + }; + }; +}; -- 2.28.0.402.g5ffc5be6b7-goog

2 3

[PATCH v2 0/3] binman: Make FIT image subentries respect offset, alignment and padding
by Alper Nebi Yasak 01 Sep '20

01 Sep '20

I've been automating the process in doc/README.chromium-chainload and while experimenting with whether a "kernel" image with u-boot-spl and u-boot would work, noticed I couldn't align/offset/pad the two parts. E.g. in something like the following, binman doesn't add the necessary padding to place the "u-boot" to the correct offset within the "kernel-1" data: fit { description = "example"; images { kernel-1 { description = "U-Boot with SPL"; type = "kernel"; arch = "arm64"; os = "linux"; compression = "none"; u-boot-spl { }; u-boot { offset = <CONFIG_SPL_PAD_TO>; }; }; }; }; Not sure if that'll ever be really necessary besides my experiment, but it doesn't seem like skipping the padding was a deliberate choice, so here are some fixes I wrote for that. Changes in v2: - Add test to check that sections ignore hash*, signature* nodes - Move section padding test to the end of file - Renumber tests to accommodate for the first patch's new test - Use 'section' instead of 'image' for FIT subimage sections - Also rename 'Members:' comment for the renamed _fit_content variable - Clarify comments around FIT subimage section/content processing - Don't check for section.ObtainContents() returning False (never does) v1: https://patchwork.ozlabs.org/project/uboot/list/?series=197693 Alper Nebi Yasak (3): binman: Ignore hash*, signature* nodes in sections binman: Respect pad-before property of section subentries binman: Build FIT image subentries with the section etype tools/binman/etype/fit.py | 41 +++++++------ tools/binman/etype/section.py | 4 +- tools/binman/ftest.py | 37 ++++++++++++ .../165_section_ignore_hash_signature.dts | 40 +++++++++++++ tools/binman/test/166_pad_in_sections.dts | 26 +++++++++ .../test/167_fit_image_subentry_alignment.dts | 57 +++++++++++++++++++ 6 files changed, 186 insertions(+), 19 deletions(-) create mode 100644 tools/binman/test/165_section_ignore_hash_signature.dts create mode 100644 tools/binman/test/166_pad_in_sections.dts create mode 100644 tools/binman/test/167_fit_image_subentry_alignment.dts -- 2.28.0

2 9

Re: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi()
by Rick Chen 01 Sep '20

01 Sep '20

Hi Heinrich > From: Heinrich Schuchardt [mailto:xypron.glpk@gmx.de] > Sent: Tuesday, August 11, 2020 11:57 AM > To: Rick Jian-Zhi Chen(陳建志) > Cc: Sean Anderson; Lukas Auer; Simon Glass; Anup Patel; Daniel Schwierzeck; u-boot(a)lists.denx.de; Heinrich Schuchardt > Subject: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi() > > At least on the Kendryte K210: > > gd->arch.available_harts= 0x0000000000000003 arch.ipi[0].addr= > gd->0x0000000000000000 arch.ipi[0].arg0= 0x0000000000000000 > gd->arch.ipi[0].arg1= 0x0000000000000000 arch.ipi[1].addr= > gd->0x0000000000000000 arch.ipi[1].arg0= 0x0000000000000000 > gd->arch.ipi[1].arg1= 0x0000000000000000 > > We should not jump to 0x0 to handle an interrupt. Can you explain why K210 be affected by it ? > > Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> > --- > arch/riscv/lib/smp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c index ac22136314..d725fa32e8 100644 > --- a/arch/riscv/lib/smp.c > +++ b/arch/riscv/lib/smp.c > @@ -96,6 +96,8 @@ void handle_ipi(ulong hart) > return; > } > > + if (!smp_function) > + return; > smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1); } I remember Sean add this check in [v10,14/21] riscv: Clean up IPI initialization code . And I ask him to remove. https://patchwork.ozlabs.org/project/uboot/patch/20200503024637.327733-15-s… Thanks, Rick > > -- > 2.28.0

4 8

from https://gitlab.denx.de/u-boot/custodians/u-boot-mips:f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master:
by Mauro Condarelli 01 Sep '20

01 Sep '20

Sorry to disturb :( I am trying to switch from https://gitlab.denx.de/u-boot/custodians/u-boot-mips commit f3d8c7f8d3c02ff1de172aff7e6392a9ddd1f5b2 to master. In both case I'm using plain "vocore2_defconfig". Actually I'm using: make ARCH=mips CROSS_COMPILE=~/vocore/__V2__/Buildroot-2/mipsel-buildroot-linux-uclibc_sdk-buildroot/bin/mipsel-linux- all for master and Buildroot compilation environment for `u-boot-mips`, but I don't think that's the problem (compiler is the same, if needed I'll recompile manually "old" also). Of course the two versions have tons of differences, but .config is essentially the same (some reordering and a few apparently harmless new CONFIG_s; iff deemed useful I can post both, but, as said, I'm using in-tree vocore2_defconfig in both cases). First thing is something changed in compilation and the old "u-boot-mtmips.bin" si nowhere to be found, apparently replaced by "u-boot-with-spl.bin". Second data point is new u-boot is substantially larger: -rwxr-xr-x 1 root root 244580 Aug 31 20:06 u-boot-mtmips.bin -rwxr-xr-x 1 root root 275005 Aug 31 20:00 u-boot-with-spl.bin Third and most important new version does not work: =============================================== U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200) Trying to boot from NOR U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200) CPU: MediaTek MT7628A ver:1 eco:2 Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz DRAM: 128 MiB WDT: Started with servicing (60s timeout) MMC: mmc@10130000: 0 Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In: uart2@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - b6:bf:30:14:ba:25 eth0: eth@10110000 Hit any key to stop autoboot: 0 => load mmc 0:1 80010000 u-boot-mtmips.bin && go ${fileaddr} 244580 bytes read in 17 ms (13.7 MiB/s) ## Starting application at 0x80010000 ... U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200) Trying to boot from NOR U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200) CPU: MediaTek MT7628A ver:1 eco:2 Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz DRAM: 128 MiB WDT: Started with servicing (60s timeout) MMC: mmc@10130000: 0 Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In: uart2@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 36:f2:c3:0a:27:a4 eth0: eth@10110000 Hit any key to stop autoboot: 0 => =============================================== U-Boot SPL 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200) Trying to boot from NOR U-Boot 2020.04-rc1 (Mar 29 2020 - 17:07:13 +0200) CPU: MediaTek MT7628A ver:1 eco:2 Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz DRAM: 128 MiB WDT: Started with servicing (60s timeout) MMC: mmc@10130000: 0 Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB OK In: uart2@e00 Out: uart2@e00 Err: uart2@e00 Model: VoCore2 Net: Warning: eth@10110000 (eth0) using random MAC address - 1e:a9:c5:a8:35:82 eth0: eth@10110000 Hit any key to stop autoboot: 0 => load mmc 0:1 80010000 u-boot-with-spl.bin && go ${fileaddr} 275005 bytes read in 20 ms (13.1 MiB/s) ## Starting application at 0x80010000 ... <<dead>> =============================================== What am I doing so wrong? I'm available to all possible tests, but I'm, most likely, just missing something obvious. I'm also available on IRC as "mcon". Thanks in advance. Mauro Condarelli

3 7

[PATCH v2] fastboot: getvar: fix partition-size return value
by Gary Bisson 01 Sep '20

01 Sep '20

The size returned by 'getvar partition-size' should be in bytes, not in blocks as fastboot uses that value to generate empty partition when running format [1]. Note that the function was already returning the proper size in bytes for NAND devices (see struct part_info details). [1] https://android.googlesource.com/platform/system/core/+/refs/heads/android1… Signed-off-by: Gary Bisson <gary.bisson(a)boundarydevices.com> --- Changelog v1->v2: - removed change for FASTBOOT_FLASH_NAND as not necessary (and therefore not building) --- drivers/fastboot/fb_getvar.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c index 52da34b1e37..d43f2cfee66 100644 --- a/drivers/fastboot/fb_getvar.c +++ b/drivers/fastboot/fb_getvar.c @@ -95,7 +95,7 @@ static const struct { * * @param[in] part_name Info for which partition name to look for * @param[in,out] response Pointer to fastboot response buffer - * @param[out] size If not NULL, will contain partition size (in blocks) + * @param[out] size If not NULL, will contain partition size * @return Partition number or negative value on error */ static int getvar_get_part_info(const char *part_name, char *response, @@ -109,7 +109,7 @@ static int getvar_get_part_info(const char *part_name, char *response, r = fastboot_mmc_get_part_info(part_name, &dev_desc, &part_info, response); if (r >= 0 && size) - *size = part_info.size; + *size = part_info.size * part_info.blksz; # elif CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND) struct part_info *part_info; -- 2.28.0

2 2

[GIT] Pull request: u-boot-dfu (27.08.2019)
by Lukasz Majewski 01 Sep '20

01 Sep '20

Dear Marek, Please find a set of DFU/Gadget/sdp/fastboot related fixes and enhancements: https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/commits/master The git tag with detailed changes description in this PR can be found here: https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-27Aug… Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma(a)denx.de

2 5

"Drop ffs" functionality in MTD DFU backend
by Guillermo Rodriguez Garcia 01 Sep '20

01 Sep '20

Hello all, I am using u-boot on a STM32MP1 EV1 board. Until recently, the NAND DFU backend was used to flash UBI images to the board. I used the DFU_NAND_TRIMFFS option to ensure that the UBI image was correctly flashed to NAND. Recently, ST has switched from the NAND DFU backend to the MTD DFU backend. Is there a way to tell the MTD subsystem to do the same (drop trailing all-0xff pages) in order to flash UBI images to raw NAND? Thank you, Guillermo Rodriguez Garcia guille.rodriguez(a)gmail.com

1 0

"Drop ffs" functionality in MTD DFU backend
by Guillermo Rodriguez Garcia 01 Sep '20

01 Sep '20

Hello all, I am using u-boot on a STM32MP1 EV1 board. Until recently, the NAND DFU backend was used to flash UBI images to the board. I used the DFU_NAND_TRIMFFS option to ensure that the UBI image was correctly flashed to NAND. Recently, ST has switched from the NAND DFU backend to the MTD DFU backend. Is there a way to tell the MTD subsystem to do the same (drop trailing all-0xff pages) in order to flash UBI images to raw NAND? Thank you, Guillermo Rodriguez Garcia guille.rodriguez(a)gmail.com

1 0

[PATCH v3] x86: qemu: Remove dead code
by Andy Shevchenko 01 Sep '20

01 Sep '20

start.S does nothing and can be safely removed. Makefile is still being used by the build system, so simply replace the rule in it. We use stub C-file like it's done for other boards. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Simon Glass <sjg(a)chromium.org> Reviewed-by: Bin Meng <bmeng.cn(a)gmail.com> --- v3: fixed linker error (Bin) board/emulation/qemu-x86/Makefile | 2 +- board/emulation/qemu-x86/qemu-x86.c | 0 board/emulation/qemu-x86/start.S | 8 -------- 3 files changed, 1 insertion(+), 9 deletions(-) create mode 100644 board/emulation/qemu-x86/qemu-x86.c delete mode 100644 board/emulation/qemu-x86/start.S diff --git a/board/emulation/qemu-x86/Makefile b/board/emulation/qemu-x86/Makefile index 782e298b74ce..ff4aaa51c540 100644 --- a/board/emulation/qemu-x86/Makefile +++ b/board/emulation/qemu-x86/Makefile @@ -2,4 +2,4 @@ # # Copyright (C) 2015, Bin Meng <bmeng.cn(a)gmail.com> -obj-y += start.o +obj-y += qemu-x86.o diff --git a/board/emulation/qemu-x86/qemu-x86.c b/board/emulation/qemu-x86/qemu-x86.c new file mode 100644 index 000000000000..e69de29bb2d1 diff --git a/board/emulation/qemu-x86/start.S b/board/emulation/qemu-x86/start.S deleted file mode 100644 index e4bde561b20d..000000000000 --- a/board/emulation/qemu-x86/start.S +++ /dev/null @@ -1,8 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ -/* - * Copyright (C) 2015, Bin Meng <bmeng.cn(a)gmail.com> - */ - -.globl early_board_init -early_board_init: - jmp early_board_init_ret -- 2.28.0

2 1

[PATCH v2 01/15] x86: Introduce USE_EARLY_BOARD_INIT option
by Andy Shevchenko 01 Sep '20

01 Sep '20

Introduce USE_EARLY_BOARD_INIT option and select it by the actual users. Cc: George McCollister <george.mccollister(a)gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Stefan Roese <sr(a)denx.de> Reviewed-by: Aiden Park <aiden.park(a)intel.com> --- v2: added Rb tag(s), appended CONFIG prefix when use the option in the code arch/x86/Kconfig | 3 +++ arch/x86/cpu/start.S | 3 +++ board/google/chromebook_coral/Kconfig | 1 + board/google/chromebook_link/Kconfig | 1 + board/google/chromebook_samus/Kconfig | 1 + 5 files changed, 9 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a34b108fffa6..76276c602745 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -203,6 +203,9 @@ config SPL_X86_32BIT_INIT help This is enabled when 32-bit init is in SPL +config USE_EARLY_BOARD_INIT + bool + config RESET_SEG_START hex depends on X86_RESET_VECTOR diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index 4ad515ce0856..3b6ed37bc07e 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -88,6 +88,7 @@ _start: /* Clear the interrupt vectors */ lidt blank_idt_ptr +#ifdef CONFIG_USE_EARLY_BOARD_INIT /* * Critical early platform init - generally not used, we prefer init * to happen later when we have a console, in case something goes @@ -96,6 +97,8 @@ _start: jmp early_board_init .globl early_board_init_ret early_board_init_ret: +#endif + post_code(POST_START) /* Initialise Cache-As-RAM */ diff --git a/board/google/chromebook_coral/Kconfig b/board/google/chromebook_coral/Kconfig index 940bee89b0b6..27671958e146 100644 --- a/board/google/chromebook_coral/Kconfig +++ b/board/google/chromebook_coral/Kconfig @@ -18,6 +18,7 @@ config SYS_TEXT_BASE config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select X86_RESET_VECTOR + select USE_EARLY_BOARD_INIT select INTEL_APOLLOLAKE select BOARD_ROMSIZE_KB_16384 diff --git a/board/google/chromebook_link/Kconfig b/board/google/chromebook_link/Kconfig index 944716d002c9..dd29ddf694be 100644 --- a/board/google/chromebook_link/Kconfig +++ b/board/google/chromebook_link/Kconfig @@ -19,6 +19,7 @@ config SYS_TEXT_BASE config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select X86_RESET_VECTOR + select USE_EARLY_BOARD_INIT select NORTHBRIDGE_INTEL_IVYBRIDGE select HAVE_INTEL_ME select BOARD_ROMSIZE_KB_8192 diff --git a/board/google/chromebook_samus/Kconfig b/board/google/chromebook_samus/Kconfig index 90c23cba1bed..9f66d7998870 100644 --- a/board/google/chromebook_samus/Kconfig +++ b/board/google/chromebook_samus/Kconfig @@ -19,6 +19,7 @@ config SYS_TEXT_BASE config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select X86_RESET_VECTOR + select USE_EARLY_BOARD_INIT select INTEL_BROADWELL select HAVE_INTEL_ME select BOARD_ROMSIZE_KB_8192 -- 2.28.0

2 33