December 2020 - U-Boot

[PATCH] fs: squasfs: fix a possible NULL pointer dereference in sqfs_opendir()
by Richard Genoud 22 Dec '20

22 Dec '20

token_count may be != 0 and token_list not yet allocated when the out code is reached Reported-by: Coverity CID 313547 Fixes: ea1b1651c6a8 ("fs/squashfs: sqfs_opendir: simplify error handling") Signed-off-by: Richard Genoud <richard.genoud(a)posteo.net> --- fs/squashfs/sqfs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c index 608a2bb454c..c47046b76e5 100644 --- a/fs/squashfs/sqfs.c +++ b/fs/squashfs/sqfs.c @@ -949,8 +949,9 @@ int sqfs_opendir(const char *filename, struct fs_dir_stream **dirsp) *dirsp = (struct fs_dir_stream *)dirs; out: - for (j = 0; j < token_count; j++) - free(token_list[j]); + if (token_list) + for (j = 0; j < token_count; j++) + free(token_list[j]); free(token_list); free(pos_list); free(path);

2 11

[PATCH v2 00/14] qemu: arm64: Add support for uefi capsule update on qemu arm platform
by Sughosh Ganu 22 Dec '20

22 Dec '20

The capsule update feature is supported on a platform configuration booting in a non-secure mode, i.e with -machine virt,secure=off option set. This results in the platform booting u-boot directly without the presence of trusted firmware(tf-a). Steps that need to be followed for using this feature have been provided as part of the documentation. Support has also been added for enabling the capsule authentication feature. Capsule authentication, as defined by the uefi specification is very much on similar lines to the logic used for variable authentication. As a result, most of the signature verification code already in use for variable authentication has been used for capsule authentication. Storage of the public key certificate, needed for the signature verification process is in form of the efi signature list(esl) structure. This public key is stored on an overlay which is then merged with the platform's base fdt at runtime. The public key esl file can be embedded into the overlay dtb using the mkeficapsule utility that has been added as part of the capsule update support series by Takahiro Akashi. Steps needed for enabling capsule authentication have been provided as part of the documentation. This patch series needs to be applied on top of the capsule update support patch series from Takahiro Akashi on the next branch. Changes since V1: * Added support for embedding the public key cert in an overlay using the -O option * The earlier patch was adding a call to pci_init in board_init. Moved the virtio_init call to board_late_init * Change MTDPARTS_NOR[01] as config options instead of defining them in the qemu-arm.h config header. * Enable CONFIG_SYS_MTDPARTS_RUNTIME with CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT * Build set_dfu_alt_info and board_get_alt_info functions only if CONFIG_SET_DFU_ALT_INFO is defined * Enable CONFIG_SET_DFU_ALT_INFO with CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT * Detect the presence of the FMP Payload header at runtime instead of using a Kconfig option, as was suggested by Heinrich * Change the documentation to reflect the usage of overlays for embedding the public key certs at runtime * Fix the build for 'make htmldocs' Sughosh Ganu (14): mkeficapsule: Add support for embedding public key in a dtb qemu: arm: Initialise virtio in board_late_init crypto: Fix the logic to calculate hash with authattributes set qemu: arm64: Add support for dynamic mtdparts for the platform qemu: arm64: Set dfu_alt_info variable for the platform fsp: Move and rename fsp_types.h file efi_loader: Add logic to parse EDKII specific fmp payload header dfu_mtd: Add provision to unlock mtd device efi_loader: Make the pkcs7 header parsing function an extern efi_loader: Re-factor code to build the signature store from efi signature list efi: capsule: Add support for uefi capsule authentication efi_loader: Enable uefi capsule authentication efidebug: capsule: Add a command to update capsule on disk qemu: arm64: Add documentation for capsule update arch/x86/include/asm/fsp/fsp_support.h | 3 +- board/emulation/qemu-arm/Kconfig | 20 ++ board/emulation/qemu-arm/qemu-arm.c | 168 +++++++++++++ cmd/efidebug.c | 14 ++ configs/qemu_arm64_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 188 ++++++++++++++ drivers/dfu/dfu_mtd.c | 20 +- include/efi_api.h | 18 ++ include/efi_loader.h | 12 + .../fsp/fsp_types.h => include/signatures.h | 6 +- lib/crypto/pkcs7_verify.c | 37 ++- lib/efi_loader/Kconfig | 19 ++ lib/efi_loader/efi_capsule.c | 122 +++++++++ lib/efi_loader/efi_firmware.c | 77 +++++- lib/efi_loader/efi_signature.c | 192 +++++++++++---- lib/efi_loader/efi_variable.c | 93 +------ tools/Makefile | 1 + tools/mkeficapsule.c | 233 +++++++++++++++++- 18 files changed, 1060 insertions(+), 164 deletions(-) rename arch/x86/include/asm/fsp/fsp_types.h => include/signatures.h (95%) -- 2.17.1

2 22

[PATCH] sysboot: add zboot support to boot x86 image
by Kory Maincent 22 Dec '20

22 Dec '20

Signed-off-by: Kory Maincent <kory.maincent(a)bootlin.com> --- cmd/pxe_utils.c | 4 ++++ include/command.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/cmd/pxe_utils.c b/cmd/pxe_utils.c index 53af04d7dc..deaedcf347 100644 --- a/cmd/pxe_utils.c +++ b/cmd/pxe_utils.c @@ -548,6 +548,10 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label) /* Try booting a Image */ else do_bootz(cmdtp, 0, bootm_argc, bootm_argv); +#elif defined(CONFIG_CMD_ZBOOT) + /* Try booting an x86_64 Image */ + else + do_zboot(cmdtp, 0, bootm_argc, bootm_argv); #endif unmap_sysmem(buf); diff --git a/include/command.h b/include/command.h index d1063774ce..57fe65000b 100644 --- a/include/command.h +++ b/include/command.h @@ -133,6 +133,8 @@ extern int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); extern int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); +extern int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); + extern int common_diskboot(cmd_tbl_t *cmdtp, const char *intf, int argc, char *const argv[]); -- 2.17.1

2 1

[PATCH v2] fsp: Move and rename fsp_types.h file
by Sughosh Ganu 22 Dec '20

22 Dec '20

The fsp_types.h header file contains macros for building signatures of different widths. These signature macros are architecture agnostic, and can be used in all places which use signatures in a data structure. Move and rename the fsp_types.h under the common include header. Signed-off-by: Sughosh Ganu <sughosh.ganu(a)linaro.org> --- Changes since v1: Handled review comments from Simon Glass Build tested for cougarcanyon2 board which builds the relevant fsp code. arch/x86/include/asm/fsp/fsp_support.h | 3 ++- .../x86/include/asm/fsp/fsp_types.h => include/signatures.h | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) rename arch/x86/include/asm/fsp/fsp_types.h => include/signatures.h (95%) diff --git a/arch/x86/include/asm/fsp/fsp_support.h b/arch/x86/include/asm/fsp/fsp_support.h index 29e511415c..3cd3e4fcf5 100644 --- a/arch/x86/include/asm/fsp/fsp_support.h +++ b/arch/x86/include/asm/fsp/fsp_support.h @@ -7,11 +7,12 @@ #ifndef __FSP_SUPPORT_H__ #define __FSP_SUPPORT_H__ +#include <signatures.h> + #include <asm/fsp/fsp_bootmode.h> #include <asm/fsp/fsp_fv.h> #include <asm/fsp/fsp_hob.h> #include <asm/fsp/fsp_infoheader.h> -#include <asm/fsp/fsp_types.h> #include <asm/fsp_arch.h> #include <asm/fsp/fsp_azalia.h> diff --git a/arch/x86/include/asm/fsp/fsp_types.h b/include/signatures.h similarity index 95% rename from arch/x86/include/asm/fsp/fsp_types.h rename to include/signatures.h index 3d5b17ecf1..4042db1e00 100644 --- a/arch/x86/include/asm/fsp/fsp_types.h +++ b/include/signatures.h @@ -4,8 +4,8 @@ * Copyright (C) 2014, Bin Meng <bmeng.cn(a)gmail.com> */ -#ifndef __FSP_TYPES_H__ -#define __FSP_TYPES_H__ +#ifndef __SIGNATURES_H__ +#define __SIGNATURES_H__ /** * Returns a 16-bit signature built from 2 ASCII characters. @@ -59,4 +59,4 @@ #define SIGNATURE_64(A, B, C, D, E, F, G, H) \ (SIGNATURE_32(A, B, C, D) | ((u64)(SIGNATURE_32(E, F, G, H)) << 32)) -#endif +#endif /* __SIGNATURES_H__ */ -- 2.17.1

3 3

[PATCH] fsp: Move and rename fsp_types.h file
by Sughosh Ganu 22 Dec '20

22 Dec '20

The fsp_types.h header file contains macros for building signatures of different widths. These signature macros are architecture agnostic, and can be used in all places which use signatures in a data structure. Move and rename the fsp_types.h under the common include header. Signed-off-by: Sughosh Ganu <sughosh.ganu(a)linaro.org> --- Build tested for cougarcanyon2 board which builds the relevant fsp code. arch/x86/include/asm/fsp/fsp_support.h | 3 ++- .../asm/fsp/fsp_types.h => include/signature_types.h | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-) rename arch/x86/include/asm/fsp/fsp_types.h => include/signature_types.h (94%) diff --git a/arch/x86/include/asm/fsp/fsp_support.h b/arch/x86/include/asm/fsp/fsp_support.h index 29e511415c..7651a0dac0 100644 --- a/arch/x86/include/asm/fsp/fsp_support.h +++ b/arch/x86/include/asm/fsp/fsp_support.h @@ -11,10 +11,11 @@ #include <asm/fsp/fsp_fv.h> #include <asm/fsp/fsp_hob.h> #include <asm/fsp/fsp_infoheader.h> -#include <asm/fsp/fsp_types.h> #include <asm/fsp_arch.h> #include <asm/fsp/fsp_azalia.h> +#include <signature_types.h> + #define FSP_LOWMEM_BASE 0x100000UL #define FSP_HIGHMEM_BASE 0x100000000ULL #define UPD_TERMINATOR 0x55AA diff --git a/arch/x86/include/asm/fsp/fsp_types.h b/include/signature_types.h similarity index 94% rename from arch/x86/include/asm/fsp/fsp_types.h rename to include/signature_types.h index 3d5b17ecf1..9b8c0543f6 100644 --- a/arch/x86/include/asm/fsp/fsp_types.h +++ b/include/signature_types.h @@ -4,8 +4,8 @@ * Copyright (C) 2014, Bin Meng <bmeng.cn(a)gmail.com> */ -#ifndef __FSP_TYPES_H__ -#define __FSP_TYPES_H__ +#ifndef __SIGNATURE_TYPES_H__ +#define __SIGNATURE_TYPES_H__ /** * Returns a 16-bit signature built from 2 ASCII characters. @@ -59,4 +59,4 @@ #define SIGNATURE_64(A, B, C, D, E, F, G, H) \ (SIGNATURE_32(A, B, C, D) | ((u64)(SIGNATURE_32(E, F, G, H)) << 32)) -#endif +#endif /* __SIGNATURE_TYPES_H__ */ -- 2.17.1

3 3

[PATCH v1] doc: edison: Update information about xFSTK
by Andy Shevchenko 22 Dec '20

22 Dec '20

xFSTK sources got a new home under Edison Firmware Group on GitHub [1]. Update Intel Edison documentation accordingly. While here, fix couple of typos. [1]: https://github.com/edison-fw Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- doc/board/intel/edison.rst | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/doc/board/intel/edison.rst b/doc/board/intel/edison.rst index d658fac02c8f..711fb4984ed4 100644 --- a/doc/board/intel/edison.rst +++ b/doc/board/intel/edison.rst @@ -45,16 +45,27 @@ Updating U-Boot using xFSTK --------------------------- You can also update U-Boot using the xfstk-dldr-solo tool if you can build it. -One way to do that is to follow the `xFSTK`_ instructions. You may need to use -a virtual machine running Ubuntu Trusty. Once you have built it and installed -libboost-all-dev, you can copy xfstk-dldr-solo to /usr/local/bin and +One way to do that is to follow the `xFSTK`_ instructions. In short, after you +install all necessary dependencies and clone repository, it will look like this: + +.. code-block:: console + + cd xFSTK + export DISTRIBUTION_NAME=ubuntu20.04 + export BUILD_VERSION=1.8.5 + git checkout v$BUILD_VERSION + ... + +Once you have built it, you can copy xfstk-dldr-solo to /usr/local/bin and libboost_program_options.so.1.54.0 to /usr/lib/i386-linux-gnu/ and with luck -it will work. You might fine this `drive`_ helpful. +it will work. You might find this `drive`_ helpful. + +If it does, then you can download and unpack the Edison recovery image, +install dfu-util, reset your board and flash U-Boot like this: -If it does, then you can download and unpack the Edison reocovery image, -install dfu-util, reset your board and flash U-Boot like this:: +.. code-block:: console - $ xfstk-dldr-solo --gpflags 0x80000007 \ + xfstk-dldr-solo --gpflags 0x80000007 \ --osimage u-boot-edison.img \ --fwdnx recover/edison_dnx_fwr.bin \ --fwimage recover/edison_ifwi-dbg-00.bin \ @@ -64,7 +75,7 @@ This should show the following .. code-block:: none - XFSTK Downloader Solo 0.0.0 + XFSTK Downloader Solo 1.8.5 Copyright (c) 2015 Intel Corporation Build date and time: Aug 15 2020 15:07:13 @@ -75,13 +86,12 @@ This should show the following .......(lots of dots)........XFSTK-STATUS--Reconnecting to device - Attempt #1 .......(even more dots)...................... - You have about 10 seconds after resetting the board to type the above command. If you want to check if the board is ready, type: .. code-block:: none - lsusb |egrep "8087|8086" + lsusb | egrep "8087|8086" Bus 001 Device 004: ID 8086:e005 Intel Corp. If you see a device with the same ID as above, the board is waiting for your @@ -157,5 +167,5 @@ After about 5 seconds you should see some console output from the board: edison login: -.. _xFSTK: https://community.intel.com/t5/Intel-Makers/Building-xFSTK-on-Ubuntu-14-04-… +.. _xFSTK: https://github.com/edison-fw/xFSTK .. _drive: https://drive.google.com/drive/u/0/folders/1URPHrOk9-UBsh8hjv-7WwC0W6Fy61uAJ -- 2.29.2

2 2

imx8mp_evk: boot error "alloc space exhausted"
by ZHIZHIKIN Andrey 22 Dec '20

22 Dec '20

Hello Peng, I've tried to boot the i.MX8M Plus EVK with U-Boot 2020.10 and faced the error message during the boot process, which indicates that the allocation space in early malloc area is exhausted. Looking at the log, I was able to bisect it to the commit 28fff3fa1c ("imx: imx8mp_evk: fix boot issue"), where the CONFIG_SYS_MALLOC_F_LEN has been reduced from 0x10000 to 0x8000 and CONFIG_SPL_SYS_MALLOC_SIMPLE was enabled. Extract from the patch shows the following diff: -CONFIG_SYS_MALLOC_F_LEN=0x10000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 +CONFIG_SPL_SYS_MALLOC_SIMPLE=y If the CONFIG_SYS_MALLOC_F_LEN is returned to the original value - error message disappears, and I can observe that the total occupation of early malloc area (reported via bdinfo) contains following count: ----------------- u-boot=> bdinfo <snip> Early malloc usage: a648 / 10000 ----------------- As it can be seen, the value 0xa648 overflows the imposed limit of 0x8000, causing 2 allocations after ATF execution to fail. According to the Patchwork [1], this has been already reported by Fabio but there was no resolution provided to address this further. Neither the commit message in 28fff3fa1c provides any additional hint on why those config options were setup with those values. V1 of this patch series did not have any config options in it, and the changelog of v2 is also missing to advise why those options were added to the series. Can you please explain why CONFIG_SYS_MALLOC_F_LEN and CONFIG_SPL_SYS_MALLOC_SIMPLE config options were added with that patch, and if it is safe to have them reverted to the original values? Another Thanks a lot! Regards, Andrey Link: [1]: http://patchwork.ozlabs.org/project/uboot/patch/20200512093901.14831-2-peng…

3 4

Re: FW: [PATCH 0/6] video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME
by Patrick DELAUNAY 21 Dec '20

21 Dec '20

Hi Soeren, > From: Soeren Moch <smoch(a)web.de> Sent: dimanche 6 décembre 2020 20:59 > On 03.12.20 10:15, Patrick Delaunay wrote: > >> I propose this serie to remove the vidconsole work-around, activated >> with the 2 options VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME and >> cleanup the associated code in console.c (under #ifdef >> CONFIG_VIDCONSOLE_AS_LCD) This options are now obsolete and they was >> planned to be removed around the end of 2020. I propose this patchset >> for v2021.04 even if I don't test this serie on real boards. >> > I really would like to keep this code for now. > I propose to remove these options because they are indicated obsolete in the config description in drivers/video/Kconfig (I see it during code review): "This option will be removed around the end of 2020" But I have no issue to kept it. > On the tbs2910 board this workaround was introduced in the last u-boot > release (v2020.10), so there was almost no time for end users to > notice the warning and to update there environment. Not every end user > installs every new u-boot release, so we really should give more time > for this change. > I agree that for your project, with migration to DM_VIDEO it is a really short notice. commit 645d39aea367064868dcdd30c411806f4403b67b board: tbs2910: Fix video output with existing environments => only integrated in v2020.10-rc2, sorry to miss it > This workaround is self-contained, small, easy to maintain, and > strictly opt-in. So this workaround hurts nobody, but removing this > will let users alone without any HDMI output. So on this board > (without included serial console port), this will result in unhappy > users, especially since without any console output there is no chance > to get any idea what is going wrong. > Initially, I proposed this patch to cleanup the console.c code with 2 other series: 1) http://patchwork.ozlabs.org/project/uboot/list/?series=218309 "console: remove #ifdef CONFIG when it is possible" 2) http://patchwork.ozlabs.org/project/uboot/list/?series=218089 "console: cosmetics: remove #if 0" And I just want just to remove the remaining "#ifdef CONFIG_...." in console.c But I agree that I need to change my proposal to remove this workaround code (it is only use to help the DM VIDEO migration for existing board) and change the release target. I propose to : - remove patch 1/6 of the serie for your board - no more remove the options in 6/6 but add warning in Makefile when the option is activated and change target in config desciption ifeq ($(CONFIG_VIDCONSOLE_AS_LCD),y) @echo >&2 "===================== WARNING ======================" @echo >&2 "This board does use CONFIG_VIDCONSOLE_AS_LCD workaround." @echo >&2 "Please update the existing user defined environments before " @echo >&2 "v2022.01 release." @echo >&2 "Failure to update by the deadline may result in video console" @echo >&2 "issue when this woarkaround will be removed." @echo >&2 "====================================================" endif => open point: which acceptable target to remove this feature ? v2022.01 ? Anyway, if the the maintainers (video or console) think this code should be kept, I can also drop this serie. Thanks. Patrick

4 4

[PATCH v3 00/12] Raspberry Pi 400/Compute Module 4 support
by Nicolas Saenz Julienne 21 Dec '20

21 Dec '20

This series could be split into at least two or even three parts, but I kept it as is for now as it contains all the changes needed in order to have u-boot working on the new Raspberry Pi 400 and Raspberry Pi Compute Module 4. There are core changes, specifically with regard to cpu to bus address space translations. So far we had relied on hard-coded values but RPi needs per device translations as it has at least three distinct bus address spaces with different offsets. So it's a good opportunity to implement bus translations the right way by parsing DT's dma-ranges. Here's a more concrete example of what we're dealing with: - On a RPi4, SoC version BCM2711C0 with 8GB of memory [0x0 0x200000000] [0x200000000 0x400000000] [0xc0000000 0x100000000] [0x00000000 0x100000000] phys/cpu address PCIe bus address Legacy peripheral emmc2 address space space address space space - On a RPi4, SoC version BCM2711C0 with 4GB of memory [0x0 0x100000000] [0x100000000 0x200000000] [0xc0000000 0x100000000] [0x00000000 0x100000000] phys/cpu address PCIe bus address Legacy peripheral emmc2 address space space address space space - On a RPi4, SoC version BCM2711B0 with 8GB of memory (bus can only access the lower 3GB of memory because of a SoC routing bug) [0x0 0x200000000] [0x00000000 0xC0000000] [0xc0000000 0x100000000] phys/cpu address PCIe bus address Legacy peripheral space space address space --- Changes since v2: - Test builds not broken with buildman - Add tests to all DM changes - Make code conditional with config option - Correct OF refcount - Add config changes - Address small changes as per reviews Changes since v1: - Fix some issues in 'dm: Introduce xxx_get_dma_range()' - Fix some typos in commit messages - Change DTB file name for RPi400 - Address Matthias' comments Nicolas Saenz Julienne (12): rpi: Add identifier for the new RPi400 rpi: Add identifier for the new CM4 pci: pcie-brcmstb: Fix inbound window configurations dm: Introduce xxx_get_dma_range() dm: test: Add test case for dev_get_dma_ranges() dm: Introduce DMA constraints into the core device model dm: test: Add test case for dev->dma_offset dm: Introduce dev_phys_to_bus()/dev_bus_to_phys() dm: test: Add test case for dev_phys_to_bus()/dev_bus_to_phys() xhci: translate virtual addresses into the bus's address space mmc: Introduce mmc_phys_to_bus()/mmc_bus_to_phys() configs: rpi4: Enable DM_DMA across all RPi4 configurations arch/sandbox/dts/test.dts | 21 ++++++++ board/raspberrypi/rpi/rpi.c | 10 ++++ common/fdt_support.c | 73 ++++++++++++++++++++++++++++ configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + drivers/core/Kconfig | 10 ++++ drivers/core/device.c | 35 ++++++++++++++ drivers/core/of_addr.c | 78 ++++++++++++++++++++++++++++++ drivers/core/ofnode.c | 9 ++++ drivers/core/read.c | 6 +++ drivers/mmc/sdhci.c | 7 +-- drivers/pci/pcie_brcmstb.c | 12 ++--- drivers/usb/host/xhci-mem.c | 45 +++++++++-------- drivers/usb/host/xhci-ring.c | 11 +++-- drivers/usb/host/xhci.c | 4 +- include/dm/device.h | 3 ++ include/dm/of_addr.h | 17 +++++++ include/dm/ofnode.h | 16 ++++++ include/dm/read.h | 21 ++++++++ include/fdt_support.h | 14 ++++++ include/mmc.h | 10 ++++ include/phys2bus.h | 16 ++++++ include/usb/xhci.h | 22 ++++++++- test/dm/Makefile | 2 + test/dm/core.c | 30 ++++++++++++ test/dm/phys2bus.c | 36 ++++++++++++++ test/dm/read.c | 49 +++++++++++++++++++ 32 files changed, 526 insertions(+), 38 deletions(-) create mode 100644 test/dm/phys2bus.c create mode 100644 test/dm/read.c -- 2.29.2

2 30

[ANN] U-Boot v2021.01-rc4 released
by Tom Rini 21 Dec '20

21 Dec '20

Hey all, Alright, I've gotten well off schedule. I think the take away for me really is that it's better to mid-week and get back on schedule than try and change the Mondays I release on. So here's -rc4, and I hope this is very close to what the final release will be, oon January 11th. I will do another, final, -rc on January 4th. The only big change here is that I have dropped Travis-CI support as they are reducing the amount of monthly build time FOSS projects get, and that's just not going to work for U-Boot. I do appreciate all of the cycles we've gotten over the years. In terms of a changelog, git log --merges v2021.01-rc3..v2021.01-rc4 contains what I've pulled but as always, better PR messages and tags will provide better results here. Thanks all! -- Tom

1 0