July 2021 - U-Boot

Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0
by Alex G. 29 Jul '21

29 Jul '21

Hi Artem, I'm re-adding the u-boot mailing list to the CC field, as I see your email contains no sensitive information. On 7/28/21 2:30 PM, Artem Panfilov wrote: > We have broken CI builds on your bare-metal CentOS 7 servers with latest > master. I think it is good reason to have a support. Our corporate > clients have CentOS 7 too. I thought we solved problems associated with bare builds on ancient OSes by using containerized builds. There's is CI infrastructure based on this on source.denx.de that uses docker. As things change, and we eventually move to GNU TLS, a lot more things might break for old build hosts. I believe it's worth looking at containerized builds. Given that a solution exists for your problem, I think the argument for this patch quite weak. > There is no nice way to handle openssl difference. You could check other > commits related to openssl compatibility. They all looks ugly. > Another solution is to disable CONFIG_TOOLS_LIBCRYPTO by default that > broke our builds. Do you need cryptographic features in mkimage? If not just disable TOOLS_LIBCRYPTO in your builds. Alex > Best regards, > Artem > > ср, 28 июл. 2021 г., 22:16 Alex G. <mr.nuke.me(a)gmail.com > <mailto:mr.nuke.me@gmail.com>>: > > > > On 7/28/21 1:10 PM, Artem Panfilov wrote: > > Fix LibreSSL compilation for versions before v2.7.0. > > > > Fix following compilation issue when CONFIG_TOOLS_LIBCRYPTO is > enabled: > > tools/lib/ecdsa/ecdsa-libcrypto.o: In function `prepare_ctx': > > ecdsa-libcrypto.c:(.text+0x94): undefined reference to > > `OPENSSL_init_ssl' > > ecdsa-libcrypto.c:(.text+0x148): undefined reference to > > `EC_GROUP_order_bits' > > tools/lib/ecdsa/ecdsa-libcrypto.o: In function > > `ecdsa_check_signature.isra.0': > > ecdsa-libcrypto.c:(.text+0x32c): undefined reference to > `ECDSA_SIG_set0' > > tools/lib/ecdsa/ecdsa-libcrypto.o: In function `ecdsa_sign': > > ecdsa-libcrypto.c:(.text+0x42c): undefined reference to > `ECDSA_SIG_get0' > > ecdsa-libcrypto.c:(.text+0x443): undefined reference to > `BN_bn2binpad' > > ecdsa-libcrypto.c:(.text+0x455): undefined reference to > `BN_bn2binpad' > > tools/lib/ecdsa/ecdsa-libcrypto.o: In function > `ecdsa_add_verify_data': > > ecdsa-libcrypto.c:(.text+0x5fa): undefined reference to > > `EC_GROUP_order_bits' > > ecdsa-libcrypto.c:(.text+0x642): undefined reference to > > `EC_POINT_get_affine_coordinates' > > > > Signed-off-by: Artem Panfilov <panfilov.artyom(a)gmail.com > <mailto:panfilov.artyom@gmail.com>> > > --- > > lib/ecdsa/ecdsa-libcrypto.c | 80 > ++++++++++++++++++++++++++++++++++++- > > 1 file changed, 79 insertions(+), 1 deletion(-) > > > > diff --git a/lib/ecdsa/ecdsa-libcrypto.c > b/lib/ecdsa/ecdsa-libcrypto.c > > index 1757a14562..50aa093acd 100644 > > --- a/lib/ecdsa/ecdsa-libcrypto.c > > +++ b/lib/ecdsa/ecdsa-libcrypto.c > > @@ -24,6 +24,70 @@ > > #include <openssl/ec.h> > > #include <openssl/bn.h> > > > > +#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ > > + (defined(LIBRESSL_VERSION_NUMBER) && > LIBRESSL_VERSION_NUMBER < 0x02070000fL) > > > Is there a reasonable use case for supporting an external library that > is more than three years old at this point? > > Otherwise NAK, as such #ifdefs don't really help with readability. I > think Simon will agree here. > > There's also the issue of deciding what version we have at compile > time, > which ignores the dynamic linking nature of .so libs. This leads into > soname versioning territory. Let's not go there. > > Alex > > > +#include <openssl/err.h> > > + > > +static int EC_GROUP_order_bits(const EC_GROUP *group) > > +{ > > + int ret = 0; > > + BIGNUM *order; > > + > > + if (!group) > > + return ret; > > + > > + order = BN_new(); > > + > > + if (!order) { > > + ERR_clear_error(); > > + return ret; > > + } > > + > > + if (!EC_GROUP_get_order(group, order, NULL)) { > > + ERR_clear_error(); > > + BN_free(order); > > + return ret; > > + } > > + > > + ret = BN_num_bits(order); > > + BN_free(order); > > + return ret; > > +} > > + > > +static void ECDSA_SIG_get0(const ECDSA_SIG *sig, const BIGNUM > **pr, const BIGNUM **ps) > > +{ > > + if (pr != NULL) > > + *pr = sig->r; > > + if (ps != NULL) > > + *ps = sig->s; > > +} > > + > > +static int ECDSA_SIG_set0(ECDSA_SIG *sig, BIGNUM *r, BIGNUM *s) > > +{ > > + if (r == NULL || s == NULL) > > + return 0; > > + BN_clear_free(sig->r); > > + BN_clear_free(sig->s); > > + sig->r = r; > > + sig->s = s; > > + return 1; > > +} > > + > > +int BN_bn2binpad(const BIGNUM *a, unsigned char *to, int tolen) > > +{ > > + int n = BN_num_bytes(a); > > + > > + if (n < 0 || n > tolen) > > + return -1; > > + > > + memset(to, 0, tolen - n); > > + if (BN_bn2bin(a, to + tolen - n) < 0) > > + return -1; > > + > > + return tolen; > > +}tures in mkimage? If not just disable TOOLS_LIBCRYPTO in your builds. > > +#endif > > + > > /* Image signing context for openssl-libcrypto */ > > struct signer { > > EVP_PKEY *evp_key; /* Pointer to EVP_PKEY object */ > > @@ -34,9 +98,18 @@ struct signer { > > > > static int alloc_ctx(struct signer *ctx, const struct > image_sign_info *info) > > { > > + int ret = 0; > > + > > memset(ctx, 0, sizeof(*ctx)); > > > > - if (!OPENSSL_init_ssl(0, NULL)) { > > +#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ > > +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < > 0x02070000fL) > > + ret = SSL_library_init(); > > +#else > > + ret = OPENSSL_init_ssl(0, NULL); > > +#endif > > + > > + if (!ret) { > > fprintf(stderr, "Failure to init SSL library\n"); > > return -1; > > } > > @@ -285,7 +358,12 @@ static int do_add(struct signer *ctx, void > *fdt, const char *key_node_name) > > x = BN_new(); > > y = BN_new(); > > point = EC_KEY_get0_public_key(ctx->ecdsa_key); > > +#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ > > +(defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < > 0x02070000fL) > > + EC_POINT_get_affine_coordinates_GFp(group, point, x, y, NULL); > > +#else > > EC_POINT_get_affine_coordinates(group, point, x, y, NULL); > > +#endif > > > > ret = fdt_setprop_string(fdt, key_node, "ecdsa,curve", > curve_name); > > if (ret < 0) > > >

3 9

[PATCH 1/2] spi: ich: Limit slave->max_read_size
by Bin Meng 29 Jul '21

29 Jul '21

Since commit 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()") (in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller in software sequencer mode. ICH controller can only transfer a small number of bytes at once. Before commit 43c145b8b3ee, the logic happens to make sure data.nbytes is limited to slave->max_write_size but after commit 43c145b8b3ee data.nbytes is no longer limited because slave->max_read_size is not initialized with a valid number. Fixes: 43c145b8b3ee ("spi: ich: Correct max-size bug in ich_spi_adjust_size()") Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- drivers/spi/ich.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c index 3d49c22a9d..08d54e86f4 100644 --- a/drivers/spi/ich.c +++ b/drivers/spi/ich.c @@ -918,12 +918,14 @@ static int ich_spi_child_pre_probe(struct udevice *dev) struct spi_slave *slave = dev_get_parent_priv(dev); /* - * Yes this controller can only write a small number of bytes at + * Yes this controller can only transfer a small number of bytes at * once! The limit is typically 64 bytes. For hardware sequencing a * a loop is used to get around this. */ - if (!plat->hwseq) + if (!plat->hwseq) { + slave->max_read_size = priv->databytes; slave->max_write_size = priv->databytes; + } /* * ICH 7 SPI controller only supports array read command * and byte program command for SST flash -- 2.25.1

2 5

qemu-kvm doesn't work with qemu-x86_64_defconfig
by Matwey V. Kornilov 29 Jul '21

29 Jul '21

Hello, I am trying to build master for qemu-x86_64_defconfig. When I try to boot u-boot.rom as the following everything works fine: > qemu-system-x86_64 -nographic -bios u-boot.rom U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300) Trying to boot from SPI Jumping to 64-bit U-Boot: Note many features are missing U-Boot 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300) CPU: QEMU Virtual CPU version 2.5+ DRAM: 128 MiB Loading Environment from nowhere... OK Incorrect expansion ROM header signature 4daa Model: QEMU x86 (I440FX) Net: e1000: 52:54:00:12:34:56 eth0: e1000#0 Hit any key to stop autoboot: 0 When I try to enable KVM as the following, the boot process hangs: > qemu-system-x86_64 -enable-kvm -cpu host -nographic -bios u-boot.rom U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300) Trying to boot from SPI Jumping to 64-bit U-Boot: Note many features are missing What have I missed? Maybe KVM is just not supported?

2 2

[PATCH 0/6] VIM3: misc cleanups to prepare android support
by Mattijs Korpershoek 29 Jul '21

29 Jul '21

The Khadas VIM3 and VIM3L boards are well supported in the Android Open Source project via the yukawa[1] platform. Their U-Boot version, despite being public [2] is not in mainline. These series a couple of cleanups to prepare to add mainline U-Boot support for vim3 / vim3l so that we can boot Android. [1] https://source.android.com/setup/build/devices#vim3_and_vim3l_boards [2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ Mattijs Korpershoek (6): configs: sei610: fix typo in header comment configs: meson64_android: fix bad indent in EXTRA_ENV_SETTINGS configs: meson64_android: use CONFIG_FASTBOOT_USB_DEV configs: meson64_android: use boot part label instead of index configs: meson64_android: use logo part label instead of index configs: meson64_android: don't set console bootargs include/configs/meson64_android.h | 30 +++++++++++++++++------------- include/configs/sei610.h | 2 +- 2 files changed, 18 insertions(+), 14 deletions(-) -- 2.30.2

2 13

[RFC PATCH] mtd: spi-nor-core: Handle SPI_RX_SLOW in spi_nor_adjust_hwcaps()
by Bin Meng 29 Jul '21

29 Jul '21

When CONFIG_SPI_FLASH_SMART_HWCAPS is on, SPI_RX_SLOW flag of the SPI controller is not honored. This adds the missing logic there. With this patch, SPI flash read works again with ICH SPI controller on Intel Crown Bay board. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- The quirky stuff of ICH SPI controller is that it only supports normal read (opcode 3) but not fast read (opcode 11), so that's why SPI_RX_SLOW was introduced before. At present the ICH SPI driver does not implement the supports_op() hook. I can add a check against opcode 11 there, however I see a comment in spi_nor_check_op() saying that SPI controller implementation should not check the opcode. /* * First test with 4 address bytes. The opcode itself might be a 3B * addressing opcode but we don't care, because SPI controller * implementation should not check the opcode, but just the sequence. */ drivers/mtd/spi/spi-nor-core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 99e2f16349..e9b46c39b5 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -2855,6 +2855,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor, const struct spi_nor_flash_parameter *params, u32 *hwcaps) { + struct spi_slave *spi = nor->spi; unsigned int cap; /* @@ -2879,6 +2880,10 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor, if (!(*hwcaps & BIT(cap))) continue; + if ((spi->mode & SPI_RX_SLOW) && + (BIT(cap) == SNOR_HWCAPS_READ_FAST)) + *hwcaps &= ~BIT(cap); + rdidx = spi_nor_hwcaps_read2cmd(BIT(cap)); if (rdidx >= 0 && spi_nor_check_readop(nor, &params->reads[rdidx])) -- 2.25.1

2 2

[PATCH] board: ti: k2g: Program PadConfig_202 before locking RSTMUX8
by Suman Anna 29 Jul '21

29 Jul '21

The PADCONFIG_202 register (0x02621328) is affected by the locking of the RSTMUX8 register (0x02620328), and so cannot be configured in kernel. This has been confirmed as a hardware bug and affects all K2G SoCs. Setup the pinmux for this pin before locking the RSTMUX8 register to allow the ICSS1 PRU1 Ethernet PHY port to work properly. The workaround was added only for the K2G-ICE board to configure the pins needed for the PRUSS Ethernet usecase. Signed-off-by: Suman Anna <s-anna(a)ti.com> --- board/ti/ks2_evm/mux-k2g.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h index fa6c92cbdf1e..f24e62850b8b 100644 --- a/board/ti/ks2_evm/mux-k2g.h +++ b/board/ti/ks2_evm/mux-k2g.h @@ -368,6 +368,9 @@ struct pin_cfg k2g_ice_evm_pin_cfg[] = { { 98, BUFFER_CLASS_B | PIN_PDIS | MODE(0) }, /* MDIO_DATA */ { 99, BUFFER_CLASS_B | PIN_PDIS | MODE(0) }, /* MDIO_CLK */ + /* ICSS1 Padconf Workaround */ + { 202, MODE(1) | PIN_PDIS }, /* PR1_PRU1_GPO1.PR1_PRU1_GPI1 (PR1_MII1_RXD1) */ + { MAX_PIN_N, } }; -- 2.32.0

2 1

[PATCH] arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-mode
by Suman Anna 29 Jul '21

29 Jul '21

The default U-Boot environment variables and design are all set up to have the MCU R5FSS cluster to be in Split-mode. This is the setting in v2021.01 U-Boot and the dt nodes are synched with the kernel binding property names in commit 468ec2f3ef8f ("remoteproc: k3_r5: Sync to upstreamed kernel DT property names") merged in v2021.04-rc2. The mode for the cluster got switched back to LockStep mode by mistake in commit e49787634312 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot") also in v2021.04-rc2. This throws the following warning messages when early-booting the cores using default env variables, k3_r5f_rproc r5f@41400000: Invalid op: Trying to start secondary core 2 in lockstep mode Load Remote Processor 1 with data@addr=0x82000000 65268 bytes: Failed! Fix this by switching back the cluster to the expected Split-mode. Make this mode change in the u-boot specific dtsi file to avoid such sync overrides in the future until the kernel dts is also switched to Split-mode by default. Fixes: e49787634312 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot") Signed-off-by: Suman Anna <s-anna(a)ti.com> --- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi index df850a2edb6e..0c1305df7e45 100644 --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi @@ -76,3 +76,7 @@ &tx_pru2_1 { remoteproc-name = "tx_pru2_1"; }; + +&mcu_r5fss0 { + ti,cluster-mode = <0>; +}; -- 2.32.0

2 1

[PATCH 0/5] Cleanup MAIN R5F boot from R5 SPL
by Suman Anna 29 Jul '21

29 Jul '21

Hi Lokesh, The following series cleans up the code related to booting of Main R5FSS0 Core0 from R5 SPL, and moves it to A72 U-Boot on J721E SoCs. This is no longer supported after the R5 SPL re-architecture that splits the System Firmware functionality onto two separate processors. This functionality has been merged post v2021.07 tag towards v2021.10-rc1. The Main R5FSS0 Core0 is already being booted on A72 U-Boot on J7200 SoCs, the other SoC family that follows this split system firmware architecture. Following is the patch summary: - Patch 1 skips the booting of Main R5FSS in R5 SPL and moves it to be supported on A72 U-Boot. - Patches 2 and 3 cleanup the start_non_linux_remote_cores() code - Patch 4 removes the Main R5F nodes from R5 SPL dtb - Patch 5 disables the K3 R5F remoteproc driver to be built in R5 SPL (tiboot3.bin size reduces by about 5K). regards Suman Suman Anna (5): arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-Boot arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPL arm: mach-k3: Cleanup common start_non_linux_remote_cores() arm: dts: k3-j721e-r5: Remove MAIN R5FSS0 cluster from SPL configs: j721e_evm_r5: Disable K3 R5F remoteproc .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 14 -------- .../arm/dts/k3-j721e-r5-common-proc-board.dts | 2 -- arch/arm/mach-k3/common.c | 5 --- arch/arm/mach-k3/common.h | 1 - arch/arm/mach-k3/j721e_init.c | 36 ------------------- configs/j721e_evm_r5_defconfig | 1 - include/configs/j721e_evm.h | 3 +- 7 files changed, 1 insertion(+), 61 deletions(-) -- 2.32.0

2 7

[PATCH v5 00/20] TI/Cadence: Add Sierra/Torrent SERDES driver
by Kishon Vijay Abraham I 29 Jul '21

29 Jul '21

Patch series adds Sierra and Torrent SERDES driver for the SERDES used in TI's K3 platforms. This SERDES is used by USB3, PCIe and Ethernet. This series is mostly an adaptation of drivers added in upstream Linux kernel. Changes from v4: 1) Dropped `[PATCH v4 01/21] drivers: reset: Add devm_to_reset() to return dummy "struct reset_ctl"` and will be worked independently of this series. This was mainly introduced for handling optional reset which is not mandatory for both Sierra and Torrent. 2) Fixed sectionauthor name for j721e_evm.rst Changes from v3: 1) Dropped "drivers: reset: Handle gracefully NULL pointers" and added "drivers: reset: Add devm_to_reset() to return dummy "struct reset_ctl" 2) Moved documentation from board/ti/j721e/README to doc/board/ti/j721e_evm.rst 3) Adapted Sierra and Torrent driver to 1). Changes from v2: 1) Re-worked "Handle gracefully NULL pointers" to fix Simons comments 2) Ported the part that allows creating clocks without explicit sub-nodes in DT from the upstream linux kernel. Changes from v1: 1) Fixed string comparison strncmp() to remove "==" 2) Added a test for node name comparison to ignore unit address in test/dm 3) Added better commit message in "drivers: reset: Handle gracefully NULL pointers" Alan Douglas (1): phy: cadence: Add driver for Sierra PHY Aswath Govindraju (7): dt-bindings: phy: Add definitions for additional phy types phy: cadence: Add driver for Torrent SERDES board: ti: j721e: Add support for probing and configuring Torrent serdes on J7200 arm: dts: k3-j7200-main: Add DT node for torrent serdes arm: dts: k3-j7200-common-proc-board: Enable SERDES DT arm: dts: k3-j7200-common-proc-board-u-boot: Add u-boot tags for torrent serdes configs: j7200_evm_a72_defconfig: Add config for torrent serdes and common clock framework Jean-Jacques Hiblot (2): phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC configs: j721e_evm_a72_defconfig: Enable the drivers required for the USB3 support Kishon Vijay Abraham I (10): dm: core: Add helper to compare node names dm: test: Add test case to check node name ignoring unit address dt-bindings: phy: Add defines for AM64 SERDES Wrapper dt-bindings: phy: cadence-torrent: Add defines for refclk driver dt-bindings: ti-serdes-mux: Add defines for AM64 SoC ARM: dts: k3-j721e: Add support for USB3 in USB0 instance env: ti: j721e-evm: Add env variable to power on & reset QSGMII PHY in J7200 EVM configs: j7200_evm_a72: Add CONFIG_PREBOOT to configure ethernet PHY doc: board: Move j721e document to doc/board/ti/ directory doc: board: j721e_evm: Add documentation for firmware loading .../k3-j7200-common-proc-board-u-boot.dtsi | 12 + arch/arm/dts/k3-j7200-common-proc-board.dts | 23 + arch/arm/dts/k3-j7200-main.dtsi | 63 + .../k3-j721e-common-proc-board-u-boot.dtsi | 19 +- board/ti/j721e/README | 277 -- board/ti/j721e/evm.c | 34 +- configs/j7200_evm_a72_defconfig | 8 + configs/j721e_evm_a72_defconfig | 6 + doc/board/index.rst | 1 + doc/board/ti/j721e_evm.rst | 331 +++ drivers/core/ofnode.c | 13 + drivers/phy/Kconfig | 3 + drivers/phy/Makefile | 2 + drivers/phy/cadence/Kconfig | 11 + drivers/phy/cadence/Makefile | 2 + drivers/phy/cadence/phy-cadence-sierra.c | 751 +++++ drivers/phy/cadence/phy-cadence-torrent.c | 2463 +++++++++++++++++ drivers/phy/ti/Kconfig | 9 + drivers/phy/ti/Makefile | 1 + drivers/phy/ti/phy-j721e-wiz.c | 1156 ++++++++ include/configs/j721e_evm.h | 16 +- include/dm/ofnode.h | 10 + include/dt-bindings/mux/ti-serdes.h | 5 + include/dt-bindings/phy/phy-cadence.h | 20 + include/dt-bindings/phy/phy-ti.h | 21 + include/dt-bindings/phy/phy.h | 1 + test/dm/core.c | 14 + 27 files changed, 4992 insertions(+), 280 deletions(-) delete mode 100644 board/ti/j721e/README create mode 100644 doc/board/ti/j721e_evm.rst create mode 100644 drivers/phy/cadence/Kconfig create mode 100644 drivers/phy/cadence/Makefile create mode 100644 drivers/phy/cadence/phy-cadence-sierra.c create mode 100644 drivers/phy/cadence/phy-cadence-torrent.c create mode 100644 drivers/phy/ti/Kconfig create mode 100644 drivers/phy/ti/Makefile create mode 100644 drivers/phy/ti/phy-j721e-wiz.c create mode 100644 include/dt-bindings/phy/phy-cadence.h create mode 100644 include/dt-bindings/phy/phy-ti.h -- 2.17.1

3 22

[PATCH v2 0/6] AM64: Add support for higher speed modes and boot mode in eMMC
by Aswath Govindraju 29 Jul '21

29 Jul '21

The following series of patches add support for, - HS200/HS400 speed modes - eMMC boot mode - gpt and FDT library overlay This series of patches, - dependent on https://patchwork.ozlabs.org/project/uboot/list/?series=237442 - applies on top of, https://patchwork.ozlabs.org/project/uboot/list/?series=255259 changes since v1: - rebased the series on top of latest mainline master Aswath Govindraju (4): arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to spl_mmc_boot_mode() arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias index 1 for main_sdhci1 node configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in eMMC and FAT write. configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT library overlay Kishon Vijay Abraham I (2): configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400 configs: am64x_evm_*_defconfig: Enable configs to support eMMC boot arch/arm/dts/k3-am642-sk-u-boot.dtsi | 5 +++++ arch/arm/mach-k3/am642_init.c | 2 +- configs/am64x_evm_a53_defconfig | 18 +++++++++++++++--- configs/am64x_evm_r5_defconfig | 7 +++++++ include/configs/am64x_evm.h | 6 ------ 5 files changed, 28 insertions(+), 10 deletions(-) -- 2.17.1

2 7