[PATCH 00/16] Ten64 updates 2023-07
This is a series of updates for the Ten64 board, that are part of our firmware releases but not yet upstreamed into U-Boot.
Changes of note include:
- Turning on standard boot support
Standard boot improves the user experience over distroboot on Ten64, as we had various hacks in our firmware to solve some corner-case issues (e.g DTB handling) in distroboot, which are not needed with the bootflow system.
- Recognition of the new 'RevD' board variant distributed to OEM customers
- Fixing various boot issues related to FIT images and operating systems running out of the NAND (OpenWrt, recovery environment).
- A better 'opt-out' solution for fsl_setenv_bootcmd for Layerscape platforms booting from TF-A.
This was discussed when the Ten64 was upstreamed into U-Boot. I think declaring fsl_setenv_bootcmd as __weak and allowing individual boards to override is the best way to do this without significant rework. (We actually depend on a similar feature for the DPAA2/MC firmware loading)
Compared to our firmware branch, there is still a few features missing (e.g USB Hub, fan controller and fixes for the VSC8514). Some of these depend on other things (like sorting out device tree schemas) so may not appear in mainline U-Boot for a while yet.
Mathew McBride (16): board: traverse: ten64: recognize board revision D board: traverse: ten64: ensure retimer reset is done on new board revisions board: traverse: ten64: fix DPAA2 (network) DPL corruption issue board: traverse: ten64: update DPAA2 (network) binary path on sdcards board: traverse: ten64: specify bootargs for recovery environment board: traverse: ten64: add NAND based OpenWrt bootcmd board: ten64: add a bootmenu entries for NAND-based entries configs: ten64: enable NVME_PCI board: traverse: ten64: init nvme devices in late boot to ensure bootflow availability board: traverse: ten64: fix allocation order of MAC addresses board: traverse: ten64: set serial# to be 'label' MAC board: ten64: disable watchdog autostart board: traverse: ten64: adopt standard boot defaults arch: arm: fsl-layerscape: allow "opt-out" of fsl_setenv_bootcmd board: ten64: opt out of fsl_setenv_bootcmd board: ten64: strip extra u-boot compatibles from FDT
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +- arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi | 10 +++ board/traverse/ten64/ten64.c | 95 ++++++++++++++++------ configs/ten64_tfa_defconfig | 7 +- include/configs/ten64.h | 34 ++++++-- 5 files changed, 114 insertions(+), 34 deletions(-)
Ten64 board revision D is a variant that removes the USB hub and PCIe expander/switch, but is otherwise compatible with the main production "C" version.
At the same time, revise the printf specifiers (PCB version "1064-0201%s") to reduce the number of string characters related to the boot printout.
Signed-off-by: Mathew McBride matt@traverse.com.au --- board/traverse/ten64/ten64.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 5dfb7165c0..88f22e85d7 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -47,7 +47,9 @@ static void ten64_board_retimer_ds110df410_init(void); enum { TEN64_BOARD_REV_A = 0xFF, TEN64_BOARD_REV_B = 0xFE, - TEN64_BOARD_REV_C = 0xFD + TEN64_BOARD_REV_C = 0xFD, + TEN64_BOARD_REV_D = 0xFC, + TEN64_BOARD_MAX };
#define RESV_MEM_IN_BANK(b) (gd->arch.resv_ram >= base[b] && \ @@ -75,20 +77,24 @@ int checkboard(void)
switch (board_rev) { case TEN64_BOARD_REV_A: - snprintf(boardmodel, 32, "1064-0201A (Alpha)"); + snprintf(boardmodel, 32, "A (Alpha)"); break; case TEN64_BOARD_REV_B: - snprintf(boardmodel, 32, "1064-0201B (Beta)"); + snprintf(boardmodel, 32, "B (Beta)"); break; case TEN64_BOARD_REV_C: - snprintf(boardmodel, 32, "1064-0201C"); + snprintf(boardmodel, 32, "C"); + break; + case TEN64_BOARD_REV_D: + snprintf(boardmodel, 32, "D"); break; default: - snprintf(boardmodel, 32, "1064 Revision %X", (0xFF - board_rev)); + snprintf(boardmodel, 32, " Revision %X", (0xFF - board_rev)); break; }
- printf("Board: %s, boot from ", boardmodel); + printf("Board: 1064-0201%s, boot from ", boardmodel); + if (src == BOOT_SOURCE_SD_MMC) puts("SD card\n"); else if (src == BOOT_SOURCE_QSPI_NOR)
On 7/21/2023 12:39 PM, Mathew McBride wrote:
Ten64 board revision D is a variant that removes the USB hub and PCIe expander/switch, but is otherwise compatible with the main production "C" version.
At the same time, revise the printf specifiers (PCB version "1064-0201%s") to reduce the number of string characters related to the boot printout.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
Board revision C (production) and later require the SFP+ retimer to be turned on (or reset) on boot, by way of issuing a command to the board's microcontroller (via I2C).
The comparison statement here was incorrect, as the board ID decrements every revision (from 0xFF downwards), so this was matching board RevA,B,C instead of Rev >= C.
Another oops that transpired when working on this issue, is that if the board controller is not called (such as CONFIG_TEN64_CONTROLLER=n or earlier board rev), then the retimer udevice was not obtained. So the board version check has to be moved inside board_cycle_retimer (which probes/fetches the retimer device) as well.
Signed-off-by: Mathew McBride matt@traverse.com.au --- board/traverse/ten64/ten64.c | 37 ++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 88f22e85d7..df44baf24f 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -341,20 +341,27 @@ static int board_cycle_retimer(struct udevice **retim_dev) u8 loop; struct udevice *uc_dev; struct udevice *i2cbus; + u32 board_rev = ten64_get_board_rev();
ret = ten64_get_micro_udevice(&uc_dev, &i2cbus); if (ret) return ret;
- ret = dm_i2c_probe(i2cbus, I2C_RETIMER_ADDR, 0, retim_dev); - if (ret == 0) { - puts("(retimer on, resetting...) "); + /* Retimer power cycle not implemented on early board + * revisions/controller firmwares + */ + if (IS_ENABLED(CONFIG_TEN64_CONTROLLER) && + board_rev <= TEN64_BOARD_REV_C) { + ret = dm_i2c_probe(i2cbus, I2C_RETIMER_ADDR, 0, retim_dev); + if (ret == 0) { + puts("(retimer on, resetting...) ");
- ret = misc_call(uc_dev, TEN64_CNTRL_10G_OFF, NULL, 0, NULL, 0); - mdelay(1000); - } + ret = misc_call(uc_dev, TEN64_CNTRL_10G_OFF, NULL, 0, NULL, 0); + mdelay(1000); + }
- ret = misc_call(uc_dev, TEN64_CNTRL_10G_ON, NULL, 0, NULL, 0); + ret = misc_call(uc_dev, TEN64_CNTRL_10G_ON, NULL, 0, NULL, 0); + }
// Wait for retimer to come back for (loop = 0; loop < 5; loop++) { @@ -375,19 +382,13 @@ static void ten64_board_retimer_ds110df410_init(void) u8 reg; int ret; struct udevice *retim_dev; - u32 board_rev = ten64_get_board_rev();
puts("Retimer: "); - /* Retimer power cycle not implemented on early board - * revisions/controller firmwares - */ - if (IS_ENABLED(CONFIG_TEN64_CONTROLLER) && - board_rev >= TEN64_BOARD_REV_C) { - ret = board_cycle_retimer(&retim_dev); - if (ret) { - puts("Retimer power on failed\n"); - return; - } + + ret = board_cycle_retimer(&retim_dev); + if (ret) { + puts("Retimer power on failed\n"); + return; }
/* Access to Control/Shared register */
On 7/21/2023 12:39 PM, Mathew McBride wrote:
Board revision C (production) and later require the SFP+ retimer to be turned on (or reset) on boot, by way of issuing a command to the board's microcontroller (via I2C).
The comparison statement here was incorrect, as the board ID decrements every revision (from 0xFF downwards), so this was matching board RevA,B,C instead of Rev >= C.
Another oops that transpired when working on this issue, is that if the board controller is not called (such as CONFIG_TEN64_CONTROLLER=n or earlier board rev), then the retimer udevice was not obtained. So the board version check has to be moved inside board_cycle_retimer (which probes/fetches the retimer device) as well.
Signed-off-by: Mathew McBride matt@traverse.com.au
board/traverse/ten64/ten64.c | 37 ++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 88f22e85d7..df44baf24f 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -341,20 +341,27 @@ static int board_cycle_retimer(struct udevice **retim_dev) u8 loop; struct udevice *uc_dev; struct udevice *i2cbus;
u32 board_rev = ten64_get_board_rev();
ret = ten64_get_micro_udevice(&uc_dev, &i2cbus); if (ret) return ret;
- ret = dm_i2c_probe(i2cbus, I2C_RETIMER_ADDR, 0, retim_dev);
- if (ret == 0) {
puts("(retimer on, resetting...) ");
- /* Retimer power cycle not implemented on early board
* revisions/controller firmwares*/- if (IS_ENABLED(CONFIG_TEN64_CONTROLLER) &&
board_rev <= TEN64_BOARD_REV_C) {ret = dm_i2c_probe(i2cbus, I2C_RETIMER_ADDR, 0, retim_dev);if (ret == 0) {
'!ret'. Please run checkpatch.pl.
puts("(retimer on, resetting...) ");
ret = misc_call(uc_dev, TEN64_CNTRL_10G_OFF, NULL, 0, NULL, 0);mdelay(1000);- }
ret = misc_call(uc_dev, TEN64_CNTRL_10G_OFF, NULL, 0, NULL, 0);
return value not checked?
mdelay(1000);}
- ret = misc_call(uc_dev, TEN64_CNTRL_10G_ON, NULL, 0, NULL, 0);
ret = misc_call(uc_dev, TEN64_CNTRL_10G_ON, NULL, 0, NULL, 0);
This is called whether dm_i2c_probe returns failure or success? And return value not checked?
Regards, Peng.
}
// Wait for retimer to come back for (loop = 0; loop < 5; loop++) {
@@ -375,19 +382,13 @@ static void ten64_board_retimer_ds110df410_init(void) u8 reg; int ret; struct udevice *retim_dev;
u32 board_rev = ten64_get_board_rev();
puts("Retimer: ");
/* Retimer power cycle not implemented on early board
* revisions/controller firmwares*/if (IS_ENABLED(CONFIG_TEN64_CONTROLLER) &&
board_rev >= TEN64_BOARD_REV_C) {ret = board_cycle_retimer(&retim_dev);if (ret) {puts("Retimer power on failed\n");return;}
ret = board_cycle_retimer(&retim_dev);
if (ret) {
puts("Retimer power on failed\n");return;}
/* Access to Control/Shared register */
The DPAA2 DPL (data plane layout) file was previously being loaded into 0x80300000, and set to be applied just before hand off to the kernel.
When a FIT image with a load_address of 0x80000000 was booted with bootm, the DPL in memory was overwritten.
Move the DPL load to 0x8E000000 (196MiB away from 0x80000000, and below the other typical load addr of 0x90000000).
Ideally in the future, the DPL lazyapply command ("fsl_mc lazyapply DPL $dpl_addr") should be set to load the DPL contents into a memory area owned by U-Boot.
Signed-off-by: Mathew McBride matt@traverse.com.au --- include/configs/ten64.h | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/configs/ten64.h b/include/configs/ten64.h index e86c163132..1601fb733e 100644 --- a/include/configs/ten64.h +++ b/include/configs/ten64.h @@ -19,11 +19,14 @@ "sf probe 0:0 && sf read 0x80000000 0x300000 0x200000 &&" \ "sf read 0x80200000 0x5C0000 0x40000 &&" \ "fsl_mc start mc 0x80000000 0x80200000 && " \ - "sf read 0x80300000 0x580000 0x40000 && fsl_mc lazyapply DPL 0x80300000\0" + "sf read 0x8E000000 0x580000 0x40000 && fsl_mc lazyapply DPL 0x8E000000 && "\ + "echo 'default DPL loaded'\0" #define SD_MC_INIT_CMD \ "mmcinfo; fatload mmc 0 0x80000000 mcfirmware/mc_ls1088a.itb; "\ "fatload mmc 0 0x80200000 dpaa2config/dpc.0x1D-0x0D.dtb; "\ - "fsl_mc start mc 0x80000000 0x80200000\0" + "fsl_mc start mc 0x80000000 0x80200000 && " \ + "fatload mmc 0 0x8E000000 dpaa2config/eth-dpl-all.dtb && " \ + "fsl_mc lazyapply DPL 0x8E000000 && echo 'default DPL loaded'\0"
#define BOOT_TARGET_DEVICES(func) \ func(NVME, nvme, 0) \ @@ -45,7 +48,6 @@ BOOTENV \ "load_efi_dtb=mtd read devicetree $fdt_addr_r && fdt addr $fdt_addr_r && " \ "fdt resize && fdt boardsetup\0" \ - "bootcmd_recovery=mtd read recovery 0xa0000000; mtd read dpl 0x80100000 && " \ - "fsl_mc apply DPL 0x80100000 && bootm 0xa0000000#ten64\0" + "bootcmd_recovery=mtd read recovery 0xa0000000; && bootm 0xa0000000#ten64\0"
#endif /* __TEN64_H */
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The DPAA2 DPL (data plane layout) file was previously being loaded into 0x80300000, and set to be applied just before hand off to the kernel.
When a FIT image with a load_address of 0x80000000 was booted with bootm, the DPL in memory was overwritten.
Move the DPL load to 0x8E000000 (196MiB away from 0x80000000, and below the other typical load addr of 0x90000000).
Ideally in the future, the DPL lazyapply command ("fsl_mc lazyapply DPL $dpl_addr") should be set to load the DPL contents into a memory area owned by U-Boot.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
Change the firmware on microSD path to "firmware/traverse/ten64" as per EBBR section 4.2[1].
The Traverse firmware tools now locate the DPAA2 firmware and configuration files under that path on the rescue SD card image. If a user then installs a standard Linux distribution over the top of that sdcard, (in theory) it will be left alone by distribution boot tooling.
Signed-off-by: Mathew McBride matt@traverse.com.au
[1] https://arm-software.github.io/ebbr/index.html#firmware-partition-filesystem --- include/configs/ten64.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/configs/ten64.h b/include/configs/ten64.h index 1601fb733e..63fbafd132 100644 --- a/include/configs/ten64.h +++ b/include/configs/ten64.h @@ -15,6 +15,8 @@ #define QSPI_NOR_BOOTCOMMAND "run distro_bootcmd" #define SD_BOOTCOMMAND "run distro_bootcmd"
+#define SD_FIRMWARE_PATH "firmware/traverse/ten64/" + #define QSPI_MC_INIT_CMD \ "sf probe 0:0 && sf read 0x80000000 0x300000 0x200000 &&" \ "sf read 0x80200000 0x5C0000 0x40000 &&" \ @@ -22,10 +24,10 @@ "sf read 0x8E000000 0x580000 0x40000 && fsl_mc lazyapply DPL 0x8E000000 && "\ "echo 'default DPL loaded'\0" #define SD_MC_INIT_CMD \ - "mmcinfo; fatload mmc 0 0x80000000 mcfirmware/mc_ls1088a.itb; "\ - "fatload mmc 0 0x80200000 dpaa2config/dpc.0x1D-0x0D.dtb; "\ + "mmcinfo; fatload mmc 0 0x80000000 " SD_FIRMWARE_PATH "mc_ls1088a.itb; "\ + "fatload mmc 0 0x80200000 " SD_FIRMWARE_PATH "dpc.0x1D-0x0D.dtb; "\ "fsl_mc start mc 0x80000000 0x80200000 && " \ - "fatload mmc 0 0x8E000000 dpaa2config/eth-dpl-all.dtb && " \ + "fatload mmc 0 0x8E000000 " SD_FIRMWARE_PATH "eth-dpl-all.dtb && " \ "fsl_mc lazyapply DPL 0x8E000000 && echo 'default DPL loaded'\0"
#define BOOT_TARGET_DEVICES(func) \
On 7/21/2023 12:39 PM, Mathew McBride wrote:
Change the firmware on microSD path to "firmware/traverse/ten64" as per EBBR section 4.2[1].
The Traverse firmware tools now locate the DPAA2 firmware and configuration files under that path on the rescue SD card image. If a user then installs a standard Linux distribution over the top of that sdcard, (in theory) it will be left alone by distribution boot tooling.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
The recovery environment[1] on the Ten64 is a OpenWrt- based ramdisk stored on the NAND intended to help with system setup tasks.
Before the bootargs were not being set for the recovery command, relying instead on the existing bootargs variable.
Ensure the bootargs are set correctly prior to booting recovery.
Signed-off-by: Mathew McBride matt@traverse.com.au
[1] https://ten64doc.traverse.com.au/software/recovery/ --- include/configs/ten64.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/configs/ten64.h b/include/configs/ten64.h index 63fbafd132..1b8b27c230 100644 --- a/include/configs/ten64.h +++ b/include/configs/ten64.h @@ -50,6 +50,7 @@ BOOTENV \ "load_efi_dtb=mtd read devicetree $fdt_addr_r && fdt addr $fdt_addr_r && " \ "fdt resize && fdt boardsetup\0" \ - "bootcmd_recovery=mtd read recovery 0xa0000000; && bootm 0xa0000000#ten64\0" + "bootcmd_recovery=mtd read recovery 0xa0000000 && " \ + "setenv bootargs "earlycon root=/dev/ram0 ramdisk_size=0x3000000" && bootm 0xa0000000#ten64\0"
#endif /* __TEN64_H */
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The recovery environment[1] on the Ten64 is a OpenWrt- based ramdisk stored on the NAND intended to help with system setup tasks.
Before the bootargs were not being set for the recovery command, relying instead on the existing bootargs variable.
Ensure the bootargs are set correctly prior to booting recovery.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
The default Ten64 MTD configuration reserves two ubifs partitions for OpenWrt residing on NAND flash. Add the bootcmd for this system into the default environment.
Signed-off-by: Mathew McBride matt@traverse.com.au --- include/configs/ten64.h | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/include/configs/ten64.h b/include/configs/ten64.h index 1b8b27c230..f9e800d4b6 100644 --- a/include/configs/ten64.h +++ b/include/configs/ten64.h @@ -39,6 +39,11 @@ func(PXE, pxe, 0) #include <config_distro_bootcmd.h>
+#define OPENWRT_NAND_BOOTCMD \ + "bootcmd_openwrt_nand=ubi part ubi${openwrt_active_sys} && "\ + "ubi read $load_addr kernel && " \ + "setenv bootargs "root=/dev/ubiblock0_1 earlycon ubi.mtd=ubi${openwrt_active_sys}" &&"\ + "bootm $load_addr#ten64\0" #undef CFG_EXTRA_ENV_SETTINGS
#define CFG_EXTRA_ENV_SETTINGS \ @@ -48,6 +53,8 @@ "kernel_addr_r=0x81000000\0" \ "load_addr=0xa0000000\0" \ BOOTENV \ + OPENWRT_NAND_BOOTCMD \ + "openwrt_active_sys=a\0" \ "load_efi_dtb=mtd read devicetree $fdt_addr_r && fdt addr $fdt_addr_r && " \ "fdt resize && fdt boardsetup\0" \ "bootcmd_recovery=mtd read recovery 0xa0000000 && " \
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The default Ten64 MTD configuration reserves two ubifs partitions for OpenWrt residing on NAND flash. Add the bootcmd for this system into the default environment.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
The recovery-firmware and OpenWrt-NAND do not yet have bootflow /bootstd entrypoints, so add bootmenu entries to make them accessible.
Signed-off-by: Mathew McBride matt@traverse.com.au --- include/configs/ten64.h | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/configs/ten64.h b/include/configs/ten64.h index f9e800d4b6..d2bef9b6e5 100644 --- a/include/configs/ten64.h +++ b/include/configs/ten64.h @@ -46,6 +46,15 @@ "bootm $load_addr#ten64\0" #undef CFG_EXTRA_ENV_SETTINGS
+#if CONFIG_IS_ENABLED(CMD_BOOTMENU) +#define DEFAULT_MENU_ENTRIES \ + "bootmenu_0=Continue standard boot=run bootcmd\0" \ + "bootmenu_1=Boot into recovery=run bootcmd_recovery\0" \ + "bootmenu_2=Boot OpenWrt from NAND=run bootcmd_openwrt_nand\0" +#else +#define DEFAULT_MENU_ENTRIES "" +#endif /* CONFIG_IS_ENABLED(CMD_BOOTMENU) */ + #define CFG_EXTRA_ENV_SETTINGS \ "BOARD=ten64\0" \ "fdt_addr_r=0x90000000\0" \ @@ -57,7 +66,8 @@ "openwrt_active_sys=a\0" \ "load_efi_dtb=mtd read devicetree $fdt_addr_r && fdt addr $fdt_addr_r && " \ "fdt resize && fdt boardsetup\0" \ - "bootcmd_recovery=mtd read recovery 0xa0000000 && " \ - "setenv bootargs "earlycon root=/dev/ram0 ramdisk_size=0x3000000" && bootm 0xa0000000#ten64\0" + "bootcmd_recovery=mtd read recovery 0xa0000000; " \ + "setenv bootargs "earlycon root=/dev/ram0 ramdisk_size=0x3000000" && bootm 0xa0000000#ten64\0" \ + DEFAULT_MENU_ENTRIES
#endif /* __TEN64_H */
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The recovery-firmware and OpenWrt-NAND do not yet have bootflow /bootstd entrypoints, so add bootmenu entries to make them accessible.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
This restores NVMe functionality after PCI(e) NVMe support was split out from the NVMe driver.
Signed-off-by: Mathew McBride matt@traverse.com.au --- configs/ten64_tfa_defconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/configs/ten64_tfa_defconfig b/configs/ten64_tfa_defconfig index 9797a343e5..7d63ee40e9 100644 --- a/configs/ten64_tfa_defconfig +++ b/configs/ten64_tfa_defconfig @@ -76,6 +76,8 @@ CONFIG_SYS_MEMAC_LITTLE_ENDIAN=y CONFIG_E1000=y CONFIG_MII=y CONFIG_NVME=y +CONFIG_NVME_PCI=y +CONFIG_PCI=y CONFIG_DM_PCI_COMPAT=y CONFIG_PCIE_LAYERSCAPE_RC=y CONFIG_DM_RTC=y
On 7/21/2023 12:39 PM, Mathew McBride wrote:
This restores NVMe functionality after PCI(e) NVMe support was split out from the NVMe driver.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
Ensure nvme devices are scanned before reaching the shell, otherwise extra user intervention ("nvme scan") is required before they are visible to bootdev/bootflow.
Signed-off-by: Mathew McBride matt@traverse.com.au --- board/traverse/ten64/ten64.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index df44baf24f..39f0d107cd 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -31,6 +31,7 @@ #include <asm/arch/fsl_serdes.h> #include <asm/arch/soc.h> #include <asm/arch-fsl-layerscape/fsl_icid.h> +#include <nvme.h>
#include <fsl_immap.h>
@@ -184,6 +185,11 @@ void fdt_fixup_board_enet(void *fdt) int fsl_board_late_init(void) { ten64_board_retimer_ds110df410_init(); + + /* Ensure nvme storage devices are available to bootflow */ + if (IS_ENABLED(CONFIG_NVME)) + nvme_scan_namespace(); + return 0; }
@@ -444,3 +450,4 @@ static void ten64_board_retimer_ds110df410_init(void)
puts("OK\n"); } +
On 7/21/2023 12:39 PM, Mathew McBride wrote:
Ensure nvme devices are scanned before reaching the shell, otherwise extra user intervention ("nvme scan") is required before they are visible to bootdev/bootflow.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
On Ten64 boards, the "serial number" is the MAC address of the first Gigabit Ethernet interface (labelled GE0 on the appliance), and counted up from there.
The previous logic did not take into account U-Boot's ordering of the network interfaces. By setting aliases/ethernetX in the device tree we can ensure the U-Boot 'ethX' is the same as the labelled port order on the unit, as well as the one adopted by Linux.
Signed-off-by: Mathew McBride matt@traverse.com.au --- arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi | 10 ++++++++++ board/traverse/ten64/ten64.c | 4 ++-- 2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi b/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi index 89566bf849..4e6700d586 100644 --- a/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi +++ b/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi @@ -6,6 +6,16 @@ /{ aliases { spi0 = &qspi; + ethernet0 = &dpmac7; + ethernet1 = &dpmac8; + ethernet2 = &dpmac9; + ethernet3 = &dpmac10; + ethernet4 = &dpmac3; + ethernet5 = &dpmac4; + ethernet6 = &dpmac5; + ethernet7 = &dpmac6; + ethernet8 = &dpmac2; + ethernet9 = &dpmac1; }; };
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 39f0d107cd..0febc0baf0 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -328,8 +328,8 @@ static void ten64_set_macaddrs_from_board_info(struct t64uc_board_info *boardinf this_dpmac_num = allocation_order[intfidx]; printf("DPMAC%d: %s\n", this_dpmac_num, ethaddr); snprintf(enetvar, 10, - (this_dpmac_num != 1) ? "eth%daddr" : "ethaddr", - this_dpmac_num - 1); + (intfidx != 0) ? "eth%daddr" : "ethaddr", + intfidx); macaddr++;
if (!env_get(enetvar))
The GE0 (first Gigabit Ethernet interface) is used as the 'serial number' for the board and appliance.
To ensure the 'true' board S/N is available regardless of how the DPAA2 subsystem is configured, use serial# so it is passed in the device tree.
Signed-off-by: Mathew McBride matt@traverse.com.au --- board/traverse/ten64/ten64.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 0febc0baf0..17057966c8 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -296,6 +296,7 @@ static void ten64_set_macaddrs_from_board_info(struct t64uc_board_info *boardinf { char ethaddr[18]; char enetvar[10]; + char serial[18]; u8 intfidx, this_dpmac_num; u64 macaddr = 0; /* We will copy the MAC address returned from the @@ -316,6 +317,19 @@ static void ten64_set_macaddrs_from_board_info(struct t64uc_board_info *boardinf */ macaddr = __be64_to_cpu(macaddr);
+ /* Set serial# to GE0/DPMAC7 MAC address + * (Matches the labels on the board and appliance) + */ + snprintf(serial, 18, "%02X%02X%02X%02X%02X%02X", + MACADDRBITS(macaddr, 40), + MACADDRBITS(macaddr, 32), + MACADDRBITS(macaddr, 24), + MACADDRBITS(macaddr, 16), + MACADDRBITS(macaddr, 8), + MACADDRBITS(macaddr, 0)); + if (!env_get("serial#")) + env_set("serial#", serial); + for (intfidx = 0; intfidx < 10; intfidx++) { snprintf(ethaddr, 18, "%02X:%02X:%02X:%02X:%02X:%02X", MACADDRBITS(macaddr, 40),
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The GE0 (first Gigabit Ethernet interface) is used as the 'serial number' for the board and appliance.
To ensure the 'true' board S/N is available regardless of how the DPAA2 subsystem is configured, use serial# so it is passed in the device tree.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
The watchdog driver was previously enabled but not used until U-Boot's fsl-ls1088a.dtsi was updated to describe them.
Some Linux distributions (e.g Debian 11) do not engage the SP805 watchdogs, causing unexpected resets after boot.
To conserve the user experience, turn off the autostart, and we will provide a mechanism to turn them on at boot via env vars.
Signed-off-by: Mathew McBride matt@traverse.com.au --- configs/ten64_tfa_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/ten64_tfa_defconfig b/configs/ten64_tfa_defconfig index 7d63ee40e9..796a826b72 100644 --- a/configs/ten64_tfa_defconfig +++ b/configs/ten64_tfa_defconfig @@ -96,6 +96,7 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_GADGET=y +# CONFIG_WATCHDOG_AUTOSTART is not set CONFIG_WDT=y CONFIG_WDT_SP805=y CONFIG_TPM=y
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The watchdog driver was previously enabled but not used until U-Boot's fsl-ls1088a.dtsi was updated to describe them.
Some Linux distributions (e.g Debian 11) do not engage the SP805 watchdogs, causing unexpected resets after boot.
To conserve the user experience, turn off the autostart, and we will provide a mechanism to turn them on at boot via env vars.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
With the previous updates to the device tree, Ten64 can use Standard Boot 'out of the box'.
Signed-off-by: Mathew McBride matt@traverse.com.au --- configs/ten64_tfa_defconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configs/ten64_tfa_defconfig b/configs/ten64_tfa_defconfig index 796a826b72..78e05cb4b6 100644 --- a/configs/ten64_tfa_defconfig +++ b/configs/ten64_tfa_defconfig @@ -22,7 +22,9 @@ CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_DISTRO_DEFAULTS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0500 ramdisk_size=0x3000000 default_hugepagesz=2m hugepagesz=2m hugepages=256" -# CONFIG_USE_BOOTCOMMAND is not set +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y +CONFIG_BOOTSTD_BOOTCOMMAND=y CONFIG_LOGLEVEL=7 # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y
On 7/21/2023 12:39 PM, Mathew McBride wrote:
With the previous updates to the device tree, Ten64 can use Standard Boot 'out of the box'.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
Allow individual Layerscape boards to opt-out of fsl_setenv_bootcmd by declaring the original function as weak.
fsl_setenv_bootcmd is used to change the bootcmd based on the TF-A boot source (e.g QSPI vs SD/MMC) for reasons including secure boot / integrity measurements and DPAA2 configuration loading. See previous discussion at [1].
On the Ten64 board, our bootcmd is the same across all TF-A boot sources so we don't want this behaviour.
Signed-off-by: Mathew McBride matt@traverse.com.au
[1] https://patchwork.ozlabs.org/project/uboot/patch/20211110044639.7070-3-matt@... --- arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c b/arch/arm/cpu/armv8/fsl-layerscape/soc.c index 359cbc0430..577a0b6098 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c @@ -810,7 +810,7 @@ int qspi_ahb_init(void) #ifdef CONFIG_TFABOOT #define MAX_BOOTCMD_SIZE 512
-int fsl_setenv_bootcmd(void) +__weak int fsl_setenv_bootcmd(void) { int ret; enum boot_src src = get_boot_src();
On 7/21/2023 12:39 PM, Mathew McBride wrote:
Allow individual Layerscape boards to opt-out of fsl_setenv_bootcmd by declaring the original function as weak.
fsl_setenv_bootcmd is used to change the bootcmd based on the TF-A boot source (e.g QSPI vs SD/MMC) for reasons including secure boot / integrity measurements and DPAA2 configuration loading. See previous discussion at [1].
On the Ten64 board, our bootcmd is the same across all TF-A boot sources so we don't want this behaviour.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
Our bootcmd is the same regardless of where the SoC loaded it's code from, so we don't want fsl_setenv_bootcmd to do anything.
Signed-off-by: Mathew McBride matt@traverse.com.au --- board/traverse/ten64/ten64.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 17057966c8..3cb8bad855 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -465,3 +465,12 @@ static void ten64_board_retimer_ds110df410_init(void) puts("OK\n"); }
+/* Opt out of the fsl_setenv_bootcmd + * in arch/arm/cpu/armv8/fsl-layerscape/soc.c + * which is invoked by board_late_init. + */ +int fsl_setenv_bootcmd(void) +{ + return 0; +} +
On 7/21/2023 12:39 PM, Mathew McBride wrote:
Our bootcmd is the same regardless of where the SoC loaded it's code from, so we don't want fsl_setenv_bootcmd to do anything.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
The u-boot version of the LS1088A device tree has an extra compatible (simple-mfd) added to &fsl_mc to facilitate usage with U-Boot's device model.
Unfortunately FreeBSD will only match the single "fsl,qoriq-mc" exactly when the node is a "bus" object, so we need to strip out the extra compatible before presenting it to the operating system.
Signed-off-by: Mathew McBride matt@traverse.com.au --- board/traverse/ten64/ten64.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c index 3cb8bad855..52daae6e24 100644 --- a/board/traverse/ten64/ten64.c +++ b/board/traverse/ten64/ten64.c @@ -174,6 +174,12 @@ void fdt_fixup_board_enet(void *fdt) return; }
+ /* In the U-Boot FDT, a 'simple-mfd' compatible is added. + * Remove this as FreeBSD will only match "fsl,qoriq-mc" + * exactly on the DPAA2 bus/MC node. + */ + fdt_setprop(fdt, offset, "compatible", "fsl,qoriq-mc", 12); + if (get_mc_boot_status() == 0 && (is_lazy_dpl_addr_valid() || get_dpl_apply_status() == 0)) fdt_status_okay(fdt, offset);
On 7/21/2023 12:39 PM, Mathew McBride wrote:
The u-boot version of the LS1088A device tree has an extra compatible (simple-mfd) added to &fsl_mc to facilitate usage with U-Boot's device model.
Unfortunately FreeBSD will only match the single "fsl,qoriq-mc" exactly when the node is a "bus" object, so we need to strip out the extra compatible before presenting it to the operating system.
Signed-off-by: Mathew McBridematt@traverse.com.au
Reviewed-by: Peng Fan peng.fan@nxp.com
On Fri, 21 Jul 2023 04:39:15 +0000, Mathew McBride wrote:
This is a series of updates for the Ten64 board, that are part of our firmware releases but not yet upstreamed into U-Boot.
Changes of note include:
- Turning on standard boot support
[...]
Applied to u-boot/master, thanks!
On Fri, Aug 4, 2023, at 12:37 AM, Tom Rini wrote:
On Fri, 21 Jul 2023 04:39:15 +0000, Mathew McBride wrote:
This is a series of updates for the Ten64 board, that are part of our firmware releases but not yet upstreamed into U-Boot.
Changes of note include:
- Turning on standard boot support
[...]
Applied to u-boot/master, thanks!
Oops, I was still working on a v2 of the series to resolve the issues Peng identified with the retimer reset. The new patch "board: ten64: add missing error checks for retimer power on" should be applied to fix it.
-- Tom
participants (3)
-
Mathew McBride -
Peng Fan -
Tom Rini