December 2021 - U-Boot

[PATCH v3 1/2] binman: Do not pollute source tree when build with `make O=...`
by Andy Shevchenko 28 Dec '21

28 Dec '21

Importing libraries in Python caches the bytecode by default. Since we run scripts in source tree it ignores the current directory settings, which is $(srctree), and creates cache just in the middle of the source tree. Move cache to the current directory. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- v3: avoided crash (Simon), preserved tree hierarchy tools/binman/main.py | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/tools/binman/main.py b/tools/binman/main.py index 8c1e478d54ce..d19ded491af7 100755 --- a/tools/binman/main.py +++ b/tools/binman/main.py @@ -16,9 +16,20 @@ import sys import traceback import unittest +# Get the absolute path to this file at run-time +our_path = os.path.dirname(os.path.realpath(__file__)) +our1_path = os.path.dirname(our_path) +our2_path = os.path.dirname(our1_path) + +# +# Do not pollute source tree with cache files: +# https://stackoverflow.com/a/60024195/2511795 +# https://bugs.python.org/issue33499 +# +sys.pycache_prefix = os.path.relpath(our_path, os.environ.get('srctree', our2_path)) + # Bring in the patman and dtoc libraries (but don't override the first path # in PYTHONPATH) -our_path = os.path.dirname(os.path.realpath(__file__)) sys.path.insert(2, os.path.join(our_path, '..')) from patman import test_util -- 2.33.0

3 6

[PATCH v2 0/2] Arm Juno board documentation
by Andre Przywara 28 Dec '21

28 Dec '21

Hi, The Arm Ltd. Juno development board is an open, vendor-neutral, Armv8-A development platform. U-Boot is one of the two supported normal world payloads in the firmware design, though U-Boot never really described the process of building or installing it. Fix that by adding documentation for the board in the doc/board directory. Cheers, Andre Changelog: v1 ... v2: - fvp64: RST improvements (links, make command line) - fvp64: use most common platform name in TF-A build command - juno: use more precise naming for Juno development *platform* - juno: fix wrong naming of MCC management controller - juno: mention and link to Juno TRM - juno: simplify SD card connection instructions - juno: use fiptool update instead of complicated explicit re-packaging - juno: describe devicetree selection more precisely Andre Przywara (1): doc: add Arm Juno board documentation Peter Hoyes (1): doc: Add documentation for the Arm VExpress64 board configs doc/board/armltd/fvp64.rst | 30 ++++++++++ doc/board/armltd/index.rst | 11 ++++ doc/board/armltd/juno.rst | 114 +++++++++++++++++++++++++++++++++++++ doc/board/index.rst | 1 + 4 files changed, 156 insertions(+) create mode 100644 doc/board/armltd/fvp64.rst create mode 100644 doc/board/armltd/index.rst create mode 100644 doc/board/armltd/juno.rst -- 2.25.1

4 8

[PATCH 1/1] efi: fix typo in description of struct efi_entry_hdr
by Heinrich Schuchardt 28 Dec '21

28 Dec '21

Add missing colon. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- include/efi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/efi.h b/include/efi.h index 0ec5913ddd..1432038838 100644 --- a/include/efi.h +++ b/include/efi.h @@ -321,7 +321,7 @@ struct efi_info_hdr { * struct efi_entry_hdr - Header for a table entry * * @type: enum eft_entry_t - * @size size of entry bytes excluding header and padding + * @size: size of entry bytes excluding header and padding * @addr: address of this entry (0 if it follows the header ) * @link: size of entry including header and padding * @spare1: Spare space for expansion -- 2.33.1

2 1

[PATCH 1/1] tools: avoid OpenSSL deprecation warnings
by Heinrich Schuchardt 28 Dec '21

28 Dec '21

Our Gitlab CI buildsystem is set up to treat warnings as errors. With OpenSSL 3.0 a lot of deprecation warnings occur. With the patch compatibility with OpenSSL 1.1.1 is declared. In the long run we should upgrade our code to use the current API. A -Wdiscarded-qualifiers warning is muted by casting. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- lib/aes/aes-encrypt.c | 3 +++ lib/ecdsa/ecdsa-libcrypto.c | 2 ++ lib/rsa/rsa-sign.c | 6 ++++-- tools/kwbimage.c | 2 ++ 4 files changed, 11 insertions(+), 2 deletions(-) diff --git a/lib/aes/aes-encrypt.c b/lib/aes/aes-encrypt.c index a6d1720f30..e74e35eaa2 100644 --- a/lib/aes/aes-encrypt.c +++ b/lib/aes/aes-encrypt.c @@ -2,6 +2,9 @@ /* * Copyright (c) 2019,Softathome */ + +#define OPENSSL_API_COMPAT 0x10101000L + #include "mkimage.h" #include <stdio.h> #include <string.h> diff --git a/lib/ecdsa/ecdsa-libcrypto.c b/lib/ecdsa/ecdsa-libcrypto.c index 1757a14562..ae6dfa0ba9 100644 --- a/lib/ecdsa/ecdsa-libcrypto.c +++ b/lib/ecdsa/ecdsa-libcrypto.c @@ -18,6 +18,8 @@ * Copyright (c) 2020,2021, Alexandru Gagniuc <mr.nuke.me(a)gmail.com> */ +#define OPENSSL_API_COMPAT 0x10101000L + #include <u-boot/ecdsa.h> #include <u-boot/fdt-libcrypto.h> #include <openssl/ssl.h> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c index 0e0a890fd1..0d05165760 100644 --- a/lib/rsa/rsa-sign.c +++ b/lib/rsa/rsa-sign.c @@ -3,6 +3,8 @@ * Copyright (c) 2013, Google Inc. */ +#define OPENSSL_API_COMPAT 0x10101000L + #include "mkimage.h" #include <stdlib.h> #include <stdio.h> @@ -688,9 +690,9 @@ int rsa_add_verify_data(struct image_sign_info *info, void *keydest) goto err_get_pub_key; #if OPENSSL_VERSION_NUMBER < 0x10100000L || \ (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - rsa = EVP_PKEY_get1_RSA(pkey); + rsa = (RSA *)EVP_PKEY_get1_RSA(pkey); #else - rsa = EVP_PKEY_get0_RSA(pkey); + rsa = (RSA *)EVP_PKEY_get0_RSA(pkey); #endif ret = rsa_get_params(rsa, &exponent, &n0_inv, &modulus, &r_squared); if (ret) diff --git a/tools/kwbimage.c b/tools/kwbimage.c index d200ff2425..53715c6e78 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -7,6 +7,8 @@ * <thomas.petazzoni(a)free-electrons.com> */ +#define OPENSSL_API_COMPAT 0x10101000L + #include "imagetool.h" #include <limits.h> #include <image.h> -- 2.33.1

2 1

[PATCH v5 0/6] fpga: zynqmp: Adding support of loading authenticated images
by Oleksandr Suvorov 28 Dec '21

28 Dec '21

This patchset introduces support for the authenticated FPGA images on ZynqMP boards, besides that introducing common way to pass the compatible property to any fpga driver. It bases on the initial work by Jorge Ramirez-Ortiz <jorge(a)foundries.io> https://patchwork.ozlabs.org/project/uboot/patch/20211015091506.2602-1-jorg… https://patchwork.ozlabs.org/project/uboot/patch/20211005111324.19749-3-jor… Changes in v5: - replace ifdef with if() where it's possible Changes in v4: - change interface to xilinx_desc->operations->open() callback. - fix a bug from previous version of the patchset in dereferencing of a parent fpga_desc structure. Changes in v3: - remove the patch which introduced CMD_SPL_FPGA_LOAD_SECURE. - fix mixing definitions/declarations. - replace strcmp() calls with more secure strncmp(). - document the "u-boot,zynqmp-fpga-ddrauth" compatible string. - fix code style by check-patch recommendations. Changes in v2: - add function fit_fpga_load() to simplify calls of fpga_load() from contexts without a compatible attribute. - move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c - prepare for passing a "compatible" FDT property to any fpga driver. Oleksandr Suvorov (6): fpga: add option for loading FPGA secure bitstreams fpga: add fit_fpga_load function fpga: xilinx: pass an address of xilinx_desc in fpga_desc fpga: xilinx: add missed identifier names fpga: xilinx: pass xilinx_desc pointer address into load() ops fpga: zynqmp: support loading authenticated images boot/Kconfig | 4 +-- cmd/Kconfig | 3 +- common/spl/spl_fit.c | 6 ++-- doc/uImage.FIT/source_file_format.txt | 5 +++- drivers/fpga/Kconfig | 14 +++++++++ drivers/fpga/fpga.c | 41 ++++++++++++++++++++------- drivers/fpga/spartan2.c | 3 +- drivers/fpga/spartan3.c | 3 +- drivers/fpga/versalpl.c | 2 +- drivers/fpga/virtex2.c | 3 +- drivers/fpga/xilinx.c | 8 ++++-- drivers/fpga/zynqmppl.c | 30 +++++++++++++++++--- drivers/fpga/zynqpl.c | 3 +- include/fpga.h | 4 +++ include/xilinx.h | 12 ++++---- 15 files changed, 106 insertions(+), 35 deletions(-) -- 2.33.1

2 7

[PATCH v2] doc: qemu-arm peripherials
by Heinrich Schuchardt 28 Dec '21

28 Dec '21

* add description how to add RNG device * for a disk specify format=raw to avoid a warning * fix a typo Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- v2: remove unrelated change --- doc/board/emulation/qemu-arm.rst | 9 +++++++-- drivers/tpm/tpm2_tis_mmio.c | 5 ++++- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 584ef0a7e1..7c24e29410 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -65,7 +65,8 @@ can be enabled with the following command line parameters: - To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.:: - -drive if=none,file=disk.img,id=mydisk -device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0 + -drive if=none,file=disk.img,format=raw,id=mydisk \ + -device ich9-ahci,id=ahci -device ide-drive,drive=mydisk,bus=ahci.0 - To add an Intel E1000 network adapter, pass e.g.:: @@ -75,10 +76,14 @@ can be enabled with the following command line parameters: -device usb-ehci,id=ehci -- To add a NVMe disk, pass e.g.:: +- To add an NVMe disk, pass e.g.:: -drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo +- To add a random number generator, pass e.g.:: + + -device virtio-rng-pci + These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well. Enabling TPMv2 support -- 2.32.0

2 1

[PATCH] sunxi: add board documentation
by Andre Przywara 28 Dec '21

28 Dec '21

Add some long overdue instructions for building and installing U-Boot on Allwinner SoC based boards. This describes the building process, including TF-A and crust, plus installation to SD card, eMMC and SPI flash, both from Linux and U-Boot itself. Also describe FEL booting. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- Hi, please have a look whether this makes sense. Feel free to just try something, and point out ambiguities or missing bits. For missing topics, please send a follow-up patch ;-) Also this is quite long, shall this be split up in two (or more) files? This is what rst.ninjs.org made of it, if you prefer to read it formatted: https://paste.c-net.org/PleasantNeedy Cheers, Andre doc/board/allwinner/index.rst | 9 + doc/board/allwinner/sunxi.rst | 304 ++++++++++++++++++++++++++++++++++ 2 files changed, 313 insertions(+) create mode 100644 doc/board/allwinner/index.rst create mode 100644 doc/board/allwinner/sunxi.rst diff --git a/doc/board/allwinner/index.rst b/doc/board/allwinner/index.rst new file mode 100644 index 00000000000..7352ccd5c0a --- /dev/null +++ b/doc/board/allwinner/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Allwinner (sunxi) boards +======================== + +.. toctree:: + :maxdepth: 2 + + sunxi diff --git a/doc/board/allwinner/sunxi.rst b/doc/board/allwinner/sunxi.rst new file mode 100644 index 00000000000..693eb32e168 --- /dev/null +++ b/doc/board/allwinner/sunxi.rst @@ -0,0 +1,304 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. Copyright (C) 2021 Arm Ltd. + +Allwinner SoC based boards +========================== +For boards using an Allwinner ARM based SoC ("sunxi"), the U-Boot build +system generates a single integrated image file: ``u-boot-sunxi-with-spl.bin.`` +This file can be used on SD cards, eMMC devices, SPI flash and for the +USB-OTG based boot method (FEL). To build this file: + +* For 64-bit SoCs, build Trusted Firmware (TF-A, formerly known as ATF) first, + you will need its ``bl31.bin``. See below for more details. +* Optionally on 64-bit SoCs, build the crust management processor firmware. +* Build U-Boot:: + + $ export BL31=/path/to/bl31.bin # required for 64-bit SoCs + $ export SCP=/src/crust/build/scp/scp.bin # optional for some 64-bit SoCs + $ make <yourboardname>_defconfig + $ make -j5 -s +* Transfer to an uSD card (see below for more details):: + + $ dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=8k seek=1 +* Boot and enjoy! + +For more details, and alternative boot locations or installations, see below. + +Building Arm Trusted Firmware (TF-A) +------------------------------------ +Boards using a 64-bit Soc (A64, H5, H6, H616, R329) require the BL31 stage of +the `Arm Trusted Firmware-A`_ firmware. This provides the reference +implementation of secure software for Armv8-A, offering PSCI and SMCCC +services. Allwinner support is fully mainlined. To build bl31.bin:: + + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git + $ cd trusted-firmware-a + $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_a64 DEBUG=1 + $ export BL31=$(pwd)/build/sun50i_a64/debug/bl31.bin + +The target platform (``PLAT=``) for A64 and H5 SoCs is sun50i_a64, for the H6 +sun50i_h6, for the H616 sun50i_h616, and for the R329 sun50i_r329. Use:: + + $ find plat/allwinner -name platform.mk + +to find all supported platforms. `docs/plat/allwinner.rst`_ contains more +information and lists some build options. + +Building the Crust management processor firmware +------------------------------------------------ +For some SoCs and boards, the integrated OpenRISC management controller can +be used to provide power management services, foremost suspend to RAM. +There is a community supported Open Source implementation called `crust`_, +which runs on most SoCs featuring a management controller. + +This firmware part is optional, setting the SCP environment variable to +/dev/null avoids the warning message when building without one. + +To build crust's scp.bin, you need an OpenRISC (or1k) cross compiler, then:: + + $ git clone https://github.com/crust-firmware/crust.git + $ cd crust + $ make <yourboard>_defconfig + $ make CROSS_COMPILE=or1k-none-elf- scp + $ export SCP=$(pwd)/build/scp/scp.bin + +Find a list of supported board configurations in the `configs/`_ directory. + +Building the U-Boot image +------------------------- +Find the U-Boot defconfig file for your board first. Those files live in +the ``configs/`` directory; you can grep for the stub name of the devicetree +file, if you know that, or for the SoC name to find the right version:: + + $ git grep -l MACH_SUN8I_H3 configs + $ git grep -l sun50i-h6-orangepi-3 configs + +The `linux-sunxi`_ wiki also lists the name of the defconfig file in the +respective board page. Then use this defconfig file to create the .config +file, and build the image:: + + $ make <yourboard>_defconfig + $ make -j5 + +For 64-bit boards, this requires either the BL31 environment variable to be +set (as shown above in the TF-A build example), or it to be supplied on the +build command line:: + + $ make BL31=/src/tf-a.git/build/sun50i_h616/debug/bl31.bin -j5 -s + +The same applies to the (optional) SCP firmware. + +The file containing everything you need is called ``u-boot-sunxi-with-spl.bin``, +you will find it in the root folder of your U-Boot (build) tree. Except for +raw NAND flash devices this very same file can be used for any boot source. +It will contain the SPL image, fitted with the proper signature recognised by +the BROM, and the required checksum. Also it will contain at least U-Boot +proper, either wrapped in the legacy U-Boot image format, or in a FIT image. +The board's devicetree is also included, either appended to the U-Boot proper +image, or contained in the FIT image. If required by the SoC, this FIT file will +also include the other firmware images. + +Installing U-Boot +----------------- + +Installing on a (micro-) SD card +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +All Allwinner SoCs will try to find a boot image at sector 16 (8KB) of +an SD card, connected to the first MMC controller. To transfer the generated +image to an SD card, from any Linux device (including the board itself) with +an (micro-)SD card reader, type:: + + # dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1k seek=8 + +``/dev/sdx`` needs to be replaced with the block device name of the SD card +reader. On some machines this could be ``/dev/mmcblkX``. +Newer SoCs (starting from H3), also look at sector 256 (128KB) for the +signature (after having checked the 8KB location). Installing the firmware +there has the advantage of not overlapping with a GPT partition table. Simply +replace the "``seek=8``" above with "``seek=128``". + +You can also use an existing (mainline) U-Boot to write to the SD card. Load +the generated U-Boot image somewhere into DRAM (via ``ext4load``, ``fatload``, +or ``tftpboot``), then write to MMC device 0:: + + => fatload mmc 0:1 $kernel_addr_r u-boot-sunxi-with-spl.bin + => mmc dev 0 + => mmc write $kernel_addr_r 0x10 0x7f0 + +To use the alternative boot location on newer SoCs:: + + => mmc write $kernel_addr_r 0x100 0x700 + +Installing on eMMC (on-board flash memory) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Some boards have a soldered eMMC chip, some other boards have an eMMC socket +to receive an optional eMMC module. U-Boot can be installed to those chips, +to boot without an SD card inserted. The Boot-ROM can boot either from the +regular user data partition, or from one of the separate eMMC boot partitions. +U-Boot can be installed either from a running Linux instance on the device, +from a running (mainline) U-Boot, or via an adapter for the (removable) +eMMC module. + +Installing on an eMMC user data partition from Linux +```````````````````````````````````````````````````` +If you have a running Linux instance on the device, and have somehow copied +over the image file to that device, you can write the image directly into the +eMMC device from there. +Find the name of the block device file first, it is one of the +``/dev/mmcblk<X>`` devices. eMMC devices typically also list a +``/dev/mmcblk<X>boot0`` partition (see below), this helps you to tell it apart +from the SD card device. +To install onto the user data partition:: + + # dd if=u-boot-sunxi-with-spl.bin of=/dev/dev/mmcblkX bs=1k seek=8 + +Similar to SD cards, the BROM in newer SoCs (H3 and above) also checks +sector 256 of an eMMC, so you can use "``seek=128``" as well. + +Installing on an eMMC boot partition from Linux +``````````````````````````````````````````````` +In the following examples, ``/dev/mmcblkX`` needs to be replaced with the block +device name of the eMMC device. The eMMC device can be recognised by also +listing the boot partitions (``/dev/mmcblkXboot0``) in ``/proc/partitions``. + +To allow booting from one of the eMMC boot partitions, this one needs to be +enabled first. This only needs to be done once, as this setting is +persistent, even though the boot partition can be disabled or changed again +any time later:: + + # apt-get install mmc-utils + # mmc bootbus set single_hs x1 x4 /dev/mmcblkX + # mmc bootpart enable 1 1 /dev/mmcblkX + +The first "1" in the last command points to the boot partition number to be +used, typically devices offer two boot partitions. + +By default Linux disables write access to the boot partitions, to prevent +accidental overwrites. You need to disable the write protection (until the +next reboot), then can write the U-Boot image to the *first* sector of the +selected boot partition:: + + # echo 0 > /sys/block/mmcblkXboot0/force_ro + # dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblkXboot0 bs=1k + +Installing on an eMMC user data partition from U-Boot +````````````````````````````````````````````````````` +You can also write the generated image file to an SD card, boot the device +from there, and burn the very same image to the eMMC device from U-Boot. +The following commands copy the image from the SD card to the eMMC device:: + + => mmc dev 0 + => mmc read $kernel_addr_r 0x10 0x7f0 + => mmc dev 1 + => mmc write $kernel_addr_r 0x10 0x7f0 + +You can also copy an image from the 8K offset of an SD card to the 128K +offset of the eMMC (or any combination), just change the "``0x10 0x7f0``" above +to "``0x100 0x700``", respectively. Of course the image file can be loaded via +any other loading method, including ``fatload``, ``ext4load``, ``tftpboot``. + +Installing on an eMMC boot partition from U-Boot +```````````````````````````````````````````````` +The selected eMMC boot partition needs to be initially enabled first (same +as in Linux above), you can do this from U-Boot with:: + + => mmc dev 1 + => mmc bootbus 1 1 0 0 + => mmc partconf 1 1 1 1 + +The first "1" in both commands denotes the MMC device number. The second "1" +in the partconf command sets the required ``BOOT_ACK`` option, the last two "1"s +selects the active boot partition and the target for the next data access, +respectively. So for the next "``mmc write``" command to address one of the boot +partitions, the last number must either be "1" or "2", "0" would switch (back) +to the normal user data partition. + +Then load the ``u-boot-sunxi-with-spl.bin`` image file into DRAM, either by +reading directly from an SD card or eMMC user data partition, or from a +file system or TFTP (see above), and transfer it to the boot partition:: + + => tftpboot $kernel_addr_r u-boot-sunxi-with-spl.bin + => mmc write $kernel_addr_r 0 0x7f0 + +After that the device should boot from the selected boot partition, which takes +precedence over booting from the user data partition. + +Installing on SPI flash +^^^^^^^^^^^^^^^^^^^^^^^ +Some devices have a SPI NOR flash chip soldered on the board. If it is +connected to the SPI0 pins on PortC, the BROM can also boot from there. +Typically the SPI flash has the lowest boot priority, so SD card and eMMC +devices will be considered first. + +Installing on SPI flash from Linux +`````````````````````````````````` +If the devicetree enables and describes the SPI flash device, you can access +the SPI flash content from Linux, using the `MTD utils`_:: + + # apt-get install mtd-utils + # mtdinfo + # mtd_debug erase /dev/mtdX 0 0xf0000 + # mtd_debug write /dev/mtdX 0 0xf0000 u-boot-sunxi-with-spl.bin + +``/dev/mtdX`` needs to be replaced with the respective device name, as listed +in the output of ``mtdinfo``. + +Installing on SPI flash from U-Boot +``````````````````````````````````` +If SPI flash driver and command support (``CONFIG_CMD_SF``) is enabled in the +U-Boot configuration, the image file can be installed via U-Boot as well:: + + => tftpboot $kernel_addr_r u-boot-sunxi-with-spl.bin + => sf probe + => sf erase 0 +0xf0000 + => sf write $kernel_addr_r 0 $filesize + +Installing on SPI flash via USB in FEL mode +``````````````````````````````````````````` +If the device is in FEL mode (see below), the SPI flash can also be filled +with the sunxi-fel utility, via an USB(-OTG) cable from any USB host machine:: + + $ sunxi-fel -v -p spiflash-write 0 u-boot-sunxi-with-spl.bin + +Booting via the USB(-OTG) FEL mode +---------------------------------- +If none of the boot locations checked by the BROM contain a medium or valid +signature, the BROM will enter the so-called FEL mode, in which it will +listen to commands from a host on the SoC's USB-OTG interface. Those commands +allow to read from and write to arbitrary memory locations, also to start +execution at any address, which allows to bootstrap a board solely via an +USB cable. Some boards feature a "FEL" or "U-Boot" button, which forces +FEL mode despite a valid boot location being present. The same can be achieved +via a `magic binary`_ on an SD card, which allows to enter FEL mode on any +board. + +To use FEL booting, let the board enter FEL mode, via any of the mentioned +methods (no boot media, FEL button, SD card with FEL binary), then connect +a USB cable to the board's USB OTG port. Some boards (Pine64, TV boxes) don't +have a separate OTG port. In this case mostly one of the USB-A ports is +connected to USB0, and can be used via a non-standard USB-A to USB-A cable. + +Typically there is no on-board indication of FEL mode, other than a new USB +device appearing on the connected host computer. The USB vendor/device ID +is 1f3a:efe8. Mostly this will identify as "sunxi SoC OTG connector in +FEL/flashing mode", but older distributions might still report "Onda +(unverified) V972 tablet in flashing mode". + +The `sunxi_fel`_ tool implements the proprietary BROM protocol, and allows to +bootstrap U-Boot by just providing our venerable u-boot-sunxi-with-spl.bin:: + + $ sudo apt-get install sunxi-tools + $ sunxi-fel -v -p uboot u-boot-sunxi-with-spl.bin + +Additional binaries like a kernel, an initial ramdisk or a boot script, can +also be uploaded via FEL, check the Wiki's `FEL page`_ for more details. + +.. _`Arm Trusted Firmware-A`: https://www.trustedfirmware.org/projects/tf-a/ +.. _`docs/plat/allwinner.rst`: https://trustedfirmware-a.readthedocs.io/en/latest/plat/allwinner.html +.. _`crust`: https://github.com/crust-firmware/crust +.. _`configs/`: https://github.com/crust-firmware/crust/tree/master/configs +.. _`linux-sunxi`: https://linux-sunxi.org +.. _`MTD utils`: http://www.linux-mtd.infradead.org/ +.. _`magic binary`: https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/fel-sdboot.sunxi +.. _`sunxi_fel`: https://github.com/linux-sunxi/sunxi-tools +.. _`FEL page`: https://linux-sunxi.org/FEL/USBBoot -- 2.17.6

3 6

[PATCH 00/12] event: Add support for events/hooks
by Simon Glass 28 Dec '21

28 Dec '21

It is a common need in U-Boot to have one subsystem notify another when something happens. An example is reading a partition table when a new block device is set up. It is also common to add weak functions and 'hook' functions to modify how U-Boot works. See for example ft_board_setup() and the like. U-Boot would benefit from a generic mechanism to handle these cases, with the ability to hook into various 'events' in a subsystem-independent and transparent way. This series provides a way to create and dispatch events, with a way of registering a 'spy' which watches for events of different types. This allows 'hook' functions to be created in a generic way. It also includes a script to list the hooks in an image, which is a bit easier to debug than weak functions, as well as an 'event' command to do the same from within U-Boot. These 'static' events can be used to replace hooks like misc_init_f(), for example. Also included is basic support for 'dynamic' events, where a spy can be registered at runtime. The need for this is still being figured out. Enabling events uses a little over 200 bytes of extra code space, on 32-bit machines, a one-off cost. Simon Glass (12): Makefile: Keep symbols in u-boot-init with LTO sandbox: start: Sort the header files binman: Expand elf support a little event: Add basic support for events event: Add a simple test event: Set up the event system on start-up event: Add events for device probe/remove event: Convert misc_init_f() to use events event: Convert arch_cpu_init_dm() to use events event: Add a command event: Add a script to decode the event-spy list event: Add documentation MAINTAINERS | 10 ++ Makefile | 2 +- arch/Kconfig | 3 + arch/arm/Kconfig | 3 + arch/arm/include/asm/omap_common.h | 2 + arch/arm/mach-imx/imx8m/soc.c | 4 +- arch/arm/mach-imx/imx8ulp/soc.c | 4 +- arch/arm/mach-omap2/am33xx/board.c | 10 +- arch/arm/mach-omap2/hwinit-common.c | 5 +- arch/mips/Kconfig | 1 + arch/mips/mach-pic32/cpu.c | 4 +- arch/nios2/cpu/cpu.c | 4 +- arch/riscv/cpu/cpu.c | 5 +- arch/riscv/include/asm/system.h | 5 + arch/riscv/lib/spl.c | 3 +- arch/sandbox/cpu/start.c | 8 +- arch/x86/cpu/baytrail/cpu.c | 4 +- arch/x86/cpu/broadwell/cpu.c | 4 +- arch/x86/cpu/ivybridge/cpu.c | 4 +- arch/x86/cpu/quark/quark.c | 4 +- arch/x86/include/asm/fsp2/fsp_api.h | 8 ++ arch/x86/lib/fsp2/fsp_init.c | 4 +- arch/x86/lib/spl.c | 12 -- arch/x86/lib/tpl.c | 10 -- board/google/chromebook_coral/coral.c | 6 +- board/keymile/kmcent2/kmcent2.c | 5 +- cmd/Kconfig | 8 ++ cmd/Makefile | 1 + cmd/event.c | 27 ++++ common/Kconfig | 37 ++++- common/Makefile | 2 + common/board_f.c | 13 +- common/board_r.c | 1 + common/event.c | 196 ++++++++++++++++++++++++++ common/log.c | 1 + configs/chromebook_coral_defconfig | 1 + configs/galileo_defconfig | 1 + configs/kmcent2_defconfig | 2 +- configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 1 - configs/sandbox_spl_defconfig | 1 - configs/tools-only_defconfig | 1 - doc/develop/event.rst | 100 +++++++++++++ doc/develop/index.rst | 1 + doc/usage/event.rst | 49 +++++++ doc/usage/index.rst | 1 + drivers/core/Kconfig | 10 ++ drivers/core/device-remove.c | 8 ++ drivers/core/device.c | 9 ++ drivers/core/root.c | 5 + include/asm-generic/global_data.h | 13 ++ include/dm/device-internal.h | 10 ++ include/event.h | 182 ++++++++++++++++++++++++ include/event_internal.h | 35 +++++ include/init.h | 12 -- include/log.h | 2 + scripts/event_dump.py | 117 +++++++++++++++ test/common/Makefile | 1 + test/common/event.c | 85 +++++++++++ test/py/tests/test_event_dump.py | 19 +++ test/test-main.c | 4 + tools/binman/elf.py | 58 +++++++- 63 files changed, 1067 insertions(+), 83 deletions(-) create mode 100644 cmd/event.c create mode 100644 common/event.c create mode 100644 doc/develop/event.rst create mode 100644 doc/usage/event.rst create mode 100644 include/event.h create mode 100644 include/event_internal.h create mode 100755 scripts/event_dump.py create mode 100644 test/common/event.c create mode 100644 test/py/tests/test_event_dump.py -- 2.34.1.448.ga2b2bfdf31-goog

1 12

[PATCH 00/12] It is a common need in U-Boot to have one subsystem notify another
by Simon Glass 28 Dec '21

28 Dec '21

when something happens. An example is reading a partition table when a new block device is set up. It is also common to add weak functions and 'hook' functions to modify how U-Boot works. See for example ft_board_setup() and the like. U-Boot would benefit from a generic mechanism to handle these cases, with the ability to hook into various 'events' in a subsystem-independent and transparent way. This series provides a way to create and dispatch events, with a way of registering a 'spy' which watches for events of different types. This allows 'hook' functions to be created in a generic way. It also includes a script to list the hooks in an image, which is a bit easier to debug than weak functions, as well as an 'event' command to do the same from within U-Boot. These 'static' events can be used to replace hooks like misc_init_f(), for example. Also included is basic support for 'dynamic' events, where a spy can be registered at runtime. The need for this is still being figured out. Enabling events uses a little over 200 bytes of extra code space, on 32-bit machines, a one-off cost. Simon Glass (12): Makefile: Keep symbols in u-boot-init with LTO sandbox: start: Sort the header files binman: Expand elf support a little event: Add basic support for events event: Add a simple test event: Set up the event system on start-up event: Add events for device probe/remove event: Convert misc_init_f() to use events event: Convert arch_cpu_init_dm() to use events event: Add a command event: Add a script to decode the event-spy list event: Add documentation MAINTAINERS | 10 ++ Makefile | 2 +- arch/Kconfig | 3 + arch/arm/Kconfig | 3 + arch/arm/include/asm/omap_common.h | 2 + arch/arm/mach-imx/imx8m/soc.c | 4 +- arch/arm/mach-imx/imx8ulp/soc.c | 4 +- arch/arm/mach-omap2/am33xx/board.c | 10 +- arch/arm/mach-omap2/hwinit-common.c | 5 +- arch/mips/Kconfig | 1 + arch/mips/mach-pic32/cpu.c | 4 +- arch/nios2/cpu/cpu.c | 4 +- arch/riscv/cpu/cpu.c | 5 +- arch/riscv/include/asm/system.h | 5 + arch/riscv/lib/spl.c | 3 +- arch/sandbox/cpu/start.c | 8 +- arch/x86/cpu/baytrail/cpu.c | 4 +- arch/x86/cpu/broadwell/cpu.c | 4 +- arch/x86/cpu/ivybridge/cpu.c | 4 +- arch/x86/cpu/quark/quark.c | 4 +- arch/x86/include/asm/fsp2/fsp_api.h | 8 ++ arch/x86/lib/fsp2/fsp_init.c | 4 +- arch/x86/lib/spl.c | 12 -- arch/x86/lib/tpl.c | 10 -- board/google/chromebook_coral/coral.c | 6 +- board/keymile/kmcent2/kmcent2.c | 5 +- cmd/Kconfig | 8 ++ cmd/Makefile | 1 + cmd/event.c | 27 ++++ common/Kconfig | 37 ++++- common/Makefile | 2 + common/board_f.c | 13 +- common/board_r.c | 1 + common/event.c | 196 ++++++++++++++++++++++++++ common/log.c | 1 + configs/chromebook_coral_defconfig | 1 + configs/galileo_defconfig | 1 + configs/kmcent2_defconfig | 2 +- configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig | 1 - configs/sandbox_spl_defconfig | 1 - configs/tools-only_defconfig | 1 - doc/develop/event.rst | 100 +++++++++++++ doc/develop/index.rst | 1 + doc/usage/event.rst | 49 +++++++ doc/usage/index.rst | 1 + drivers/core/Kconfig | 10 ++ drivers/core/device-remove.c | 8 ++ drivers/core/device.c | 9 ++ drivers/core/root.c | 5 + include/asm-generic/global_data.h | 13 ++ include/dm/device-internal.h | 10 ++ include/event.h | 182 ++++++++++++++++++++++++ include/event_internal.h | 35 +++++ include/init.h | 12 -- include/log.h | 2 + scripts/event_dump.py | 117 +++++++++++++++ test/common/Makefile | 1 + test/common/event.c | 85 +++++++++++ test/py/tests/test_event_dump.py | 19 +++ test/test-main.c | 4 + tools/binman/elf.py | 58 +++++++- 63 files changed, 1067 insertions(+), 83 deletions(-) create mode 100644 cmd/event.c create mode 100644 common/event.c create mode 100644 doc/develop/event.rst create mode 100644 doc/usage/event.rst create mode 100644 include/event.h create mode 100644 include/event_internal.h create mode 100755 scripts/event_dump.py create mode 100644 test/common/event.c create mode 100644 test/py/tests/test_event_dump.py -- 2.34.1.448.ga2b2bfdf31-goog

1 0

Pull request: u-boot-spi/master
by Jagan Teki 27 Dec '21

27 Dec '21

Hi Tom, Please pull this PR. thanks, Jagan. The following changes since commit 4a14bfffd42f968ed9d72a780a8d44a9053c5b95: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-11-30 08:59:22 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-spi master for you to fetch changes up to d7b1d8259e62c781f2c87acfac08f3c0505030dd: mtd: spi-nor-ids: Add support for W25Q01JV (2021-12-16 12:58:47 +0530) ---------------------------------------------------------------- Marek Vasut (1): mtd: cqspi: Wait for transfer completion Michal Simek (1): mtd: spi: Remove SF_DUAL_FLASH symbol from Kconfig Ram Narayanan (1): mtd: spi-nor-ids: Add support for W25Q01JV drivers/mtd/spi/Kconfig | 6 ------ drivers/mtd/spi/spi-nor-ids.c | 5 +++++ drivers/spi/cadence_qspi_apb.c | 17 +++++++++++++++++ 3 files changed, 22 insertions(+), 6 deletions(-)

2 1