August 2020 - U-Boot

Missing BMP 565RGB video support
by Trommel, Kees (Contractor) 02 Sep '20

02 Sep '20

Hi Agust, The latest version of the U-Boot does not support conversion from 24BPP BMP to a 16BPP 565RGB encoded frame buffer. It uses always 555RGB encoding (see function video_bmp_display in video_bmp.c). Older versions of the U-Boot (e.g. 2015.04) supported this because the platform specific device driver passed not only the BPP but also the encoding. Do you know whether this lost support was done on purpose or lost by accident? I encountered this issue when trying to display a 24BPP BMP splash screen at an i.MX6 platform. Kees. --- This communication contains confidential information. If you are not the intended recipient please return this email to the sender and delete it from your records. Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System.

2 2

[PATCH] pinctrl: mediatek: mt8512: fix the wrong start address of ranges
by Chunfeng Yun 02 Sep '20

02 Sep '20

The start address of dout, pullen and pullsel ragnes are wrong, so fix up them. Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com> --- drivers/pinctrl/mediatek/pinctrl-mt8512.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8512.c b/drivers/pinctrl/mediatek/pinctrl-mt8512.c index af43754..bf2a8dd9 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mt8512.c +++ b/drivers/pinctrl/mediatek/pinctrl-mt8512.c @@ -31,15 +31,15 @@ static const struct mtk_pin_field_calc mt8512_pin_di_range[] = { }; static const struct mtk_pin_field_calc mt8512_pin_do_range[] = { - PIN_FIELD(0, 115, 0x860, 0x10, 0, 1), + PIN_FIELD(0, 115, 0x0A0, 0x10, 0, 1), }; static const struct mtk_pin_field_calc mt8512_pin_pullen_range[] = { - PIN_FIELD(0, 115, 0x900, 0x10, 0, 1), + PIN_FIELD(0, 115, 0x860, 0x10, 0, 1), }; static const struct mtk_pin_field_calc mt8512_pin_pullsel_range[] = { - PIN_FIELD(0, 115, 0x0A0, 0x10, 0, 1), + PIN_FIELD(0, 115, 0x900, 0x10, 0, 1), }; static const struct mtk_pin_field_calc mt8512_pin_ies_range[] = { -- 1.9.1

3 2

[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

[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

[PATCH 0/2] x86: Minor nits from previous reviews
by Simon Glass 01 Sep '20

01 Sep '20

I found a few nits in my queue that were not addressed at the time. This series fixes them. Simon Glass (2): x86: pinctrl: Fix 'relatove' typo x86: Drop nhlt_serialise() arch/x86/include/asm/acpi_nhlt.h | 8 -------- drivers/pinctrl/intel/Kconfig | 2 +- 2 files changed, 1 insertion(+), 9 deletions(-) -- 2.28.0.402.g5ffc5be6b7-goog

2 6

[PATCH] x86: mtrr: Fix parsing of "mtrr list" command
by Wolfgang Wallner 01 Sep '20

01 Sep '20

The command 'mtrr' does not recognize the 'list' subcommand any more since the code restructuring in commit b2a76b3fe75a ("x86: mtrr: Restructure so command execution is in one place"). The if-else parsing the command arguments does not take 'list' into account: the if-branch is intended for no subcommands, the else-branch is intended for the non-list subcommands (which all expect additional arguments). Calling the 'mtrr list' subcommand leads to a "return CMD_RET_USAGE" in the else-branch. Fix this by changing the else-branch to explicitly checking for if (cmd != 'l'). Fixes: b2a76b3fe75a ("x86: mtrr: Restructure so command execution is in one place") Signed-off-by: Wolfgang Wallner <wolfgang.wallner(a)br-automation.com> --- cmd/x86/mtrr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cmd/x86/mtrr.c b/cmd/x86/mtrr.c index e118bba5a2..99efecb9d8 100644 --- a/cmd/x86/mtrr.c +++ b/cmd/x86/mtrr.c @@ -121,7 +121,8 @@ static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int argc, if (argc < 1 || !cmd) { cmd = 'l'; reg = 0; - } else { + } + if (cmd != 'l') { if (argc < 2) return CMD_RET_USAGE; reg = simple_strtoul(argv[1], NULL, 16); -- 2.28.0

3 3