[PATCH 00/16] Ten64 updates 2023-07

[PATCH 00/16] Ten64 updates 2023-07

[Mathew McBride]

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(-)

-- 
2.30.1

[PATCH 01/16] board: traverse: ten64: recognize board revision D

[Mathew McBride]

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)
-- 
2.30.1

[PATCH 02/16] board: traverse: ten64: ensure retimer reset is done on new board revisions

[Mathew McBride]

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 */
-- 
2.30.1

[PATCH 03/16] board: traverse: ten64: fix DPAA2 (network) DPL corruption issue

[Mathew McBride]

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 */
-- 
2.30.1

[PATCH 04/16] board: traverse: ten64: update DPAA2 (network) binary path on sdcards

[Mathew McBride]

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) \
-- 
2.30.1

[PATCH 05/16] board: traverse: ten64: specify bootargs for recovery environment

[Mathew McBride]

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 */
-- 
2.30.1

[PATCH 06/16] board: traverse: ten64: add NAND based OpenWrt bootcmd

[Mathew McBride]

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 && " \
-- 
2.30.1

[PATCH 07/16] board: ten64: add a bootmenu entries for NAND-based entries

[Mathew McBride]

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 */
-- 
2.30.1

[PATCH 08/16] configs: ten64: enable NVME_PCI

[Mathew McBride]

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
-- 
2.30.1

[PATCH 09/16] board: traverse: ten64: init nvme devices in late boot to ensure bootflow availability

[Mathew McBride]

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");
 }
+
-- 
2.30.1

[PATCH 10/16] board: traverse: ten64: fix allocation order of MAC addresses

[Mathew McBride]

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))
-- 
2.30.1

[PATCH 11/16] board: traverse: ten64: set serial# to be 'label' MAC

[Mathew McBride]

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),
-- 
2.30.1

[PATCH 12/16] board: ten64: disable watchdog autostart

[Mathew McBride]

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
-- 
2.30.1

[PATCH 13/16] board: traverse: ten64: adopt standard boot defaults

[Mathew McBride]

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
-- 
2.30.1

[PATCH 14/16] arch: arm: fsl-layerscape: allow "opt-out" of fsl_setenv_bootcmd

[Mathew McBride]

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@traverse.com.au/#2790037
---
 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();
-- 
2.30.1

[PATCH 15/16] board: ten64: opt out of fsl_setenv_bootcmd

[Mathew McBride]

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;
+}
+
-- 
2.30.1

[PATCH 16/16] board: ten64: strip extra u-boot compatibles from FDT

[Mathew McBride]

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);
-- 
2.30.1

Re: [PATCH 02/16] board: traverse: ten64: ensure retimer reset is done on new board revisions

[Peng Fan]

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 */

Re: [PATCH 03/16] board: traverse: ten64: fix DPAA2 (network) DPL corruption issue

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 04/16] board: traverse: ten64: update DPAA2 (network) binary path on sdcards

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 05/16] board: traverse: ten64: specify bootargs for recovery environment

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 06/16] board: traverse: ten64: add NAND based OpenWrt bootcmd

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 07/16] board: ten64: add a bootmenu entries for NAND-based entries

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 08/16] configs: ten64: enable NVME_PCI

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 09/16] board: traverse: ten64: init nvme devices in late boot to ensure bootflow availability

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 11/16] board: traverse: ten64: set serial# to be 'label' MAC

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 12/16] board: ten64: disable watchdog autostart

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 13/16] board: traverse: ten64: adopt standard boot defaults

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 14/16] arch: arm: fsl-layerscape: allow "opt-out" of fsl_setenv_bootcmd

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 15/16] board: ten64: opt out of fsl_setenv_bootcmd

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 16/16] board: ten64: strip extra u-boot compatibles from FDT

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 01/16] board: traverse: ten64: recognize board revision D

[Peng Fan]

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 McBride<matt@traverse.com.au>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH 00/16] Ten64 updates 2023-07

[Tom Rini]

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!

-- 
Tom

Re: [PATCH 00/16] Ten64 updates 2023-07

[Mathew McBride]

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
> 
>