February 2021 - U-Boot

How to have a menu in u-boot ? (newbie)
by Thomas Carrié 08 Feb '21

08 Feb '21

Hello, Is there an equivalent of the Grub menu in u-boot? Context: I want to create two entries in a menu to boot either Ubuntu-Mate or CoreElec on ODROID-N2 hardware. Thank you for your help Thomas

2 1

Please pull u-boot-x86
by Bin Meng 07 Feb '21

07 Feb '21

Hi Tom, This PR includes the following x86 changes for v2021.04: Various enhancements to smbios for more flexibility to allow more flexibility as to where the data for SMBIOS tables comes from: - introduces some standard sysinfo options as a source, e.g. to read strapping pins to determine the board revision - allows the U-Boot version number to be included - allows the version number to be provided programmatically, e.g. to support the build system adding information after U-Boot is built Azure results: PASS https://dev.azure.com/bmeng/GitHub/_build/results?buildId=321&view=results The following changes since commit 8308a28af821d6498186b3dd7463db9874cd2daf: Merge tag 'ti-v2021.04-rc2' of https://gitlab.denx.de/u-boot/custodians/u-boot-ti (2021-02-05 09:39:31 -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 07c9e683a484bc8e5e22976feb54b1c1a460068d: smbios: Allow a few values to come from sysinfo (2021-02-06 19:20:36 +0800) ---------------------------------------------------------------- Simon Glass (12): README: Add doumentation for version information Makefile: Provide numeric versions smbios: Move smbios_write_type to the C file smbios: Use char consistently for the eos member smbios: Set BIOS release version smbios: Use a struct to keep track of context smbios: Drop the eos parameter smbios: Track the end of the string table smbios: Add more options for the BIOS version string sysinfo: Move #ifdef so that operations are always defined x86: coral: Add sysinfo ops smbios: Allow a few values to come from sysinfo Makefile | 4 +++ board/google/chromebook_coral/coral.c | 5 +++ doc/develop/index.rst | 1 + doc/develop/version.rst | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++ include/asm-generic/global_data.h | 6 ++++ include/smbios.h | 26 +++++++------- include/sysinfo.h | 13 ++++++- lib/smbios.c | 248 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------- 8 files changed, 328 insertions(+), 76 deletions(-) create mode 100644 doc/develop/version.rst Regards, Bin

2 1

[PATCHv3 0/4] SCP03 control
by Jorge Ramirez-Ortiz 07 Feb '21

07 Feb '21

The following patchset allows U-Boot to enable the Secure Channel Protocol 03 implemented in a TEE and executed between the processor and the secure element. It also allows U-Boot to request the rotation of the encryption keys defined as part of the protocol; when this is request is made, the TEE will derive new keys program them in the secure element so all communications with the secure element remains secured. Changes v3: common: SCP03 control (enable and provision of keys) Simon Glass: document Kconfig include common.h return -ENXIO on TA not available cmd: SCP03: enable and provision command Simon Glass: requested .rst docs printf on error use U_BOOT_CMD_WITH_SUBCMDS drivers: tee: sandbox: SCP03 control emulator Simon Glass: expand Kconfig information Changes v2: remove obsolete patch (wasnt part of the set) Jorge Ramirez-Ortiz (4): common: SCP03 control (enable and provision of keys) cmd: SCP03: enable and provision command drivers: tee: sandbox: SCP03 control emulator doc: describe the scp03 command cmd/Kconfig | 8 +++++ cmd/Makefile | 3 ++ cmd/scp03.c | 48 +++++++++++++++++++++++++++++ common/Kconfig | 8 +++++ common/Makefile | 1 + common/scp03.c | 53 +++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + doc/usage/scp03.rst | 33 ++++++++++++++++++++ drivers/tee/optee/Kconfig | 6 ++++ drivers/tee/sandbox.c | 60 ++++++++++++++++++++++++++++++++++-- include/scp03.h | 21 +++++++++++++ include/tee/optee_ta_scp03.h | 21 +++++++++++++ 12 files changed, 261 insertions(+), 2 deletions(-) create mode 100644 cmd/scp03.c create mode 100644 common/scp03.c create mode 100644 doc/usage/scp03.rst create mode 100644 include/scp03.h create mode 100644 include/tee/optee_ta_scp03.h -- 2.30.0

1 4

u-boot idbloader.img fails to initialise LPDDR3 on nanopi m4 v1
by Christopher Obbard 07 Feb '21

07 Feb '21

hi! Both 2020.04, 2021.01 and latest u-boot HEAD fails to setup nano pi m4 V1 LPDDR3. these are compiled with latest ATF HEAD. Any pointers on where to debug ? For what it's worth; I can boot on nanopi m4 V2 board with patch[1], so I am sure it's a DDR thing. U-Boot TPL 2020.04 (Feb 06 2021 - 09:28:53) sdram_init: LPDDR3 - 933MHz failed! rk3399_dmc_init DRAM init failed -22 Missing DTB U-Boot TPL 2021.01 (Feb 05 2021 - 12:45:32) sdram_init: LPDDR3 - 933MHz failed! rk3399_dmc_init DRAM init failed -22 Missing DTB thanks! Chris [1]: https://patchwork.ozlabs.org/project/uboot/patch/20201018052548.29195-1-lib…

1 1

arm64: rk3399: Add support NanoPi R4s
by alex tian 07 Feb '21

07 Feb '21

>From dda4c03b91c1af76c60ef4835d68861b3cae0cc9 Mon Sep 17 00:00:00 2001 From: Xiaobo Tian <xiaobo(a)btc-btc.net> Date: Mon, 8 Feb 2021 00:16:54 +0800 Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card support, including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0 port. port.It also has two GPIO headers which allows further peripherals to be used. The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1]. [1] https://github.com/torvalds/linux/commit/e7a095908227fb3ccc86d001d9e13c9ae2… Signed-off-by: xiaobo <xiaobo(a)btc-btc.net> --- arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 17 +++ arch/arm/dts/rk3399-nanopi-r4s.dts | 129 +++++++++++++++++++++ board/rockchip/evb_rk3399/MAINTAINERS | 6 + configs/nanopi-r4s-rk3399_defconfig | 62 ++++++++++ 5 files changed, 215 insertions(+) create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts create mode 100644 configs/nanopi-r4s-rk3399_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 858b79ac97..528dfe069e 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \ rk3288-evb.dtb \ rk3288-firefly.dtb \ rk3288-miqi.dtb \ + rk3399-nanopi-r4s.dtb \ rk3288-phycore-rdk.dtb \ rk3288-popmetal.dtb \ rk3288-rock2-square.dtb \ diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi new file mode 100644 index 0000000000..284ded4360 --- /dev/null +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * RK3399-based FriendlyElec boards device tree source + * + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd + * + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd. + * (http://www.friendlyarm.com) + * + * Copyright (c) 2018 Collabora Ltd. + * Copyright (c) 2019 Arm Ltd. + * Copyright (C) 2020 Xiaobo <xiaobo(a)btc-btc.net> + */ + +#include "rk3399-nanopi4-u-boot.dtsi" +#include "rk3399-sdram-lpddr4-100.dtsi" +#include "rk3399-sdram-ddr3-1866.dtsi" diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts b/arch/arm/dts/rk3399-nanopi-r4s.dts new file mode 100644 index 0000000000..ffb4012089 --- /dev/null +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts @@ -0,0 +1,129 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd + * + * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd. + * (http://www.friendlyarm.com) + * + * Copyright (c) 2018 Collabora Ltd. + * Copyright (c) 2019 Arm Ltd. + * Copyright (C) 2020 Xiaobo <xiaobo(a)btc-btc.net> + */ + +/dts-v1/; +#include "rk3399-nanopi4.dtsi" + +/ { + model = "FriendlyElec NanoPi R4S"; + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399"; + + vdd_5v: vdd-5v { + compatible = "regulator-fixed"; + regulator-name = "vdd_5v"; + regulator-always-on; + regulator-boot-on; + }; + + fan: pwm-fan { + compatible = "pwm-fan"; + cooling-levels = <0 12 18 255>; + #cooling-cells = <2>; + fan-supply = <&vdd_5v>; + pwms = <&pwm1 0 50000 0>; + }; +}; + +&cpu_thermal { + trips { + cpu_warm: cpu_warm { + temperature = <55000>; + hysteresis = <2000>; + type = "active"; + }; + + cpu_hot: cpu_hot { + temperature = <65000>; + hysteresis = <2000>; + type = "active"; + }; + }; + + cooling-maps { + map2 { + trip = <&cpu_warm>; + cooling-device = <&fan THERMAL_NO_LIMIT 1>; + }; + + map3 { + trip = <&cpu_hot>; + cooling-device = <&fan 2 THERMAL_NO_LIMIT>; + }; + }; +}; + +&emmc_phy { + status = "disabled"; +}; + +&fusb0 { + status = "disabled"; +}; + +&leds { + lan_led: led-1 { + gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>; + label = "nanopi-r4s:green:lan"; + }; + + wan_led: led-2 { + gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>; + label = "nanopi-r4s:green:wan"; + }; +}; + +&leds_gpio { + rockchip,pins = + <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>, + <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>, + <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>; +}; + +&pcie0 { + max-link-speed = <1>; + num-lanes = <1>; + vpcie3v3-supply = <&vcc3v3_sys>; + + pcie@0 { + reg = <0x00000000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + }; +}; + +&sdhci { + status = "disabled"; +}; + +&sdio0 { + status = "disabled"; +}; + +&sdmmc { + host-index-min = <1>; +}; + +&u2phy0_host { + phy-supply = <&vdd_5v>; +}; + +&u2phy1_host { + status = "disabled"; +}; + +&usbdrd_dwc3_0 { + dr_mode = "host"; +}; + +&vcc3v3_sys { + vin-supply = <&vcc5v0_sys>; +}; diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS index 4c889e06a6..8e26844cf0 100644 --- a/board/rockchip/evb_rk3399/MAINTAINERS +++ b/board/rockchip/evb_rk3399/MAINTAINERS @@ -55,6 +55,12 @@ S: Maintained F: configs/nanopi-neo4-rk3399_defconfig F: arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi +NANOPI-R4S +M: Xiaobo Tian <xiaobo(a)btc-btc.net> +S: Maintained +F: configs/nanopi-r4s-rk3399_defconfig +F: arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi + ORANGEPI-RK3399 M: Jagan Teki <jagan(a)amarulasolutions.com> S: Maintained diff --git a/configs/nanopi-r4s-rk3399_defconfig b/configs/nanopi-r4s-rk3399_defconfig new file mode 100644 index 0000000000..0a3c28b012 --- /dev/null +++ b/configs/nanopi-r4s-rk3399_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x00200000 +CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_ROCKCHIP_RK3399=y +CONFIG_TARGET_EVB_RK3399=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_DEBUG_UART_BASE=0xFF1A0000 +CONFIG_DEBUG_UART_CLOCK=24000000 +CONFIG_DEBUG_UART=y +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-r4s.dtb" +CONFIG_DISPLAY_BOARDINFO_LATE=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000 +CONFIG_TPL=y +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_TIME=y +CONFIG_SPL_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-r4s" +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_ROCKCHIP=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_GMAC_ROCKCHIP=y +CONFIG_PMIC_RK8XX=y +CONFIG_REGULATOR_PWM=y +CONFIG_REGULATOR_RK8XX=y +CONFIG_PWM_ROCKCHIP=y +CONFIG_RAM_RK3399_LPDDR4=y +CONFIG_BAUDRATE=1500000 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYSRESET=y +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_ASIX=y +CONFIG_USB_ETHER_ASIX88179=y +CONFIG_USB_ETHER_MCS7830=y +CONFIG_USB_ETHER_RTL8152=y +CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_DM_VIDEO=y +CONFIG_DISPLAY=y +CONFIG_VIDEO_ROCKCHIP=y +CONFIG_DISPLAY_ROCKCHIP_HDMI=y +CONFIG_SPL_TINY_MEMSET=y +CONFIG_ERRNO_STR=y -- 2.30.0

1 0

[PATCHv2 1/3] common: SCP03 control (enable and provision of keys)
by Jorge Ramirez-Ortiz 07 Feb '21

07 Feb '21

This Trusted Application allows enabling and provisioning SCP03 keys on TEE controlled secure element (ie, NXP SE050) For information on SCP03, check the Global Platform HomePage[1] [1] globalplatform.org Signed-off-by: Jorge Ramirez-Ortiz <jorge(a)foundries.io> --- common/Kconfig | 8 ++++++ common/Makefile | 1 + common/scp03.c | 52 ++++++++++++++++++++++++++++++++++++ include/scp03.h | 19 +++++++++++++ include/tee/optee_ta_scp03.h | 21 +++++++++++++++ 5 files changed, 101 insertions(+) create mode 100644 common/scp03.c create mode 100644 include/scp03.h create mode 100644 include/tee/optee_ta_scp03.h diff --git a/common/Kconfig b/common/Kconfig index 2bb3798f80..482f123534 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -588,6 +588,14 @@ config AVB_BUF_SIZE endif # AVB_VERIFY +config SCP03 + bool "Build SCP03 - Secure Channel Protocol O3 - controls" + depends on OPTEE || SANDBOX + depends on TEE + help + This option allows U-Boot to enable and or provision SCP03 on an OPTEE + controlled Secured Element. + config SPL_HASH bool # "Support hashing API (SHA1, SHA256, etc.)" help diff --git a/common/Makefile b/common/Makefile index daeea67cf2..215b8b26fd 100644 --- a/common/Makefile +++ b/common/Makefile @@ -137,3 +137,4 @@ obj-$(CONFIG_CMD_LOADB) += xyzModem.o obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += xyzModem.o obj-$(CONFIG_AVB_VERIFY) += avb_verify.o +obj-$(CONFIG_SCP03) += scp03.o diff --git a/common/scp03.c b/common/scp03.c new file mode 100644 index 0000000000..c655283387 --- /dev/null +++ b/common/scp03.c @@ -0,0 +1,52 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2021, Foundries.IO + * + */ + +#include <scp03.h> +#include <tee.h> +#include <tee/optee_ta_scp03.h> + +static int scp03_enable(bool provision) +{ + const struct tee_optee_ta_uuid uuid = PTA_SCP03_UUID; + struct tee_open_session_arg session; + struct tee_invoke_arg invoke; + struct tee_param param; + struct udevice *tee = NULL; + + tee = tee_find_device(tee, NULL, NULL, NULL); + if (!tee) + return -ENODEV; + + memset(&session, 0, sizeof(session)); + tee_optee_ta_uuid_to_octets(session.uuid, &uuid); + if (tee_open_session(tee, &session, 0, NULL)) + return -ENODEV; + + memset(&param, 0, sizeof(param)); + param.attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT; + param.u.value.a = provision; + + memset(&invoke, 0, sizeof(invoke)); + invoke.func = PTA_CMD_ENABLE_SCP03; + invoke.session = session.session; + + if (tee_invoke_func(tee, &invoke, 1, &param)) + return -EIO; + + tee_close_session(tee, session.session); + + return 0; +} + +int tee_enable_scp03(void) +{ + return scp03_enable(false); +} + +int tee_provision_scp03(void) +{ + return scp03_enable(true); +} diff --git a/include/scp03.h b/include/scp03.h new file mode 100644 index 0000000000..034796ada3 --- /dev/null +++ b/include/scp03.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * (C) Copyright 2021, Foundries.IO + * + */ + +#ifndef _SCP03_H +#define _SCP03_H + +/* + * Requests to OPTEE to enable or provision the Secure Channel Protocol on its + * Secure Element + * + * If key provisioning is requested, OPTEE shall generate new SCP03 keys and + * write them to the Secure Element. + */ +int tee_enable_scp03(void); +int tee_provision_scp03(void); +#endif /* _SCP03_H */ diff --git a/include/tee/optee_ta_scp03.h b/include/tee/optee_ta_scp03.h new file mode 100644 index 0000000000..13f9956d98 --- /dev/null +++ b/include/tee/optee_ta_scp03.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: BSD-3-Clause */ +/* + * (C) Copyright 2021, Foundries.IO + * + */ +#ifndef __TA_SCP03_H +#define __TA_SCP03_H + +#define PTA_SCP03_UUID { 0xbe0e5821, 0xe718, 0x4f77, \ + { 0xab, 0x3e, 0x8e, 0x6c, 0x73, 0xa9, 0xc7, 0x35 } } + +/* + * Enable Secure Channel Protocol functionality (SCP03) on the Secure Element. + * Setting the operation value to something different than NULL will trigger + * the SCP03 provisioning request. + * + * in params[0].a = operation + */ +#define PTA_CMD_ENABLE_SCP03 0 + +#endif /*__TA_SCP03_H*/ -- 2.30.0

3 7

Help for boot an iMX7 with u-boot-imx from scratch
by Juan Manuel Alvarez 07 Feb '21

07 Feb '21

Hello, I've got a board with an iMX7D and I want to make an image runable by myself from "scratch". Using machine for iMX7D Sabre board to do this, I've modified without succes some files of u-boot-imx: arch/arm/dts/imx7d-xxxx.dts files board/freescale/mx7dsabresd/xxxxx files include/configs/mx7dsabresd.h My "custom" board has the debug uart, ddr ram, and other gpio/port/devices changed respect iMX7D Sabre board. I still haven't got an u-boot-imx image that works. When I power on the board I get nothing on the debug uart (no trace nor rom code). Anyone knows what files I should touch to make the correct changes? Thank you!!!

1 0

[PATCH v5 00/10] fastboot: Add better support for specifying partitions
by Sean Anderson 07 Feb '21

07 Feb '21

This series adds support for flashing eMMC boot partitions, and for flashing whole partitions. Specifically, it does this by using the existing U-Boot naming scheme to specify partitions, and not by adding new KConfig options. I have added tests for partition naming, but not for the whole flash process (though that could be a future project). I have tested this on one board, but I have *not* tested the mt85-specific KConfigs. Hopefully this series can be a way to phase out those options. Changes in v5: - Don't build fastboot test unless we have both FASTBOOT_FLASH *and* EFI_PARTITION. This fixes some sandbox builds where only EFI_PARTITION was configured. - Fix conflict between anchors in docs - Fix incorrect heading name Changes in v4: - xxx_auto_alloc_size -> xxx_auto - Fix missing closing brace - Expand documentation, making it more man-page-like Changes in v3: - Rebase onto dfu/master Changes in v2: - Update documentation for part_get_info_by_dev_and_name - Move partition documentation under doc/usage Sean Anderson (10): mmc: sandbox: Add support for writing test: dm: Add test for fastboot mmc partition naming part: Give several functions more useful return values part: Support getting whole disk from part_get_info_by_dev_and_name_or_num part: Support string block devices in part_get_info_by_dev_and_name fastboot: Remove mmcpart argument from raw_part_get_info_by_name fastboot: Move part_get_info_by_name_or_alias after raw_part_get_info_by_name fastboot: Allow u-boot-style partitions doc: Rename k210 partitions anchor doc: Document partition specifications cmd/ab_select.c | 3 +- configs/sandbox64_defconfig | 2 + configs/sandbox_defconfig | 2 + disk/part.c | 90 +++++++++------- doc/android/fastboot.rst | 4 + doc/board/sipeed/maix.rst | 4 +- doc/usage/index.rst | 1 + doc/usage/partitions.rst | 80 ++++++++++++++ drivers/fastboot/fb_mmc.c | 210 +++++++++++++++++++++--------------- drivers/mmc/sandbox_mmc.c | 43 ++++++-- include/part.h | 6 +- test/dm/Makefile | 3 + test/dm/fastboot.c | 95 ++++++++++++++++ test/dm/mmc.c | 19 +++- 14 files changed, 419 insertions(+), 143 deletions(-) create mode 100644 doc/usage/partitions.rst create mode 100644 test/dm/fastboot.c -- 2.25.1

2 12

[RFC PATCH 00/13] spi: dw: Add support for XIP mode
by Sean Anderson 07 Feb '21

07 Feb '21

This adds support for memory-mapped ("DIRMAP") reads (called XIP by the datasheet). In theory, these have better performance than regular reads. In practice, the CPU is already fast enough to max out the performance of this peripheral. The real end-goal is to be able to boot a XIP kernel. This SoC has just barely enough SRAM to boot Linux, and using a XIP kernel would decrease the memory pressure to something tolerable. It would also probably absolutely *tank* the performance, since not only is SPI flash ~8x slower than regular memory, there is no cache to mitigate that latency. So it remains to be seen whether this is worth it at all. This series is RFC because it currently reads all 1s on one board I have. On the other board I have, it reads and writes fine. I will try and investigate this, but I expect any changes to occur in "spi: dw: Add support for DIRMAP". Sean Anderson (13): linux err: Synchronize with Linux 5.10 spi-mem: Add dirmap API from Linux mtd: spi-nor: use spi-mem dirmap API core: ofnode: Fix inconsistent returns of *_read_u32_array mux: Inline mux functions when CONFIG_MUX is disabled mux: Define a stub for mux_get_by_index if CONFIG_MUX is disabled mux: mmio: Only complain about idle-states if it is malformed spi: dw: Define XIP registers spi: dw: Add XIP and XIP_CONCURRENT caps spi: dw: Use a mux to access registers spi: dw: Add support for DIRMAP riscv: k210: Increase SPI3 bus clock to CPU speed riscv: k210: Add bindings for SPI XIP arch/riscv/dts/k210.dtsi | 25 ++- drivers/core/ofnode.c | 15 +- drivers/mtd/spi/sf_probe.c | 79 ++++++++ drivers/mtd/spi/spi-nor-core.c | 45 +++-- drivers/mux/mmio.c | 5 +- drivers/spi/Kconfig | 10 + drivers/spi/designware_spi.c | 337 +++++++++++++++++++++++++++++++-- drivers/spi/spi-mem.c | 270 ++++++++++++++++++++++++++ include/linux/err.h | 21 +- include/linux/mtd/spi-nor.h | 6 + include/mux.h | 25 ++- include/spi-mem.h | 99 ++++++++++ 12 files changed, 889 insertions(+), 48 deletions(-) -- 2.29.2

3 20

[PATCH 0/4] mkimage: Add a 'keyfile' argument for image signing
by Alexandru Gagniuc 07 Feb '21

07 Feb '21

This series is a continuation of the following series * [PATCH v5 0/6] Add support for ECDSA image signing (with test) There were some requests in the previous series to be more consistent between RSA and ECDSA paths, particularly in the area of handling the 'keydir' argument. This series adds a 'keyfile' argument to be used in lieu of the antiquated 'keydir'. Using 'keyfile' allows signing images that do not contain a "key-name-hint" property. Other issues, such as automatically adding the 'signature' node were discussed. Such features are beyond the scope of this series. I am going to halt any further work on mkimage because of time constraints. I hope the corrections in this series are sufficient to finally allow users to sign their images with ECDSA. Alexandru Gagniuc (4): doc: signature.txt: Document the keydir and keyfile arguments mkimage: Add a 'keyfile' argument for image signing lib/rsa: Use the 'keyfile' argument from mkimage lib/ecdsa: Use the 'keydir' argument from mkimage if appropriate doc/uImage.FIT/signature.txt | 13 +++++++++ include/image.h | 8 ++++-- lib/ecdsa/ecdsa-libcrypto.c | 10 ++++++- lib/rsa/rsa-sign.c | 34 +++++++++++++++++------ tools/fit_image.c | 3 +- tools/image-host.c | 54 ++++++++++++++++++++---------------- tools/imagetool.h | 1 + tools/mkimage.c | 6 +++- 8 files changed, 91 insertions(+), 38 deletions(-) -- 2.26.2

2 8