June 2021 - U-Boot

EFI from usb HDD
by Michal Simek 19 Aug '21

19 Aug '21

Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) On zcu104 I see one more error message "PE image measurement failed" But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x00000800 0x001007fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x0000000000000000 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal

4 18

[PATCH] arm: at91: gardena-smart-gateway-at91sam: Adjust to production values
by Reto Schneider 18 Aug '21

18 Aug '21

From: Reto Schneider <reto.schneider(a)husqvarnagroup.com> This commit updates the default config with the values that will be used soon on the Atmel / Microchip AT91SAM9G25 based GARDENA smart gateway. Signed-off-by: Reto Schneider <reto.schneider(a)husqvarnagroup.com> --- This patch applies to current u-boot-atmel/next configs/gardena-smart-gateway-at91sam_defconfig | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/configs/gardena-smart-gateway-at91sam_defconfig b/configs/gardena-smart-gateway-at91sam_defconfig index 40fe0f150e..c626cd699a 100644 --- a/configs/gardena-smart-gateway-at91sam_defconfig +++ b/configs/gardena-smart-gateway-at91sam_defconfig @@ -8,6 +8,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_NR_DRAM_BANKS=1 +CONFIG_SYS_MEMTEST_START=0x0 CONFIG_ENV_SIZE=0x10000 CONFIG_DM_GPIO=y CONFIG_SPL_TEXT_BASE=0x300000 @@ -22,6 +23,8 @@ CONFIG_DEBUG_UART=y CONFIG_FIT=y CONFIG_NAND_BOOT=y CONFIG_BOOTDELAY=0 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_STOP_STR="x" CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6M(kernel)ro,-(rootfs) rootfstype=ubifs ubi.mtd=6 root=ubi0:rootfs rw" CONFIG_SYS_CONSOLE_IS_IN_ENV=y @@ -32,20 +35,26 @@ CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_NAND_DRIVERS=y CONFIG_SPL_NAND_BASE=y CONFIG_HUSH_PARSER=y +CONFIG_CMD_LICENSE=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_MEMTEST=y +CONFIG_SYS_ALT_MEMTEST=y CONFIG_CMD_DM=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_CMD_MTD=y CONFIG_CMD_NAND=y CONFIG_CMD_WDT=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_CMD_PING=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y +CONFIG_CMD_GETTIME=y +CONFIG_CMD_UUID=y CONFIG_CMD_FAT=y CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y CONFIG_MTDIDS_DEFAULT="nand0=atmel_nand" CONFIG_MTDPARTS_DEFAULT="atmel_nand:1536k(uboot),10752k(unused),-(ubi)" CONFIG_CMD_UBI=y @@ -58,6 +67,8 @@ CONFIG_ENV_UBI_PART="ubi" CONFIG_ENV_UBI_VOLUME="uboot_env0" CONFIG_ENV_UBI_VOLUME_REDUND="uboot_env1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y +CONFIG_VERSION_VARIABLE=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SPL_DM=y @@ -71,6 +82,7 @@ CONFIG_LED_GPIO=y CONFIG_MTD=y CONFIG_NAND_ATMEL=y CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER=y +CONFIG_MTD_UBI_FASTMAP=y CONFIG_DM_ETH=y CONFIG_MACB=y CONFIG_PINCTRL=y @@ -84,3 +96,4 @@ CONFIG_ATMEL_PIT_TIMER=y CONFIG_WDT=y CONFIG_WDT_AT91=y # CONFIG_UBIFS_SILENCE_MSG is not set +CONFIG_LZMA=y -- 2.30.2

3 2

[PATCH v5 0/5] Enable ECDSA FIT verification for stm32mp
by Alexandru Gagniuc 16 Aug '21

16 Aug '21

This series is based on the following: "[PATCH 00/18] image: Reduce #ifdef abuse in image code" This rebase is awesome because we don't need to change #defines in common code or rely on hidden #ifdefs. Q: Will there be a software-only implementation of ECDSA ? A: That is the goal, so that we can have more extensive testing with the sandbox. I don not have the bandwidth to implement it. There has been an initial poer of software ecdsa here: https://github.com/timr11/u-boot/tree/ecdsa-vrf-1 Q: Can more code be shared with the RSA verification path? A: Probably yes. Mostly having to do with parsing the "/signature" node and "key-name-hint"s in the u-boot FDT. Although there isn't any copypasted RSA code, or code with substantial similarity. Changes since v4: - Use U_BOOT_CRYPTO_ALGO() to add ECDSA to .u_boot_list - No need to #define IMAGE_ENABLE_VERIFY_ECDSA - Use ut_asserteq(x, -ENODEV) instead of ut_assert(x == -ENODEV) Changes since v3: - Remove unused ecdsa_check_key() function Changes since v2: - Spell out "elliptic curve" in Kconfig (Although RSA isn't spelled out) Changes since v1: - Add test to make sure the UCLASS is enabled - Fix check against wrong sig_len in ecdsa_romapi.c - s/U_BOOT_DEVICE/U_BOOT_DRVINFO/ - Use "if(!ret)" instead of "if (ret == 0)" - Use uclass_first_device_err() instead of uclass_first_device() - Make sure #includes are correctly alphabetized Alexandru Gagniuc (5): dm: crypto: Define UCLASS API for ECDSA signature verification lib: ecdsa: Implement UCLASS_ECDSA verification on target arm: stm32mp1: Implement ECDSA signature verification Kconfig: FIT_SIGNATURE should not select RSA_VERIFY test: dm: Add test for ECDSA UCLASS support arch/arm/mach-stm32mp/Kconfig | 9 ++ arch/arm/mach-stm32mp/Makefile | 1 + arch/arm/mach-stm32mp/ecdsa_romapi.c | 102 ++++++++++++++++++++ common/Kconfig.boot | 8 +- configs/sandbox_defconfig | 2 + include/crypto/ecdsa-uclass.h | 39 ++++++++ include/dm/uclass-id.h | 1 + lib/Kconfig | 1 + lib/Makefile | 1 + lib/ecdsa/Kconfig | 23 +++++ lib/ecdsa/Makefile | 1 + lib/ecdsa/ecdsa-verify.c | 134 +++++++++++++++++++++++++++ test/dm/Makefile | 1 + test/dm/ecdsa.c | 39 ++++++++ 14 files changed, 358 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c create mode 100644 include/crypto/ecdsa-uclass.h create mode 100644 lib/ecdsa/Kconfig create mode 100644 lib/ecdsa/Makefile create mode 100644 lib/ecdsa/ecdsa-verify.c create mode 100644 test/dm/ecdsa.c -- 2.31.1

5 24

[PATCH v1] imx: mkimage_fit_atf: replace @ with hyphen
by Oliver Graute 16 Aug '21

16 Aug '21

Unit addresses are not allowed anymore in a FIT image since commit 3f04db891a35 ("image: Check for unit addresses in FITs") This caused this error on mkimage creation: ./tools/mkimage: verify_header failed for FIT Image support with exit code 1 Makefile:1393: recipe for target 'u-boot.itb' failed make: *** [u-boot.itb] Error 1 replacing @ with hyphen solved the issue Signed-off-by: Oliver Graute <oliver.graute(a)kococonnector.com> Cc: Stefano Babic <sbabic(a)denx.de> Cc: Fabio Estevam <festevam(a)gmail.com> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: Simon Glass <sjg(a)chromium.org> Cc: uboot-imx <uboot-imx(a)nxp.com> --- arch/arm/mach-imx/mkimage_fit_atf.sh | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh b/arch/arm/mach-imx/mkimage_fit_atf.sh index fe12b7bb4b..c5fb9b0fc3 100755 --- a/arch/arm/mach-imx/mkimage_fit_atf.sh +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh @@ -53,7 +53,7 @@ cat << __HEADER_EOF description = "Configuration to load ATF before U-Boot"; images { - uboot@1 { + uboot-1 { description = "U-Boot (64-bit)"; os = "u-boot"; data = /incbin/("$BL33"); @@ -68,7 +68,7 @@ cnt=1 for dtname in $* do cat << __FDT_IMAGE_EOF - fdt@$cnt { + fdt-$cnt { description = "$(basename $dtname .dtb)"; data = /incbin/("$dtname"); type = "flat_dt"; @@ -79,7 +79,7 @@ cnt=$((cnt+1)) done cat << __HEADER_EOF - atf@1 { + atf-1 { description = "ARM Trusted Firmware"; os = "arm-trusted-firmware"; data = /incbin/("$BL31"); @@ -93,7 +93,7 @@ __HEADER_EOF if [ -f $BL32 ]; then cat << __HEADER_EOF - tee@1 { + tee-1 { description = "TEE firmware"; data = /incbin/("$BL32"); type = "firmware"; @@ -108,7 +108,7 @@ fi cat << __CONF_HEADER_EOF }; configurations { - default = "config@1"; + default = "config-1"; __CONF_HEADER_EOF @@ -117,20 +117,20 @@ for dtname in $* do if [ -f $BL32 ]; then cat << __CONF_SECTION_EOF - config@$cnt { + config-$cnt { description = "$(basename $dtname .dtb)"; - firmware = "uboot@1"; - loadables = "atf@1", "tee@1"; + firmware = "uboot-1"; + loadables = "atf-1", "tee-1"; fdt = "fdt@$cnt"; }; __CONF_SECTION_EOF else cat << __CONF_SECTION1_EOF - config@$cnt { + config-$cnt { description = "$(basename $dtname .dtb)"; - firmware = "uboot@1"; - loadables = "atf@1"; - fdt = "fdt@$cnt"; + firmware = "uboot-1"; + loadables = "atf-1"; + fdt = "fdt-$cnt"; }; __CONF_SECTION1_EOF fi -- 2.17.1

6 10

Building U-Boot for Compulab's imx8mm-cl-iot-gate board
by Fabio Estevam 11 Aug '21

11 Aug '21

Hi Paul, I am trying to build U-Boot 2021.07-rc5 for the imx8mm-cl-iot-gate_defconfig target and I am following the imx8mm-evk readme: doc/board/freescale/imx8mm_evk.rst for the build instructions and this is the output: make[1]: Nothing to be done for 'SPL'. BINMAN all Image 'main-section' is missing external blobs and is non-functional: blob-ext Some images are invalid This happens because I did not provide the fip.bin binary. Is it OK if I remove the fip.bin entry like this? Would the board still boot? --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi @@ -217,18 +217,6 @@ }; }; - fip { - description = "Trusted Firmware FIP"; - type = "firmware"; - arch = "arm64"; - compression = "none"; - load = <0x40310000>; - - fip_blob: blob-ext{ - filename = "fip.bin"; - }; - }; - fdt { description = "NAME"; type = "flat_dt"; Could you please let me know the process for generating fip.bin? It would be nice to have a doc/board/compulab/imx8mm-iot-gate.rst README file with these details. I can help with that but need your help to clarify the generation of fip.bin. Also, is it OK if I use the ATF firmware and LPDDR binaries version as specified in doc/board/freescale/imx8mm_evk.rst ? Thanks, Fabio Estevam

2 8

[RFC PATCH v1] phy: rockchip: add basic rk3328 support to phy-rockchip-inno-usb2.c
by Johan Jonker 11 Aug '21

11 Aug '21

The rk3328 uses a usb phy simulair to rk3399 with only 1 instead of 2 usb ports. Reuse existing U-boot driver and add basic rk3328 support to phy-rockchip-inno-usb2.c Signed-off-by: Johan Jonker <jbx6244(a)gmail.com> --- drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 29 +++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c index 62b8ba3a4a..bfb531d3cd 100644 --- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c +++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c @@ -243,6 +243,31 @@ static int rockchip_usb2phy_bind(struct udevice *dev) return ret; } +static const struct rockchip_usb2phy_cfg rk3328_usb2phy_cfgs[] = { + { + .reg = 0x100, + .port_cfgs = { + [USB2PHY_PORT_OTG] = { + .phy_sus = { 0x0100, 8, 0, 0, 0x1d1 }, + .bvalid_det_en = { 0x0110, 2, 2, 0, 1 }, + .bvalid_det_st = { 0x0114, 2, 2, 0, 1 }, + .bvalid_det_clr = { 0x0118, 2, 2, 0, 1 }, + .utmi_avalid = { 0x0120, 10, 10, 0, 1 }, + .utmi_bvalid = { 0x0120, 9, 9, 0, 1 }, + }, + [USB2PHY_PORT_HOST] = { + .phy_sus = { 0x104, 8, 0, 0, 0x1d1 }, + .ls_det_en = { 0x110, 1, 1, 0, 1 }, + .ls_det_st = { 0x114, 1, 1, 0, 1 }, + .ls_det_clr = { 0x118, 1, 1, 0, 1 }, + .utmi_ls = { 0x120, 17, 16, 0, 1 }, + .utmi_hstdet = { 0x120, 19, 19, 0, 1 } + } + }, + }, + { /* sentinel */ } +}; + static const struct rockchip_usb2phy_cfg rk3399_usb2phy_cfgs[] = { { .reg = 0xe450, @@ -291,6 +316,10 @@ static const struct rockchip_usb2phy_cfg rk3399_usb2phy_cfgs[] = { static const struct udevice_id rockchip_usb2phy_ids[] = { { + .compatible = "rockchip,rk3328-usb2phy", + .data = (ulong)&rk3328_usb2phy_cfgs + }, + { .compatible = "rockchip,rk3399-usb2phy", .data = (ulong)&rk3399_usb2phy_cfgs, }, -- 2.11.0

2 2

[PATCH] rk3399: boot_devices fix spinor node name
by Artem Lapkin 11 Aug '21

11 Aug '21

Problem: board_spl_was_booted_from return wrong boot_devices[3] value /spi@ff1d0000 and same-as-spl dont work properly for SPINOR flash because arch/arm/mach-rockchip/spl-boot-order.c spl_node_to_boot_device need parse SPINOR flash node as UCLASS_SPI_FLASH spl-boot-order: same-as-spl > *** BOOT_SOURCE_ID 3 (2:emmc 3:spi 5:sd ... /spi@ff1d0000 > board_boot_order: could not map node @618 to a boot-device /sdhci@fe330000 > /mmc@fe320000 Solution: just change it to /spi@ff1d0000/flash@0 spl-boot-order: same-as-spl > *** BOOT_SOURCE_ID 3 (2:emmc 3:spi 5:sd ... /spi@ff1d0000/flash@0 > /sdhci@fe330000 > /mmc@fe320000 Signed-off-by: Artem Lapkin <art(a)khadas.com> --- arch/arm/mach-rockchip/rk3399/rk3399.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c b/arch/arm/mach-rockchip/rk3399/rk3399.c index 869d2159..69e0c8c2 100644 --- a/arch/arm/mach-rockchip/rk3399/rk3399.c +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c @@ -28,7 +28,7 @@ DECLARE_GLOBAL_DATA_PTR; const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = { [BROM_BOOTSOURCE_EMMC] = "/sdhci@fe330000", - [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d0000", + [BROM_BOOTSOURCE_SPINOR] = "/spi@ff1d0000/flash@0", [BROM_BOOTSOURCE_SD] = "/mmc@fe320000", }; -- 2.25.1

3 3

[PATCH 1/5] ARM: board: warp: Import dts files
by Peter Robinson 09 Aug '21

09 Aug '21

Import the i.MX6 based Warp dts files from Linux 5.12-rc1. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> Cc: Fabio Estevam <fabio.estevam(a)nxp.com> Cc: Stefano Babic <sbabic(a)denx.de> --- arch/arm/dts/Makefile | 4 +- arch/arm/dts/imx6sl-warp.dts | 234 +++++++++++++++++++++++++++++++++++ 2 files changed, 237 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/imx6sl-warp.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 116f75192f..1481a6ec46 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -734,7 +734,9 @@ dtb-y += \ endif -dtb-$(CONFIG_MX6SL) += imx6sl-evk.dtb +dtb-$(CONFIG_MX6SL) += \ + imx6sl-evk.dtb \ + imx6sl-warp.dtb dtb-$(CONFIG_MX6SLL) += imx6sll-evk.dtb diff --git a/arch/arm/dts/imx6sl-warp.dts b/arch/arm/dts/imx6sl-warp.dts new file mode 100644 index 0000000000..9d7c888489 --- /dev/null +++ b/arch/arm/dts/imx6sl-warp.dts @@ -0,0 +1,234 @@ +/* + * Copyright 2014, 2015 O.S. Systems Software LTDA. + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public + * License along with this file; if not, write to the Free + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, + * MA 02110-1301 USA + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; + +#include <dt-bindings/gpio/gpio.h> +#include "imx6sl.dtsi" + +/ { + model = "Revotics WaRP Board"; + compatible = "revotics,imx6sl-warp", "fsl,imx6sl"; + + memory@80000000 { + device_type = "memory"; + reg = <0x80000000 0x20000000>; + }; + + usdhc3_pwrseq: usdhc3_pwrseq { + compatible = "mmc-pwrseq-simple"; + reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>, /* WL_REG_ON */ + <&gpio4 7 GPIO_ACTIVE_LOW>, /* WL_HOSTWAKE */ + <&gpio3 25 GPIO_ACTIVE_LOW>, /* BT_REG_ON */ + <&gpio3 27 GPIO_ACTIVE_LOW>, /* BT_HOSTWAKE */ + <&gpio4 4 GPIO_ACTIVE_LOW>, /* BT_WAKE */ + <&gpio4 6 GPIO_ACTIVE_LOW>; /* BT_RST_N */ + }; +}; + +&uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart1>; + status = "okay"; +}; + +&uart3 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart3>; + status = "okay"; +}; + +&uart5 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uart5>; + uart-has-rtscts; + status = "okay"; +}; + +&usbotg1 { + dr_mode = "peripheral"; + disable-over-current; + status = "okay"; +}; + +&usbotg2 { + dr_mode = "host"; + disable-over-current; + status = "okay"; +}; + +&usdhc2 { + pinctrl-names = "default", "state_100mhz", "state_200mhz"; + pinctrl-0 = <&pinctrl_usdhc2>; + pinctrl-1 = <&pinctrl_usdhc2_100mhz>; + pinctrl-2 = <&pinctrl_usdhc2_200mhz>; + bus-width = <8>; + non-removable; + status = "okay"; +}; + +&usdhc3 { + pinctrl-names = "default", "state_100mhz", "state_200mhz"; + pinctrl-0 = <&pinctrl_usdhc3>; + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + bus-width = <4>; + non-removable; + keep-power-in-suspend; + wakeup-source; + mmc-pwrseq = <&usdhc3_pwrseq>; + status = "okay"; +}; + +&iomuxc { + imx6sl-warp { + pinctrl_uart1: uart1grp { + fsl,pins = < + MX6SL_PAD_UART1_RXD__UART1_RX_DATA 0x41b0b1 + MX6SL_PAD_UART1_TXD__UART1_TX_DATA 0x41b0b1 + >; + }; + + + pinctrl_uart3: uart3grp { + fsl,pins = < + MX6SL_PAD_AUD_RXC__UART3_RX_DATA 0x41b0b1 + MX6SL_PAD_AUD_RXC__UART3_TX_DATA 0x41b0b1 + >; + }; + + pinctrl_uart5: uart5grp { + fsl,pins = < + MX6SL_PAD_ECSPI1_SCLK__UART5_RX_DATA 0x41b0b1 + MX6SL_PAD_ECSPI1_MOSI__UART5_TX_DATA 0x41b0b1 + MX6SL_PAD_ECSPI1_MISO__UART5_RTS_B 0x4130b1 + MX6SL_PAD_ECSPI1_SS0__UART5_CTS_B 0x4130b1 + >; + }; + + pinctrl_usdhc2: usdhc2grp { + fsl,pins = < + MX6SL_PAD_SD2_CMD__SD2_CMD 0x417059 + MX6SL_PAD_SD2_CLK__SD2_CLK 0x410059 + MX6SL_PAD_SD2_DAT0__SD2_DATA0 0x417059 + MX6SL_PAD_SD2_DAT1__SD2_DATA1 0x417059 + MX6SL_PAD_SD2_DAT2__SD2_DATA2 0x417059 + MX6SL_PAD_SD2_DAT3__SD2_DATA3 0x417059 + MX6SL_PAD_SD2_DAT4__SD2_DATA4 0x417059 + MX6SL_PAD_SD2_DAT5__SD2_DATA5 0x417059 + MX6SL_PAD_SD2_DAT6__SD2_DATA6 0x417059 + MX6SL_PAD_SD2_DAT7__SD2_DATA7 0x417059 + MX6SL_PAD_SD2_RST__SD2_RESET 0x417059 + >; + }; + + pinctrl_usdhc2_100mhz: usdhc2grp100mhz { + fsl,pins = < + MX6SL_PAD_SD2_CMD__SD2_CMD 0x4170b9 + MX6SL_PAD_SD2_CLK__SD2_CLK 0x4100b9 + MX6SL_PAD_SD2_DAT0__SD2_DATA0 0x4170b9 + MX6SL_PAD_SD2_DAT1__SD2_DATA1 0x4170b9 + MX6SL_PAD_SD2_DAT2__SD2_DATA2 0x4170b9 + MX6SL_PAD_SD2_DAT3__SD2_DATA3 0x4170b9 + MX6SL_PAD_SD2_DAT4__SD2_DATA4 0x4170b9 + MX6SL_PAD_SD2_DAT5__SD2_DATA5 0x4170b9 + MX6SL_PAD_SD2_DAT6__SD2_DATA6 0x4170b9 + MX6SL_PAD_SD2_DAT7__SD2_DATA7 0x4170b9 + MX6SL_PAD_SD2_RST__SD2_RESET 0x4170b9 + >; + }; + + pinctrl_usdhc2_200mhz: usdhc2grp200mhz { + fsl,pins = < + MX6SL_PAD_SD2_CMD__SD2_CMD 0x4170f9 + MX6SL_PAD_SD2_CLK__SD2_CLK 0x4100f9 + MX6SL_PAD_SD2_DAT0__SD2_DATA0 0x4170f9 + MX6SL_PAD_SD2_DAT1__SD2_DATA1 0x4170f9 + MX6SL_PAD_SD2_DAT2__SD2_DATA2 0x4170f9 + MX6SL_PAD_SD2_DAT3__SD2_DATA3 0x4170f9 + MX6SL_PAD_SD2_DAT4__SD2_DATA4 0x4170f9 + MX6SL_PAD_SD2_DAT5__SD2_DATA5 0x4170f9 + MX6SL_PAD_SD2_DAT6__SD2_DATA6 0x4170f9 + MX6SL_PAD_SD2_DAT7__SD2_DATA7 0x4170f9 + MX6SL_PAD_SD2_RST__SD2_RESET 0x4170f9 + >; + }; + + pinctrl_usdhc3: usdhc3grp { + fsl,pins = < + MX6SL_PAD_SD3_CMD__SD3_CMD 0x417059 + MX6SL_PAD_SD3_CLK__SD3_CLK 0x410059 + MX6SL_PAD_SD3_DAT0__SD3_DATA0 0x417059 + MX6SL_PAD_SD3_DAT1__SD3_DATA1 0x417059 + MX6SL_PAD_SD3_DAT2__SD3_DATA2 0x417059 + MX6SL_PAD_SD3_DAT3__SD3_DATA3 0x417059 + >; + }; + + pinctrl_usdhc3_100mhz: usdhc3grp100mhz { + fsl,pins = < + MX6SL_PAD_SD3_CMD__SD3_CMD 0x4170b9 + MX6SL_PAD_SD3_CLK__SD3_CLK 0x4100b9 + MX6SL_PAD_SD3_DAT0__SD3_DATA0 0x4170b9 + MX6SL_PAD_SD3_DAT1__SD3_DATA1 0x4170b9 + MX6SL_PAD_SD3_DAT2__SD3_DATA2 0x4170b9 + MX6SL_PAD_SD3_DAT3__SD3_DATA3 0x4170b9 + >; + }; + + pinctrl_usdhc3_200mhz: usdhc3grp200mhz { + fsl,pins = < + MX6SL_PAD_SD3_CMD__SD3_CMD 0x4170f9 + MX6SL_PAD_SD3_CLK__SD3_CLK 0x4100f9 + MX6SL_PAD_SD3_DAT0__SD3_DATA0 0x4170f9 + MX6SL_PAD_SD3_DAT1__SD3_DATA1 0x4170f9 + MX6SL_PAD_SD3_DAT2__SD3_DATA2 0x4170f9 + MX6SL_PAD_SD3_DAT3__SD3_DATA3 0x4170f9 + >; + }; + }; +}; -- 2.31.1

5 13

[PATCH 0/5] arm: dts: stm32mp157c-odyssey-som: sync SDMMC2 with Linux and TF‑A
by Grzegorz Szymaszek 05 Aug '21

05 Aug '21

This patchset updates the properties of the SDMMC2 device tree node so that they match their Linux kernel and Trusted Firmware A counterparts. Two differences will remain: — in the Linux kernel device tree, the VQMMC supply is incorrectly set to v3v3 (buck4) instead of vdd (buck3); — in the TF‑A device tree, only the “default” pinctrl is configured. Additionally, this patchset enables SDMMC2 in SPL. Grzegorz Szymaszek (5): arm: dts: stm32mp157c-odyssey-som: fix the basic SDMMC2 properties arm: dts: stm32mp157c-odyssey-som: enable all SDMMC2 data lanes arm: dts: stm32mp157c-odyssey-som: set the SDMMC2 VQMMC supply arm: dts: stm32mp157c-odyssey-som: enable the SDMMC2 eMMC HS DDR mode arm: dts: stm32mp157c-odyssey-som: enable SDMMC2 in SPL .../dts/stm32mp157c-odyssey-som-u-boot.dtsi | 21 +++++++++++++++++++ arch/arm/dts/stm32mp157c-odyssey-som.dtsi | 15 +++++++------ 2 files changed, 30 insertions(+), 6 deletions(-) -- 2.30.2

2 11

[PATCH] doc: Add basic information about running CI tests
by Tom Rini 05 Aug '21

05 Aug '21

Start out by documenting general expectations on when CI is run, how anyone can run Azure pipelines, and how GitLab CI pipelines can be run. Signed-off-by: Tom Rini <trini(a)konsulko.com> --- doc/develop/ci_testing.rst | 45 ++++++++++++++++++++++++++++++++++++++ doc/develop/index.rst | 1 + 2 files changed, 46 insertions(+) create mode 100644 doc/develop/ci_testing.rst diff --git a/doc/develop/ci_testing.rst b/doc/develop/ci_testing.rst new file mode 100644 index 000000000000..48dbec4a4452 --- /dev/null +++ b/doc/develop/ci_testing.rst @@ -0,0 +1,45 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Continuous Integration testing +============================== + +All changes require passing our continuous integration tests prior to being +merged in to mainline. To help facilitate merges being accepted quickly, +custodians are encouraged but not required to run a pipeline prior to sending a +pull request. Individual developers submitting significant or widespread +changes are encouraged to run a pipeline themselves prior to posting. + +In order to make this process as easy as possible, the ability to run a CI +pipeline is provided in both Azure and GitLab. Both of these pipelines perform +their Linux build jobs on the same Docker container image. + +Azure Pipelines +--------------- + +Currently there are two ways to run a Microsoft Azure Pipeline test for U-Boot. +The first way is to create an account with Microsoft at +https://azure.microsoft.com/en-us/services/devops/ and then use the +``.azure-pipelines.yml`` file in the U-Boot repository as the pipeline +description. The second way is to use GitHub and submit a pull request against +https://github.com/u-boot/u-boot as this will trigger an Azure pipeline run. +Clicking on your pull request on the list at +https://github.com/u-boot/u-boot/pulls and then the "Checks" tab will show the +results. + +GitLab CI Pipelines +------------------- + +Currently, we support running GitLab CI pipelines only for custodians, due to +the resources the project has available. For Custodians, it is a matter of +enabling the pipeline feature in your project repository following the standard +GitLab documentation. For non-custodians, the pipeline itself is part of the +tree and should be able to be used on any GitLab instance, with whatever +runners you are able to provide. + +Docker container +---------------- + +As previously states, both of the above pipelines build using the same Docker +container image. This is maintained in the repository at +https://gitlab.denx.de/u-boot/gitlab-ci-runner and new images are made as +needed to support new tests or features. diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 0a7e204b3438..d5619e8fce86 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -7,6 +7,7 @@ Develop U-Boot .. toctree:: :maxdepth: 2 + ci_testing coccinelle commands crash_dumps -- 2.17.1

3 8