May 2021 - U-Boot

[PATCH] pico-imx6: README: Fix the boot mode settings URL
by Fabio Estevam 09 Jun '21

09 Jun '21

The original URL that explains the boot mode setting is no longer valid. Update to the new one. Signed-off-by: Fabio Estevam <festevam(a)gmail.com> --- board/technexion/pico-imx6/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/technexion/pico-imx6/README b/board/technexion/pico-imx6/README index f1e84bfe8294..f4970865022a 100644 --- a/board/technexion/pico-imx6/README +++ b/board/technexion/pico-imx6/README @@ -20,7 +20,7 @@ If the eMMC has already a U-Boot flashed then the user can go to step 2 below in order to update U-Boot. Put pico board in USB download mode (Refer to the following link for details: -https://www.technexion.com/support/knowledgebase/boot-configuration-settings-for-pico-baseboards/). +https://developer.technexion.com/docs/pico-evaluation-kit-boot-mode-settings ) Connect a USB to serial adapter between the host PC and pico. -- 2.25.1

2 1

[PATCHv2] net: convert TFTP_TSIZE to proper Kconfig option
by Tero Kristo 09 Jun '21

09 Jun '21

TFTP transfer size can be used to re-size the TFTP progress bar on single line based on the server reported file size. The support for this has been around from 2019, but it was never converted to proper Kconfig. While adding this new Kconfig, enable it by default for OMAP2+ and K3 devices also. Signed-off-by: Tero Kristo <kristo(a)kernel.org> --- v2: convert to proper Kconfig and add defaults for TI platforms net/Kconfig | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/net/Kconfig b/net/Kconfig index c4b4dae064..ba0ca813ce 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -74,6 +74,17 @@ config TFTP_WINDOWSIZE before an ack response is required. The default TFTP implementation implies a window size of 1. +config TFTP_TSIZE + bool "Track TFTP transfers based on file size option" + depends on CMD_TFTPBOOT + default y if (ARCH_OMAP2PLUS || ARCH_K3) + help + By default, TFTP progress bar is increased for each received UDP + frame, which can lead into long time being spent for sending + data over the UART. Enabling this option, TFTP queries the file + size from server, and if supported, limits the progress bar to + 50 characters total which fits on single line. + config SERVERIP_FROM_PROXYDHCP bool "Get serverip value from Proxy DHCP response" help -- 2.17.1

3 3

Boot stops on RPi4 yocto/hardknott (u-boot 2021.01)
by Morten Bruun 09 Jun '21

09 Jun '21

Hi, I'm working on a project where we recently upgraded to Yocto/hardknott. After the upgrade to U-Boot 2021.01 the boot stops at switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... and then nothing more happens. Sometimes resetting power will cause the RPi4 to boot - but not always. I then downgraded to U-Boot 2020.07 and the RPi4 boots every time. I will be looking at the commits between 2020.07 and 2021.01 - but I'm not really sure what to look for - any ideas? Best regards Morten

4 4

[PATCH v4 0/2] log: Allow multiple lines and conversion to printf()
by Simon Glass 08 Jun '21

08 Jun '21

At present when logging is not enabled, all log() calls become nops. This does not seem right, since if the log level is high enough then there should be some sort of message. So in that case, this series updates it to print the message if the log level is above LOGL_INFO. This mimics the behaviour for the log_...() macros like log_debug() and log_info(), so we can drop the special case for these. Also the current implementation does not support multiple log calls on the same line nicely. The tags are repeated so the line is very hard to read. This series adds that as a new feature. Changes in v4: - Fix missing header for SPL Changes in v3: - Rebase on hexdump series http://patchwork.ozlabs.org/project/uboot/list/?series=242818 Changes in v2: - Update commit message and cover letter to mention log_...() macros - Add a test for !CONFIG_LOG - Update log() to (effectively) call debug() for log_level == LOGL_DEBUG Simon Glass (2): sandbox: log: Avoid build error with !CONFIG_LOG log: Convert log values to printf() if not enabled configs/sandbox_defconfig | 1 + doc/develop/logging.rst | 6 ++++-- include/log.h | 34 +++++++++++++++------------------- test/log/Makefile | 2 ++ test/log/nolog_ndebug.c | 39 +++++++++++++++++++++++++++++++++++++++ test/log/nolog_test.c | 3 +++ 6 files changed, 64 insertions(+), 21 deletions(-) create mode 100644 test/log/nolog_ndebug.c -- 2.31.1.607.g51e8a6a459-goog

2 3

[PATCH v2 00/12] display_options: Start to unify print_buffer() and hexdump
by Simon Glass 08 Jun '21

08 Jun '21

At present we have two ways of showing a hex dump. Once has been in U-Boot since the dawn of time and the other was recently added from Linux. They both have their own unique features. This series makes a few changes to bring them closer together. It also adds support for logging a buffer, which is useful since it can put it through the same log drivers as other logging output. Also it adds tests, so we can check the behaviour. The code-size impact of the main part of this series is 160 bytes on Thumb2, which seems acceptable. However the final patch adds another 600 bytes or so, which is not. Changes in v2: - Drop unwanted #if at top of file - Fix sandbox build error Simon Glass (12): console: Report an error when output buffer is exhausted test: Detect when expect_str is too small test: Convert print tests to use ut framework test: Add a test for print_buffer() display_options: Drop two spaces before the ASCII column hexdump: Move API to header file hexdump: Add support for sandbox hexdump: Support any rowsize hexdump: Allow ctrl-c to interrupt output display_options: Split print_buffer() into two functions log: Add support for logging a buffer RFC: display_options: Use print_hex_dump() for print_buffer() common/console.c | 18 +- common/log.c | 30 ++++ include/asm-generic/global_data.h | 16 +- include/console.h | 3 +- include/display_options.h | 25 +++ include/hexdump.h | 81 ++++++++- include/log.h | 35 ++++ include/test/suites.h | 1 + include/test/test.h | 4 +- lib/display_options.c | 124 ++++++++----- lib/hexdump.c | 104 +++-------- test/cmd/mem_search.c | 26 +-- test/cmd_ut.c | 2 + test/dm/rtc.c | 9 +- test/log/log_test.c | 27 +++ test/print_ut.c | 284 ++++++++++++++++++++++++------ test/ut.c | 55 +++++- 17 files changed, 629 insertions(+), 215 deletions(-) -- 2.31.1.607.g51e8a6a459-goog

2 13

[PATCH v2 0/2] clk: rockchip: rk3568: add clock driver
by Elaine＠denx.de 08 Jun '21

08 Jun '21

From: Elaine Zhang <zhangqing(a)rock-chips.com> Add basic clock for rk3568 which including cpu, bus, mmc, i2c, pwm, gmac ...clocks init. Change in V2: [PATCH v2 0/1]: No change. [PATCH v2 0/2]: update the copyright info and remove unused clock set/get. Elaine Zhang (2): rockchip: rk3568: add device tree file rockchip: rk3568: add clock driver .../include/asm/arch-rockchip/cru_rk3568.h | 504 +++ drivers/clk/rockchip/Makefile | 1 + drivers/clk/rockchip/clk_rk3568.c | 2959 +++++++++++++++++ include/dt-bindings/clock/rk3568-cru.h | 925 ++++++ 4 files changed, 4389 insertions(+) create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3568.h create mode 100644 drivers/clk/rockchip/clk_rk3568.c create mode 100644 include/dt-bindings/clock/rk3568-cru.h -- 2.17.1

4 9

[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

[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

[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