February 2021 - U-Boot

Please pull mmc-2021-2-19
by Peng Fan (OSS) 19 Feb '21

19 Feb '21

Hi Tom, Please pull mmc-2021-2-19 Sorry for delay, I have been quite busy in the past days. ===================== mmc_spi improvement added mmc-pwrseq to remove duplicated code fix response timeout after switch command sdhci: skip cache invalidation if DMA is not used ===================== Thanks, Peng. The following changes since commit 2dddc1bb296308b48f89f31e711965fa2c8091a0: net: tftp: Avoid sending extra ack on completion (2021-02-18 08:20:34 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git tags/mmc-2021-2-19 for you to fetch changes up to 144d0574d5f3652008ef400e86cc66db5ef88736: configs: enable CONFIG_MMC_PWRSEQ configuration (2021-02-19 15:11:33 +0800) ---------------------------------------------------------------- Bin Meng (4): mmc: mmc_spi: Print verbose debug output when crc16 check fails mmc: mmc_spi: Move argument check to the beginning of mmc_spi_sendcmd() mmc: mmc_spi: Fix potential spec violation in receiving card response mmc: mmc_spi: Document the 3 local functions Jaehoon Chung (7): mmc: initialize an err variable cmd: mmc: update the mmc command's usage about argument mmc: pwrseq: add mmc-pwrseq file to provide a generic interface mmc: meson_gx_mmc: use mmc_pwrseq instead of meson_mmc_pwrseq mmc: rockchip_dw_mmc: use mmc_pwrseq instead of rockchip_mmc_pwrseq ARM: mach-meson: select MMC_PWRSEQ config configs: enable CONFIG_MMC_PWRSEQ configuration Stefan Bosch (1): mmc: fix response timeout after switch command Yuezhang.Mo(a)sony.com (1): mmc: sdhci: skip cache invalidation if DMA is not used arch/arm/mach-meson/Kconfig | 1 + cmd/mmc.c | 6 +++--- configs/chromebit_mickey_defconfig | 1 + configs/chromebook_bob_defconfig | 1 + configs/chromebook_jerry_defconfig | 1 + configs/chromebook_minnie_defconfig | 1 + configs/chromebook_speedy_defconfig | 1 + drivers/mmc/Kconfig | 7 +++++++ drivers/mmc/Makefile | 1 + drivers/mmc/meson_gx_mmc.c | 45 +++------------------------------------------ drivers/mmc/mmc-pwrseq.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ drivers/mmc/mmc.c | 5 +++-- drivers/mmc/mmc_spi.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------- drivers/mmc/rockchip_dw_mmc.c | 42 +++--------------------------------------- drivers/mmc/sdhci.c | 2 ++ include/mmc.h | 15 +++++++++++++++ 16 files changed, 153 insertions(+), 107 deletions(-) create mode 100644 drivers/mmc/mmc-pwrseq.c

2 1

Frustrations of running testing
by Alex G. 19 Feb '21

19 Feb '21

Hi, I keep being hit by two frustrating issues when trying to run tests. My expectation is that I can run a test at any time when working on something -- usually to check the correctness of that something. That's not the case today. The first one is an error message about mrproper: $ ./test/py/test.py --bd sandbox_spl .. is not clean, please run 'make mrproper' I don't think this message is very useful. Running 'mrproper' is out of the question, as it would wipe out the branch I'm currently working on. So what I end up doing is deleting the mrimproper check from the Makefile. And while it's a fast workaround, it dirties the tree and gets in the way of rebasing patches or working with git. I can continue just fine without 'mrproper death' so I really don't understand the over-abundance of caution in breaking the build. The second issue is the how the tests are trying to build graphics: $ ./test/py/test.py --bd sandbox_spl -k "whatever" make[1]: sdl2-config: Command not found ../arch/sandbox/cpu/sdl.c:10:10: fatal error: SDL2/SDL.h: No such file or directory 10 | #include <SDL2/SDL.h> The solution is to set NO_SDL=1, but this is far from obvious. The first instinct is always to look up the command help: $ ./test/py/test.py --help But this really isn't at all useful. A simple grep for sdl2-config also doesn't immediately reveal the solution. Most u-boot tools get their arguments via the commandline. Thus, a reasonably competent u-boot developer will not think that environment variables are the solution. Ergo, environment variables are not the ideal way to solve this. Maybe we could have a commandline option, and at the very least, catch this error and print something useful on the console. I'm not sure what the preferred way would be to solve the above. For me, these issues cause a significant enough disruption to my workflow, that I am very likely to not run tests regularly. I suspect I'm not alone. Alex

2 1

Marvell PHY Support
by Marr, Hayden (Platform COE - Software) 19 Feb '21

19 Feb '21

Hello, I need to know if u-boot currently supports the Marvell PHY 88X3540 device. (Product brief here: https://jp.marvell.com/content/dam/marvell/en/public-collateral/phys-transc…) We will be using u-boot on LX2160A-based hardware, containing this PHY chip. Please reach out with any information/guidance. Thanks! Hayden Marr Engineer I Software Honeywell | Aerospace | Platform COE 21111 N. 19th Ave (Deer Valley) Phoenix, AZ 85027 Office: 602.436.0216 Hayden.Marr(a)Honeywell.com<mailto:Hayden.Marr@Honeywell.com> Honeywell.com

1 0

RAM test Uboot
by Fariya F 19 Feb '21

19 Feb '21

Hi, I would like to perform a RAM test at the bootloader level. My board is a beaglebone board. The problem is that my beaglebone board isn't booting successfully. The kernel is crashing with "Unable to handle kernel paging request at virtual address" I suspect it could be something to do with RAM/MMU and hence would want to perform a RAM test. Could someone help me with commands via which I can write to memory locations starting from xx to yy and read back and see if the content matches with what I wrote. The intent is to save these commands by 'saveenv' and execute it using the 'run' command on the bootloader prompt. FYI, my bootloader version read from the source code Makefile is (Version: 2016, Patch 03). [I tried just the bare command mtest and it takes forever to complete - not sure why so I thought I would do a memory write and memory read and compare and determine if everything is OK with the RAM or not] #2: In addition when I check the eMMC partition map using mmc commands on the bootloader prompt - everything looks ok. Is it possible to determine if some corruption happened to the eMMC due to which the kernel wouldn't boot? Regards, FF

1 0

[PATCH v4 0/8] spl: fit: Play nicely with OP-TEE and Linux
by Alexandru Gagniuc 19 Feb '21

19 Feb '21

The purpose of this series is to allow SPL to boot an image with both OP-TEE and Linux. The "simple" fit code was mostly ready for this, albeit quite unreadable. To be able to make these changes reviewable, some major refactoring had to be done. In fact, of the eight changes, (6) are refactoring patches, and (2) are functional changes. I wish I could have written this with a negative line count. I have unfortunately failed at that, and this series will be adding 5 lines to u-boot. The takeaway is that the following type FIT can be loaded from SPL directly: images { optee@1 { type = "tee"; os = "tee"; ... }; kernel@1 { type = "kernel"; os = "linux"; ... }; fdt(a)devicetree.dtb { ... } fdt(a)overlay.dto { ... }; }; configurations { conf@quickboot { kernel = "optee@1"; fdt = "fdt(a)stm32mp157c-ev1.dtb", "fdt(a)overlay.dto"; loadables = "kernel@1"; }; }; Changes since v2: * Fix copmiler error for IMX spl.c Changes since v2: * Fixed embarrasing rebase mishap on one of the patches. Changes since v1: * Added struct comments (Simon Glass) * Added comment do describe args of board_spl_fit_post_load() (Simon Glass) * Fixed predicate of if clause on spl_load_simple_fit() (me) Alexandru Gagniuc (8): spl: fit: Drop 'length' argument to board_spl_fit_post_load() spl: fit: Factor out FIT parsing and use a context struct spl: fit: Pass FIT context via a structure pointer spl: fit: Remove useless loop in spl_fit_get_image_name() spl: fit: Only look up FIT configuration node once image: Do not #if guard board_fit_image_post_process() prototype spl: fit: Replace #ifdef blocks with more readable constructs spl: fit: Load devicetree when a Linux payload is found arch/arm/mach-imx/spl.c | 7 +- common/spl/spl_fit.c | 261 +++++++++++++++++++++------------------- include/image.h | 7 -- include/spl.h | 4 +- 4 files changed, 142 insertions(+), 137 deletions(-) -- 2.26.2

2 16

Can’t boot FIT kernel image
by Алексей Бе ляев 19 Feb '21

19 Feb '21

Hello! I'm trying to make FIT Kernel+dtb image for U-Boot. ``` mkimage -E -f Image.its Image.new ``` Image.its: ``` /dts-v1/; / { description = "ARM64 OpenWrt FIT (Flattened Image Tree)"; #address-cells = <1>; images { kernel@1 { description = "ARM64 OpenWrt Linux-5.4.60"; data = /incbin/("arch/arm64/boot/Image.lzma"); type = "kernel"; arch = "arm64"; os = "linux"; compression = "lzma"; load = <0x40008000>; entry = <0x40008000>; hash@1 { algo = "crc32"; }; hash@2 { algo = "sha1"; }; }; fdt@1 { description = "ARM64 OpenWrt xunlong_orangepi-zero-plus2 device tree blob"; data = /incbin/("sun50i-h5-orangepi-zero-plus2.dtb"); type = "flat_dt"; arch = "arm64"; compression = "none"; load = <0x4FA00000>; hash@1 { algo = "crc32"; }; hash@2 { algo = "sha1"; }; }; }; configurations { default = "config@1"; config@1 { description = "OpenWRT"; kernel = "kernel@1"; fdt = "fdt@1"; }; }; }; ``` and it Look like good. U-boot print correct Information about it. ``` U-Boot 2020.04 (Aug 28 2020 - 09:44:29 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi Zero Plus2 DRAM: 512 MiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000' mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 => fatload mmc 0 53E00000 Image.new 3561732 bytes read in 513 ms (6.6 MiB/s) => setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=5452574f-02 rootwait earlycon=uart,mmio32,0x01c28000 => bootm 53E00000 ## Loading kernel from FIT Image at 53e00000 ... Using 'config@1' configuration Trying 'kernel@1' kernel subimage Description: ARM64 OpenWrt Linux-5.4.60 Type: Kernel Image Compression: lzma compressed Data Start: 0x53e0043c Data Size: 3537003 Bytes = 3.4 MiB Architecture: AArch64 OS: Linux Load Address: 0x40008000 Entry Point: 0x40008000 Hash algo: crc32 Hash value: 1003b68e Hash algo: sha1 Hash value: 94d9ea6a0f543649d294b50bd2a7bba1857cf538 Verifying Hash Integrity ... crc32+ sha1+ OK ## Loading fdt from FIT Image at 53e00000 ... Using 'config@1' configuration Trying 'fdt@1' fdt subimage Description: ARM64 OpenWrt xunlong_orangepi-zero-plus2 device tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x5415fca8 Data Size: 23641 Bytes = 23.1 KiB Architecture: AArch64 Load Address: 0x4fa00000 Hash algo: crc32 Hash value: fc8daabb Hash algo: sha1 Hash value: 6c18b66e1c9bb6dfb289701e1a478e294cb3568c Verifying Hash Integrity ... crc32+ sha1+ OK Loading fdt from 0x5415fca8 to 0x4fa00000 Booting using the fdt blob at 0x4fa00000 Uncompressing Kernel Image Loading Device Tree to 0000000049ff7000, end 0000000049fffc58 ... OK Starting kernel ... ``` And device has freeze. Kernel and dtb is fine. I have Image.lzma and "dtb" files distinctly and their work fine: ``` U-Boot 2020.04 (Aug 28 2020 - 09:44:29 +0000) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi Zero Plus2 DRAM: 512 MiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000' mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 => load mmc 0 53E00000 Image.lzma 3537067 bytes read in 506 ms (6.7 MiB/s) => fatload mmc 0 0x4FA00000 sun50i-h5-orangepi-zero-plus2.dtb 23641 bytes read in 5 ms (4.5 MiB/s) => setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=5452574f-02 rootwait earlycon=uart,mmio32,0x01c28000 =bootm 0x53E00000 - 0x4FA00000 ## Booting kernel from Legacy Image at 53e00000 ... Image Name: Linux Image Type: AArch64 Linux Kernel Image (lzma compressed) Data Size: 3537003 Bytes = 3.4 MiB Load Address: 40080000 Entry Point: 40080000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Uncompressing Kernel Image Loading Device Tree to 0000000049ff7000, end 0000000049fffc58 ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.4.60 (spider(a)horoshiki.ru) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r14283-42d14ace3e)) #0 SMP Fri Aug 28 09:44:29 2020 [ 0.000000] Machine model: OrangePi Zero Plus2 ``` What I do wrong? PS. Kernel boot normally by next command: ``` lzmadec 0x53e0043c 0x40008000 imxtract 53e00000 fdt@1 0x4FA00000 booti 0x40008000 - 0x4FA00000 ``` --

2 1

[PATCH btrfs-progs] btrfs-progs: do not fail when offset of a ROOT_ITEM is not -1
by Marek Behún 19 Feb '21

19 Feb '21

When the btrfs_read_fs_root() function is searching a ROOT_ITEM with location key offset other than -1, it currently fails via BUG_ON. The offset can have other value than -1, though. This can happen for example if a subvolume is renamed: $ btrfs subvolume create X && sync Create subvolume './X' $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: X$ location key (270 ROOT_ITEM 18446744073709551615) type DIR transid 283 data_len 0 name_len 1 name: X $ mv X Y && sync $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: Y$ location key (270 ROOT_ITEM 0) type DIR transid 285 data_len 0 name_len 1 name: Y As can be seen the offset changed from -1ULL to 0. Do not fail in this case. Signed-off-by: Marek Behún <marek.behun(a)nic.cz> Cc: David Sterba <dsterba(a)suse.com> Cc: Qu Wenruo <wqu(a)suse.com> Cc: Tom Rini <trini(a)konsulko.com> --- kernel-shared/disk-io.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel-shared/disk-io.c b/kernel-shared/disk-io.c index 6f584986..ba8ffd8b 100644 --- a/kernel-shared/disk-io.c +++ b/kernel-shared/disk-io.c @@ -752,8 +752,7 @@ struct btrfs_root *btrfs_read_fs_root(struct btrfs_fs_info *fs_info, return fs_info->free_space_root ? fs_info->free_space_root : ERR_PTR(-ENOENT); - BUG_ON(location->objectid == BTRFS_TREE_RELOC_OBJECTID || - location->offset != (u64)-1); + BUG_ON(location->objectid == BTRFS_TREE_RELOC_OBJECTID); node = rb_search(&fs_info->fs_root_tree, (void *)&objectid, btrfs_fs_roots_compare_objectids, NULL); -- 2.26.2

2 1

[PATCH] arm: dts: imx7d-sdb: Fix enet by setting soft spi mode to 3 for extended io
by Christian Bräuner Sørensen 19 Feb '21

19 Feb '21

This patch sets SPI MODE 3 for the fairchild 74HC595 device that is used to reset the ethernet device, which fixes ethernet. Reasoning: The imx7dsabresd board uses SPI for setting the extended IO. One of the purposes of this extended IO, is having the ability to set ENET_RST i.e. reset the ethernet PHY. Without proper reset of the PHY, ethernet does not work. commit 0e146993bb3d ("spi: add support for all spi modes with soft spi") broke network support for boards using imx7d-sdb, since it actually corrected default SPI mode setting for the software emulated soft_spi to 0, i.e. CPHA to 0 and CPOL to 0. Previously, the driver defaulted to CPHA 1 and CPOL 1 (i.e. spi mode 3). After the default SPI mode is now 0 (which is the correct default value) we now need to actively set CPHA and CPOL to 1 for the specific devices that actually needs this. Signed-off-by: Christian Bräuner Sørensen <yocto(a)bsorensen.net> --- arch/arm/dts/imx7d-sdb.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/dts/imx7d-sdb.dts b/arch/arm/dts/imx7d-sdb.dts index 8191ac7c33..6ed21ce8b0 100644 --- a/arch/arm/dts/imx7d-sdb.dts +++ b/arch/arm/dts/imx7d-sdb.dts @@ -58,6 +58,8 @@ reg = <0>; registers-number = <1>; spi-max-frequency = <100000>; + spi-cpha; + spi-cpol; }; }; -- 2.25.1

2 1

sunxi/pinephone suggestions and fixes
by Nicolas Boulenguez 19 Feb '21

19 Feb '21

Hello. Please consider the attached suggestions for the sunxi/pinephone platform. Among commits written for and by Mobian users, these ones may be of interest for all pinephone owners. Each header mentions the original motivation and author. Thanks. (Please CC me in follow-ups)

2 1

[PATCH 2/2] clk: imx8mp Enable EQOS clock
by Arendt, Steffen 19 Feb '21

19 Feb '21

Enable SPI clock for imx8mp Signed-off-by: Steffen Arendt <s.arendt(a)sensopart.de> --- diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c index b31afb31c0..c8a0b4549b 100644 --- a/drivers/clk/imx/clk-imx8mp.c +++ b/drivers/clk/imx/clk-imx8mp.c @@ -130,6 +130,15 @@ static const char *imx8mp_ecspi3_sels[] = {"osc_24m", "sys_pll2_200m", "sys_pll1 "sys_pll2_250m", "audio_pll2_out", }; #endif +static const char *imx8mp_enet_qos_sels[] = {"osc_24m", "sys_pll2_125m", "sys_pll2_50m", + "sys_pll2_100m", "sys_pll1_160m", "audio_pll1_out", + "video_pll1_out", "clk_ext4", }; + +static const char *imx8mp_enet_qos_timer_sels[] = {"osc_24m", "sys_pll2_100m", "audio_pll1_out", + "clk_ext1", "clk_ext2", "clk_ext3", + "clk_ext4", "video_pll1_out", }; + + static const char *imx8mp_usdhc1_sels[] = {"clock-osc-24m", "sys_pll1_400m", "sys_pll1_800m", "sys_pll2_500m", "sys_pll3_out", "sys_pll1_266m", "audio_pll2_out", "sys_pll1_100m", }; @@ -426,6 +435,12 @@ static int imx8mp_clk_probe(struct udevice *dev) imx_clk_gate4("ecspi3_root_clk", "ecspi3", base + 0x4090, 0)); #endif + clk_dm(IMX8MP_CLK_ENET_QOS, + imx8m_clk_composite("enet_qos", imx8mp_enet_qos_sels, base + 0xa880)); + clk_dm(IMX8MP_CLK_ENET_QOS_TIMER, + imx8m_clk_composite("enet_qos_timer", imx8mp_enet_qos_timer_sels, base + 0xa900)); + + return 0; }

1 0