June 2021 - U-Boot

[PATCH 0/2] ARM64: rockchip: evb_rk3399: Khadas Edge add USB OHCI
by Artem Lapkin 08 Jun '21

08 Jun '21

Problem: USB2.0 port can recognize any USB1.1 devices (like usb keyboard) Add missed USB OHCI configuration Artem Lapkin (2): ARM64: rockchip: evb_rk3399: add usb ohci definations configs: rockchip: rk3399: Khadas Edge add USB OHCI configs/khadas-edge-captain-rk3399_defconfig | 2 ++ configs/khadas-edge-rk3399_defconfig | 2 ++ configs/khadas-edge-v-rk3399_defconfig | 2 ++ include/configs/evb_rk3399.h | 3 +++ 4 files changed, 9 insertions(+) -- 2.25.1

2 4

[RFC] nvme errors on QEMU
by Heinrich Schuchardt 08 Jun '21

08 Jun '21

I am calling qemu-x86_64_defconfig with qemu-system-x86_64 -machine pc-i440fx-2.5 -m 1G -smp cores=2 \ -bios u-boot.rom -nographic -gdb tcp::1234 \ -drive file=../sandbox.img,if=none,format=raw,id=nvme1 \ -device nvme,drive=nvme1,serial="S3EWNX0J123456K" \ -netdev user,id=eth0,tftp=tftp -device e1000,netdev=eth0 \ -device virtio-rng-pci nvme info displays a lot of errors: => nvme scan => nvme info Device 0: Vendor: 0x8086 Rev: 1.0 Prod: S3EWNX0J123456K Type: Hard Disk Capacity: 128.9 MB = 0.1 GB (264190 x 512) ERROR: status = 4002, phase = 1, head = 1 ERROR: status = 4002, phase = 0, head = 0 Device 1: Vendor: 0x8086 Rev: 1.0 Prod: S3EWNX0J123456K Type: Hard Disk Capacity: not available ERROR: status = 4002, phase = 0, head = 1 ERROR: status = 4002, phase = 1, head = 0 Device 2: Vendor: 0x8086 Rev: 1.0 Prod: S3EWNX0J123456K Type: Hard Disk Capacity: not available ... ERROR: status = 4002, phase = 1, head = 1 ERROR: status = 4002, phase = 0, head = 0 Device 255: Vendor: 0x8086 Rev: 1.0 Prod: S3EWNX0J123456K Type: Hard Disk Capacity: not available Why does 'nvme scan' create 255 nvme-blk devices too many? Best regards Heinrich

1 0

[PATCH] Prepare v2021.07-rc4
by xiaobo 08 Jun '21

08 Jun '21

From: Tom Rini <trini(a)konsulko.com> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index e048113ae2..a73481d18c 100644 --- a/Makefile +++ b/Makefile @@ -3,7 +3,7 @@ VERSION = 2021 PATCHLEVEL = 07 SUBLEVEL = -EXTRAVERSION = -rc3 +EXTRAVERSION = -rc4 NAME = # *DOCUMENTATION* -- 2.32.0

3 4

[PATCH] arm64: rk3399: Add support NanoPi R4s 1gb
by xiaobo 08 Jun '21

08 Jun '21

NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with dual-Core Cortex-A72 and Mali-T864 GPU with 1GiB(DDR3-1866) of RAM Signed-off-by: xiaobo <peterwillcn(a)gmail.com> --- arch/arm/dts/Makefile | 1 + .../arm/dts/rk3399-nanopi-r4s-1gb-u-boot.dtsi | 16 ++ arch/arm/dts/rk3399-nanopi-r4s-1gb.dts | 138 ++++++++++++++++++ board/rockchip/evb_rk3399/MAINTAINERS | 6 + configs/nanopi-r4s-1gb-rk3399_defconfig | 62 ++++++++ 5 files changed, 223 insertions(+) create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-1gb-u-boot.dtsi create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-1gb.dts create mode 100644 configs/nanopi-r4s-1gb-rk3399_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 096068261d..bbecdcfcc8 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -134,6 +134,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \ rk3399-nanopi-m4b.dtb \ rk3399-nanopi-neo4.dtb \ rk3399-nanopi-r4s.dtb \ + rk3399-nanopi-r4s-1gb.dtb rk3399-orangepi.dtb \ rk3399-pinebook-pro.dtb \ rk3399-puma-haikou.dtb \ diff --git a/arch/arm/dts/rk3399-nanopi-r4s-1gb-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-r4s-1gb-u-boot.dtsi new file mode 100644 index 0000000000..caa81eaace --- /dev/null +++ b/arch/arm/dts/rk3399-nanopi-r4s-1gb-u-boot.dtsi @@ -0,0 +1,16 @@ +// 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 <peterwillcn(a)gmail.com> + */ + +#include "rk3399-nanopi4-u-boot.dtsi" +#include "rk3399-sdram-ddr3-1866.dtsi" diff --git a/arch/arm/dts/rk3399-nanopi-r4s-1gb.dts b/arch/arm/dts/rk3399-nanopi-r4s-1gb.dts new file mode 100644 index 0000000000..6f2cf17bf1 --- /dev/null +++ b/arch/arm/dts/rk3399-nanopi-r4s-1gb.dts @@ -0,0 +1,138 @@ +// 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 <peterwillcn(a)gmail.com> + */ + +/dts-v1/; +#include "rk3399-nanopi4.dtsi" + +/ { + model = "FriendlyElec NanoPi R4S"; + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399"; + + aliases { + ethernet1 = &r8169; + }; + + 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>; + + r8169: pcie@0,0 { + reg = <0x000000 0 0 0 0>; + local-mac-address = [ 00 00 00 00 00 00 ]; + }; + }; +}; + +&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 25e308d186..b4a6a9ced3 100644 --- a/board/rockchip/evb_rk3399/MAINTAINERS +++ b/board/rockchip/evb_rk3399/MAINTAINERS @@ -67,6 +67,12 @@ S: Maintained F: configs/nanopi-r4s-rk3399_defconfig F: arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi +NANOPI-R4S-1GB +M: Xiaobo Tian <peterwillcn(a)gmail.com> +S: Maintained +F: configs/nanopi-r4s-1gb-rk3399_defconfig +F: arch/arm/dts/rk3399-nanopi-r4s-1gb-u-boot.dtsi + ORANGEPI-RK3399 M: Jagan Teki <jagan(a)amarulasolutions.com> S: Maintained diff --git a/configs/nanopi-r4s-1gb-rk3399_defconfig b/configs/nanopi-r4s-1gb-rk3399_defconfig new file mode 100644 index 0000000000..d08e75c687 --- /dev/null +++ b/configs/nanopi-r4s-1gb-rk3399_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x00200000 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_ROCKCHIP_RK3399=y +CONFIG_TARGET_EVB_RK3399=y +CONFIG_DEBUG_UART_BASE=0xFF1A0000 +CONFIG_DEBUG_UART_CLOCK=24000000 +CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-r4s-1gb" +CONFIG_DEBUG_UART=y +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-r4s-1gb.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_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_SYS_MMC_ENV_DEV=1 +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_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.32.0

1 0

[PATCH v4 0/7] arm: cache: cp15: don't map reserved region with no-map property
by Patrick Delaunay 08 Jun '21

08 Jun '21

Hi, It it the v4 serie of [1]. This v4 serie is rebased on top of master branch with update after Simon Glass review and added tags. On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region protected by a firewall. This region is reserved in the device with the "no-map" property as defined in the binding file doc/device-tree-bindings/reserved-memory/reserved-memory.txt. Sometime the platform boot failed in U-Boot on a Cortex A7 access to this region (depending of the binary and the issue can change with compiler version or with code alignment), then the firewall raise an error, for example: E/TC:0 tzc_it_handler:19 TZC permission failure E/TC:0 dump_fail_filter:420 Permission violation on filter 0 E/TC:0 dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged read, AXI ID 5c0 E/TC:0 Panic After investigation, the forbidden access is a speculative request performed by the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE property. The issue is solved only when the region reserved by OP-TEE is no more mapped in U-Boot as it is already done in Linux kernel. Tested on DK2 board with OP-TEE 3.12 / TF-A 2.4: With hard-coded address for OP-TEE reserved memory, the error doesn't occur. void dram_bank_mmu_setup(int bank) { .... for (i = start >> MMU_SECTION_SHIFT; i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT); i++) { option = DCACHE_DEFAULT_OPTION; if (i >= 0xde0) option = INVALID_ENTRY; set_section_dcache(i, option); } } Just by modifying the test on 0xde0 to 0xdf0, the OP-TEE memory protected by firewall is mapped cacheable and the error occurs. I think that it can be a general issue for ARM architecture: the "no-map" tag of reserved memory in device should be respected by U-Boot if firewall is configured before U-Boot execution. But I don't propose a generic solution in arm/lib/cache-cp15.c:dram_bank_mmu_setup() because the device tree parsing done in lmb_init_and_reserve() takes a long time when it is executed without data cache. => the previous path 7/7 of v2 series is dropped to avoid performance issue on other ARM target. To avoid this performance issue on stm32mp32mp platform, the lmb initialization is done in enable_caches() when dcache is still enable. This v3 series is composed by 7 patches - 1..3/7: preliminary steps to support flags in library in lmb (as it is done in memblock.c in Linux) - 4/7: unitary test on the added feature in lmb lib - 5/7: save the no-map flags in lmb when the device tree is parsed - 6/7: solve issue for the size of cacheable area in pre-reloc case - 7/7: update the stm32mp mmu support See also [2] which handle same speculative access on armv8 for area with Executable attribute. [1] http://patchwork.ozlabs.org/project/uboot/list/?series=241122&state=* [2] http://patchwork.ozlabs.org/project/uboot/patch/20200903000106.5016-1-marek… Regards Patrick Changes in v4: - Add comment for lmb_reserve_flags and remove extern - Remove unnecessary !! on return of boolean in lmb_is_nomap - Add comment for lmb_is_reserved_flags and remove extern - Remove unnecessary !! on return of boolean in lmb_is_reserved_flags - map the end of the DDR only before relocation, in board_f.c; this test avoid issue when board_get_usable_ram_top() is called in efi_loader function efi_add_known_memory() Changes in v3: - NEW: solve performance issue as relocated DT is not marked cacheable - call lmb_init_and_reserve when data cache is activated in enable_caches() - drop v2 patch "arm: cache: cp15: don't map the reserved region with no-map property" Changes in v2: - remove unnecessary comments in lmb.h - rebase on latest lmb patches - NEW: update in stm32mp specific MMU setup functions Patrick Delaunay (7): lmb: Add support of flags for no-map properties lmb: add lmb_is_reserved_flags lmb: add lmb_dump_region() function test: lmb: add test for lmb_reserve_flags image-fdt: save no-map parameter of reserve-memory stm32mp: Increase the reserved memory in board_get_usable_ram_top stm32mp: don't map the reserved region with no-map property arch/arm/mach-stm32mp/cpu.c | 17 +++++- arch/arm/mach-stm32mp/dram_init.c | 7 ++- common/image-fdt.c | 23 +++++--- include/lmb.h | 38 +++++++++++++ lib/lmb.c | 93 ++++++++++++++++++++++--------- test/lib/lmb.c | 89 +++++++++++++++++++++++++++++ 6 files changed, 228 insertions(+), 39 deletions(-) -- 2.17.1

2 8

[PATCH] dtoc: Allow overriding cc with $CC
by Simon Glass 07 Jun '21

07 Jun '21

From: Patrick Georgi <pgeorgi(a)google.com> The Chromium OS build system isn't particularly happy about using cc directly and fails the build when doing so. Update it to allow overriding this. Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> Signed-off-by: Simon Glass <sjg(a)chromium.org> --- tools/dtoc/fdt_util.py | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/dtoc/fdt_util.py b/tools/dtoc/fdt_util.py index 37e96b98642..34e1844ff18 100644 --- a/tools/dtoc/fdt_util.py +++ b/tools/dtoc/fdt_util.py @@ -74,6 +74,7 @@ def EnsureCompiled(fname, tmpdir=None, capture_stderr=False): for path in search_paths: args.extend(['-I', path]) args += ['-o', dts_input, fname] + cc = os.environ.get('CC') or 'cc' command.Run(cc, *args) # If we don't have a directory, put it in the tools tempdir -- 2.32.0.rc1.229.g3e70b5a671-goog

2 1

[RFC 0/5] rockchip_sfc: add support for Rockchip SFC
by Chris Morgan 07 Jun '21

07 Jun '21

From: Chris Morgan <macromorgan(a)hotmail.com> Requesting comments for a proposed patchset for adding the Rockchip serial flash controller to u-boot. The goal of these patches is to enable it for the Odroid Go Advance so that it may eventually boot exclusively from the SFC on mainline U-boot (I have tested this and it works). The specific help I need with this patch is: 1) I don't know the best way to upstream the XTX25F128B flash chip. This chip uses a continuation code for the manufacturer ID, however I cannot seem to find any way to actually read the continuation code. There is a risk of this driver, used as-is, to collide with another chip which has the same manufacturer ID with a different continuation code. 2) The Rockchip SFC driver itself (as it is mostly as-is from the BSP U-Boot sources) supports SPI NAND and chips of varying sizes, but my implementation only permits me to test with a single 128Mb flash chip. The driver itself does some checking on the bitlen in the routine rockchip_sfc_xfer() which is what is called for the dm_spi_ops.xfer. I'm not sure if there is a better way to do this. Additionally, I have to bit-shift the address written to the SFC as I suspect the value is meant to be left justified, but I never tested it further. Additionally, it might be worth mentioning but I noticed the Rockchip BROM will only boot the TPL/SPL off of the SFC if I write it to address 0x10000. This is not documented and different than the address looked at for SD card booting (512 * 64 = 0x8000 for SD Card booting). Also, like the SD card driver I can confirm that if DMA is enabled at the SPL stage A-TF seems to fail silently, then when Linux loads it hangs. There is an ifdef to force FIFO mode only in the SPL stage. Tested: Read (works) Write (works if you write to an erased sector) Erase (works) SPL Read (works if you edit the u-boot,spl-boot-order) Chris Morgan (5): spi: rockchip_sfc: add support for Rockchip SFC rockchip: px30: Add support for using SFC rockchip: px30: add the serial flash controller mtd: spi-nor-ids: Add XTX XT25F128B rockchip: px30: add support for SFC for Odroid Go Advance arch/arm/dts/px30.dtsi | 38 ++ arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 10 +- arch/arm/dts/rk3326-odroid-go2.dts | 22 + arch/arm/mach-rockchip/px30/px30.c | 64 ++ drivers/mtd/spi/Kconfig | 6 + drivers/mtd/spi/spi-nor-ids.c | 8 + drivers/spi/Kconfig | 8 + drivers/spi/Makefile | 1 + drivers/spi/rockchip_sfc.c | 652 +++++++++++++++++++++ 9 files changed, 926 insertions(+), 1 deletion(-) create mode 100644 drivers/spi/rockchip_sfc.c -- 2.25.1

4 12

[RFC PATCH 0/3] fastboot: sunxi: Determine MMC device at runtime
by Andre Przywara 07 Jun '21

07 Jun '21

At the moment the fastboot code relies on the Kconfig variable CONFIG_FASTBOOT_FLASH_MMC_DEV to point to the MMC device to use for the flash command. This value needs to be the *U-Boot device number*, which is picked by the U-Boot device model at runtime. This makes it quite tricky and fragile to fix this variable at compile time, as other DT nodes and aliases influence the enumeration process. To make this process more robust, allow the device number to be picked at runtime, which sounds like a better fit to find this device number. Patch 1/3 introduces a weak function for that purpose. Patch 2/3 then implements this function for the Allwinner platform. The code follows the idea behind the existing Kconfig defaults: Use the eMMC device, if that exists, or the SD card otherwise. This patch is actually not sunxi specific, so might be adopted by other platforms as well. Patch 3/3 then drops the existing Kconfig defaults for sunxi, to clean this up and remove the implicit assumption that the eMMC device is always device 1 (as least for the fastboot code). I would be curious if others think this is the right way forward. The fact that the U-Boot device numbers are determined at runtime seems to conflict with the idea of a Kconfig variable in the first place, hence this series. This brings us one step closer to the end goal of removing the "eMMC is device 1" assumption. I am looking forward to any comments on this series! Cheers, Andre Andre Przywara (3): fastboot: Allow runtime determination of MMC device sunxi: Implement fastboot_get_mmc_device() sunxi: Drop sunxi FASTBOOT_FLASH_MMC_DEV defaults board/sunxi/board.c | 37 +++++++++++++++++++++++++++++++++++ drivers/fastboot/Kconfig | 4 +--- drivers/fastboot/fb_command.c | 6 +++--- drivers/fastboot/fb_common.c | 3 ++- drivers/fastboot/fb_mmc.c | 12 ++++++++---- include/fastboot.h | 7 +++++++ 6 files changed, 58 insertions(+), 11 deletions(-) -- 2.17.5

4 13

[ANN] U-Boot v2021.07-rc4 released
by Tom Rini 07 Jun '21

07 Jun '21

Hey all, It's release day, and here's v2021.07-rc4. I'm getting this out early in the day as this is also when I'm opening the -next branch. I'm going to go over my queue and start putting things in there myself and hope for PRs from various maintainers soon. We did bring in the LTO series now, and since it's not enabled by default, I think we'll be OK here. It has shown however that while LTO may have been possible for a while, it still takes a fairly recent GCC to get everything right. There's at least one reported problem with 9.2.x that's fixed with 10.x. I also want to point out again that the deadline for DM_PCI, DM_USB and DM_SPI_FLASH will be 2 years past it's "convert or remove" deadline when v2021.07 is released, and I've posted removal series that will come in shortly after. DM_VIDEO also has that as a deadline but Anatolij sent a PR that's in this release which disabled DM_VIDEO on the few remaining unconverted boards, so that's all complete now. And in talking with Jagan off-list, DM_SPI_FLASH conversion looks to be complete already. In terms of a changelog, git log --merges v2021.07-rc3..v2021.07-rc4 contains what I've pulled but as always, better PR messages and tags will provide better results here. I do have my reminders setup for doing -rc releases every other Monday from here on out and final release on July 5th, 2021. Thanks all! -- Tom

1 0

[PATCH v3 00/19] am335x, guardian: update board specific changes
by Gireesh.Hiremath＠in.bosch.com 07 Jun '21

07 Jun '21

From: Gireesh Hiremath <Gireesh.Hiremath(a)in.bosch.com> address the v2 review comments >Hi Gireesh, > >On 22/04/21 7:01 pm, Gireesh.Hiremath(a)in.bosch.com wrote: >> From: Gireesh Hiremath <Gireesh.Hiremath(a)in.bosch.com> >> >> add support for updated TI clock driver, backlight, splash screen, swi >> logic, add ubi fastmap support, update pinmux, code clean up >> >> address the v1 review comments like: >> split board changes and defconfig changes into separate patches, >> adding clock support > >Overall looks good. Just minor comments: >- For config file changes can you make $subject as > configs: am335x_guardian: ... >- Can you rebase on top of latest master? > >Thanks and regards, >Lokesh Hi Lokesh, config file subject changed to configs: am335x_guardian:... rebased to latest master branch Thanks and regards, Gireesh Hiremath Gireesh Hiremath (16): configs: am335x_guardian: Enable clock driver configs: am335x_guardian: add ubi fastmap support configs: am335x_guardian: add memtest configs am335x, guardian: add memtest address range am335x, guardian: set environment variable autoload to no am335x, guardian: code cleanup and boot optimization configs: am335x_guardian: set boot delay configs: am335x_guardian: disable spl command am335x, guardian: update swi logic am335x, guardian: Enable backlight configs: am335x_guardian: Enable display config drivers: video: hx8238 fix build bug am335x, guardian: Enable panel driver Himax HX8238D am335x, guardian: software update available status is stored in AM3352 RTC scracth register configs: am335x_guardian: Enable bootcount nvmem support configs: am335x_guardian: add register maps support Moses Christopher (3): am335x, guardian: mem: Add board dependent mem values am335x, guardian: set tftp_load_addr in environment am335x, guardian: Update pinmux configuration arch/arm/dts/am335x-guardian-u-boot.dtsi | 11 ++ arch/arm/dts/am335x-guardian.dts | 14 +- .../include/asm/arch-am33xx/mem-guardian.h | 63 ++++++++ arch/arm/mach-omap2/am33xx/Kconfig | 2 + arch/arm/mach-omap2/am33xx/board.c | 4 + arch/arm/mach-omap2/mem-common.c | 4 + board/bosch/guardian/board.c | 151 +++++++++++++++--- board/bosch/guardian/mux.c | 3 +- configs/am335x_guardian_defconfig | 28 +++- drivers/bootcount/Kconfig | 27 +++- drivers/bootcount/Makefile | 1 + drivers/bootcount/bootcount_nvmem.c | 57 +++++++ drivers/video/Makefile | 2 +- drivers/video/hx8238d.c | 4 +- include/configs/am335x_guardian.h | 21 ++- 15 files changed, 350 insertions(+), 42 deletions(-) create mode 100644 arch/arm/include/asm/arch-am33xx/mem-guardian.h create mode 100644 drivers/bootcount/bootcount_nvmem.c -- 2.20.1

2 20