December 2020 - U-Boot

[PATCH v1 1/4] IOMUX: Preserve console list if realloc() fails
by Andy Shevchenko 17 Dec '20

17 Dec '20

It's realloc() 101 to avoid `foo = realloc(foo, ...);` call due to getting a memory leak. Actually it's not clear why realloc() has been used here. If we shrink the array, the memcpy() overwrites it anyway with the contents of a new array. If it becomes bigger, same story. Drop useless realloc() for good and thus preserve console list in case of failed allocation. Fixes: 16a28ef219c2 ("IOMUX: Add console multiplexing support.") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- common/iomux.c | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/common/iomux.c b/common/iomux.c index 7cfd9f2e9162..cee5f266c86e 100644 --- a/common/iomux.c +++ b/common/iomux.c @@ -129,19 +129,10 @@ int iomux_doenv(const int console, const char *arg) return 1; } else { /* Works even if console_devices[console] is NULL. */ - console_devices[console] = - (struct stdio_dev **)realloc(console_devices[console], - cs_idx * sizeof(struct stdio_dev *)); - if (console_devices[console] == NULL) { - free(cons_set); - return 1; - } - memcpy(console_devices[console], cons_set, cs_idx * - sizeof(struct stdio_dev *)); - + free(console_devices[console]); + console_devices[console] = cons_set; cd_count[console] = cs_idx; } - free(cons_set); return 0; } #endif /* CONSOLE_MUX */ -- 2.29.2

2 5

[PATCH 1/1] doc: man-page for bootefi command
by Heinrich Schuchardt 16 Dec '20

16 Dec '20

Provide a description of the bootefi command. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- MAINTAINERS | 1 + doc/usage/bootefi.rst | 135 ++++++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + 3 files changed, 137 insertions(+) create mode 100644 doc/usage/bootefi.rst diff --git a/MAINTAINERS b/MAINTAINERS index 127e30c0a5..8675965fe5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -679,6 +679,7 @@ S: Maintained T: git https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git F: doc/api/efi.rst F: doc/uefi/* +F: doc/usage/bootefi.rst F: drivers/rtc/emul_rtc.c F: include/capitalization.h F: include/charset.h diff --git a/doc/usage/bootefi.rst b/doc/usage/bootefi.rst new file mode 100644 index 0000000000..432a2b2fed --- /dev/null +++ b/doc/usage/bootefi.rst @@ -0,0 +1,135 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright 2020, Heinrich Schuchardt <xypron.glpk(a)gmx.de> + +bootefi command +=============== + +Synopsis +-------- + +.. code-block:: + + bootefi [image_addr] [fdt_addr] + bootefi bootmgr [fdt_addr] + bootefi hello [fdt_addr] + bootefi selftest [fdt_addr] + +Description +----------- + +The *bootefi* command is used to launch a UEFI binary which can be either of + +* UEFI application +* UEFI boot services driver +* UEFI run-time services driver + +An operating system requires a hardware description which can either be +presented as ACPI table (CONFIG\_GENERATE\_ACPI\_TABLE=y) or as device-tree +The load address of the device-tree may be provided as parameter *fdt\_addr*. If +this address is not specified, the bootefi command will try to fall back in +sequence to: + +* the device-tree specified by environment variable *fdt\_addr* +* the device-tree specified by environment variable *fdtcontroladdr* + +The load address of the binary is specified by parameter *image_address*. A +command sequence to run a UEFI application might look like + +.. code-block:: + + load mmc 0:2 $fdt_addr_r dtb + load mmc 0:1 $kernel_addr_r /EFI/grub/grubaa64.efi + bootefi $kernel_addr_r $fdt_addr_r + +The last file loaded defines the image file path in the loaded image protocol. +Hence the executable should always be loaded last. + +The value of the environment variable *bootargs* is converted from UTF-8 to +UTF-16 and passed as load options in the loaded image protocol to the UEFI +binary. + +Note + UEFI binaries that are contained in FIT images are launched via the + *bootm* command. + +UEFI boot manager +''''''''''''''''' + +The UEFI boot manager is invoked by the *bootefi bootmgr* sub-command. +Here boot options are defined by UEFI variables with a name consisting of the +letters *Boot* followed by a four digit hexadecimal number, e.g. *Boot0001* or +*BootA03E*. The boot variable defines a label, the device path of the binary to +execute as well as the load options passed in the loaded image protocol. + +If the UEFI variable *BootNext* is defined, it specifies the number of the boot +option to execute next. If no binary can be loaded via *BootNext* the variable +*BootOrder* specifies in which sequence boot options shalled be tried. + +The values of these variables can be managed using the U-Boot command +*efidebug*. + +UEFI hello world application +'''''''''''''''''''''''''''' + +U-Boot can be compiled with a hello world application that can be launched using +the *bootefi hello* sub-command. A session might look like + +.. code-block:: + + => setenv bootargs 'Greetings to the world' + => bootefi hello + Booting /MemoryMapped(0x0,0x10001000,0x1000) + Hello, world! + Running on UEFI 2.8 + Have SMBIOS table + Have device tree + Load options: Greetings to the world + +UEFI selftest +''''''''''''' + +U-Boot can be compiled with UEFI unit tests. These unit tests are invoked using +the *bootefi selftest* sub-command. + +Which unit test is executed is controlled by the environment variable +*efi\_selftest*. If this variable is not set, all unit tests that are not marked +as 'on request' are executed. + +To show a list of the available unit tests the value *list* can be used + +.. code-block:: + + => setenv efi_selftest list + => bootefi selftest + + Available tests: + 'block image transfer' - on request + 'block device' + 'configuration tables' + ... + +A single test is selected for execution by setting the *efi\_selftest* +environment variable to match one of the listed identifiers + +.. code-block:: + + => setenv efi_selftest 'block image transfer' + => bootefi selftest + +Some of the tests execute the ExitBootServices() UEFI boot service and will not +return to the command line but require a board reset. + +Configuration +------------- + +To use the *bootefi* command you must specify CONFIG\_CMD\_BOOTEFI=y. +The *bootefi hello* sub-command requries CMD\_BOOTEFI\_HELLO=y. +The *bootefi selftest* sub-command depends on CMD\_BOOTEFI\_SELFTEST=y. + +See also +-------- + +* *bootm* for launching UEFI binaries packed in FIT images +* *booti*, *bootm*, *bootz* for launching a Linux kernel without using the + UEFI sub-system +* *efidebug* for setting UEFI boot variables diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 6c4b5b9240..fbb2c0481c 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -11,6 +11,7 @@ Shell commands .. toctree:: :maxdepth: 1 + bootefi bootmenu button pstore -- 2.29.2

1 0

U-Boot failures on CM4 and Pi4-8Gb
by Dave Jones 16 Dec '20

16 Dec '20

Hi, We've recently run across some failures with U-Boot on a couple of platforms, specifically the relatively new Pi Compute Module 4, and the Pi 4 8GB of RAM. On the CM4, U-Boot failed to identify the eMMC storage, and on the Pi 4 8GB, a crash and reset occurred when U-Boot tried to read from the boot file-system on the SD card, but only when booted with no monitor attached (attaching a monitor results in a successful boot, at least under arm64). These were with more-or-less stock rpi_4_defconfig and rpi_4_32b_defconfig configurations from v2020.10 (our local config changes bump the env-size, enable OF_BOARD, and RAW_INITRD, but that's it). I've bisected the source and figured out roughly the commits responsible; for the CM4 eMMC case it's the enabling of DMA for the SDHCI interface in c6b9fbf756. The Pi 4 8GB failure was a little more complex in that the bisection pointed to 3113c84ba2 (a merge), however that gave me a few clues to try and after a little experimenting I found that disabling CONFIG_PCI_BRCMSTB (effectively disabling the PCI driver for the platform) got things working happily again. I'm happy to submit the local patches I'm adding to the Ubuntu build to work around these, but obviously those fixes are "brute force and ignorance" patches that just disable the relevant config; would such patches be wanted, or would the community prefer to figure out the root causes in each case? I'm happy to test any patches on the relevant hardware if anyone doesn't have access to the necessary boards. Best regards, Dave Jones.

3 6

Fujitsu does not respond to GPL request
by Hal Martin 16 Dec '20

16 Dec '20

Hello, I hope I am not breaking an community rules by posing this question to the mailing list, according to the DENX website, this is the correct place to ask my question. [1] I have a Fujitsu TX140 S2 server with iRMC S4. Fujitsu includes a written offer to provide the GPL source code through the "Third Party Licenses" link in the iRMC web admin interface. [2] The stated contact is < primergy-opensource(a)ts.fujitsu.com> I have been trying to reach someone at Fujitsu using the above email address since early November to receive a copy of the GPL source code of u-boot and other GPL licensed software used in iRMC S4 and have thus far received no response from them. Has anyone else successfully requested and received GPL source code from Fujitsu? If so, could you share how you went about this and if it differed from the process I used? Regards, Hal Martin [1] https://www.denx.de/wiki/U-Boot/Contacts [2] https://gist.github.com/halmartin/5eaf26c8b2ca4be46d25f25464128689

1 0

[PATCH v3 0/6] VIM3: add support for checking 'Function' button state
by Marek Szyprowski 16 Dec '20

16 Dec '20

Hi All, This patchset adds all building blocks needed for checking the 'Function' button state in the boot script on Amlogic A311D based VIM3 board. This button is connected to the ADC lines of the SoC, so it required to enable meson SARADC, the clocks needed for it and a simple button-adc drivers. Once applied, one can use following commands in the boot scripts: -->8--- echo Checking Func button state: \\c if button Function then echo Selected alternative boot ... fi --->8--- The above script requires commit a6bfd71a96 ("cmd/button: return button status") already present in mainline tree. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v3: - removed 'button' env variable - extended kconfig and patch descriptions v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html - removed Change-Id tags - split defconfig changes into ADC and button related v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html - initial submission Patch summary: Marek Szyprowski (6): clk: meson: add minimal driver for g12a-ao clocks adc: meson-saradc: add G12A variant adc: meson-saradc: skip hardware init only if ADC is enabled configs: khadas-vim3: enable ADC device support button: add a simple ADC-based button driver configs: khadas-vim3: enable Function button support configs/khadas-vim3_defconfig | 4 ++ drivers/adc/meson-saradc.c | 9 ++- drivers/button/Kconfig | 8 +++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 117 ++++++++++++++++++++++++++++++++++ drivers/clk/meson/Makefile | 1 + drivers/clk/meson/g12a-ao.c | 83 ++++++++++++++++++++++++ 7 files changed, 221 insertions(+), 2 deletions(-) create mode 100644 drivers/button/button-adc.c create mode 100644 drivers/clk/meson/g12a-ao.c -- 2.17.1

2 7

[PATCH 0/3] board: amlogic: add WeTek Core2 support
by Christian Hewitt 16 Dec '20

16 Dec '20

This patchset adds support for the WeTek Core2 box which is based on the Amlogic S912 (GXM) SoC. Patches are based on u-boot-amlogic-next branch in the custodians tree. Christian Hewitt (3): ARM: dts: import WeTek Core2 DTs from Linux 5.10 boards: amlogic: add WeTek Core2 support boards: amlogic: update documentation for WeTek Core2 arch/arm/dts/Makefile | 1 + arch/arm/dts/meson-gx-p23x-q20x.dtsi | 324 ++++++++++++++++++ .../arm/dts/meson-gxm-wetek-core2-u-boot.dtsi | 7 + arch/arm/dts/meson-gxm-wetek-core2.dts | 87 +++++ configs/wetek-core2_defconfig | 70 ++++ doc/board/amlogic/index.rst | 3 +- doc/board/amlogic/wetek-core2.rst | 90 +++++ 7 files changed, 581 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/meson-gx-p23x-q20x.dtsi create mode 100644 arch/arm/dts/meson-gxm-wetek-core2-u-boot.dtsi create mode 100644 arch/arm/dts/meson-gxm-wetek-core2.dts create mode 100644 configs/wetek-core2_defconfig create mode 100644 doc/board/amlogic/wetek-core2.rst -- 2.17.1

2 4

Please pull u-boot-x86
by Bin Meng 16 Dec '20

16 Dec '20

Hi Tom, This PR includes the following x86 changes for v2021.01 release: - Update cmdline parameter to be an env var in zimage boot - Various minor fixes for Intel Edison board Azure pipelines results: PASS https://dev.azure.com/bmeng/GitHub/_build/results?buildId=301&view=results The following changes since commit 56f02f0ae85da8bb2dca66c7816dbb1429f92072: Merge tag 'u-boot-amlogic-20201215' of https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2020-12-15 09:08:14 -0500) are available in the git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to f89e8acbc81ee6d9e57f0156c3ee6de44528c8b7: x86: edison: Switch to DM_USB_GADGET (2020-12-16 13:51:24 +0800) ---------------------------------------------------------------- Andy Shevchenko (6): x86: tangier: Find proper memory region for relocation x86: edison: Drop unneeded DM_PCI_COMPAT x86: edison: Add CPU to compatible string x86: edison: BINMAN selection is specific to the board x86: edison: Use dwc3-generic driver for Intel Edison x86: edison: Switch to DM_USB_GADGET Simon Glass (2): x86: zimage: Update cmdline parameter to be an env var x86: coral: Update the boot script arch/x86/cpu/tangier/Kconfig | 8 +++----- arch/x86/cpu/tangier/sdram.c | 43 +++++++++++++++++++++++++++++++++++++++++++ arch/x86/dts/edison.dts | 14 +++++++++++++- arch/x86/lib/zimage.c | 15 ++++++++------- board/intel/edison/Kconfig | 1 + board/intel/edison/edison.c | 35 ----------------------------------- configs/edison_defconfig | 2 +- drivers/usb/dwc3/dwc3-generic.c | 1 + include/configs/chromebook_coral.h | 11 +++++++---- 9 files changed, 77 insertions(+), 53 deletions(-) Regards, Bin

2 1

[PATCH 0/2] Use RNG to get random behaviour
by matthias.bgg＠kernel.org 16 Dec '20

16 Dec '20

From: Matthias Brugger <mbrugger(a)suse.com> For now bootp and uuid code use a weak seed for generating random data. U-Boot as support for RNG devices now, so we should change to code to use them if they are present. This will help mitigate issues like seen in CVE-2019-11690. Matthias Brugger (2): lib: uuid: use RNG device if present net: Use NDRNG device in srand_mac() lib/uuid.c | 20 +++++++++++++++++--- net/net_rand.h | 18 +++++++++++++++++- 2 files changed, 34 insertions(+), 4 deletions(-) -- 2.29.2

4 7

[PATCH 1/2] arm: dts: rockchip: rk3399: enable rng at the SoC level
by Peter Robinson 16 Dec '20

16 Dec '20

The rng is embedded in the SoC so enable it in the device tree universally, the use of it can be controlled by enabling/disabling at the device config level. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> Cc: Kever Yang <kever.yang(a)rock-chips.com> --- arch/arm/dts/rk3399-evb-u-boot.dtsi | 4 ---- arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4 ---- arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ---- arch/arm/dts/rk3399-u-boot.dtsi | 2 +- 4 files changed, 1 insertion(+), 13 deletions(-) diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi b/arch/arm/dts/rk3399-evb-u-boot.dtsi index 8056dc843e..398b205ec2 100644 --- a/arch/arm/dts/rk3399-evb-u-boot.dtsi +++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi @@ -13,10 +13,6 @@ }; }; -&rng { - status = "okay"; -}; - &i2c0 { u-boot,dm-pre-reloc; }; diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi index ded7db0aef..c3e866a779 100644 --- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi +++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi @@ -28,10 +28,6 @@ u-boot,dm-pre-reloc; }; -&rng { - status = "okay"; -}; - &sdhci { max-frequency = <25000000>; u-boot,dm-pre-reloc; diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi index 6317b47e41..37dff04adf 100644 --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi @@ -15,10 +15,6 @@ }; }; -&rng { - status = "okay"; -}; - &spi1 { spi_flash: flash@0 { u-boot,dm-pre-reloc; diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi index ecd230c720..73922c328a 100644 --- a/arch/arm/dts/rk3399-u-boot.dtsi +++ b/arch/arm/dts/rk3399-u-boot.dtsi @@ -32,7 +32,7 @@ rng: rng@ff8b8000 { compatible = "rockchip,cryptov1-rng"; reg = <0x0 0xff8b8000 0x0 0x1000>; - status = "disabled"; + status = "okay"; }; dmc: dmc { -- 2.29.2

1 1

[PATCH v1] distro_bootcmd: set devtype for dhcp boot
by Igor Opaniuk 16 Dec '20

16 Dec '20

From: Igor Opaniuk <igor.opaniuk(a)toradex.com> Set $devtype for DHCP boot, which can be handy for the boot.scr for detection of devtype used (for example, when the same boot.scr is used for both mmc/dhcp boot): if test ${devtype} = "dhcp"; then ... fi Signed-off-by: Igor Opaniuk <igor.opaniuk(a)toradex.com> --- include/config_distro_bootcmd.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index ff29ef5a90..f5d113513a 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -367,6 +367,7 @@ #endif #define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \ "bootcmd_dhcp=" \ + "setenv devtype " #devtypel "; " \ BOOTENV_RUN_NET_USB_START \ BOOTENV_RUN_PCI_ENUM \ "if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \ -- 2.17.1

3 3