May 2020 - U-Boot

Failsafe booting to alternate linux image/fs
by Brendan Simon (eTRIX) 28 May '20

28 May '20

Hi, Before I embark on my own implementation of a failsafe bootloading process from my embedded system (Xilinx Zynq board booting from SD Card), I thought I'd quickly ask the experts if there are any standard implementations in u-boot. The current u-boot being used is from 2015. It probably needs to be updated (for various reasons). It is loaded from the first partition (64MB/FAT32) of an SD Card as part of a file called `BOOT.BIN`. The `Env.txt` file contains settings for two linux root systems (including kernel and dtb) on separate partitions (ext4/1GB). The first statement in `Env.txt` has a `part=2` or `part=3` to indicate, which partition to boot from (load kernel and set cmdline for rootfs, etc). My simple approach was to store a env var for the number of reboot attempts. On every boot attempt, the env var would be incremented. If linux booted successfully it would set the env var to zero (I believe there are linux tools to do that). If linux didn't boot successfully, eventually the reboot count env var would reach some value, where the alternative partition would be selected as an attempt to get something booting and up and running. NOTE: the devices are remote and need to be up as much as possible so they can be monitored/managed. *Does this type of functionality exist already in u-boot?* I'm guessing/hoping it does (and hope to use it directly or leverage the features that make sense) rather than reinventing the wheel. *Where is the best place to go to get information/documentation on this?* Finally, I'm looking at migrating to EMMC, maybe with a golden image for failsafe use, and two partitions for current filesystem and next/upgrade filesystem. *Is there any documentation that might be a useful in this use case?* Thanks, Brendan.

1 0

[Patch v4] net: pfe_eth: Use spi_flash_read API to access flash memory
by Kuldeep Singh 28 May '20

28 May '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> --- v4: -Return -ENODEV if flash probe fails v3: -Replace ret with 0 if flash probe fails v2: -Add return error code -Changes in displayed error 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..27ae8ae 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 -ENODEV; + } + + 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

3 5

[PATCH][v4 1/6] board: tbs2910: disable loadb and loads commands
by Denis 'GNUtoo' Carikli 28 May '20

28 May '20

The loadb and loads commands are not needed for booting. There are also more reliable and faster alternatives to loadb and loads that can be used with the current configuration. As that the resulting image is already very close to the size limit, removing the loadb and loads commands shouldn't hurt. With arm-linux-gnueabi-gcc 9.2.0-1 from the Parabola GNU/Linux distribution we have the following size reduction: - text: 6733 bytes - data: 116 bytes - bss: 1172 bytes - total: 8021 bytes Acked-by: Soeren Moch <smoch(a)web.de> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo(a)cyberdimension.org> --- configs/tbs2910_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index 61d4c74324..570ae850e4 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -26,6 +26,8 @@ CONFIG_CMD_BOOTZ=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y +# CONFIG_CMD_LOADB is not set +# CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y CONFIG_CMD_PART=y CONFIG_CMD_PCI=y -- 2.25.1

2 18

[PATCH] I2C: ls1043a, ls1046a: enable SYS_I2C_MXC
by Biwen Li 28 May '20

28 May '20

From: Biwen Li <biwen.li(a)nxp.com> This enables SYS_I2C_MXC to fix a bug that failed to boot from sd card with image u-boot-with-spl-pbl.bin Signed-off-by: Biwen Li <biwen.li(a)nxp.com> --- arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 ++-- include/configs/ls1043a_common.h | 1 - include/configs/ls1046a_common.h | 1 - 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig index b25639183f..ac53d64e31 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig @@ -74,7 +74,7 @@ config ARCH_LS1043A select SYS_FSL_HAS_DDR4 select ARCH_EARLY_INIT_R select BOARD_EARLY_INIT_F - select SYS_I2C_MXC if !DM_I2C + select SYS_I2C_MXC select SYS_I2C_MXC_I2C1 if !DM_I2C select SYS_I2C_MXC_I2C2 if !DM_I2C select SYS_I2C_MXC_I2C3 if !DM_I2C @@ -107,7 +107,7 @@ config ARCH_LS1046A select SYS_FSL_SRDS_2 select ARCH_EARLY_INIT_R select BOARD_EARLY_INIT_F - select SYS_I2C_MXC if !DM_I2C + select SYS_I2C_MXC select SYS_I2C_MXC_I2C1 if !DM_I2C select SYS_I2C_MXC_I2C2 if !DM_I2C select SYS_I2C_MXC_I2C3 if !DM_I2C diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h index 985f40412c..2155bb45b2 100644 --- a/include/configs/ls1043a_common.h +++ b/include/configs/ls1043a_common.h @@ -144,7 +144,6 @@ /* I2C */ #ifndef CONFIG_DM_I2C #define CONFIG_SYS_I2C -#define CONFIG_SYS_I2C_MXC #define CONFIG_SYS_I2C_MXC_I2C1 /* enable I2C bus 1 */ #define CONFIG_SYS_I2C_MXC_I2C2 /* enable I2C bus 2 */ #define CONFIG_SYS_I2C_MXC_I2C3 /* enable I2C bus 3 */ diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h index e80c2996ef..1748422885 100644 --- a/include/configs/ls1046a_common.h +++ b/include/configs/ls1046a_common.h @@ -129,7 +129,6 @@ /* I2C */ #ifndef CONFIG_DM_I2C #define CONFIG_SYS_I2C -#define CONFIG_SYS_I2C_MXC #define CONFIG_SYS_I2C_MXC_I2C1 /* enable I2C bus 1 */ #define CONFIG_SYS_I2C_MXC_I2C2 /* enable I2C bus 2 */ #define CONFIG_SYS_I2C_MXC_I2C3 /* enable I2C bus 3 */ -- 2.17.1

1 0

[PATCH v1] x86: acpi: Drop _HID() where enumerated by _ADR()
by Andy Shevchenko 28 May '20

28 May '20

ACPICA complains that either _HID() or _ADR() should be used. For General Purpose DMA we may not drop the _ADR() because the device is enumerated by PCI. Thus, simple drop _HID(). Reported-by: Bin Meng <bmeng.cn(a)gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl index eaf75c8c673d..01077293bb91 100644 --- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl +++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl @@ -531,7 +531,6 @@ Device (PCI0) Device (GDMA) { Name (_ADR, 0x00150000) - Name (_HID, "808611A2") Name (_UID, Zero) Method (_STA, 0, NotSerialized) -- 2.26.2

2 2

[PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in Self Refresh mode"
by Biwen Li 27 May '20

27 May '20

From: Biwen Li <biwen.li(a)nxp.com> This reverts commit 2a5d5d27edfbdb0e02a7fcf05569f92c02ae44ee. After applied this patch, failed to boot to uboot(hang in ddr init) on P3041DS, P4080DS and so on. --- drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c index 952b296dd8..a9b085db8c 100644 --- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c +++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c @@ -370,8 +370,6 @@ step2: debug("Setting DEBUG_3[21] to 0x%08x\n", in_be32(&ddr->debug[2])); #endif /* part 1 of the workaound */ - /* Always start in self-refresh, clear after MEM_EN */ - setbits_be32(&ddr->sdram_cfg_2, SDRAM_CFG2_FRC_SR); /* * 500 painful micro-seconds must elapse between @@ -384,6 +382,8 @@ step2: #ifdef CONFIG_DEEP_SLEEP if (is_warm_boot()) { + /* enter self-refresh */ + setbits_be32(&ddr->sdram_cfg_2, SDRAM_CFG2_FRC_SR); /* do board specific memory setup */ board_mem_sleep_setup(); temp_sdram_cfg = (in_be32(&ddr->sdram_cfg) | SDRAM_CFG_BI); @@ -395,10 +395,6 @@ step2: out_be32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN); asm volatile("sync;isync"); - /* Exit self-refresh after DDR conf as some ddr memories can fail. */ - clrbits_be32(&ddr->sdram_cfg_2, SDRAM_CFG2_FRC_SR); - asm volatile("sync;isync"); - total_gb_size_per_controller = 0; for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) { if (!(regs->cs[i].config & 0x80000000)) @@ -548,4 +544,9 @@ step2: clrbits_be32(&ddr->sdram_cfg, 0x2); } #endif /* CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134 */ +#ifdef CONFIG_DEEP_SLEEP + if (is_warm_boot()) + /* exit self-refresh */ + clrbits_be32(&ddr->sdram_cfg_2, SDRAM_CFG2_FRC_SR); +#endif } -- 2.17.1

4 6

Please pull u-boot-marvell/master
by Stefan Roese 27 May '20

27 May '20

Hi Tom, please pull these MVEBU related fixes. ---------------------------------------------------------------- - Fix SPI boot on ds414 (Ezra) - Fix PHY mode definition on armada-3720-uDPU (Jakov) - Convert CRS305-1G-4S to generic version (Luka) ---------------------------------------------------------------- Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=8&view=results Thanks, Stefan The following changes since commit 0ab24c37f03a3a23982edb63d88c4f22bb8bc2c5: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-riscv (2020-05-26 15:27:04 -0400) are available in the Git repository at: git@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to df9ebbe17ea13de4c443849ecf23cba545dd0395: arm: mvebu: Convert CRS305-1G-4S board to CRS3xx-98DX3236 (2020-05-27 07:03:17 +0200) ---------------------------------------------------------------- Ezra Buehler (2): arm: mvebu: ds414: add u-boot,dm-pre-reloc to spi0 arm: mvebu: ds414: define CONFIG_SYS_U_BOOT_OFFS Jakov Petrina (1): arm: mvebu: armada-3720-uDPU: fix PHY mode definition to sgmii-2500 Luka Kovacic (1): arm: mvebu: Convert CRS305-1G-4S board to CRS3xx-98DX3236 arch/arm/dts/armada-3720-uDPU.dts | 4 +- arch/arm/dts/armada-xp-crs305-1g-4s.dts | 103 +------------------ arch/arm/dts/armada-xp-crs305-1g-4s.dtsi | 111 +++++++++++++++++++++ arch/arm/dts/armada-xp-synology-ds414-u-boot.dtsi | 9 ++ arch/arm/mach-mvebu/Kconfig | 10 +- board/mikrotik/crs305-1g-4s/MAINTAINERS | 7 -- .../{crs305-1g-4s => crs3xx-98dx3236}/.gitignore | 0 board/mikrotik/crs3xx-98dx3236/MAINTAINERS | 11 ++ .../{crs305-1g-4s => crs3xx-98dx3236}/Makefile | 2 +- .../{crs305-1g-4s => crs3xx-98dx3236}/README | 12 +-- .../{crs305-1g-4s => crs3xx-98dx3236}/binary.0 | 0 .../crs3xx-98dx3236.c} | 0 .../kwbimage.cfg.in | 2 +- configs/crs305-1g-4s_defconfig | 46 ++++----- .../configs/{crs305-1g-4s.h => crs3xx-98dx3236.h} | 6 +- include/configs/ds414.h | 3 + 16 files changed, 179 insertions(+), 147 deletions(-) create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dtsi create mode 100644 arch/arm/dts/armada-xp-synology-ds414-u-boot.dtsi delete mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS rename board/mikrotik/{crs305-1g-4s => crs3xx-98dx3236}/.gitignore (100%) create mode 100644 board/mikrotik/crs3xx-98dx3236/MAINTAINERS rename board/mikrotik/{crs305-1g-4s => crs3xx-98dx3236}/Makefile (93%) rename board/mikrotik/{crs305-1g-4s => crs3xx-98dx3236}/README (64%) rename board/mikrotik/{crs305-1g-4s => crs3xx-98dx3236}/binary.0 (100%) rename board/mikrotik/{crs305-1g-4s/crs305-1g-4s.c => crs3xx-98dx3236/crs3xx-98dx3236.c} (100%) rename board/mikrotik/{crs305-1g-4s => crs3xx-98dx3236}/kwbimage.cfg.in (75%) rename include/configs/{crs305-1g-4s.h => crs3xx-98dx3236.h} (87%)

2 1

Please pull u-boot-x86
by Bin Meng 27 May '20

27 May '20

Hi Tom, This PR includes the following x86 changes for v2020.07 release: - Use device tree for FSP-M and FSP-S configuration on Intel Apollo Lake - Add SMBIOS cbmem entry parsing for coreboot - Various clean-ups to CBFS implementation The following changes since commit 0ab24c37f03a3a23982edb63d88c4f22bb8bc2c5: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-riscv (2020-05-26 15:27:04 -0400) are available in the git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to 0621b5e1eeb6bcf08b220136f09d433d880f65a5: cbfs: Don't require the CBFS size with cbfs_init_mem() (2020-05-27 14:40:09 +0800) ---------------------------------------------------------------- Bernhard Messerklinger (3): x86: apl: Only load VBT if CONFIG_HAVE_VBT is enabled x86: apl: Use devicetree for FSP-M configuration x86: apl: Use devicetree for FSP-S configuration Christian Gmeiner (2): x86: coreboot: add SMBIOS cbmem entry parsing cbfs: drop file_cbfs_result declaration Simon Glass (14): x86: mtrr: Drop the mask display when changing an mtrr cbfs: Rename the result variable cbfs: Use ulong consistently cbfs: Use bool type for whether initialised cbfs: Adjust return value of file_cbfs_next_file() cbfs: Adjust file_cbfs_load_header() to use cbfs_priv cbfs: Adjust cbfs_load_header_ptr() to use cbfs_priv cbfs: Unify the two header loaders cbfs: Use void * for the position pointers cbfs: Record the start address in cbfs_priv cbfs: Return the error code from file_cbfs_init() cbfs: Change file_cbfs_find_uncached() to return an error cbfs: Allow reading a file from a CBFS given its base addr cbfs: Don't require the CBFS size with cbfs_init_mem() arch/x86/cpu/apollolake/Makefile | 1 + arch/x86/cpu/apollolake/fsp_bindings.c | 1805 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ arch/x86/cpu/apollolake/fsp_m.c | 169 +--------- arch/x86/cpu/apollolake/fsp_s.c | 430 ++------------------------ arch/x86/cpu/coreboot/tables.c | 14 + arch/x86/dts/chromebook_coral.dts | 73 ++++- arch/x86/include/asm/arch-apollolake/fsp/fsp_m_upd.h | 168 ++++++++++ arch/x86/include/asm/arch-apollolake/fsp/fsp_s_upd.h | 202 ++++++++++++ arch/x86/include/asm/arch-apollolake/fsp_bindings.h | 110 +++++++ arch/x86/include/asm/arch-coreboot/sysinfo.h | 2 + arch/x86/include/asm/coreboot_tables.h | 11 + arch/x86/lib/fsp2/fsp_init.c | 3 +- cmd/cbfs.c | 3 +- cmd/x86/mtrr.c | 1 - doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt | 320 +++++++++++++++++++ doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt | 483 +++++++++++++++++++++++++++++ fs/cbfs/cbfs.c | 240 +++++++++------ include/cbfs.h | 42 ++- 18 files changed, 3399 insertions(+), 678 deletions(-) create mode 100644 arch/x86/cpu/apollolake/fsp_bindings.c create mode 100644 arch/x86/include/asm/arch-apollolake/fsp_bindings.h create mode 100644 doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt create mode 100644 doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt Regards, Bin

2 1

uboot and persistent snapshot booting
by Jori van Dam 27 May '20

27 May '20

Hello das U-boot enthusiasts, I've been working on a buildroot OS for the embedded device my company is developing. Currently I'm looking at optimizing the boot process to be as fast as possible. I've read a bunch of articles about snapshot booting and fixed snapshots to improve startup time. One paper in particular ( Hiroki Kaminaga , https://www.kernel.org/doc/ols/2006/ols2006v2-pages-25-34.pdf ) references the use of the command "bootss" which is supposed to be implemented in U-boot. I've looked in my instance of u-boot and in the compilation options of buildroot (for U-boot) and can't find anything that references this command. Also, I can't find any documentation regarding this approach of booting with a snapshot. Is there someone who had some experience/knowledge concerning this who can point me in the right direction? Thank you for your time. Best regards, Jori van Dam Met vriendelijke groet, With kind regards, Jori van Dam Software Developer, Emcatron T: +31(0)252-700224 emcatron.com <http://www.emcatron.com/> ________________________________ Notice: The information contained in this communication may be confidential and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.

2 1

rk3399: SPI boot: Return from ROM unsuccessful (with TPL)
by Jagan Teki 27 May '20

27 May '20

It seems like SPI boot on rk3399 with TPL based is unable to return from ROM or switching to from TPL to SPL is unsuccessful. I have verified board_init_f on spl.c and the control is not even reached here. On the other hand the SPL-alone boot flow works fine from SPI. SPI boot log: U-Boot TPL 2020.07-rc2-00047-gd2ebbbd0e6,`irty (May 20 2020 - 17:22:25) Channel 0: LPDDR4, 50MHz BW=30 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Shze=2048LB Channel 1: LPDR4,50MHz BW=32 CoL=10 Bk=8 CR0 Row=15 CS1 Row=15 CS=2 Die BW=16 Cize=2048LB 256B stride 256B spride lpddr4_set_rate: change freq to 400000000 mhz 0, 1 lpddr4_set_rate8 changE freq to 800000000 mhz 0, 0 Trying to bont from BOOTROM Returning to boot ROM... Any inputs? Jagan.

3 6