January 2020 - U-Boot

[PATCH 1/1] efi_loader: imply VIDEO_ANSI
by Heinrich Schuchardt 15 Jan '20

15 Jan '20

UEFI programs like GRUB make change terminal colors which requires support for ANSI escape sequences. Let CONFIG_EFI_LOADER=y imply CONFIG_VIDEO_ANSI. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- lib/efi_loader/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 21ef440341..5016a61f49 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -15,6 +15,7 @@ config EFI_LOADER select HAVE_BLOCK_DEVICE select REGEX imply CFB_CONSOLE_ANSI + imply VIDEO_ANSI help Select this option if you want to run UEFI applications (like GNU GRUB or iPXE) on top of U-Boot. If this option is enabled, U-Boot -- 2.24.1

1 0

[PATCH] tegra: fdt: Add tegra186-u-boot.dtsi
by Stephen Warren 14 Jan '20

14 Jan '20

From: Stephen Warren <swarren(a)nvidia.com> All Tegra chips except Tegra186 have a tegraNNN-u-boot.dtsi. Duplicate Tegra210's copy of this file for Tegra186. This ensures that a /binman node exists in U-Boot's control DT. Subsequent to 3c10dc95bdd0 ("binman: Add a library to access binman entries") this appears to be required. I haven't really investigated why all this is necessary or how it works, but simply observed the boot failure listed below, bisected it, noticed the inconsistency in DT files, and found that fixing it resolved the boot issue. U-Boot 2020.01-rc4-00256-g3c10dc95bdd0 (Jan 07 2020 - 10:25:00 -0700) SoC: tegra186 Model: NVIDIA P2771-0000-500 Board: NVIDIA P2771-0000 DRAM: 7.8 GiB initcall sequence 00000000fffb7858 failed at call 00000000800955a8 (err=-22) ### ERROR ### Please RESET the board ### Fixes: 3c10dc95bdd0 ("binman: Add a library to access binman entries") Fixes: f2faffecb016 ("binman: tegra: Convert to use binman") Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- arch/arm/dts/tegra186-u-boot.dtsi | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 arch/arm/dts/tegra186-u-boot.dtsi diff --git a/arch/arm/dts/tegra186-u-boot.dtsi b/arch/arm/dts/tegra186-u-boot.dtsi new file mode 100644 index 000000000000..7c1197255284 --- /dev/null +++ b/arch/arm/dts/tegra186-u-boot.dtsi @@ -0,0 +1,3 @@ +#include <config.h> + +#include "tegra-u-boot.dtsi" -- 2.24.1

3 3

[U-Boot] [PATCH 00/10] ARM: clearfog: add run-time board detect
by Baruch Siach 14 Jan '20

14 Jan '20

Newer revisions of SolidRun Clearfog Base/Pro carriers and Armada 388 SOM add EEPROM storage for board detection. This patch series adds support for reading EEPROM stored board information, and using it to set RAM training parameters, serdes configuration, and kernel DT selection. The information is stored in EEPROM in TLV format defined for the ONIE project. https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html This series add the sys_eeprom command from ONIE carried U-Boot patch, with a number for changes as described in the patch log. The TLV format is unchanged. This series also adds support for the newly introduced single board, Aramda 385 based Clearfog GTR system. RAM configuration on that system requires both Armada 38x DDR clocks to be enabled. The first patch in this series adds the necessary code to allow per-board selection of DDR clock. Baruch Siach (10): ddr: marvell: a38x: allow board specific clock out setup arm: mvebu: clearfog: enable both DDR clocks cmd: add sys_eeprom command ARM: mvebu: clearfog: add EEPROM devices ARM: mvebu: clearfog: add support for EEPROM TLV info ARM: mvebu: clearfog: read basic TLV data ARM: mvebu: clearfog: print TLV stored product name ARM: mvebu: clearfog: run-time selection of DT file ARM: mvebu: clearfog: add Clearfog GTR support ARM: mvebu: clearfog: add Clearfog Base serdes configuration arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 12 + arch/arm/dts/armada-388-clearfog.dts | 6 + .../arm/dts/armada-38x-solidrun-microsom.dtsi | 8 + arch/arm/mach-mvebu/Kconfig | 1 + board/solidrun/clearfog/clearfog.c | 164 ++- cmd/Kconfig | 12 + cmd/Makefile | 2 + cmd/sys_eeprom.c | 1078 +++++++++++++++++ configs/clearfog_defconfig | 5 + drivers/ddr/marvell/a38x/ddr3_training.c | 10 +- drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 + include/sys_eeprom.h | 169 +++ 12 files changed, 1466 insertions(+), 4 deletions(-) create mode 100644 cmd/sys_eeprom.c create mode 100644 include/sys_eeprom.h -- 2.24.0

2 25

[PATCH] configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE
by Mark Kettenis 14 Jan '20

14 Jan '20

This enables readning the cpuid from e-fuse, and deriving a static MAC address from it. Signed-off-by: Mark Kettenis <kettenis(a)openbsd.org> --- configs/firefly-rk3399_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig index b84d7b9ff0..20a7be9b82 100644 --- a/configs/firefly-rk3399_defconfig +++ b/configs/firefly-rk3399_defconfig @@ -8,6 +8,7 @@ CONFIG_DEBUG_UART_BASE=0xFF1A0000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_DEBUG_UART=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb" +CONFIG_MISC_INIT_R=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set @@ -27,6 +28,8 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y +CONFIG_ROCKCHIP_EFUSE=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y -- 2.24.1

2 1

Garbage UART output on RPI 4 with upstream kernel DTB
by Stefan Wahren 13 Jan '20

13 Jan '20

Hi, i tried to run current U-Boot (rpi_4_32b_defconfig) on my RPi 4 with bcm2711-rpi-4-b.dtb from the upstream kernel. Unfortunately i only see garbage on the debug UART (pin 14 & 15). Using the DTB from the downstream kernel has a proper UART output. The config.txt contains debug_uart=1 I compared both and identified an offending Linux commit: ARM: dts: bcm283x: Remove brcm,bcm2835-pl011 compatible Unfortunately reverting this patch still doesn't fix the issue. Any ideas? Best regards Stefan

2 6

[PATCH] board: fsl: lx2160a: Fix the for loop in board_fix_fdt
by Pankaj Bansal 13 Jan '20

13 Jan '20

Fix for loop in board_fix_fdt that erroneously increments the counter in all cases. the counter should be incremented only if a matching string has been found. Fixes: 5d535aa40b ("board: fsl: lx2160a: implement board_fix_fdt") Signed-off-by: Pankaj Bansal <pankaj.bansal(a)nxp.com> --- board/freescale/lx2160a/lx2160a.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/board/freescale/lx2160a/lx2160a.c b/board/freescale/lx2160a/lx2160a.c index e5b7fec9a4..0950f5064b 100644 --- a/board/freescale/lx2160a/lx2160a.c +++ b/board/freescale/lx2160a/lx2160a.c @@ -148,7 +148,8 @@ int board_fix_fdt(void *fdt) reg_name = reg_names; remaining_names_len = names_len - (reg_name - reg_names); - for (i = 0; (i < ARRAY_SIZE(reg_names_map)) && names_len; i++) { + i = 0; + while ((i < ARRAY_SIZE(reg_names_map)) && remaining_names_len) { old_name_len = strlen(reg_names_map[i].old_str); new_name_len = strlen(reg_names_map[i].new_str); if (memcmp(reg_name, reg_names_map[i].old_str, @@ -164,6 +165,7 @@ int board_fix_fdt(void *fdt) new_name_len); names_len -= old_name_len; names_len += new_name_len; + i++; } reg_name = memchr(reg_name, '\0', remaining_names_len); -- 2.17.1

1 0

[U-Boot] U-Boot for the Socfpga Arria10 board
by Wolfgang Grandegger 13 Jan '20

13 Jan '20

Hello, I'm trying to understand what is necessary to get mainline U-Boot booting from the eMMC of an Arria10 board, which is significantly different to the Cyclone 5. I'm playing with U-Boot v2019.10! I find some related documentation at [1]. Section "Arria 10 SoC - Boot from SD Card " seems to apply to the mainline U-Boot as well, at a first glance. Is there some similar doc for mainline U-Boot? What are the differences in mainline? Is it working or is something missing? So I need at least three partitions on the eMMC: 1. VFAT partition with u-boot.img and fit_spl_fpga.itb 2. A2 partition with 4x u-boot-spl.sfp (or u-boot-with-spl.sfp) 3. Linux partition Where do I specify the physical number of the partition 1.? Is it still possible to load the secondary bootloader (u-boot.img) from offset 0x800 of the A2 partition? It seems that "SPL_FS_FAT" breaks it. [1] https://rocketboards.org/foswiki/Documentation/BuildingBootloader TIA, Wolfgang

2 2

[Patch v3] net: pfe_eth: Use spi_flash_read API to access flash memory
by Kuldeep Singh 13 Jan '20

13 Jan '20

Current PFE firmware access spi-nor memory directly. New spi-mem framework does not support direct memory access. So, let's use spi_flash_read API to access memory instead of directly using it. Signed-off-by: Kuldeep Singh <kuldeep.singh(a)nxp.com> --- v3: -Replace ret with 0 if flash probe fails v2: -Add return error code -Some changes in displayed log drivers/net/pfe_eth/pfe_firmware.c | 45 +++++++++++++++++++++++++++++++++++++- include/configs/ls1012a_common.h | 5 ++++- 2 files changed, 48 insertions(+), 2 deletions(-) diff --git a/drivers/net/pfe_eth/pfe_firmware.c b/drivers/net/pfe_eth/pfe_firmware.c index e4563f1..6145f4e 100644 --- a/drivers/net/pfe_eth/pfe_firmware.c +++ b/drivers/net/pfe_eth/pfe_firmware.c @@ -12,13 +12,14 @@ #include <net/pfe_eth/pfe_eth.h> #include <net/pfe_eth/pfe_firmware.h> +#include <spi_flash.h> #ifdef CONFIG_CHAIN_OF_TRUST #include <fsl_validate.h> #endif #define PFE_FIRMWARE_FIT_CNF_NAME "config@1" -static const void *pfe_fit_addr = (void *)CONFIG_SYS_LS_PFE_FW_ADDR; +static const void *pfe_fit_addr; /* * PFE elf firmware loader. @@ -159,6 +160,44 @@ static int pfe_fit_check(void) return ret; } +int pfe_spi_flash_init(void) +{ + struct spi_flash *pfe_flash; + int ret = 0; + void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH); + +#ifdef CONFIG_DM_SPI_FLASH + struct udevice *new; + + /* speed and mode will be read from DT */ + ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, + CONFIG_ENV_SPI_CS, 0, 0, &new); + + pfe_flash = dev_get_uclass_priv(new); +#else + pfe_flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, + CONFIG_ENV_SPI_CS, + CONFIG_ENV_SPI_MAX_HZ, + CONFIG_ENV_SPI_MODE); +#endif + if (!pfe_flash) { + printf("SF: probe for pfe failed\n"); + return 0; + } + + ret = spi_flash_read(pfe_flash, + CONFIG_SYS_LS_PFE_FW_ADDR, + CONFIG_SYS_QE_FMAN_FW_LENGTH, + addr); + if (ret) + printf("SF: read for pfe failed\n"); + + pfe_fit_addr = addr; + spi_flash_free(pfe_flash); + + return ret; +} + /* * PFE firmware initialization. * Loads different firmware files from FIT image. @@ -183,6 +222,10 @@ int pfe_firmware_init(void) int ret = 0; int fw_count; + ret = pfe_spi_flash_init(); + if (ret) + goto err; + ret = pfe_fit_check(); if (ret) goto err; diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h index 2579e2f..cbc5bff 100644 --- a/include/configs/ls1012a_common.h +++ b/include/configs/ls1012a_common.h @@ -36,9 +36,12 @@ /* Size of malloc() pool */ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024) +/* PFE */ +#define CONFIG_SYS_FMAN_FW_ADDR 0x400d0000 +#define CONFIG_SYS_QE_FMAN_FW_LENGTH 0x10000 + /*SPI device */ #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT) -#define CONFIG_SYS_FMAN_FW_ADDR 0x400d0000 #define CONFIG_SPI_FLASH_SPANSION #define CONFIG_FSL_SPI_INTERFACE #define CONFIG_SF_DATAFLASH -- 2.7.4

2 4

[U-Boot] Question about GPL v3 font
by Masahiro Yamada 13 Jan '20

13 Jan '20

Hi. According to the Kconfig entry, drivers/video/fonts/nimbus_sans_l_regular.ttf is licensed under GPL v3. How the license is handled when U-Boot is compiled with CONFIG_CONSOLE_TRUETYPE_NIMBUS=y ? I am asking this since many companies, I guess, have GPL-v3 allergy. config CONSOLE_TRUETYPE_NIMBUS bool "Nimbus Sans Regular" depends on CONSOLE_TRUETYPE default y help Nimbus Sans L is a version of Nimbus Sans using Adobe font sources. It was designed in 1987. A subset of Nimbus Sans L were released under the GPL. Although the characters are not exactly the same, Nimbus Sans L has metrics almost identical to Helvetica and Arial. (From Wikipedia, the free encyclopedia) From: https://fontlibrary.org/en/font/nimbus-sans-l License: GNU GPL v3 http://www.gnu.org/copyleft/gpl.html -- Best Regards Masahiro Yamada

5 8

[PATCH v2] tools: ftdgrep: correct the find regions loop in do_fdtgrep
by Patrick Delaunay 13 Jan '20

13 Jan '20

Use realloc and update the loop executed in do_fdtgrep to find all the regions: only test count > max_region after the second pass. This patch solve an issue if the number of region found (count) is greater then the default value (max_region = count = 100): the second pass is never executed, because the loop stops after the first pass (i = 0, count > 100, max_regions = 100) with error -1 and the error message "Internal error with fdtgrep_find_region". I also update the error message. Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- Changes in v2: - Change malloc to realloc to avoid memory leak. tools/fdtgrep.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/fdtgrep.c b/tools/fdtgrep.c index 8f44f599c1..2a8058f57f 100644 --- a/tools/fdtgrep.c +++ b/tools/fdtgrep.c @@ -805,7 +805,7 @@ static int do_fdtgrep(struct display_info *disp, const char *filename) * we do another pass to actually record them. */ for (i = 0; i < 2; i++) { - region = malloc(count * sizeof(struct fdt_region)); + region = realloc(region, count * sizeof(struct fdt_region)); if (!region) { fprintf(stderr, "Out of memory for %d regions\n", count); @@ -823,8 +823,10 @@ static int do_fdtgrep(struct display_info *disp, const char *filename) } if (count <= max_regions) break; + } + if (count > max_regions) { free(region); - fprintf(stderr, "Internal error with fdtgrep_find_region)(\n"); + fprintf(stderr, "Internal error with fdtgrep_find_region()\n"); return -1; } -- 2.17.1

1 0