April 2021 - U-Boot

Bug: qemu_arm64: Cannot access the second flash bank
by Robin Randhawa 13 Sep '21

13 Sep '21

Hi folks. [CC'ing some hopefully relevant folks]. As of: commit 0ba41ce1b7816c229cc19e0621148b98f990cb68 libfdt: return correct value if #size-cells property is not present .. accesses to the second flash bank on the qemu_arm64 virtual board appear broken. To demonstrate, consider that the physical memory map for the 2 flash banks is: Bank 1: 0x0000_0000 - 0x03FC_0000 Bank 2: 0x0400_0000 - 0x7FC0_0000 Now, consider the abbreviated output of the flinfo command pre and post the above commit: Pre: === => flinfo Bank # 1: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 00000000 RO 00040000 RO 00080000 RO 000C0000 00100000 00140000 00180000 001C0000 00200000 00240000 . . 03E80000 03EC0000 03F00000 03F40000 03F80000 03FC0000 Bank # 2: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 04000000 RO 04040000 04080000 040C0000 04100000 04140000 04180000 041C0000 04200000 04240000 . . 07E80000 07EC0000 07F00000 07F40000 07F80000 07FC0000 Post: ==== => flinfo Bank # 1: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 00000000 RO 00040000 RO 00080000 RO 000C0000 00100000 00140000 00180000 001C0000 00200000 00240000 . . 03E80000 03EC0000 03F00000 03F40000 03F80000 03FC0000 Bank # 2: CFI conformant flash (32 x 16) Size: 64 MB in 256 Sectors Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x0018 Erase timeout: 16384 ms, write timeout: 3 ms Buffer write timeout: 3 ms, buffer size: 2048 bytes Sector Start Addresses: 400000000000000 400000000040000 400000000080000 4000000000C0000 400000000100000 400000000140000 400000000180000 4000000001C0000 400000000200000 400000000240000 . . 400000003E80000 400000003EC0000 400000003F00000 40 0000003F40000 400000003F80000 400000003FC0000 As a result, the second bank is unusable for environment stores (CONFIG_ENV_ADDR is 0x4000000): => saveenv Saving Environment to Flash... Error: start and/or end address not on sector boundary Error: start and/or end address not on sector boundary Failed (1) Rewinding the u-boot repo to before this commit fixes the problem. Manually (uncleanly) reverting the commit and it's dependent commits fixes the problem. Here are the HEAD commits from the relevant repos that I used for the data above: qemu: commit dd5b0f95490883cd8bc7d070db8de70d5c979cbc u-boot: commit 6cb87cbb1475f668689f95911d1521ee6ba7f55c Here is the qemu invocation I used: $ dd if=/dev/zero of=./flash0-with-uboot.img bs=1M count=64 && dd if=/path/to/u-boot.bin of=./flash0-with-uboot.img conv=notrunc $ qemu-system-aarch64 -M virt -cpu cortex-a53 -m 1024M -nographic -drive if=pflash,format=raw,index=0,file=flash0-with-uboot.img -drive if=pflash,format=raw,index=1,file=flash1.img I'm happy to help test any fixes if and as needed. Cheers, Robin

3 9

[u-boot PATCH] arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS Northbridge
by Roger Quadros 08 Sep '21

08 Sep '21

NB0 is bridge to SRAM and NB1 is bridge to DDR. To ensure that SRAM transfers are not stalled due to delays during DDR refreshes, SRAM traffic should be higher priority (threadmap=2) than DDR traffic (threadmap=0). This patch does just that. This is required to fix ICSSG TX lock-ups due to delays in MSMC transfers due to incorrect Northbridge configuration. Signed-off-by: Roger Quadros <rogerq(a)ti.com> Acked-by: Andrew F. Davis <afd(a)ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> Acked-by: Benoit Parrot <bparrot(a)ti.com> --- arch/arm/mach-k3/am6_init.c | 14 ++++++++++++++ arch/arm/mach-k3/include/mach/am6_hardware.h | 7 +++++++ 2 files changed, 21 insertions(+) diff --git a/arch/arm/mach-k3/am6_init.c b/arch/arm/mach-k3/am6_init.c index 8d107b870b..9379b95bdb 100644 --- a/arch/arm/mach-k3/am6_init.c +++ b/arch/arm/mach-k3/am6_init.c @@ -86,6 +86,18 @@ static void store_boot_index_from_rom(void) bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX); } +static void setup_am654_navss_northbridge(void) +{ + /* + * NB0 is bridge to SRAM and NB1 is bridge to DDR. + * To ensure that SRAM transfers are not stalled due to + * delays during DDR refreshes, SRAM traffic should be higher + * priority (threadmap=2) than DDR traffic (threadmap=0). + */ + writel(0x2, NAVSS0_NBSS_NB0_CFG_BASE + NAVSS_NBSS_THREADMAP); + writel(0x0, NAVSS0_NBSS_NB1_CFG_BASE + NAVSS_NBSS_THREADMAP); +} + void board_init_f(ulong dummy) { #if defined(CONFIG_K3_LOAD_SYSFW) || defined(CONFIG_K3_AM654_DDRSS) @@ -101,6 +113,8 @@ void board_init_f(ulong dummy) /* Make all control module registers accessible */ ctrl_mmr_unlock(); + setup_am654_navss_northbridge(); + #ifdef CONFIG_CPU_V7R disable_linefill_optimization(); setup_k3_mpu_regions(); diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h b/arch/arm/mach-k3/include/mach/am6_hardware.h index 6df7631545..45a5b31c52 100644 --- a/arch/arm/mach-k3/include/mach/am6_hardware.h +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h @@ -47,4 +47,11 @@ /* MCU SCRATCHPAD usage */ #define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE +/* NAVSS Northbridge config */ +#define NAVSS0_NBSS_NB0_CFG_BASE 0x03802000 +#define NAVSS0_NBSS_NB1_CFG_BASE 0x03803000 + +#define NAVSS_NBSS_PID 0x0 +#define NAVSS_NBSS_THREADMAP 0x10 + #endif /* __ASM_ARCH_AM6_HARDWARE_H */ -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

4 7

[PATCH] Revert "mmc: sdhci: set to INT_DATA_END when there are data"
by Yuezhang.Mo＠sony.com 06 Sep '21

06 Sep '21

This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59. In eMMC specification, for the response-with-busy(R1b, R5b) command, the DAT0 will driven to LOW as BUSY status, and in sdhci specification, the transfer complete bit should be wait for BUSY status de-assert. All response-with-busy commands don't contain data, the data judgement is no need. Signed-off-by: Yuezhang.Mo <Yuezhang.Mo(a)sony.com> --- drivers/mmc/sdhci.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index d9ab6a0a83..8568f65b18 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -258,8 +258,7 @@ static int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, flags = SDHCI_CMD_RESP_LONG; else if (cmd->resp_type & MMC_RSP_BUSY) { flags = SDHCI_CMD_RESP_SHORT_BUSY; - if (data) - mask |= SDHCI_INT_DATA_END; + mask |= SDHCI_INT_DATA_END; } else flags = SDHCI_CMD_RESP_SHORT; -- 2.25.1

5 13

[PATCH v2 0/5] cmd: bind: Fix driver binding
by Patrice Chotard 01 Sep '21

01 Sep '21

This series is fixing issues reported by Herbert Poetzl when trying to bind Ethernet gadget over USB on STM32MP1 platform. 2 issues have been found: - fix the bind command. - add dwc2 bcdDevice in USB gadget controller. - add test to check binding of driver without compatible string. Changes in v2: - add bind test Patrice Chotard (5): cmd: bind: Fix driver binding on a device usb: gadget: Add bcdDevice for the DWC2 USB Gadget Controller usb: sandbox: Add gadget callbacks configs: sandbox: add USB_ETHER and GADGET_DOWNLOAD gadget support test/py: Add usb gadget binding test cmd/bind.c | 2 +- configs/sandbox_defconfig | 3 +++ drivers/core/device.c | 2 +- drivers/core/lists.c | 11 ++++++++--- drivers/core/root.c | 2 +- drivers/misc/imx8/scu.c | 2 +- drivers/serial/serial-uclass.c | 2 +- drivers/timer/timer-uclass.c | 2 +- drivers/usb/gadget/gadget_chips.h | 8 ++++++++ drivers/usb/host/usb-sandbox.c | 28 ++++++++++++++++++++++++++++ include/dm/lists.h | 3 ++- test/dm/nop.c | 2 +- test/dm/test-fdt.c | 2 +- test/py/tests/test_bind.py | 7 +++++++ 14 files changed, 64 insertions(+), 12 deletions(-) -- 2.17.1

3 12

[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] 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

[PATCH] fs/squashfs: Fix some hardlinks reading the wrong inode
by Campbell Suter 05 Aug '21

05 Aug '21

In SquashFS, the contents of a directory is stored by squashfs_directory_entry structures which contain the file's name, inode and position within the filesystem. The inode number is not stored directly; instead each directory has one or more headers which set a base inode number, and files store the offset from that to the file's inode number. In mksquashfs, each inode is allocated a number in the same order as they are written to the directory table; thus the offset from the header's base inode number to the file's inode number is usually positive. Hardlinks are simply stored with two directory entries referencing the same file. This means the second entry will thus have an inode number much lower than the surrounding files. Since the header's base inode number comes from the first entry that uses the header, this delta will usually be negative. Previously, U-Boot's squashfs_directory_entry.inode_offset field was declared as an unsigned value. Thus when a negative value was found, it would either resolve to an invalid inode number or to that of an unrelated file. A squashfs image to test this can be created like so: echo hi > sqfs_test_files/001-root-file mkdir sqfs_test_files/002-subdir touch sqfs_test_files/002-subdir/003-file ln sqfs_test_files/{001-root-file,002-subdir/004-link} mksquashfs sqfs_test_files/ test.sqfs -noappend Note that squashfs sorts the files ASCIIbetacally, so we can use the names to control the order they appear in. The ordering is important - the first reference to the file must have a lower inode number than the directory in which the second reference resides, and the second reference cannot be the first file in the directory. Listing this sample image in U-Boot results in: => sqfsls virtio 2 002-subdir 0 003-file Inode not found. 0 004-link Signed-off-by: Campbell Suter <campbell(a)snapit.group> --- fs/squashfs/sqfs_filesystem.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/squashfs/sqfs_filesystem.h b/fs/squashfs/sqfs_filesystem.h index 856cd15e349..5440b6c0e05 100644 --- a/fs/squashfs/sqfs_filesystem.h +++ b/fs/squashfs/sqfs_filesystem.h @@ -231,7 +231,7 @@ union squashfs_inode { struct squashfs_directory_entry { u16 offset; - u16 inode_offset; + s16 inode_offset; u16 type; u16 name_size; char name[0]; -- 2.31.1

3 2

[PATCH] fit: Fix verification of images with external data
by John Keeping 05 Aug '21

05 Aug '21

The "-E" option to mkimage generates a FIT with external data using the data-size and data-offset properties which must both be ignored when verifying a signature. Add "data-offset" to the list of excluded properties for signature verification; since the line is now too long, re-format the list to one-per-line and make it static since the data is constant. Signed-off-by: John Keeping <john(a)metanate.com> --- common/image-fit-sig.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c index 55ddf1879e..b979cd2a4b 100644 --- a/common/image-fit-sig.c +++ b/common/image-fit-sig.c @@ -245,7 +245,13 @@ static int fit_config_check_sig(const void *fit, int noffset, int required_keynode, int conf_noffset, char **err_msgp) { - char * const exc_prop[] = {"data", "data-size", "data-position"}; + static char * const exc_prop[] = { + "data", + "data-size", + "data-position", + "data-offset" + }; + const char *prop, *end, *name; struct image_sign_info info; const uint32_t *strings; -- 2.31.1

3 3

[PATCH] mmc: sdhci: Write to HOST_CONTROL2 register for HS400 speed mode
by Aswath Govindraju 29 Jul '21

29 Jul '21

From: Faiz Abbas <faiz_abbas(a)ti.com> Enable HS400 speed mode by writing to HOST_CONTROL2 register. Signed-off-by: Faiz Abbas <faiz_abbas(a)ti.com> Signed-off-by: Aswath Govindraju <a-govindraju(a)ti.com> --- drivers/mmc/sdhci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index d9ab6a0a839e..eea4701d8af5 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -507,6 +507,9 @@ void sdhci_set_uhs_timing(struct sdhci_host *host) case MMC_HS_200: reg |= SDHCI_CTRL_UHS_SDR104; break; + case MMC_HS_400: + reg |= SDHCI_CTRL_HS400; + break; default: reg |= SDHCI_CTRL_UHS_SDR12; } -- 2.17.1

4 15

[PATCH] sunxi: Load sun8i secure monitor to SRAM A2
by Samuel Holland 27 Jul '21

27 Jul '21

Most sun6i-derived SoCs contain SRAM A2, a secure SRAM area for ARISC SCP firmware. H3 has a smaller SRAM than other SoCs (A31/A33/A23/A83T). On sun8i SoCs which do not have SRAM B, we can use part of this SRAM for the secure monitor. Follow the design of 64-bit SoCs and use the first part for the monitor, and the last 16 KiB for the SCP firmware. With this change, the monitor no longer needs to reserve a region in DRAM. Signed-off-by: Samuel Holland <samuel(a)sholland.org> --- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 11 +++++++++++ include/configs/sun8i.h | 7 +++++++ 2 files changed, 18 insertions(+) diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h index 02ce73954d..d4c795d89c 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h @@ -11,7 +11,18 @@ #define SUNXI_SRAM_A1_BASE 0x00000000 #define SUNXI_SRAM_A1_SIZE (16 * 1024) /* 16 kiB */ +#if defined(CONFIG_SUNXI_GEN_SUN6I) && \ + !defined(CONFIG_MACH_SUN8I_R40) && \ + !defined(CONFIG_MACH_SUN8I_V3S) +#define SUNXI_SRAM_A2_BASE 0x00040000 +#ifdef CONFIG_MACH_SUN8I_H3 +#define SUNXI_SRAM_A2_SIZE (48 * 1024) /* 16+32 kiB */ +#else +#define SUNXI_SRAM_A2_SIZE (80 * 1024) /* 16+64 kiB */ +#endif +#else #define SUNXI_SRAM_A2_BASE 0x00004000 /* 16 kiB */ +#endif #define SUNXI_SRAM_A3_BASE 0x00008000 /* 13 kiB */ #define SUNXI_SRAM_A4_BASE 0x0000b400 /* 3 kiB */ #define SUNXI_SRAM_D_BASE 0x00010000 /* 4 kiB */ diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h index 9b4675e4c3..545d27996c 100644 --- a/include/configs/sun8i.h +++ b/include/configs/sun8i.h @@ -12,6 +12,13 @@ * A23 specific configuration */ +/* + * Skip the first 16 KiB of SRAM A2, which is not usable, as only certain bytes + * are writable. Reserve the last 17 KiB for the resume shim and SCP firmware. + */ +#define CONFIG_ARMV7_SECURE_BASE (SUNXI_SRAM_A2_BASE + 16 * 1024) +#define CONFIG_ARMV7_SECURE_MAX_SIZE (SUNXI_SRAM_A2_SIZE - 33 * 1024) + /* * Include common sunxi configuration where most the settings are */ -- 2.26.3

2 3