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

2023-08-06 Thread 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
> 
> 


[PATCH] board: ten64: add missing error checks for retimer power on

2023-08-06 Thread Mathew McBride
The retimer reset/power on logic was changed in a recent commit,
however, it neglected to check if the commands sent to the
board microcontroller (to control power to the retimer chip)
actually completed.

Add return checks for these operations so any failures will
be reported to the user.

Signed-off-by: Mathew McBride 
Fixes: 7a041fea2 ("board: traverse: ten64: ensure retimer reset
is done on new board revisions")
---
 board/traverse/ten64/ten64.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/traverse/ten64/ten64.c b/board/traverse/ten64/ten64.c
index 52daae6e24..df9f0afe1a 100644
--- a/board/traverse/ten64/ten64.c
+++ b/board/traverse/ten64/ten64.c
@@ -383,10 +383,15 @@ static int board_cycle_retimer(struct udevice **retim_dev)
puts("(retimer on, resetting...) ");
 
ret = misc_call(uc_dev, TEN64_CNTRL_10G_OFF, NULL, 0, 
NULL, 0);
+   if (ret)
+   return ret;
mdelay(1000);
}
 
+   /* Turn on the retimer */
ret = misc_call(uc_dev, TEN64_CNTRL_10G_ON, NULL, 0, NULL, 0);
+   if (ret)
+   return ret;
}
 
// Wait for retimer to come back
-- 
2.30.1



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

2023-07-20 Thread Mathew McBride
The u-boot version of the LS1088A device tree has
an extra compatible (simple-mfd) added to _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 
---
 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



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

2023-07-20 Thread 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 
---
 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 14/16] arch: arm: fsl-layerscape: allow "opt-out" of fsl_setenv_bootcmd

2023-07-20 Thread 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 

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/2020044639.7070-3-m...@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 13/16] board: traverse: ten64: adopt standard boot defaults

2023-07-20 Thread Mathew McBride
With the previous updates to the device tree, Ten64
can use Standard Boot 'out of the box'.

Signed-off-by: Mathew McBride 
---
 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=0x300 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 12/16] board: ten64: disable watchdog autostart

2023-07-20 Thread 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 
---
 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 11/16] board: traverse: ten64: set serial# to be 'label' MAC

2023-07-20 Thread 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 
---
 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 10/16] board: traverse: ten64: fix allocation order of MAC addresses

2023-07-20 Thread 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 
---
 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 = 
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   ethernet3 = 
+   ethernet4 = 
+   ethernet5 = 
+   ethernet6 = 
+   ethernet7 = 
+   ethernet8 = 
+   ethernet9 = 
};
 };
 
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 09/16] board: traverse: ten64: init nvme devices in late boot to ensure bootflow availability

2023-07-20 Thread 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 
---
 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 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -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 08/16] configs: ten64: enable NVME_PCI

2023-07-20 Thread Mathew McBride
This restores NVMe functionality after PCI(e) NVMe support
was split out from the NVMe driver.

Signed-off-by: Mathew McBride 
---
 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 07/16] board: ten64: add a bootmenu entries for NAND-based entries

2023-07-20 Thread 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 
---
 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=0x9000\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 0xa000 && " \
-   "setenv bootargs \"earlycon root=/dev/ram0 ramdisk_size=0x300\" && 
bootm 0xa000#ten64\0"
+   "bootcmd_recovery=mtd read recovery 0xa000;  " \
+   "setenv bootargs \"earlycon root=/dev/ram0 ramdisk_size=0x300\" && 
bootm 0xa000#ten64\0" \
+   DEFAULT_MENU_ENTRIES
 
 #endif /* __TEN64_H */
-- 
2.30.1



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

2023-07-20 Thread 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 
---
 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 
 
+#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=0x8100\0"\
"load_addr=0xa000\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 0xa000 && " \
-- 
2.30.1



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

2023-07-20 Thread 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 

[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 0xa000; && bootm 
0xa000#ten64\0"
+   "bootcmd_recovery=mtd read recovery 0xa000 && " \
+   "setenv bootargs \"earlycon root=/dev/ram0 ramdisk_size=0x300\" && 
bootm 0xa000#ten64\0"
 
 #endif /* __TEN64_H */
-- 
2.30.1



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

2023-07-20 Thread 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 

[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 0x8000 0x30 0x20 &&"   \
"sf read 0x8020 0x5C 0x4 &&"
\
@@ -22,10 +24,10 @@
"sf read 0x8E00 0x58 0x4 && fsl_mc lazyapply DPL 0x8E00 
&& "\
"echo 'default DPL loaded'\0"
 #define SD_MC_INIT_CMD \
-   "mmcinfo; fatload mmc 0 0x8000 mcfirmware/mc_ls1088a.itb; "\
-   "fatload mmc 0 0x8020 dpaa2config/dpc.0x1D-0x0D.dtb; "\
+   "mmcinfo; fatload mmc 0 0x8000 " SD_FIRMWARE_PATH "mc_ls1088a.itb; 
"\
+   "fatload mmc 0 0x8020 " SD_FIRMWARE_PATH "dpc.0x1D-0x0D.dtb; "\
"fsl_mc start mc 0x8000 0x8020 && " \
-   "fatload mmc 0 0x8E00 dpaa2config/eth-dpl-all.dtb && " \
+   "fatload mmc 0 0x8E00 " SD_FIRMWARE_PATH "eth-dpl-all.dtb && " \
"fsl_mc lazyapply DPL 0x8E00 && echo 'default DPL loaded'\0"
 
 #define BOOT_TARGET_DEVICES(func) \
-- 
2.30.1



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

2023-07-20 Thread Mathew McBride
The DPAA2 DPL (data plane layout) file was previously
being loaded into 0x8030, and set to be applied
just before hand off to the kernel.

When a FIT image with a load_address of 0x8000 was
booted with bootm, the DPL in memory was overwritten.

Move the DPL load to 0x8E00 (196MiB away from 0x8000,
and below the other typical load addr of 0x9000).

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 
---
 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 0x8000 0x30 0x20 &&"   \
"sf read 0x8020 0x5C 0x4 &&"
\
"fsl_mc start mc 0x8000 0x8020 && " \
-   "sf read 0x8030 0x58 0x4 && fsl_mc lazyapply DPL 
0x8030\0"
+   "sf read 0x8E00 0x58 0x4 && fsl_mc lazyapply DPL 0x8E00 
&& "\
+   "echo 'default DPL loaded'\0"
 #define SD_MC_INIT_CMD \
"mmcinfo; fatload mmc 0 0x8000 mcfirmware/mc_ls1088a.itb; "\
"fatload mmc 0 0x8020 dpaa2config/dpc.0x1D-0x0D.dtb; "\
-   "fsl_mc start mc 0x8000 0x8020\0"
+   "fsl_mc start mc 0x8000 0x8020 && " \
+   "fatload mmc 0 0x8E00 dpaa2config/eth-dpl-all.dtb && " \
+   "fsl_mc lazyapply DPL 0x8E00 && 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 0xa000; mtd read dpl 0x8010 
&& " \
-   "fsl_mc apply DPL 0x8010 && bootm 0xa000#ten64\0"
+   "bootcmd_recovery=mtd read recovery 0xa000; && bootm 
0xa000#ten64\0"
 
 #endif /* __TEN64_H */
-- 
2.30.1



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

2023-07-20 Thread 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 
---
 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(_dev, );
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(_dev);
-   if (ret) {
-   puts("Retimer power on failed\n");
-   return;
-   }
+
+   ret = board_cycle_retimer(_dev);
+   if (ret) {
+   puts("Retimer power on failed\n");
+   return;
}
 
/* Access to Control/Shared register */
-- 
2.30.1



[PATCH 00/16] Ten64 updates 2023-07

2023-07-20 Thread 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

2023-07-20 Thread 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 
---
 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 15/18] arm: dts: fsl-ls1088a: move and sync existing bindings to be under /soc

2023-04-12 Thread Mathew McBride
Our [U-Boot] copy of fsl-ls1088a.dtsi had all the hardware under
the top level, until the DM_SERIAL implementation recently.

In this commit, remove any remaining devices (that were in U-Boot,
but not touched by previous patches in this series) to be under /soc,
updating to their upstream (Linux) bindings.

The bindings have been copied closest to their relative positions
in the Linux version, so the eventual result is that the U-Boot
and Linux fsl-ls1088a.dtsi will be identical.

The next commit will add the hardware bindings that were not
in U-Boot.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 185 +++---
 1 file changed, 104 insertions(+), 81 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 8321b73f30..d5822520fb 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -159,6 +159,20 @@
status = "disabled";
};
 
+   dspi: spi@210 {
+   compatible = "fsl,ls1088a-dspi",
+"fsl,ls1021a-v1.0-dspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x210 0x0 0x1>;
+   interrupts = ;
+   clock-names = "dspi";
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(2)>;
+   spi-num-chipselects = <6>;
+   status = "disabled";
+   };
+
duart1: serial@21c0600 {
compatible = "fsl,ns16550", "ns16550a";
reg = <0x0 0x21c0600 0x0 0x100>;
@@ -212,6 +226,16 @@
#interrupt-cells = <2>;
};
 
+   ifc: memory-controller@224 {
+   compatible = "fsl,ifc";
+   reg = <0x0 0x224 0x0 0x2>;
+   interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+   little-endian;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   status = "disabled";
+   };
+
i2c0: i2c@200 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
@@ -256,6 +280,35 @@
status = "disabled";
};
 
+   qspi: spi@20c {
+   compatible = "fsl,ls2080a-qspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x20c 0x0 0x1>,
+ <0x0 0x2000 0x0 0x1000>;
+   reg-names = "QuadSPI", "QuadSPI-memory";
+   interrupts = ;
+   clock-names = "qspi_en", "qspi";
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(4)>,
+< QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(4)>;
+   status = "disabled";
+   };
+
+   esdhc: esdhc@214 {
+   compatible = "fsl,ls1088a-esdhc", "fsl,esdhc";
+   reg = <0x0 0x214 0x0 0x1>;
+   interrupts = <0 28 0x4>; /* Level high type */
+   clock-frequency = <0>;
+   clocks = < QORIQ_CLK_HWACCEL 1>;
+   voltage-ranges = <1800 1800 3300 3300>;
+   sdhci,auto-cmd12;
+   little-endian;
+   bus-width = <4>;
+   status = "disabled";
+   };
+
usb0: usb@310 {
compatible = "snps,dwc3";
reg = <0x0 0x310 0x0 0x1>;
@@ -278,6 +331,57 @@
status = "disabled";
};
 
+   sata: sata@320 {
+   compatible = "fsl,ls1088a-ahci";
+   reg = <0x0 0x320 0x0 0x1>,
+   <0x7 0x100520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = <0 133 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK

[PATCH 10/18] arm: dts: fsl-ls1088a: move GPIO controller under "soc" per Linux

2023-04-12 Thread Mathew McBride
Move the GPIO controller definitions under the "soc" and in
the same relative position as the Linux kernel fsl-ls1088a.dtsi.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 88 +--
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index dc6241e20d..06237a58f4 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -168,6 +168,50 @@
status = "disabled";
};
 
+   gpio0: gpio@230 {
+   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
+   reg = <0x0 0x230 0x0 0x1>;
+   interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
+   little-endian;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpio1: gpio@231 {
+   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
+   reg = <0x0 0x231 0x0 0x1>;
+   interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
+   little-endian;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpio2: gpio@232 {
+   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
+   reg = <0x0 0x232 0x0 0x1>;
+   interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
+   little-endian;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpio3: gpio@233 {
+   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
+   reg = <0x0 0x233 0x0 0x1>;
+   interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
+   little-endian;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
pcie1: pcie@340 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010>, /* controller 
registers */
@@ -428,50 +472,6 @@
bus-width = <4>;
};
 
-   gpio0: gpio@230 {
-   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
-   reg = <0x0 0x230 0x0 0x1>;
-   interrupts = ;
-   little-endian;
-   gpio-controller;
-   #gpio-cells = <2>;
-   interrupt-controller;
-   #interrupt-cells = <2>;
-   };
-
-   gpio1: gpio@231 {
-   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
-   reg = <0x0 0x231 0x0 0x1>;
-   interrupts = ;
-   little-endian;
-   gpio-controller;
-   #gpio-cells = <2>;
-   interrupt-controller;
-   #interrupt-cells = <2>;
-   };
-
-   gpio2: gpio@232 {
-   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
-   reg = <0x0 0x232 0x0 0x1>;
-   interrupts = ;
-   little-endian;
-   gpio-controller;
-   #gpio-cells = <2>;
-   interrupt-controller;
-   #interrupt-cells = <2>;
-   };
-
-   gpio3: gpio@233 {
-   compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
-   reg = <0x0 0x233 0x0 0x1>;
-   interrupts = ;
-   little-endian;
-   gpio-controller;
-   #gpio-cells = <2>;
-   interrupt-controller;
-   #interrupt-cells = <2>;
-   };
-
ifc: ifc@153 {
compatible = "fsl,ifc", "simple-bus";
reg = <0x0 0x224 0x0 0x2>;
-- 
2.30.1



[PATCH 18/18] arm: dts: ten64: fix header typo and update copyright

2023-04-12 Thread Mathew McBride
Somehow, I managed to typo our company name in the U-Boot
and Linux kernel submissions.

Fix this and update the copyright year at the same time.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-ten64.dts | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a-ten64.dts 
b/arch/arm/dts/fsl-ls1088a-ten64.dts
index d4867d6cf4..0d11440d88 100644
--- a/arch/arm/dts/fsl-ls1088a-ten64.dts
+++ b/arch/arm/dts/fsl-ls1088a-ten64.dts
@@ -1,9 +1,10 @@
 // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * Device Tree file for Travese Ten64 (LS1088) board
+ * Device Tree file for Traverse Technologies Ten64
+ * (LS1088A) board
  * Based on fsl-ls1088a-rdb.dts
  * Copyright 2017-2020 NXP
- * Copyright 2019-2021 Traverse Technologies
+ * Copyright 2019-2023 Traverse Technologies
  *
  * Author: Mathew McBride 
  */
-- 
2.30.1



[PATCH 17/18] arm: dts: ten64: syncronise device tree with Linux

2023-04-12 Thread Mathew McBride
This synchronises the Linux device tree with U-Boot
(cp linux//fsl-ls1088a-ten64.dts uboot//fsl-ls1088a-ten64.dts),
as of Linux v6.2-rc5.

Missing from the U-Boot copy previously was the
Ethernet PCS definitions (required for linking with PHY in
Linux but not used by U-Boot) and various upstream
fixes and formatting changes.

The board microcontroller (which doesn't have a Linux driver)
has been moved to the -u-boot.dtsi, as well as the
spi0 quadspi alias (used by U-boot 'sf' but not valid for Linux).

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi | 13 +
 arch/arm/dts/fsl-ls1088a-ten64.dts | 56 --
 2 files changed, 45 insertions(+), 24 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
index 298adb849b..89566bf849 100644
--- a/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
@@ -3,3 +3,16 @@
 
 #include "fsl-ls1088a-u-boot.dtsi"
 
+/{
+   aliases {
+   spi0 = 
+   };
+};
+
+ {
+   uc: board-controller@7e {
+   compatible = "traverse,ten64-controller";
+   reg = <0x7e>;
+   };
+};
+
diff --git a/arch/arm/dts/fsl-ls1088a-ten64.dts 
b/arch/arm/dts/fsl-ls1088a-ten64.dts
index 55a7d41fb0..d4867d6cf4 100644
--- a/arch/arm/dts/fsl-ls1088a-ten64.dts
+++ b/arch/arm/dts/fsl-ls1088a-ten64.dts
@@ -22,7 +22,6 @@
aliases {
serial0 = 
serial1 = 
-   spi0 = 
};
 
chosen {
@@ -36,18 +35,16 @@
 * external power off (e.g ATX Power Button)
 * asserted
 */
-   powerdn {
+   button-powerdn {
label = "External Power Down";
gpios = < 17 GPIO_ACTIVE_LOW>;
-   interrupts = < 17 IRQ_TYPE_EDGE_FALLING>;
linux,code = ;
};
 
/* Rear Panel 'ADMIN' button (GPIO_H) */
-   admin {
+   button-admin {
label = "ADMIN button";
gpios = < 8 GPIO_ACTIVE_HIGH>;
-   interrupts = < 8 IRQ_TYPE_EDGE_RISING>;
linux,code = ;
};
};
@@ -55,17 +52,17 @@
leds {
compatible = "gpio-leds";
 
-   sfp1down {
+   led-0 {
label = "ten64:green:sfp1:down";
gpios = < 11 GPIO_ACTIVE_HIGH>;
};
 
-   sfp2up {
+   led-1 {
label = "ten64:green:sfp2:up";
gpios = < 12 GPIO_ACTIVE_HIGH>;
};
 
-   admin {
+   led-2 {
label = "ten64:admin";
gpios = < 12 GPIO_ACTIVE_HIGH>;
};
@@ -95,17 +92,17 @@
 /* XG1 - Upper SFP */
  {
sfp = <_xg1>;
+   pcs-handle = <>;
phy-connection-type = "10gbase-r";
managed = "in-band-status";
-   status = "okay";
 };
 
 /* XG0 - Lower SFP */
  {
sfp = <_xg0>;
+   pcs-handle = <>;
phy-connection-type = "10gbase-r";
managed = "in-band-status";
-   status = "okay";
 };
 
 /* DPMAC3..6 is GE4 to GE8 */
@@ -113,28 +110,28 @@
phy-handle = <_phy5>;
phy-connection-type = "qsgmii";
managed = "in-band-status";
-   status = "okay";
+   pcs-handle = <_0>;
 };
 
  {
phy-handle = <_phy6>;
phy-connection-type = "qsgmii";
managed = "in-band-status";
-   status = "okay";
+   pcs-handle = <_1>;
 };
 
  {
phy-handle = <_phy7>;
phy-connection-type = "qsgmii";
managed = "in-band-status";
-   status = "okay";
+   pcs-handle = <_2>;
 };
 
  {
phy-handle = <_phy8>;
phy-connection-type = "qsgmii";
managed = "in-band-status";
-   status = "okay";
+   pcs-handle = <_3>;
 };
 
 /* DPMAC7..10 is GE0 to GE3 */
@@ -142,28 +139,28 @@
phy-handle = <_phy1>;
phy-connection-type = "qsgmii";
managed = "in-band-status";
-   status = "okay";
+   pcs-handle = <_0>;
 };
 
  {
phy-handle = <_phy2>;
phy-connection-type = "qsgmii";
managed = "in-band-status";
-   status = "okay";
+   pcs-handle = <_1>;
 };
 
  {
phy-handle = <_phy3>;
phy-connection-type 

[PATCH 16/18] arm: dts: fsl-ls1088a: copy all missing bindings from Linux

2023-04-12 Thread Mathew McBride
This is effectively:

cp linux/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi \
   u-boot/arch/arm/dts/fsl-ls1088a.dtsi

Tested working with Ten64 board (LS1088A) booting openSUSE Tumbleweed.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 320 --
 1 file changed, 304 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index d5822520fb..e5fb137ac0 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -1,18 +1,27 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * NXP ls1088a SOC common device tree source
+ * Device Tree Include file for NXP Layerscape-1088A family SoC.
+ *
+ * Copyright 2017-2020 NXP
+ *
+ * Harninder Rai 
  *
- * Copyright 2017, 2020-2021, 2023 NXP
  */
-
 #include 
 #include 
+#include 
+
 / {
compatible = "fsl,ls1088a";
interrupt-parent = <>;
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   crypto = 
+   rtc1 = _alarm0;
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -121,12 +130,73 @@
};
};
 
+   thermal-zones {
+   core-cluster {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+   thermal-sensors = < 0>;
+
+   trips {
+   core_cluster_alert: core-cluster-alert {
+   temperature = <85000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+
+   core-cluster-crit {
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <_cluster_alert>;
+   cooling-device =
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>,
+   < THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   };
+   };
+   };
+
+   soc {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+   thermal-sensors = < 1>;
+
+   trips {
+   soc-crit {
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
-   interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
-<1 14 0x8>, /* Physical Non-Secure PPI, active-low 
*/
-<1 11 0x8>, /* Virtual PPI, active-low */
-<1 10 0x8>; /* Hypervisor PPI, active-low */
+   interrupts = <1 13 IRQ_TYPE_LEVEL_LOW>,/* Physical Secure PPI */
+<1 14 IRQ_TYPE_LEVEL_LOW>,/* Physical Non-Secure 
PPI */
+<1 11 IRQ_TYPE_LEVEL_LOW>,/* Virtual PPI */
+<1 10 IRQ_TYPE_LEVEL_LOW>;/* Hypervisor PPI */
+   };
+
+   pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ;
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
};
 
sysclk: sysclk {
@@ -136,6 +206,13 @@
clock-output-names = "sysclk";
};
 
+   reboot {
+   compatible = "syscon-reboot";

[PATCH 14/18] arm: dts: fsl-ls1088a: syncronise fsl-mc definition with Linux

2023-04-12 Thread Mathew McBride
This moves the fsl-mc device tree definition under the /soc
node, as well as adding interrupt and IOMMU definitions that
were not in U-Boot before.

There are slight differences between the two bindings
as we add a "simple-mfd" compatible to function
under U-Boot's driver model.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi |  12 +++
 arch/arm/dts/fsl-ls1088a.dtsi| 154 +--
 2 files changed, 85 insertions(+), 81 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
index d9d1347b0c..efcfdd96ae 100644
--- a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
@@ -29,6 +29,18 @@
compatible = "fsl,ls-mdio", "fsl,fman-memac-mdio";
 };
 
+/* DPAA2 Management Complex (MC)
+ * "simple-mfd" compatible used by U-Boot only,
+ * to allow driver model functionality.
+ */
+_mc {
+   compatible = "fsl,qoriq-mc", "simple-mfd";
+
+   dpmacs {
+   compatible = "simple-mfd";
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index ee40a55654..8321b73f30 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -577,6 +577,79 @@
reg = <3>;
};
};
+
+   fsl_mc: fsl-mc@80c00 {
+   compatible = "fsl,qoriq-mc";
+   reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
+ <0x 0x0834 0 0x4>; /* MC control 
reg */
+   msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
+   #address-cells = <3>;
+   #size-cells = <1>;
+
+   /*
+* Region type 0x0 - MC portals
+* Region type 0x1 - QBMAN portals
+*/
+   ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
+ 0x1 0x0 0x0 0x8 0x1800 0x800>;
+
+   dpmacs {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dpmac1: ethernet@1 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <1>;
+   };
+
+   dpmac2: ethernet@2 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <2>;
+   };
+
+   dpmac3: ethernet@3 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <3>;
+   };
+
+   dpmac4: ethernet@4 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <4>;
+   };
+
+   dpmac5: ethernet@5 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <5>;
+   };
+
+   dpmac6: ethernet@6 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <6>;
+   };
+
+   dpmac7: ethernet@7 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <7>;
+   };
+
+   dpmac8: ethernet@8 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <8>;
+   };
+
+   dpmac9: ethernet@9 {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <9>;
+   };
+
+   dpmac10: ethernet@a {
+   compatible = "fsl,qoriq-mc-dpmac";
+   reg = <0xa>;
+   };
+   };
+   };
};
 
dspi: dspi@210 {
@@ -664,85 +737,4 @@
compatible = "arm,psci-0.2";

[PATCH 13/18] arm: dts: fsl-ls1088a: syncronise MDIO+PCS U-Boot definitions with Linux

2023-04-12 Thread Mathew McBride
Synchronise the MDIO controller definitions with Linux, so
the controllers will be usable when passing U-Boot's
control FDT to Linux.

This also adds the PCS (internal controller) definitions
which are not used by U-Boot.

Caveat: The kernel definition uses "fsl,fman-memac-mdio",
as with other members of the Layerscape family, but
U-Boot uses a different driver for the DPAA2
Family devices (LS1088/LS2088/LX2160). So
we use "fsl,ls-mdio" as the first compatible string
for these devices.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi |  12 +++
 arch/arm/dts/fsl-ls1088a.dtsi| 116 +++
 2 files changed, 112 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
index 3a2291527c..d9d1347b0c 100644
--- a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
@@ -17,6 +17,18 @@
bootph-all;
 };
 
+/* MDIO controllers - U-Boot uses a different
+ * driver for the DPAA2 (LS/LX2) family,
+ * so must match fsl,ls-mdio first.
+ */
+ {
+   compatible = "fsl,ls-mdio", "fsl,fman-memac-mdio";
+};
+
+ {
+   compatible = "fsl,ls-mdio", "fsl,fman-memac-mdio";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index ca88b9e9f4..ee40a55654 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -477,6 +477,106 @@
 ,
 ;
};
+
+   emdio1: mdio@8b96000 {
+   compatible = "fsl,fman-memac-mdio";
+   reg = <0x0 0x8b96000 0x0 0x1000>;
+   little-endian;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clock-frequency = <250>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(1)>;
+   status = "disabled";
+   };
+
+   emdio2: mdio@8b97000 {
+   compatible = "fsl,fman-memac-mdio";
+   reg = <0x0 0x8b97000 0x0 0x1000>;
+   little-endian;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clock-frequency = <250>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(1)>;
+   status = "disabled";
+   };
+
+   pcs_mdio1: mdio@8c07000 {
+   compatible = "fsl,fman-memac-mdio";
+   reg = <0x0 0x8c07000 0x0 0x1000>;
+   little-endian;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   pcs1: ethernet-phy@0 {
+   reg = <0>;
+   };
+   };
+
+   pcs_mdio2: mdio@8c0b000 {
+   compatible = "fsl,fman-memac-mdio";
+   reg = <0x0 0x8c0b000 0x0 0x1000>;
+   little-endian;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   pcs2: ethernet-phy@0 {
+   reg = <0>;
+   };
+   };
+
+   pcs_mdio3: mdio@8c0f000 {
+   compatible = "fsl,fman-memac-mdio";
+   reg = <0x0 0x8c0f000 0x0 0x1000>;
+   little-endian;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   pcs3_0: ethernet-phy@0 {
+   reg = <0>;
+   };
+
+   pcs3_1: ethernet-phy@1 {
+   reg = <1>;
+   };
+
+   pcs3_2: ethernet-phy@2 {
+   reg = <2>;
+   };
+
+   pcs3_3: ethernet-phy@3 {
+   reg = <3>;
+   };
+   };
+
+   pcs_mdio7: mdio@8c1f000 {
+   compatible = "fsl,fman-memac-mdio";
+   reg = <0x0 0x8c1f000 0x0 0x1000>;
+   little-endian;
+ 

[PATCH 12/18] arm: dts: fsl-ls1088a: sync usb controller nodes with Linux

2023-04-12 Thread Mathew McBride
Synchronise the USB device tree definition with Linux, allowing
the U-Boot control FDT to be used to boot a Linux system with
working USB.

An extra compatible string, "fsl,layerscape-dwc3" is needed
for special handling in U-Boot, so has been added to the
-u-boot.dtsi file. It might be better to add this to the
Linux source bindings.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi |  8 +++
 arch/arm/dts/fsl-ls1088a.dtsi| 36 +---
 2 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
index ac30b813ff..3a2291527c 100644
--- a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
@@ -29,3 +29,11 @@
status = "okay";
 };
 
+ {
+   compatible = "fsl,layerscape-dwc3", "snps,dwc3";
+};
+
+ {
+   compatible = "fsl,layerscape-dwc3", "snps,dwc3";
+};
+
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index bd344ba8e2..ca88b9e9f4 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -256,6 +256,28 @@
status = "disabled";
};
 
+   usb0: usb@310 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x310 0x0 0x1>;
+   interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+   status = "disabled";
+   };
+
+   usb1: usb@311 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0x311 0x0 0x1>;
+   interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
+   dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
+   snps,dis_rxdet_inp3_quirk;
+   snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+   status = "disabled";
+   };
+
pcie1: pcie@340 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010>, /* controller 
registers */
@@ -490,20 +512,6 @@
interrupts = <0 21 0x4>; /* Level high type */
};
 
-   usb0: usb3@310 {
-   compatible = "fsl,layerscape-dwc3";
-   reg = <0x0 0x310 0x0 0x1>;
-   interrupts = <0 80 0x4>; /* Level high type */
-   dr_mode = "host";
-   };
-
-   usb1: usb3@311 {
-   compatible = "fsl,layerscape-dwc3";
-   reg = <0x0 0x311 0x0 0x1>;
-   interrupts = <0 81 0x4>; /* Level high type */
-   dr_mode = "host";
-   };
-
crypto: crypto@800 {
compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
fsl,sec-era = <8>;
-- 
2.30.1



[PATCH 09/18] arm: dts: fsl-ls1088a: import CPU definition from Linux kernel

2023-04-12 Thread Mathew McBride
This is required for Linux to boot using the same FDT as
U-Boot (such as passing the control FDT to bootefi).

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 87 +++
 1 file changed, 87 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 85316ddb66..dc6241e20d 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -13,6 +13,93 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* We have 2 clusters having 4 Cortex-A53 cores each */
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0>;
+   clocks = < QORIQ_CLK_CMUX 0>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x1>;
+   clocks = < QORIQ_CLK_CMUX 0>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x2>;
+   clocks = < QORIQ_CLK_CMUX 0>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x3>;
+   clocks = < QORIQ_CLK_CMUX 0>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu4: cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x100>;
+   clocks = < QORIQ_CLK_CMUX 1>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu5: cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x101>;
+   clocks = < QORIQ_CLK_CMUX 1>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu6: cpu@102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x102>;
+   clocks = < QORIQ_CLK_CMUX 1>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   cpu7: cpu@103 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x103>;
+   clocks = < QORIQ_CLK_CMUX 1>;
+   cpu-idle-states = <_PH20>;
+   #cooling-cells = <2>;
+   };
+
+   CPU_PH20: cpu-ph20 {
+   compatible = "arm,idle-state";
+   idle-state-name = "PH20";
+   arm,psci-suspend-param = <0x0>;
+   entry-latency-us = <1000>;
+   exit-latency-us = <1000>;
+   min-residency-us = <3000>;
+   };
+   };
+
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
-- 
2.30.1



[PATCH 08/18] arm: dts: fsl-ls1088a: match Linux FDT by disabling PCIe by default

2023-04-12 Thread Mathew McBride
The Linux kernel fsl-ls1088a.dtsi disables (status="disabled")
all PCIe controllers by default, with the bootloader (i.e U-Boot)
enabling the appropriate controllers (specified by the board
reset control word/RCW) by FDT fixup.

However, U-Boot needs these controllers to be enabled
to be usable, which we can add in the u-boot only dtsi.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi | 13 +
 arch/arm/dts/fsl-ls1088a.dtsi|  3 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
index 3eb45d47cd..ac30b813ff 100644
--- a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
@@ -16,3 +16,16 @@
  {
bootph-all;
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 71d652c818..85316ddb66 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -104,6 +104,7 @@
< 0 0 3  0 0 0 111 
IRQ_TYPE_LEVEL_HIGH>,
< 0 0 4  0 0 0 112 
IRQ_TYPE_LEVEL_HIGH>;
iommu-map = <0  0 1>; /* Fixed-up by bootloader */
+   status = "disabled";
};
 
pcie_ep1: pcie-ep@340 {
@@ -140,6 +141,7 @@
< 0 0 3  0 0 0 116 
IRQ_TYPE_LEVEL_HIGH>,
< 0 0 4  0 0 0 117 
IRQ_TYPE_LEVEL_HIGH>;
iommu-map = <0  0 1>; /* Fixed-up by bootloader */
+   status = "disabled";
};
 
pcie_ep2: pcie-ep@350 {
@@ -175,6 +177,7 @@
< 0 0 3  0 0 0 121 
IRQ_TYPE_LEVEL_HIGH>,
< 0 0 4  0 0 0 122 
IRQ_TYPE_LEVEL_HIGH>;
iommu-map = <0  0 1>; /* Fixed-up by bootloader */
+   status = "disabled";
};
 
pcie_ep3: pcie-ep@360 {
-- 
2.30.1



[PATCH 07/18] arm: dts: fsl-ls1088a: sync PCIe controller definition with Linux

2023-04-12 Thread Mathew McBride
This moves the PCIe controller definitions under /soc and adopts
the same bindings (fsl,ls1088a-pcie) as Linux. Previously,
the format was different between the two versions.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 154 +++---
 1 file changed, 106 insertions(+), 48 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 05da798380..71d652c818 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -81,6 +81,112 @@
status = "disabled";
};
 
+   pcie1: pcie@340 {
+   compatible = "fsl,ls1088a-pcie";
+   reg = <0x00 0x0340 0x0 0x0010>, /* controller 
registers */
+ <0x20 0x 0x0 0x2000>; /* 
configuration space */
+   reg-names = "regs", "config";
+   interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; /* aer 
interrupt */
+   interrupt-names = "aer";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   dma-coherent;
+   num-viewport = <256>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x20 0x0001 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x20 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   msi-parent = <>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = < 0 0 1  0 0 0 109 
IRQ_TYPE_LEVEL_HIGH>,
+   < 0 0 2  0 0 0 110 
IRQ_TYPE_LEVEL_HIGH>,
+   < 0 0 3  0 0 0 111 
IRQ_TYPE_LEVEL_HIGH>,
+   < 0 0 4  0 0 0 112 
IRQ_TYPE_LEVEL_HIGH>;
+   iommu-map = <0  0 1>; /* Fixed-up by bootloader */
+   };
+
+   pcie_ep1: pcie-ep@340 {
+   compatible = "fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep";
+   reg = <0x00 0x0340 0x0 0x0010>,
+ <0x20 0x 0x8 0x>;
+   reg-names = "regs", "addr_space";
+   num-ib-windows = <24>;
+   num-ob-windows = <256>;
+   max-functions = /bits/ 8 <2>;
+   status = "disabled";
+   };
+
+   pcie2: pcie@350 {
+   compatible = "fsl,ls1088a-pcie";
+   reg = <0x00 0x0350 0x0 0x0010>, /* controller 
registers */
+ <0x28 0x 0x0 0x2000>; /* 
configuration space */
+   reg-names = "regs", "config";
+   interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>; /* aer 
interrupt */
+   interrupt-names = "aer";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   dma-coherent;
+   num-viewport = <6>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x28 0x0001 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x28 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   msi-parent = <>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = < 0 0 1  0 0 0 114 
IRQ_TYPE_LEVEL_HIGH>,
+   < 0 0 2  0 0 0 115 
IRQ_TYPE_LEVEL_HIGH>,
+   < 0 0 3  0 0 0 116 
IRQ_TYPE_LEVEL_HIGH>,
+   < 0 0 4  0 0 0 117 
IRQ_TYPE_LEVEL_HIGH>;
+   iommu-map = <0  0 1>; /* Fixed-up by bootloader */
+   };
+
+   pcie_ep2: pcie-ep@350 {
+   compatible = "fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep";
+   reg = <0x00 0x0350 0x0 0x0010>,
+ <0x28 0x 0x8 0x>;
+   reg-names = "regs", "addr_space"

[PATCH 11/18] arm: dts: fsl-ls1088a: move I2C nodes under "soc" and syncronize with Linux

2023-04-12 Thread Mathew McBride
U-Boot's definition for the I2C controllers did not contain any
clock information. This resulted in the I2C not functioning when
the U-Boot control FDT was passed to Linux.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 76 ---
 1 file changed, 44 insertions(+), 32 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 06237a58f4..bd344ba8e2 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -212,6 +212,50 @@
#interrupt-cells = <2>;
};
 
+   i2c0: i2c@200 {
+   compatible = "fsl,vf610-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x200 0x0 0x1>;
+   interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(8)>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@201 {
+   compatible = "fsl,vf610-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x201 0x0 0x1>;
+   interrupts = <0 34 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(8)>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@202 {
+   compatible = "fsl,vf610-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x202 0x0 0x1>;
+   interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(8)>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@203 {
+   compatible = "fsl,vf610-i2c";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x203 0x0 0x1>;
+   interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < QORIQ_CLK_PLATFORM_PLL
+   QORIQ_CLK_PLL_DIV(8)>;
+   status = "disabled";
+   };
+
pcie1: pcie@340 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0340 0x0 0x0010>, /* controller 
registers */
@@ -413,38 +457,6 @@
};
};
 
-   i2c0: i2c@200 {
-   compatible = "fsl,vf610-i2c";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x0 0x200 0x0 0x1>;
-   interrupts = <0 34 4>;
-   };
-
-   i2c1: i2c@201 {
-   compatible = "fsl,vf610-i2c";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x0 0x201 0x0 0x1>;
-   interrupts = <0 34 4>;
-   };
-
-   i2c2: i2c@202 {
-   compatible = "fsl,vf610-i2c";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x0 0x202 0x0 0x1>;
-   interrupts = <0 35 4>;
-   };
-
-   i2c3: i2c@203 {
-   compatible = "fsl,vf610-i2c";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x0 0x203 0x0 0x1>;
-   interrupts = <0 35 4>;
-   };
-
dspi: dspi@210 {
compatible = "fsl,vf610-dspi";
#address-cells = <1>;
-- 
2.30.1



[PATCH 06/18] arm: dts: fsl-ls1088a: import and sync full SMMU nodes with Linux

2023-04-12 Thread Mathew McBride
To synchronise the device tree in U-Boot with Linux, the GIC
(Interrupt Controller) and SMMU/IOMMU nodes need to be synchronised
before changing any dependent components like PCIe and DPAA2/fsl-mc.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 109 +-
 1 file changed, 106 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 3afd847baf..05da798380 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -15,11 +15,23 @@
 
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
-   reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
- <0x0 0x0610 0 0x10>; /* GICR (RD_base + SGI_base) 
*/
#interrupt-cells = <3>;
interrupt-controller;
-   interrupts = <1 9 0x4>;
+   reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
+ <0x0 0x0610 0 0x10>, /* GICR(RD_base+SGI_base)*/
+ <0x0 0x0c0c 0 0x2000>, /* GICC */
+ <0x0 0x0c0d 0 0x1000>, /* GICH */
+ <0x0 0x0c0e 0 0x2>; /* GICV */
+   interrupts = <1 9 IRQ_TYPE_LEVEL_HIGH>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   its: gic-its@602 {
+   compatible = "arm,gic-v3-its";
+   msi-controller;
+   reg = <0x0 0x602 0 0x2>;
+   };
};
 
timer {
@@ -68,6 +80,97 @@
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
+
+   smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   reg = <0 0x500 0 0x80>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   dma-coherent;
+   #global-interrupts = <12>;
+// global secure fault
+   interrupts = ,
+// combined secure
+,
+// global non-secure fault
+,
+// combined non-secure
+,
+// performance counter interrupts 0-7
+,
+,
+,
+,
+,
+,
+ 

[PATCH 05/18] pci: layerscape: add support for kernel/official fsl, ls1088a-pcie binding

2023-04-12 Thread Mathew McBride
This allows the Layerscape PCIe RC driver to use the upstream
style binding (two "reg" entries instead of four).

It is similar to the previous commit e10da1f985ad
("pci: layerscape: add official ls1028a binding support")
which implemented this for the LS1028A.

Signed-off-by: Mathew McBride 
---
 drivers/pci/pcie_layerscape_rc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_layerscape_rc.c b/drivers/pci/pcie_layerscape_rc.c
index 17969e2f23..6a5bf88da2 100644
--- a/drivers/pci/pcie_layerscape_rc.c
+++ b/drivers/pci/pcie_layerscape_rc.c
@@ -403,6 +403,7 @@ static const struct ls_pcie_drvdata ls1028a_drvdata = {
 static const struct udevice_id ls_pcie_ids[] = {
{ .compatible = "fsl,ls-pcie" },
{ .compatible = "fsl,ls1028a-pcie", .data = (ulong)_drvdata },
+   { .compatible = "fsl,ls1088a-pcie", .data = (ulong)_drvdata },
{ }
 };
 
-- 
2.30.1



[PATCH 04/18] arm: dts: fsl-ls1088a: move memory node into U-Boot specific file

2023-04-12 Thread Mathew McBride
The top-level "memory" node does not exist in the Linux
version of the fsl-ls1088a.dtsi file. Move it to the U-Boot
"tweak" file, so we can have an identical copy of
fsl-ls1088a.dtsi between the projects in the end.

Signed-off-by: Mathew McBride 
---
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi | 8 
 arch/arm/dts/fsl-ls1088a.dtsi| 6 --
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
index f59d8b184c..3eb45d47cd 100644
--- a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
@@ -1,6 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0+
 #include 
 
+/{
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x 0x8000 0 0x8000>;
+ /* DRAM space - 1, size : 2 GB DRAM */
+   };
+};
+
  {
bootph-all;
 };
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index b094bcf67c..3afd847baf 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -13,12 +13,6 @@
#address-cells = <2>;
#size-cells = <2>;
 
-   memory@8000 {
-   device_type = "memory";
-   reg = <0x 0x8000 0 0x8000>;
- /* DRAM space - 1, size : 2 GB DRAM */
-   };
-
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
-- 
2.30.1



[PATCH 03/18] arm: dts: fsl-ls1088a: move u-boot bootph tags into u-boot only files

2023-04-12 Thread Mathew McBride
This moves the bootph-all tags that were added in commit a593c1fec579
("arch: arm: dts: fsl-ls1088a.dtsi: tag serial nodes with bootph-all")
into a u-boot only include.

Due to the way the U-Boot device tree "tweak" system is setup[1],
we need to have a per-board -u-boot.dtsi, which will
include the "fsl-ls1088a-u-boot.dtsi" tweaks.

By doing so, future updates to fsl-ls1088a.dtsi from upstream
(Linux kernel) can just be copied directly into the U-Boot tree,
without worrying about any extra data local to U-Boot.

Signed-off-by: Mathew McBride 

[1] - 
https://u-boot.readthedocs.io/en/latest/develop/devicetree/control.html#adding-tweaks-for-u-boot
The CONFIG_SYS_SOC, CONFIG_SYS_CPU and CONFIG_SYS_VENDOR
values are the same for the entire Layerscape family,
meaning there is no ability to create a LS1088A only
file here. But we will be adding per-board tweaks
later in any case.
---
 arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi   |  5 +
 arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi   |  5 +
 arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi |  5 +
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi   | 10 ++
 arch/arm/dts/fsl-ls1088a.dtsi  |  2 --
 5 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1088a-u-boot.dtsi

diff --git a/arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi
new file mode 100644
index 00..298adb849b
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include 
+
+#include "fsl-ls1088a-u-boot.dtsi"
+
diff --git a/arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi
new file mode 100644
index 00..298adb849b
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include 
+
+#include "fsl-ls1088a-u-boot.dtsi"
+
diff --git a/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
new file mode 100644
index 00..298adb849b
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include 
+
+#include "fsl-ls1088a-u-boot.dtsi"
+
diff --git a/arch/arm/dts/fsl-ls1088a-u-boot.dtsi 
b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
new file mode 100644
index 00..f59d8b184c
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
+#include 
+
+ {
+   bootph-all;
+};
+
+ {
+   bootph-all;
+};
diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 4782b83515..b094bcf67c 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -64,7 +64,6 @@
QORIQ_CLK_PLL_DIV(4)>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
-   bootph-all;
};
 
duart1: serial@21c0600 {
@@ -74,7 +73,6 @@
QORIQ_CLK_PLL_DIV(4)>;
interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
-   bootph-all;
};
};
 
-- 
2.30.1



[PATCH 02/18] configs: ten64: enable DM_SERIAL

2023-04-12 Thread Mathew McBride
The recent series "Convert LS1088A and LX2160 to DM_SERIAL"
from Ioana Ciornei provided the necessary support to enable
DM_SERIAL on the Ten64 board (LS1088A).

Signed-off-by: Mathew McBride 
---
 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 2396d9ef37..4e5fcddab6 100644
--- a/configs/ten64_tfa_defconfig
+++ b/configs/ten64_tfa_defconfig
@@ -81,7 +81,9 @@ CONFIG_PCIE_LAYERSCAPE_RC=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_RX8025=y
 CONFIG_DM_SCSI=y
-CONFIG_SYS_NS16550_SERIAL=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
-- 
2.30.1



[PATCH 00/18] Synchronise LS1088A/Ten64 device tree with Linux

2023-04-12 Thread Mathew McBride
I am intensively working on updating the current
"production" Ten64 (NXP LS1088A) firmware from v2020.07 to
the latest U-Boot, with the hope of taking advantage of
bootstd/bootflow and other improvements.

One desire I have is to have U-Boot "supply" the device tree
which is used for EFI boot, rather than our current method of
reading the DTB from a flash partition with commands (sf read etc.)
and plugging that into the distroboot process.

Indeed, once we syncronise the U-Boot FDT with the Linux
one, the bootflow method "Just Works" with the control
FDT, without us having to plug an external FDT into the
process.

(Note: the bootstd conversion for Ten64 will be coming in
a later commit. The DTS on it's own is only one part of 
the puzzle)

The flow of this series is:
- Fix a crash I found in the U-Boot FDT fixup for Layerscape

  The previous U-Boot copy of the fsl-ls1088a.dts did not
  have direct alias to the "crypto" node, triggering a crash
  when FDT fixup tried to operate on it.

- Enable DM_SERIAL for Ten64 (mirrors how it was enabled for
  LS1088A-RDB and LS1088A-QDS recently)

- Move all U-Boot "tweaks" into a -u-boot.dtsi file.
  Each board will have it's own -u-boot.dtsi,
  which includs the SoC-specific fsl-ls1088a-u-boot.dtsi.

- For all hardware that was in U-Boot's fsl-ls1088a.dtsi,
  and not in the "correct" place (under /soc), move them
  into /soc and adopt the Linux kernel definition.

  PCIe needed special treatment as it's U-Boot binding was
  slightly different, as well as different compatible strings
  (match a different U-Boot driver) for MDIO, USB and fsl-mc
  among others.

  At this point, Linux is able to boot on the Ten64
  using U-Boot's FDT (passed to it via EFI) with
  major hardware (Ethernet, USB, PCIe) functional.

- Finally, copy over the U-Boot fsl-ls1088a.dtsi with the
  Linux kernel version.
  They are now bit-for-bit identical, with the U-Boot tweaks
  contained externally.

- Similarly for the Ten64 DTS - fsl-ls1088a-ten64.dts
  is now identical to the kernel version.

This builds upon the recent conversion of the LS1088A
to DM_SERIAL[1]. I used a similar syncronisation for the LS1028A[2]
as a guide.

[1] - "Convert LS1088A and LX2160 to DM_SERIAL" patch series
https://patchwork.ozlabs.org/project/uboot/list/?series=346392=%2A=both

[2] - "arm: dts: ls1028a: sync device tree with linux" patch series
https://patchwork.ozlabs.org/project/uboot/list/?series=265457=%2A=both

Mathew McBride (18):
  armv8: fsl-layerscape: check for crypto node first in
fdt_fixup_remove_jr
  configs: ten64: enable DM_SERIAL
  arm: dts: fsl-ls1088a: move u-boot bootph tags into u-boot only files
  arm: dts: fsl-ls1088a: move memory node into U-Boot specific file
  pci: layerscape: add support for kernel/official fsl,ls1088a-pcie
binding
  arm: dts: fsl-ls1088a: import and sync full SMMU nodes with Linux
  arm: dts: fsl-ls1088a: sync PCIe controller definition with Linux
  arm: dts: fsl-ls1088a: match Linux FDT by disabling PCIe by default
  arm: dts: fsl-ls1088a: import CPU definition from Linux kernel
  arm: dts: fsl-ls1088a: move GPIO controller under "soc" per Linux
  arm: dts: fsl-ls1088a: move I2C nodes under "soc" and syncronize with
Linux
  arm: dts: fsl-ls1088a: sync usb controller nodes with Linux
  arm: dts: fsl-ls1088a: syncronise MDIO+PCS U-Boot definitions with
Linux
  arm: dts: fsl-ls1088a: syncronise fsl-mc definition with Linux
  arm: dts: fsl-ls1088a: move and sync existing bindings to be under
/soc
  arm: dts: fsl-ls1088a: copy all missing bindings from Linux
  arm: dts: ten64: syncronise device tree with Linux
  arm: dts: ten64: fix header typo and update copyright

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c|4 +
 arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi   |5 +
 arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi   |5 +
 arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi |   18 +
 arch/arm/dts/fsl-ls1088a-ten64.dts |   61 +-
 arch/arm/dts/fsl-ls1088a-u-boot.dtsi   |   63 +
 arch/arm/dts/fsl-ls1088a.dtsi  | 1216 +++-
 configs/ten64_tfa_defconfig|4 +-
 drivers/pci/pcie_layerscape_rc.c   |1 +
 9 files changed, 1067 insertions(+), 310 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-qds-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1088a-rdb-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1088a-ten64-u-boot.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1088a-u-boot.dtsi

-- 
2.30.1



[PATCH 01/18] armv8: fsl-layerscape: check for crypto node first in fdt_fixup_remove_jr

2023-04-12 Thread Mathew McBride
This a problem I found while updating the U-Boot fsl-ls1088a.dtsi
to match the Linux version.

fdt_fixup_remove_jr did not check whether there was a "crypto"
alias in the device tree before calling more fdt_* functions,
which resulted in a crash.

Fixes: a797f274
("ARMv8/sec_firmware : Update chosen/kaslr-seed with random number")

Signed-off-by: Mathew McBride 
---
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4f91db49ee..22ce699216 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -387,6 +387,10 @@ void fdt_fixup_remove_jr(void *blob)
u64 jr_offset, used_jr;
fdt32_t *reg;
 
+   /* Return if crypto node not found */
+   if (crypto_node < 0)
+   return;
+
used_jr = sec_firmware_used_jobring_offset();
fdt_support_default_count_cells(blob, crypto_node, _cells, NULL);
 
-- 
2.30.1



Re: [BUG] issues with new bootflow, uefi and virtio

2023-04-05 Thread Mathew McBride
Hi Vincent,

On Thu, Apr 6, 2023, at 1:04 AM, Vincent Stehlé wrote:
> Hi,
> 
> I am hitting an issue with the new bootflow when booting with UEFI from a
> virtio device on Qemu Arm.
> 
> It seems the device number computation in efiload_read_file() does not work
> in the general virtio case, where it will pick the virtio device number
> instead of the block device index. On Qemu arm virt machine, many virtio
> mmio devices are provisioned in the memory map and no assumption can be
> made on the number of the actual virtio device in use in the general case.
> 
> This is an extract of the output of `dm tree' on this platform, focused on
> the virtio device from which I would like to boot:
> 
>   virtio31  [ + ]   virtio-mmio |-- virtio_mmio@a003e00
>   blk0  [ + ]   virtio-blk  |   |-- virtio-blk#31
>   partition  0  [ + ]   blk_partition   |   |   |-- virtio-blk#31:1
>   partition  1  [ + ]   blk_partition   |   |   `-- virtio-blk#31:2
>   bootdev2  [ + ]   virtio_bootdev  |   `-- virtio-blk#31.bootdev
> 
> In this extract the actual virtio device number is 31, as will be picked by
> efiload_read_file(), but the desired block device index is zero, as would
> be used with e.g. `ls virtio 0'.

I came across the exact same issue a few days ago. Below is a patch which I 
believe fixes the problem, by using the devnum of blk uclass (virtio 0) instead 
of the sequence number of the parent udevice (e.g virtio-blk#35).

Separately, the devnum was previously being parsed as a hex which meant 
"virtio_blk#35" was actually being parsed as "virtio_blk#23". That confused me 
for a while.

If the patch looks good I can re-post it directly to the ML. I'm not 100% sure 
that I got it right.

In case the email mangles the patch, you can grab a diff here as well: 
https://gitlab.com/traversetech/ls1088firmware/u-boot/-/commit/5ed3315b4a297f143fb84f44117b5b31e5617af5

- Matt

--------

>From 5ed3315b4a297f143fb84f44117b5b31e5617af5 Mon Sep 17 00:00:00 2001
From: Mathew McBride 
Date: Wed, 5 Apr 2023 02:44:48 +
Subject: [PATCH] bootstd: use blk uclass device numbers to set efi bootdev

When loading a file from a block device, efiload_read_file
was using the seq_num of the device (e.g "35" of virtio_blk#35)
instead of the block device id (e.g what you get from running
the corresponding device scan command, like "virtio 0")

This cause EFI booting from these devices to fail as an
invalid device number is passed to blk_get_device_part_str:

Scanning bootdev 'virtio-blk#35.bootdev':
distro_efi_read_bootflow_file start (efi,fname=)
distro_efi_read_bootflow_file start (efi,fname=)
setting bootdev virtio, 35, efi/boot/bootaa64.efi, beef9a40, 170800
efi_dp_from_name calling blk_get_device_part_str
dev=virtio devnr=35 path=efi/boot/bootaa64.efi
blk_get_device_part_str (virtio,35)
blk_get_device_by_str (virtio, 35)
** Bad device specification virtio 35 **
Using default device tree: dtb/qemu-arm.dtb
No device tree available
0  efi  ready   virtio   1  virtio-blk#35.bootdev.par 
efi/boot/bootaa64.efi
** Booting bootflow 'virtio-blk#35.bootdev.part_1' with efi
blk_get_device_part_str (virtio,0:1)
blk_get_device_by_str (virtio, 0)
No UEFI binary known at beef9a40 (image 
buf=beef9a40,addr=)
Boot failed (err=-22)

Signed-off-by: Mathew McBride 
---
 boot/bootmeth_efi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index 6a97ac02ff..bc106aa736 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -117,7 +117,7 @@ static int efiload_read_file(struct blk_desc *desc, struct 
bootflow *bflow)
 * this can go away.
 */
media_dev = dev_get_parent(bflow->dev);
-   snprintf(devnum_str, sizeof(devnum_str), "%x", dev_seq(media_dev));
+   snprintf(devnum_str, sizeof(devnum_str), "%d", desc->devnum);
 
strlcpy(dirname, bflow->fname, sizeof(dirname));
last_slash = strrchr(dirname, '/');
-- 
2.30.1





Re: [PATCH v2 2/2] board: traverse: add initial Ten64 support

2021-11-17 Thread Mathew McBride
Hi Tom,

On Fri, Nov 12, 2021, at 5:20 AM, Tom Rini wrote:
> On Wed, Nov 10, 2021 at 04:46:39AM +0000, Mathew McBride wrote:
> 
> > Signed-off-by: Mathew McBride 
> > ---
> >  arch/arm/Kconfig   |  16 ++
> >  arch/arm/dts/Makefile  |   2 +
> >  arch/arm/dts/fsl-ls1088a-ten64.dts | 377 +
> 
> What is the status of this dts with upstream Linux?
It's been in Linux since v5.15, though there is going to be some flux between 
U-Boot and Linux for a short while as some devices will be introduced into one 
or the other other first.
e.g traverse,ten64-controller does not and will not have a Linux (kernel) 
counterpart but I'll try and get it added to the dt yaml's for validation.

(The upstream DTS intentionally left out some I2C devices that don't have Linux 
drivers or formal DT bindings yet)

> [snip]
> 
> 
> > +#define QSPI_NOR_BOOTCOMMAND "run distro_bootcmd"
> > +#define SD_BOOTCOMMAND "run distro_bootcmd"
> 
> You should just set CONFIG_USE_BOOTCOMMAND and then CONFIG_BOOTCOMMAND
> will be "run distro_bootcmd".  Thanks!
This actually comes about from fsl_setenv_bootcmd:
https://elixir.bootlin.com/u-boot/latest/source/arch/arm/cpu/armv8/fsl-layerscape/soc.c#L800
Which gets hooked into board_late_init
https://elixir.bootlin.com/u-boot/latest/source/arch/arm/cpu/armv8/fsl-layerscape/soc.c#L961

The main reason I understand that exists is because the secure boot (FSL trust 
architecture) setup differs a depending on where the board has booted from:
https://elixir.bootlin.com/u-boot/latest/source/include/configs/ls1088ardb.h#L448
(There is also a similar issue with mcinitcmd which does affect us)

Since trust architecture isn't supported on our board yet, it just collapses 
down to "run distro_bootcmd" regardless of where the board started from.

I guess this behaviour could be hidden behind a Kconfig so it's opt-in?

- Matt


[PATCH v2 6/6] drivers: tpm: atmel_twi: fix printf specifier compile warning

2021-11-10 Thread Mathew McBride
%d was being used as the specifier for size_t, leading to a
compiler warning

Signed-off-by: Mathew McBride 
Reviewed-by: Ilias Apalodimas 
---
 drivers/tpm/tpm_atmel_twi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index a5dfb34846..fa4fbec6bb 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -116,7 +116,7 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
}
}
if (res) {
-   printf("i2c_read returned %d (rlen=%d)\n", res, *recv_len);
+   printf("i2c_read returned %d (rlen=%zu)\n", res, *recv_len);
 #ifdef DEBUG
print_buffer(0, recvbuf, 1, *recv_len, 0);
 #endif
-- 
2.30.1



[PATCH v2 4/6] drivers: tpm: atmel_twi: do not use an offset byte

2021-11-10 Thread Mathew McBride
This driver was broken due to an empty offset byte being prepended
at the start of every transmission.

The hardware does not mimic an EEPROM device with registers so
an offset byte is not required.

Signed-off-by: Mathew McBride 
Acked-by: Ilias Apalodimas 
---
 drivers/tpm/tpm_atmel_twi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 4ff4cf4cd4..71b101406d 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -131,6 +131,7 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
 
 static int tpm_atmel_twi_probe(struct udevice *dev)
 {
+   i2c_set_chip_offset_len(dev, 0);
return 0;
 }
 
-- 
2.30.1



[PATCH v2 5/6] drivers: tpm: atmel_twi: implement get_desc operation

2021-11-10 Thread Mathew McBride
Without get_desc, the tpm command will not provide a
description of the device in 'tpm device' or 'tpm info'.

Due to the characteristics of the Atmel TPM it isn't
possible to determine certain attributes (e.g open/close
status) without using the TPM stack (compare Infineon
and ST TPM drivers), so just print out the chip model
and udevice name as the identifier.

Signed-off-by: Mathew McBride 
---
 drivers/tpm/tpm_atmel_twi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 71b101406d..a5dfb34846 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -52,7 +52,10 @@ static int tpm_atmel_twi_close(struct udevice *dev)
  */
 static int tpm_atmel_twi_get_desc(struct udevice *dev, char *buf, int size)
 {
-   return 0;
+   if (size < 50)
+   return -ENOSPC;
+
+   return snprintf(buf, size, "Atmel AT97SC3204T I2C 1.2 TPM (%s)", 
dev->name);
 }
 
 /*
-- 
2.30.1



[PATCH v2 2/6] cmd: tpm-v1: fix load_key_by_sha1 compile errors

2021-11-10 Thread Mathew McBride
This command is not compiled by default and has not been updated alongside
changes to the tpmv1 API, such as passing the TPM udevice to the relevant
functions.

Signed-off-by: Mathew McBride 
Reviewed-by: Ilias Apalodimas 
---
 cmd/tpm-v1.c | 10 +-
 lib/tpm-v1.c |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cmd/tpm-v1.c b/cmd/tpm-v1.c
index 55f2aeff46..bf238a9f2e 100644
--- a/cmd/tpm-v1.c
+++ b/cmd/tpm-v1.c
@@ -406,9 +406,9 @@ static int do_tpm_load_key_by_sha1(struct cmd_tbl *cmdtp, 
int flag, int argc,
void *key;
struct udevice *dev;
 
-   rc = get_tpm();
-   if (rc)
-   return rc;
+   err = get_tpm();
+   if (err)
+   return err;
 
if (argc < 5)
return CMD_RET_USAGE;
@@ -420,7 +420,7 @@ static int do_tpm_load_key_by_sha1(struct cmd_tbl *cmdtp, 
int flag, int argc,
return CMD_RET_FAILURE;
parse_byte_string(argv[4], usage_auth, NULL);
 
-   err = tpm_find_key_sha1(usage_auth, parent_hash, _handle);
+   err = tpm1_find_key_sha1(dev, usage_auth, parent_hash, _handle);
if (err) {
printf("Could not find matching parent key (err = %d)\n", err);
return CMD_RET_FAILURE;
@@ -428,7 +428,7 @@ static int do_tpm_load_key_by_sha1(struct cmd_tbl *cmdtp, 
int flag, int argc,
 
printf("Found parent key %08x\n", parent_handle);
 
-   err = tpm_load_key2_oiap(parent_handle, key, key_len, usage_auth,
+   err = tpm1_load_key2_oiap(dev, parent_handle, key, key_len, usage_auth,
 _handle);
if (!err) {
printf("Key handle is 0x%x\n", key_handle);
diff --git a/lib/tpm-v1.c b/lib/tpm-v1.c
index 8dc144080c..22a769c587 100644
--- a/lib/tpm-v1.c
+++ b/lib/tpm-v1.c
@@ -840,7 +840,7 @@ u32 tpm1_find_key_sha1(struct udevice *dev, const u8 
auth[20],
unsigned int i;
 
/* fetch list of already loaded keys in the TPM */
-   err = tpm_get_capability(dev, TPM_CAP_HANDLE, TPM_RT_KEY, buf,
+   err = tpm1_get_capability(dev, TPM_CAP_HANDLE, TPM_RT_KEY, buf,
 sizeof(buf));
if (err)
return -1;
@@ -852,7 +852,7 @@ u32 tpm1_find_key_sha1(struct udevice *dev, const u8 
auth[20],
/* now search a(/ the) key which we can access with the given auth */
for (i = 0; i < key_count; ++i) {
buf_len = sizeof(buf);
-   err = tpm_get_pub_key_oiap(key_handles[i], auth, buf, _len);
+   err = tpm1_get_pub_key_oiap(dev, key_handles[i], auth, buf, 
_len);
if (err && err != TPM_AUTHFAIL)
return -1;
if (err)
-- 
2.30.1



[PATCH v2 3/6] drivers: tpm: atmel_twi: drop non-DM_I2C compatibility

2021-11-10 Thread Mathew McBride
There are no users of this driver without DM_I2C

Signed-off-by: Mathew McBride 
Reviewed-by: Ilias Apalodimas 
---
 drivers/tpm/tpm_atmel_twi.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 2dcc2af67f..4ff4cf4cd4 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -81,22 +81,15 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
print_buffer(0, (void *)sendbuf, 1, send_size, 0);
 #endif
 
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   res = i2c_write(0x29, 0, 0, (uchar *)sendbuf, send_size);
-#else
res = dm_i2c_write(dev, 0, sendbuf, send_size);
-#endif
if (res) {
printf("i2c_write returned %d\n", res);
return -1;
}
 
start = get_timer(0);
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   while ((res = i2c_read(0x29, 0, 0, recvbuf, 10)))
-#else
+
while ((res = dm_i2c_read(dev, 0, recvbuf, 10)))
-#endif
{
/* TODO Use TIS_TIMEOUT from tpm_tis_infineon.h */
if (get_timer(start) > ATMEL_TPM_TIMEOUT_MS) {
@@ -116,12 +109,7 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
return -1;
} else {
*recv_len = hdr_recv_len;
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   res = i2c_read(0x29, 0, 0, recvbuf, *recv_len);
-#else
res = dm_i2c_read(dev, 0, recvbuf, *recv_len);
-#endif
-
}
}
if (res) {
-- 
2.30.1



[PATCH v2 1/6] cmd: tpm-v1: fix compile error in TPMv1 list resources command

2021-11-10 Thread Mathew McBride
This command is not compiled by default and was not
updated to pass the udevice to tpm_get_capability.

Signed-off-by: Mathew McBride 
Reviewed-by: Ilias Apalodimas 
---
 cmd/tpm-v1.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cmd/tpm-v1.c b/cmd/tpm-v1.c
index 3a7e35d525..55f2aeff46 100644
--- a/cmd/tpm-v1.c
+++ b/cmd/tpm-v1.c
@@ -582,6 +582,7 @@ static int do_tpm_flush(struct cmd_tbl *cmdtp, int flag, 
int argc,
 static int do_tpm_list(struct cmd_tbl *cmdtp, int flag, int argc,
   char *const argv[])
 {
+   struct udevice *dev;
int type = 0;
u16 res_count;
u8 buf[288];
@@ -589,6 +590,10 @@ static int do_tpm_list(struct cmd_tbl *cmdtp, int flag, 
int argc,
int err;
uint i;
 
+   err = get_tpm();
+   if (err)
+   return err;
+
if (argc != 2)
return CMD_RET_USAGE;
 
@@ -619,7 +624,7 @@ static int do_tpm_list(struct cmd_tbl *cmdtp, int flag, int 
argc,
}
 
/* fetch list of already loaded resources in the TPM */
-   err = tpm_get_capability(TPM_CAP_HANDLE, type, buf,
+   err = tpm_get_capability(dev, TPM_CAP_HANDLE, type, buf,
 sizeof(buf));
if (err) {
printf("tpm_get_capability returned error %d.\n", err);
-- 
2.30.1



[PATCH v2 0/6] drivers: tpm: Fix Atmel/Microchip TPMv1.2 issues

2021-11-10 Thread Mathew McBride
While doing bringup/rebase for the Ten64 I did some troubleshooting
for the tpm (v1.2, NOT tpm2) command which did not appear to function,
despite the Linux driver and tools (tcsd) working on the same board.

Evidently the Atmel TPM driver hasn't kept up with various step
changes in the I2C and TPM stacks, and while TPMv1.2 is quite
dated to TPMv2 it would be nice to make some use of the hardware
that is there.
(Admittedly I would love to replace our hardware TPM with an fTPM
but that is a project for another day)

There are also subcommands in tpm-v1 which also have been
missed in changes to the TPMv1 API and are fixed in this patchset.

Changes in v2:
- Include model number in get_desc output
  Example: "Atmel AT97SC3204T I2C 1.2 TPM (tpm@29)"

Mathew McBride (6):
  cmd: tpm-v1: fix compile error in TPMv1 list resources command
  cmd: tpm-v1: fix load_key_by_sha1 compile errors
  drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
  drivers: tpm: atmel_twi: do not use an offset byte
  drivers: tpm: atmel_twi: implement get_desc operation
  drivers: tpm: atmel_twi: fix printf specifier compile warning

 cmd/tpm-v1.c| 17 +++--
 drivers/tpm/tpm_atmel_twi.c | 22 +++---
 lib/tpm-v1.c|  4 ++--
 3 files changed, 20 insertions(+), 23 deletions(-)

-- 
2.30.1



[PATCH v2 2/2] board: traverse: add initial Ten64 support

2021-11-09 Thread Mathew McBride
The Ten64 is a networking-oriented MiniITX board
using the NXP LS1088A SoC.

This patch provides the bare minimum to support
Ten64 boards under U-Boot for distroboot.

Some related drivers have not yet been submitted
and this basic support lacks some of the
opinionated defaults provided by our firmware
distribution.

Signed-off-by: Mathew McBride 
---
 arch/arm/Kconfig   |  16 ++
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/fsl-ls1088a-ten64.dts | 377 +
 board/traverse/ten64/Kconfig   |  17 ++
 board/traverse/ten64/MAINTAINERS   |   8 +
 board/traverse/ten64/Makefile  |   6 +
 board/traverse/ten64/eth_ten64.c   |  47 
 board/traverse/ten64/ten64.c   | 438 +
 configs/ten64_tfa_defconfig| 119 
 include/configs/ten64.h|  55 
 10 files changed, 1085 insertions(+)
 create mode 100644 arch/arm/dts/fsl-ls1088a-ten64.dts
 create mode 100644 board/traverse/ten64/Kconfig
 create mode 100644 board/traverse/ten64/MAINTAINERS
 create mode 100644 board/traverse/ten64/Makefile
 create mode 100644 board/traverse/ten64/eth_ten64.c
 create mode 100644 board/traverse/ten64/ten64.c
 create mode 100644 configs/ten64_tfa_defconfig
 create mode 100644 include/configs/ten64.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ae911d6e35..52de5e838f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1761,6 +1761,21 @@ config TARGET_SL28
help
  Support for Kontron SMARC-sAL28 board.
 
+config TARGET_TEN64
+   bool "Support ten64"
+   select ARCH_LS1088A
+   select ARCH_MISC_INIT
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select ARCH_SUPPORT_TFABOOT
+   select BOARD_LATE_INIT
+   select SUPPORT_SPL
+   select FSL_DDR_INTERACTIVE if !SD_BOOT
+   select GPIO_EXTRA_HEADER
+   help
+ Support for Traverse Technologies Ten64 board, based
+ on NXP LS1088A.
+
 config TARGET_COLIBRI_PXA270
bool "Support colibri_pxa270"
select CPU_PXA
@@ -2197,6 +2212,7 @@ source "board/socionext/developerbox/Kconfig"
 source "board/st/stv0991/Kconfig"
 source "board/tcl/sl50/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
+source "board/traverse/ten64/Kconfig"
 source "board/variscite/dart_6ul/Kconfig"
 source "board/vscom/baltos/Kconfig"
 source "board/phytium/durian/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd8..2655707a43 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -478,6 +478,8 @@ dtb-$(CONFIG_TARGET_SL28) += fsl-ls1028a-kontron-sl28.dtb \
fsl-ls1028a-kontron-sl28-var3.dtb \
fsl-ls1028a-kontron-sl28-var4.dtb \
 
+dtb-$(CONFIG_TARGET_TEN64) += fsl-ls1088a-ten64.dtb
+
 dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
 dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
 dtb-$(CONFIG_TARGET_STARQLTECHN) += starqltechn.dtb
diff --git a/arch/arm/dts/fsl-ls1088a-ten64.dts 
b/arch/arm/dts/fsl-ls1088a-ten64.dts
new file mode 100644
index 00..43b669c642
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-ten64.dts
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for Travese Ten64 (LS1088) board
+ * Based on fsl-ls1088a-rdb.dts
+ * Copyright 2017-2020 NXP
+ * Copyright 2019-2021 Traverse Technologies
+ *
+ * Author: Mathew McBride 
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1088a.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "Traverse Ten64";
+   compatible = "traverse,ten64", "fsl,ls1088a";
+
+   aliases {
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   buttons {
+   compatible = "gpio-keys";
+
+   /* Fired by system controller when
+* external power off (e.g ATX Power Button)
+* asserted
+*/
+   powerdn {
+   label = "External Power Down";
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   interrupts = < 17 IRQ_TYPE_EDGE_FALLING>;
+   linux,code = ;
+   };
+
+   /* Rear Panel 'ADMIN' button (GPIO_H) */
+   admin {
+   label = "ADMIN button";
+   gpios = < 8 GPIO_ACTIVE_HIGH>;
+   interrupts = < 8 IRQ_TYPE_EDGE_RISING>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   sfp1down {
+   label = "ten64:green:sfp1:down";
+   gpios = < 11 GPIO_ACTIVE_HIGH>;
+   };
+
+   sfp2up {
+ 

[PATCH v2 1/2] board: traverse: add Ten64 board controller driver

2021-11-09 Thread Mathew McBride
Traverse Technologies Ten64 family boards use a microcontroller
to control low level board functions like startup and reset,
as well as holding details such as the board MAC address.

Communication between the CPU and microcontroller is via
I2C.

To keep the driver structure clean between the Ten64 board
file, DM_I2C, and a future utility command, this driver
has been implemented as a misc uclass device.

Signed-off-by: Mathew McBride 
---
 board/traverse/common/Kconfig|   6 +
 board/traverse/common/Makefile   |   1 +
 board/traverse/common/ten64-controller.h |  28 +++
 board/traverse/common/ten64_controller.c | 240 +++
 4 files changed, 275 insertions(+)
 create mode 100644 board/traverse/common/Kconfig
 create mode 100644 board/traverse/common/Makefile
 create mode 100644 board/traverse/common/ten64-controller.h
 create mode 100644 board/traverse/common/ten64_controller.c

diff --git a/board/traverse/common/Kconfig b/board/traverse/common/Kconfig
new file mode 100644
index 00..d34832bd0d
--- /dev/null
+++ b/board/traverse/common/Kconfig
@@ -0,0 +1,6 @@
+config TEN64_CONTROLLER
+   bool "Enable Ten64 board controller driver"
+   depends on TARGET_TEN64
+   help
+   Support for the board microcontroller on the Traverse
+   Ten64 family of boards.
diff --git a/board/traverse/common/Makefile b/board/traverse/common/Makefile
new file mode 100644
index 00..d31e3535b9
--- /dev/null
+++ b/board/traverse/common/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TEN64_CONTROLLER) += ten64_controller.o
diff --git a/board/traverse/common/ten64-controller.h 
b/board/traverse/common/ten64-controller.h
new file mode 100644
index 00..fed6af470d
--- /dev/null
+++ b/board/traverse/common/ten64-controller.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+#ifndef TEN64_CNTRL_H
+#define TEN64_CNTRL_H
+
+/**
+ * struct t64uc_board_info - Board Information Structure
+ * @mac: Base MAC address
+ * @cpuId: Microcontroller unique serial number
+ * @fwversion_major: Microcontroller version number (Major)
+ * @fwversion_minor: Microcontroller version number (Minor)
+ * @fwversion_patch: Microcontroller version number (Patch)
+ */
+struct t64uc_board_info {
+   u8 mac[6];
+   u32 cpuId[4];
+   u8 fwversion_major;
+   u8 fwversion_minor;
+   u8 fwversion_patch;
+} __packed;
+
+enum {
+   TEN64_CNTRL_GET_BOARD_INFO,
+   TEN64_CNTRL_10G_OFF,
+   TEN64_CNTRL_10G_ON,
+   TEN64_CNTRL_SET_NEXT_BOOTSRC
+};
+
+#endif
diff --git a/board/traverse/common/ten64_controller.c 
b/board/traverse/common/ten64_controller.c
new file mode 100644
index 00..d6ef8a8d0d
--- /dev/null
+++ b/board/traverse/common/ten64_controller.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Ten64 Board Microcontroller Driver
+ * Copyright 2021 Traverse Technologies Australia
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ten64-controller.h"
+
+/* Microcontroller command set and structure
+ * These should not be used outside this file
+ */
+
+#define T64_UC_DATA_MAX_SIZE128U
+#define T64_UC_API_MSG_HEADER_SIZE  4U
+#define T64_UC_API_HEADER_PREAMB0xcabe
+
+enum {
+   TEN64_UC_CMD_SET_BOARD_MAC = 0x10,
+   TEN64_UC_CMD_GET_BOARD_INFO = 0x11,
+   TEN64_UC_CMD_GET_STATE = 0x20,
+   TEN64_UC_CMD_SET_RESET_BTN_HOLD_TIME = 0x21,
+   TEN64_UC_CMD_ENABLE_RESET_BUTTON = 0x22,
+   TEN64_UC_CMD_SET_NEXT_BOOTSRC = 0x23,
+   TEN64_UC_CMD_ENABLE_10G = 0x24,
+   TEN64_UC_CMD_FWUP_GET_INFO = 0xA0,
+   TEN64_UC_CMD_FWUP_INIT = 0xA1,
+   TEN64_UC_CMD_FWUP_XFER = 0xA2,
+   TEN64_UC_CMD_FWUP_CHECK = 0xA3,
+   TEN64_UC_CMD_FWUPBOOT = 0x0A
+};
+
+/** struct t64uc_message - Wire Format for microcontroller messages
+ * @preamb: Message preamble (always 0xcabe)
+ * @cmd: Command to invoke
+ * @len: Length of data
+ * @data: Command data, up to 128 bytes
+ */
+struct t64uc_message {
+   u16 preamb;
+   u8 cmd;
+   u8 len;
+   u8 data[T64_UC_DATA_MAX_SIZE];
+}  __packed;
+
+enum {
+   T64_CTRL_IO_SET = 1U,
+   T64_CTRL_IO_CLEAR = 2U,
+   T64_CTRL_IO_TOGGLE = 3U,
+   T64_CTRL_IO_RESET = 4U,
+   T64_CTRL_IO_UNKNOWN = 5U
+};
+
+/** struct t64uc_board_10g_enable - Wrapper for 10G enable command
+ * @control: state to set the 10G retimer - either
+ *  T64_CTRL_IO_CLEAR (0x02) for off or
+ *  T64_CTRL_IO_SET (0x01) for on.
+ *
+ * This struct exists to simplify the wrapping of the
+ * command value into a microcontroller message and passing into
+ * functions.
+ */
+struct t64uc_board_10g_enable {
+   u8 control;
+} __packed;
+
+/** ten64_controller_send_recv_command() - Wrapper function to
+ * send a command to the microcontroller.
+ * @uc_chip: the DM I2C chip handle for the microcontroller
+ * @uc_cmd: the microcontroller API command c

[PATCH v2 0/2] Initial Traverse Ten64 board support

2021-11-09 Thread Mathew McBride
This patchset adds initial support for the Traverse Ten64
family, which is a networking focused Mini-ITX board using
NXP's LS1088A.

This patchset is the bare minimum necessary to get a system
running on U-Boot and booting via distroboot/EFI.

There are still a few more drivers to come, such as the
I2C setup for the USB5744 hub and EMC2301 fan controller.

Additionally, this patchset does not contain any of the
defaults (e.g bootmenu settings) we have in our official
firmware releases.

This set contains two additions:
- The driver for the board microcontroller
  The microcontroller holds the board MAC address
  and controls some board functions (like power to the
  10G retimer).
  This has been placed in boards/traverse/common/ as future
  Traverse products may use it as well.
- The board file itself

Changes in v2:
- Delete #if CONFIG_IS_DEFINED(..) uses
  Most of these are unlikely (such as compiling U-Boot
  with Ethernet and DPAA2) and the rest should go away
  with compiler optimization
- Move microcontroller constants (e.g API call numbers)
  to enum

Mathew McBride (2):
  board: traverse: add Ten64 board controller driver
  board: traverse: add initial Ten64 support

 arch/arm/Kconfig |  16 +
 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/fsl-ls1088a-ten64.dts   | 377 +++
 board/traverse/common/Kconfig|   6 +
 board/traverse/common/Makefile   |   1 +
 board/traverse/common/ten64-controller.h |  28 ++
 board/traverse/common/ten64_controller.c | 240 +
 board/traverse/ten64/Kconfig |  17 +
 board/traverse/ten64/MAINTAINERS |   8 +
 board/traverse/ten64/Makefile|   6 +
 board/traverse/ten64/eth_ten64.c |  47 +++
 board/traverse/ten64/ten64.c | 438 +++
 configs/ten64_tfa_defconfig  | 119 ++
 include/configs/ten64.h  |  55 +++
 14 files changed, 1360 insertions(+)
 create mode 100644 arch/arm/dts/fsl-ls1088a-ten64.dts
 create mode 100644 board/traverse/common/Kconfig
 create mode 100644 board/traverse/common/Makefile
 create mode 100644 board/traverse/common/ten64-controller.h
 create mode 100644 board/traverse/common/ten64_controller.c
 create mode 100644 board/traverse/ten64/Kconfig
 create mode 100644 board/traverse/ten64/MAINTAINERS
 create mode 100644 board/traverse/ten64/Makefile
 create mode 100644 board/traverse/ten64/eth_ten64.c
 create mode 100644 board/traverse/ten64/ten64.c
 create mode 100644 configs/ten64_tfa_defconfig
 create mode 100644 include/configs/ten64.h

-- 
2.30.1



Re: [PATCH 5/6] drivers: tpm: atmel_twi: implement get_desc operation

2021-11-09 Thread Mathew McBride



On Thu, Nov 4, 2021, at 6:39 PM, Ilias Apalodimas wrote:
> Hi Matthew,
> 
> On Thu, 4 Nov 2021 at 03:14, Mathew McBride  wrote:
> 
> >  static int tpm_atmel_twi_get_desc(struct udevice *dev, char *buf, int size)
> >  {
> > -   return 0;
> > +   if (size < 50)
> > +   return -ENOSPC;
> > +
> > +   return snprintf(buf, size, "Atmel 1.2 TPM (%s)", dev->name);
> 
> Is there anything more helpful we can print on that? Device ID,
> manufacturer ID maybe?
Perhaps the DT compatible would be useful?

=> tpm device
device 0: atmel,at97sc3204t TPM 1.2 (tpm@29)

tpm_version under Linux provides this, but it requires talking to the TPM over 
TIS:
$ tpm_version
TPM 1.2 Version Info:
  Chip Version:1.2.66.16
  Spec Level:  2
  Errata Revision: 3
  TPM Vendor ID:   ATML
  TPM Version: 0101
  Manufacturer Info:   41544d4c

> 
> Regards
> /Ilias
> >  }
> >
> >  /*
> > --
> > 2.30.1
> >
> 


[PATCH 6/6] drivers: tpm: atmel_twi: fix printf specifier compile warning

2021-11-03 Thread Mathew McBride
%d was being used as the specifier for size_t, leading to a
compiler warning

Signed-off-by: Mathew McBride 
---
 drivers/tpm/tpm_atmel_twi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 9ca33e4334..e84f9183d1 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -116,7 +116,7 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
}
}
if (res) {
-   printf("i2c_read returned %d (rlen=%d)\n", res, *recv_len);
+   printf("i2c_read returned %d (rlen=%zu)\n", res, *recv_len);
 #ifdef DEBUG
print_buffer(0, recvbuf, 1, *recv_len, 0);
 #endif
-- 
2.30.1



[PATCH 5/6] drivers: tpm: atmel_twi: implement get_desc operation

2021-11-03 Thread Mathew McBride
Without get_desc, the tpm command will not provide a
description of the device in 'tpm device' or 'tpm info'.

Due to the characteristics of the Atmel TPM it isn't
possible to determine certain attributes (e.g open/close
status) without using the TPM stack (compare Infineon
and ST TPM drivers), so just print out
the udevice name as a unique identifier.

Signed-off-by: Mathew McBride 
---
 drivers/tpm/tpm_atmel_twi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 71b101406d..9ca33e4334 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -52,7 +52,10 @@ static int tpm_atmel_twi_close(struct udevice *dev)
  */
 static int tpm_atmel_twi_get_desc(struct udevice *dev, char *buf, int size)
 {
-   return 0;
+   if (size < 50)
+   return -ENOSPC;
+
+   return snprintf(buf, size, "Atmel 1.2 TPM (%s)", dev->name);
 }
 
 /*
-- 
2.30.1



[PATCH 2/6] cmd: tpm-v1: fix load_key_by_sha1 compile errors

2021-11-03 Thread Mathew McBride
This command is not compiled by default and has not been updated alongside
changes to the tpmv1 API, such as passing the TPM udevice to the relevant
functions.

Signed-off-by: Mathew McBride 
---
 cmd/tpm-v1.c | 10 +-
 lib/tpm-v1.c |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cmd/tpm-v1.c b/cmd/tpm-v1.c
index 55f2aeff46..bf238a9f2e 100644
--- a/cmd/tpm-v1.c
+++ b/cmd/tpm-v1.c
@@ -406,9 +406,9 @@ static int do_tpm_load_key_by_sha1(struct cmd_tbl *cmdtp, 
int flag, int argc,
void *key;
struct udevice *dev;
 
-   rc = get_tpm();
-   if (rc)
-   return rc;
+   err = get_tpm();
+   if (err)
+   return err;
 
if (argc < 5)
return CMD_RET_USAGE;
@@ -420,7 +420,7 @@ static int do_tpm_load_key_by_sha1(struct cmd_tbl *cmdtp, 
int flag, int argc,
return CMD_RET_FAILURE;
parse_byte_string(argv[4], usage_auth, NULL);
 
-   err = tpm_find_key_sha1(usage_auth, parent_hash, _handle);
+   err = tpm1_find_key_sha1(dev, usage_auth, parent_hash, _handle);
if (err) {
printf("Could not find matching parent key (err = %d)\n", err);
return CMD_RET_FAILURE;
@@ -428,7 +428,7 @@ static int do_tpm_load_key_by_sha1(struct cmd_tbl *cmdtp, 
int flag, int argc,
 
printf("Found parent key %08x\n", parent_handle);
 
-   err = tpm_load_key2_oiap(parent_handle, key, key_len, usage_auth,
+   err = tpm1_load_key2_oiap(dev, parent_handle, key, key_len, usage_auth,
 _handle);
if (!err) {
printf("Key handle is 0x%x\n", key_handle);
diff --git a/lib/tpm-v1.c b/lib/tpm-v1.c
index 8dc144080c..22a769c587 100644
--- a/lib/tpm-v1.c
+++ b/lib/tpm-v1.c
@@ -840,7 +840,7 @@ u32 tpm1_find_key_sha1(struct udevice *dev, const u8 
auth[20],
unsigned int i;
 
/* fetch list of already loaded keys in the TPM */
-   err = tpm_get_capability(dev, TPM_CAP_HANDLE, TPM_RT_KEY, buf,
+   err = tpm1_get_capability(dev, TPM_CAP_HANDLE, TPM_RT_KEY, buf,
 sizeof(buf));
if (err)
return -1;
@@ -852,7 +852,7 @@ u32 tpm1_find_key_sha1(struct udevice *dev, const u8 
auth[20],
/* now search a(/ the) key which we can access with the given auth */
for (i = 0; i < key_count; ++i) {
buf_len = sizeof(buf);
-   err = tpm_get_pub_key_oiap(key_handles[i], auth, buf, _len);
+   err = tpm1_get_pub_key_oiap(dev, key_handles[i], auth, buf, 
_len);
if (err && err != TPM_AUTHFAIL)
return -1;
if (err)
-- 
2.30.1



[PATCH 4/6] drivers: tpm: atmel_twi: do not use an offset byte

2021-11-03 Thread Mathew McBride
This driver was broken due to an empty offset byte being prepended
at the start of every transmission.

The hardware does not mimic an EEPROM device with registers so
an offset byte is not required.

Signed-off-by: Mathew McBride 
---
 drivers/tpm/tpm_atmel_twi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 4ff4cf4cd4..71b101406d 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -131,6 +131,7 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
 
 static int tpm_atmel_twi_probe(struct udevice *dev)
 {
+   i2c_set_chip_offset_len(dev, 0);
return 0;
 }
 
-- 
2.30.1



[PATCH 3/6] drivers: tpm: atmel_twi: drop non-DM_I2C compatibility

2021-11-03 Thread Mathew McBride
There are no users of this driver without DM_I2C

Signed-off-by: Mathew McBride 
---
 drivers/tpm/tpm_atmel_twi.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/tpm/tpm_atmel_twi.c b/drivers/tpm/tpm_atmel_twi.c
index 2dcc2af67f..4ff4cf4cd4 100644
--- a/drivers/tpm/tpm_atmel_twi.c
+++ b/drivers/tpm/tpm_atmel_twi.c
@@ -81,22 +81,15 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
print_buffer(0, (void *)sendbuf, 1, send_size, 0);
 #endif
 
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   res = i2c_write(0x29, 0, 0, (uchar *)sendbuf, send_size);
-#else
res = dm_i2c_write(dev, 0, sendbuf, send_size);
-#endif
if (res) {
printf("i2c_write returned %d\n", res);
return -1;
}
 
start = get_timer(0);
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   while ((res = i2c_read(0x29, 0, 0, recvbuf, 10)))
-#else
+
while ((res = dm_i2c_read(dev, 0, recvbuf, 10)))
-#endif
{
/* TODO Use TIS_TIMEOUT from tpm_tis_infineon.h */
if (get_timer(start) > ATMEL_TPM_TIMEOUT_MS) {
@@ -116,12 +109,7 @@ static int tpm_atmel_twi_xfer(struct udevice *dev,
return -1;
} else {
*recv_len = hdr_recv_len;
-#if !CONFIG_IS_ENABLED(DM_I2C)
-   res = i2c_read(0x29, 0, 0, recvbuf, *recv_len);
-#else
res = dm_i2c_read(dev, 0, recvbuf, *recv_len);
-#endif
-
}
}
if (res) {
-- 
2.30.1



[PATCH 1/6] cmd: tpm-v1: fix compile error in TPMv1 list resources command

2021-11-03 Thread Mathew McBride
This command is not compiled by default and was not
updated to pass the udevice to tpm_get_capability.

Signed-off-by: Mathew McBride 
---
 cmd/tpm-v1.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cmd/tpm-v1.c b/cmd/tpm-v1.c
index 3a7e35d525..55f2aeff46 100644
--- a/cmd/tpm-v1.c
+++ b/cmd/tpm-v1.c
@@ -582,6 +582,7 @@ static int do_tpm_flush(struct cmd_tbl *cmdtp, int flag, 
int argc,
 static int do_tpm_list(struct cmd_tbl *cmdtp, int flag, int argc,
   char *const argv[])
 {
+   struct udevice *dev;
int type = 0;
u16 res_count;
u8 buf[288];
@@ -589,6 +590,10 @@ static int do_tpm_list(struct cmd_tbl *cmdtp, int flag, 
int argc,
int err;
uint i;
 
+   err = get_tpm();
+   if (err)
+   return err;
+
if (argc != 2)
return CMD_RET_USAGE;
 
@@ -619,7 +624,7 @@ static int do_tpm_list(struct cmd_tbl *cmdtp, int flag, int 
argc,
}
 
/* fetch list of already loaded resources in the TPM */
-   err = tpm_get_capability(TPM_CAP_HANDLE, type, buf,
+   err = tpm_get_capability(dev, TPM_CAP_HANDLE, type, buf,
 sizeof(buf));
if (err) {
printf("tpm_get_capability returned error %d.\n", err);
-- 
2.30.1



[PATCH 0/6] Fix Atmel/Microchip TPMv1.2 issues

2021-11-03 Thread Mathew McBride
While doing bringup/rebase for the Ten64 I did some troubleshooting
for the tpm (v1.2, NOT tpm2) command which did not appear to function,
despite the Linux driver and tools (tcsd) working on the same board.

Evidently the Atmel TPM driver hasn't kept up with various step
changes in the I2C and TPM stacks, and while TPMv1.2 is quite
dated to TPMv2 it would be nice to make some use of the hardware
that is there.
(Admittedly I would love to replace our hardware TPM with an fTPM
but that is a project for another day)

There are also subcommands in tpm-v1 which also have been
missed in changes to the TPMv1 API and are fixed in this patchset.

I have checked that this set isn't impacted by Ilias' TPM cleanup
series[1] which only touches TPMv2.

[1] - 
http://patchwork.ozlabs.org/project/uboot/cover/20211103150910.69732-1-ilias.apalodi...@linaro.org/

Mathew McBride (6):
  cmd: tpm-v1: fix compile error in TPMv1 list resources command
  cmd: tpm-v1: fix load_key_by_sha1 compile errors
  drivers: tpm: atmel_twi: drop non-DM_I2C compatibility
  drivers: tpm: atmel_twi: do not use an offset byte
  drivers: tpm: atmel_twi: implement get_desc operation
  drivers: tpm: atmel_twi: fix printf specifier compile warning

 cmd/tpm-v1.c| 17 +++--
 drivers/tpm/tpm_atmel_twi.c | 22 +++---
 lib/tpm-v1.c|  4 ++--
 3 files changed, 20 insertions(+), 23 deletions(-)

-- 
2.30.1



[PATCH 2/2] board: traverse: add initial Ten64 support

2021-11-02 Thread Mathew McBride
The Ten64 is a networking-oriented MiniITX board
using the NXP LS1088A SoC.

This patch provides the bare minimum to support
Ten64 boards under U-Boot for distroboot.

Some related drivers have not yet been submitted
and this basic support lacks some of the
opinionated defaults provided by our firmware
distribution.

Signed-off-by: Mathew McBride 
---
 arch/arm/Kconfig   |  16 ++
 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/fsl-ls1088a-ten64.dts | 377 +
 board/traverse/ten64/Kconfig   |  17 ++
 board/traverse/ten64/MAINTAINERS   |   8 +
 board/traverse/ten64/Makefile  |   6 +
 board/traverse/ten64/eth_ten64.c   |  49 
 board/traverse/ten64/ten64.c   | 433 +
 configs/ten64_tfa_defconfig| 119 
 include/configs/ten64.h|  55 
 10 files changed, 1082 insertions(+)
 create mode 100644 arch/arm/dts/fsl-ls1088a-ten64.dts
 create mode 100644 board/traverse/ten64/Kconfig
 create mode 100644 board/traverse/ten64/MAINTAINERS
 create mode 100644 board/traverse/ten64/Makefile
 create mode 100644 board/traverse/ten64/eth_ten64.c
 create mode 100644 board/traverse/ten64/ten64.c
 create mode 100644 configs/ten64_tfa_defconfig
 create mode 100644 include/configs/ten64.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b4808d4c75..d732a5a676 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1758,6 +1758,21 @@ config TARGET_SL28
help
  Support for Kontron SMARC-sAL28 board.
 
+config TARGET_TEN64
+   bool "Support ten64"
+   select ARCH_LS1088A
+   select ARCH_MISC_INIT
+   select ARM64
+   select ARMV8_MULTIENTRY
+   select ARCH_SUPPORT_TFABOOT
+   select BOARD_LATE_INIT
+   select SUPPORT_SPL
+   select FSL_DDR_INTERACTIVE if !SD_BOOT
+   select GPIO_EXTRA_HEADER
+   help
+ Support for Traverse Technologies Ten64 board, based
+ on NXP LS1088A.
+
 config TARGET_COLIBRI_PXA270
bool "Support colibri_pxa270"
select CPU_PXA
@@ -2194,6 +2209,7 @@ source "board/socionext/developerbox/Kconfig"
 source "board/st/stv0991/Kconfig"
 source "board/tcl/sl50/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
+source "board/traverse/ten64/Kconfig"
 source "board/variscite/dart_6ul/Kconfig"
 source "board/vscom/baltos/Kconfig"
 source "board/phytium/durian/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd8..2655707a43 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -478,6 +478,8 @@ dtb-$(CONFIG_TARGET_SL28) += fsl-ls1028a-kontron-sl28.dtb \
fsl-ls1028a-kontron-sl28-var3.dtb \
fsl-ls1028a-kontron-sl28-var4.dtb \
 
+dtb-$(CONFIG_TARGET_TEN64) += fsl-ls1088a-ten64.dtb
+
 dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
 dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
 dtb-$(CONFIG_TARGET_STARQLTECHN) += starqltechn.dtb
diff --git a/arch/arm/dts/fsl-ls1088a-ten64.dts 
b/arch/arm/dts/fsl-ls1088a-ten64.dts
new file mode 100644
index 00..43b669c642
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1088a-ten64.dts
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for Travese Ten64 (LS1088) board
+ * Based on fsl-ls1088a-rdb.dts
+ * Copyright 2017-2020 NXP
+ * Copyright 2019-2021 Traverse Technologies
+ *
+ * Author: Mathew McBride 
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1088a.dtsi"
+
+#include 
+#include 
+
+/ {
+   model = "Traverse Ten64";
+   compatible = "traverse,ten64", "fsl,ls1088a";
+
+   aliases {
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   buttons {
+   compatible = "gpio-keys";
+
+   /* Fired by system controller when
+* external power off (e.g ATX Power Button)
+* asserted
+*/
+   powerdn {
+   label = "External Power Down";
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   interrupts = < 17 IRQ_TYPE_EDGE_FALLING>;
+   linux,code = ;
+   };
+
+   /* Rear Panel 'ADMIN' button (GPIO_H) */
+   admin {
+   label = "ADMIN button";
+   gpios = < 8 GPIO_ACTIVE_HIGH>;
+   interrupts = < 8 IRQ_TYPE_EDGE_RISING>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   sfp1down {
+   label = "ten64:green:sfp1:down";
+   gpios = < 11 GPIO_ACTIVE_HIGH>;
+   };
+
+   sfp2up {
+ 

[PATCH 1/2] board: traverse: add Ten64 board controller driver

2021-11-02 Thread Mathew McBride
Traverse Technologies Ten64 family boards use a microcontroller
to control low level board functions like startup and reset,
as well as holding details such as the board MAC address.

Communication between the CPU and microcontroller is via
I2C.

To keep the driver structure clean between the Ten64 board
file, DM_I2C, and a future utility command, this driver
has been implemented as a misc uclass device.

Signed-off-by: Mathew McBride 
---
 board/traverse/common/Kconfig|   6 +
 board/traverse/common/Makefile   |   1 +
 board/traverse/common/ten64-controller.h |  28 +++
 board/traverse/common/ten64_controller.c | 238 +++
 4 files changed, 273 insertions(+)
 create mode 100644 board/traverse/common/Kconfig
 create mode 100644 board/traverse/common/Makefile
 create mode 100644 board/traverse/common/ten64-controller.h
 create mode 100644 board/traverse/common/ten64_controller.c

diff --git a/board/traverse/common/Kconfig b/board/traverse/common/Kconfig
new file mode 100644
index 00..d34832bd0d
--- /dev/null
+++ b/board/traverse/common/Kconfig
@@ -0,0 +1,6 @@
+config TEN64_CONTROLLER
+   bool "Enable Ten64 board controller driver"
+   depends on TARGET_TEN64
+   help
+   Support for the board microcontroller on the Traverse
+   Ten64 family of boards.
diff --git a/board/traverse/common/Makefile b/board/traverse/common/Makefile
new file mode 100644
index 00..d31e3535b9
--- /dev/null
+++ b/board/traverse/common/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TEN64_CONTROLLER) += ten64_controller.o
diff --git a/board/traverse/common/ten64-controller.h 
b/board/traverse/common/ten64-controller.h
new file mode 100644
index 00..fed6af470d
--- /dev/null
+++ b/board/traverse/common/ten64-controller.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+#ifndef TEN64_CNTRL_H
+#define TEN64_CNTRL_H
+
+/**
+ * struct t64uc_board_info - Board Information Structure
+ * @mac: Base MAC address
+ * @cpuId: Microcontroller unique serial number
+ * @fwversion_major: Microcontroller version number (Major)
+ * @fwversion_minor: Microcontroller version number (Minor)
+ * @fwversion_patch: Microcontroller version number (Patch)
+ */
+struct t64uc_board_info {
+   u8 mac[6];
+   u32 cpuId[4];
+   u8 fwversion_major;
+   u8 fwversion_minor;
+   u8 fwversion_patch;
+} __packed;
+
+enum {
+   TEN64_CNTRL_GET_BOARD_INFO,
+   TEN64_CNTRL_10G_OFF,
+   TEN64_CNTRL_10G_ON,
+   TEN64_CNTRL_SET_NEXT_BOOTSRC
+};
+
+#endif
diff --git a/board/traverse/common/ten64_controller.c 
b/board/traverse/common/ten64_controller.c
new file mode 100644
index 00..11e068f94f
--- /dev/null
+++ b/board/traverse/common/ten64_controller.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Ten64 Board Microcontroller Driver
+ * Copyright 2021 Traverse Technologies Australia
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ten64-controller.h"
+
+/* Microcontroller command set and structure
+ * These should not be used outside this file
+ */
+
+#define T64_UC_DATA_MAX_SIZE128U
+#define T64_UC_API_MSG_HEADER_SIZE  4U
+#define T64_UC_API_HEADER_PREAMB0xcabe
+
+#define TEN64_UC_CMD_SET_BOARD_MAC 0x10
+#define TEN64_UC_CMD_GET_BOARD_INFO0x11
+
+#define TEN64_UC_CMD_GET_STATE 0x20
+#define TEN64_UC_CMD_SET_RESET_BTN_HOLD_TIME   0x21
+#define TEN64_UC_CMD_ENABLE_RESET_BUTTON   0x22
+#define TEN64_UC_CMD_SET_NEXT_BOOTSRC  0x23
+#define TEN64_UC_CMD_ENABLE_10G0x24
+
+#define TEN64_UC_CMD_FWUP_GET_INFO 0xA0
+#define TEN64_UC_CMD_FWUP_INIT 0xA1
+#define TEN64_UC_CMD_FWUP_XFER 0xA2
+#define TEN64_UC_CMD_FWUP_CHECK0xA3
+#define TEN64_UC_CMD_FWUPBOOT  0xA
+
+/** struct t64uc_message - Wire Format for microcontroller messages
+ * @preamb: Message preamble (always 0xcabe)
+ * @cmd: Command to invoke
+ * @len: Length of data
+ * @data: Command data, up to 128 bytes
+ */
+struct t64uc_message {
+   u16 preamb;
+   u8 cmd;
+   u8 len;
+   u8 data[T64_UC_DATA_MAX_SIZE];
+}  __packed;
+
+#defineT64_CTRL_IO_SET 1U
+#defineT64_CTRL_IO_CLEAR   2U
+#defineT64_CTRL_IO_TOGGLE  3U
+#defineT64_CTRL_IO_RESET   4U
+#defineT64_CTRL_IO_UNKNOWN 5U
+
+/** struct t64uc_board_10g_enable - Wrapper for 10G enable command
+ * @control: state to set the 10G retimer - either
+ *  T64_CTRL_IO_CLEAR (0x02) for off or
+ *  T64_CTRL_IO_SET (0x01) for on.
+ *
+ * This struct exists to simplify the wrapping of the
+ * command value into a microcontroller message and passing into
+ * functions.
+ */
+struct t64uc_board_10g_enable {
+   u8 control;
+} __packed;
+
+/** ten64_controller_send_recv_command() - Wrapper 

[PATCH 0/2] Initial Traverse Ten64 board support

2021-11-02 Thread Mathew McBride
This patchset adds initial support for the Traverse Ten64
family, which is a networking focused Mini-ITX board using
NXP's LS1088A.

This patchset is the bare minimum necessary to get a system
running on U-Boot and booting via distroboot/EFI.

There are still a few more drivers to come, such as the
I2C setup for the USB5744 hub and EMC2301 fan controller.

Additionally, this patchset does not contain any of the
defaults (e.g bootmenu settings) we have in our official
firmware releases.

This set contains two additions:
- The driver for the board microcontroller
  The microcontroller holds the board MAC address
  and controls some board functions (like power to the
  10G retimer).
  This has been placed in boards/traverse/common/ as future
  Traverse products may use it as well.
- The board file itself

Mathew McBride (2):
  board: traverse: add Ten64 board controller driver
  board: traverse: add initial Ten64 support

 arch/arm/Kconfig |  16 +
 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/fsl-ls1088a-ten64.dts   | 377 
 board/traverse/common/Kconfig|   6 +
 board/traverse/common/Makefile   |   1 +
 board/traverse/common/ten64-controller.h |  28 ++
 board/traverse/common/ten64_controller.c | 238 +
 board/traverse/ten64/Kconfig |  17 +
 board/traverse/ten64/MAINTAINERS |   8 +
 board/traverse/ten64/Makefile|   6 +
 board/traverse/ten64/eth_ten64.c |  49 +++
 board/traverse/ten64/ten64.c | 433 +++
 configs/ten64_tfa_defconfig  | 119 +++
 include/configs/ten64.h  |  55 +++
 14 files changed, 1355 insertions(+)
 create mode 100644 arch/arm/dts/fsl-ls1088a-ten64.dts
 create mode 100644 board/traverse/common/Kconfig
 create mode 100644 board/traverse/common/Makefile
 create mode 100644 board/traverse/common/ten64-controller.h
 create mode 100644 board/traverse/common/ten64_controller.c
 create mode 100644 board/traverse/ten64/Kconfig
 create mode 100644 board/traverse/ten64/MAINTAINERS
 create mode 100644 board/traverse/ten64/Makefile
 create mode 100644 board/traverse/ten64/eth_ten64.c
 create mode 100644 board/traverse/ten64/ten64.c
 create mode 100644 configs/ten64_tfa_defconfig
 create mode 100644 include/configs/ten64.h

-- 
2.30.1



[PATCH 3/4] rtc: rx8025: set date in a single i2c transaction

2021-09-17 Thread Mathew McBride
The RX8025/RX8035 does not like having it's time registers
set byte-by-byte in separate I2C transactions.

>From the note at the top of the file, it appears
target-dependent workarounds have been used in the
past for this.

Resolve this by setting the time registers in a single
I2C transaction.

As part of this, also ensure the '24/12' flag in the RTC
is reset before writing the date (instead of after), otherwise
the RX8035 will clear the seconds and minutes registers.

Tested on Traverse Ten64 (NXP LS1088A) with RX8035.

Signed-off-by: Mathew McBride 
---
 drivers/rtc/rx8025.c | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/rtc/rx8025.c b/drivers/rtc/rx8025.c
index 09bf365f63..9423a1bb82 100644
--- a/drivers/rtc/rx8025.c
+++ b/drivers/rtc/rx8025.c
@@ -39,6 +39,7 @@ enum rx_model {
 #define RTC_DATE_REG_ADDR  0x04
 #define RTC_MON_REG_ADDR   0x05
 #define RTC_YR_REG_ADDR0x06
+#define RTC_OFFSET_REG_ADDR0x07
 
 #define RTC_CTL1_REG_ADDR  0x0e
 #define RTC_CTL2_REG_ADDR  0x0f
@@ -152,6 +153,19 @@ static int rx8025_rtc_get(struct udevice *dev, struct 
rtc_time *tmp)
  */
 static int rx8025_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
 {
+   /* To work around the read/write cycle issue mentioned
+* at the top of this file, write all the time registers
+* in one I2C transaction
+*/
+   u8 write_op[8];
+
+   /* 2412 flag must be set before doing a RTC write,
+* otherwise the seconds and minute register
+* will be cleared when the flag is set
+*/
+   if (rtc_write(dev, RTC_CTL1_REG_ADDR, RTC_CTL1_BIT_2412))
+   return -EIO;
+
DEBUGR("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
   tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
   tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
@@ -159,28 +173,16 @@ static int rx8025_rtc_set(struct udevice *dev, const 
struct rtc_time *tmp)
if (tmp->tm_year < 1970 || tmp->tm_year > 2069)
printf("WARNING: year should be between 1970 and 2069!\n");
 
-   if (rtc_write(dev, RTC_YR_REG_ADDR, bin2bcd(tmp->tm_year % 100)))
-   return -EIO;
-
-   if (rtc_write(dev, RTC_MON_REG_ADDR, bin2bcd(tmp->tm_mon)))
-   return -EIO;
-
-   if (rtc_write(dev, RTC_DAY_REG_ADDR, bin2bcd(tmp->tm_wday)))
-   return -EIO;
-
-   if (rtc_write(dev, RTC_DATE_REG_ADDR, bin2bcd(tmp->tm_mday)))
-   return -EIO;
-
-   if (rtc_write(dev, RTC_HR_REG_ADDR, bin2bcd(tmp->tm_hour)))
-   return -EIO;
-
-   if (rtc_write(dev, RTC_MIN_REG_ADDR, bin2bcd(tmp->tm_min)))
-   return -EIO;
-
-   if (rtc_write(dev, RTC_SEC_REG_ADDR, bin2bcd(tmp->tm_sec)))
-   return -EIO;
+   write_op[RTC_SEC_REG_ADDR]  = bin2bcd(tmp->tm_sec);
+   write_op[RTC_MIN_REG_ADDR]  = bin2bcd(tmp->tm_min);
+   write_op[RTC_HR_REG_ADDR]   = bin2bcd(tmp->tm_hour);
+   write_op[RTC_DAY_REG_ADDR]  = bin2bcd(tmp->tm_wday);
+   write_op[RTC_DATE_REG_ADDR] = bin2bcd(tmp->tm_mday);
+   write_op[RTC_MON_REG_ADDR]  = bin2bcd(tmp->tm_mon);
+   write_op[RTC_YR_REG_ADDR]   = bin2bcd(tmp->tm_year % 100);
+   write_op[RTC_OFFSET_REG_ADDR] = 0;
 
-   return rtc_write(dev, RTC_CTL1_REG_ADDR, RTC_CTL1_BIT_2412);
+   return dm_i2c_write(dev, 0, _op[0], 8);
 }
 
 /*
-- 
2.30.1



[PATCH 4/4] rtc: rx8025: revise single register write to use offset

2021-09-17 Thread Mathew McBride
Writing of individual registers was not functioning
correctly as a 0 'offset' byte under DM-managed
I2C was being appended in front of register we
wanted to access.

Signed-off-by: Mathew McBride 
---
 drivers/rtc/rx8025.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rx8025.c b/drivers/rtc/rx8025.c
index 9423a1bb82..1394c2306a 100644
--- a/drivers/rtc/rx8025.c
+++ b/drivers/rtc/rx8025.c
@@ -214,11 +214,14 @@ static int rx8025_rtc_reset(struct udevice *dev)
  */
 static int rtc_write(struct udevice *dev, uchar reg, uchar val)
 {
-   uchar buf[2];
-   buf[0] = reg << 4;
-   buf[1] = val;
+   /* The RX8025/RX8035 uses the top 4 bits of the
+* 'offset' byte as the start register address,
+* and the bottom 4 bits as a 'transfer' mode setting
+* (only applicable for reads)
+*/
+   u8 offset = (reg << 4);
 
-   if (dm_i2c_write(dev, 0, buf, 2)) {
+   if (dm_i2c_reg_write(dev, offset, val)) {
printf("Error writing to RTC\n");
return -EIO;
}
-- 
2.30.1



[PATCH 0/4] Add EPSON RX8035 RTC support

2021-09-17 Thread Mathew McBride
This patchset adds support for the EPSON RX8035 real time
clock to the rx8025 driver. The two devices are very similar
and with only minor differences for basic real time clock functions.

Some issues have been identified with the handling of date
setting and clock reset with the U-Boot driver which are resolved
with these patches.

It appears only one board (socrates) in the U-Boot tree uses this driver
at present, the other users either not in tree or removed under
previous cleanups, so take this opportunity to remove non_DM-RTC
support as well, and vestiges of previous board specific hacks.

The Traverse Technologies Ten64 board will be introduced in the 
near future and it will use this driver.

Mathew McBride (4):
  rtc: rx8025: drop non-DM support
  rtc: rx8025: add support for EPSON RX8035.
  rtc: rx8025: set date in a single i2c transaction
  rtc: rx8025: revise single register write to use offset

 drivers/rtc/Kconfig  |   1 +
 drivers/rtc/rx8025.c | 166 ---
 2 files changed, 63 insertions(+), 104 deletions(-)

-- 
2.30.1



[PATCH 2/4] rtc: rx8025: add support for EPSON RX8035.

2021-09-17 Thread Mathew McBride
The RX8035 is a newer model from EPSON which is
very similar in operation to the RX8025.

The changes mirror similar ones that will be
in Linux 5.15:
https://lore.kernel.org/all/20210709044518.28769-2-m...@traverse.com.au/

The UBOOT_DRIVER ID has also been corrected, previously
it declared itself as rx8010sj_rtc which is a different driver.

Signed-off-by: Mathew McBride 
---
 drivers/rtc/rx8025.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rx8025.c b/drivers/rtc/rx8025.c
index 36e5b0122c..09bf365f63 100644
--- a/drivers/rtc/rx8025.c
+++ b/drivers/rtc/rx8025.c
@@ -24,6 +24,11 @@
 #endif
 /*-*/
 
+enum rx_model {
+   model_rx_8025,
+   model_rx_8035,
+};
+
 /*
  * RTC register addresses
  */
@@ -64,6 +69,20 @@
 
 static int rtc_write(struct udevice *dev, uchar reg, uchar val);
 
+static int rx8025_is_osc_stopped(enum rx_model model, int ctrl2)
+{
+   int xstp = ctrl2 & RTC_CTL2_BIT_XST;
+   /* XSTP bit has different polarity on RX-8025 vs RX-8035.
+* RX-8025: 0 == oscillator stopped
+* RX-8035: 1 == oscillator stopped
+*/
+
+   if (model == model_rx_8025)
+   xstp = !xstp;
+
+   return xstp;
+}
+
 /*
  * Get the current time from the RTC
  */
@@ -101,8 +120,7 @@ static int rx8025_rtc_get(struct udevice *dev, struct 
rtc_time *tmp)
printf("RTC: voltage drop detected\n");
rel = -1;
}
-
-   if (!(ctl2 & RTC_CTL2_BIT_XST)) {
+   if (rx8025_is_osc_stopped(dev->driver_data, ctl2)) {
printf("RTC: oscillator stop detected\n");
rel = -1;
}
@@ -180,7 +198,11 @@ static int rx8025_rtc_reset(struct udevice *dev)
 
ctl2 = rtc_read(RTC_CTL2_REG_ADDR);
ctl2 &= ~(RTC_CTL2_BIT_PON | RTC_CTL2_BIT_VDET);
-   ctl2 |= RTC_CTL2_BIT_XST | RTC_CTL2_BIT_VDSL;
+
+   if (dev->driver_data == model_rx_8035)
+   ctl2 &= ~(RTC_CTL2_BIT_XST);
+   else
+   ctl2 |= RTC_CTL2_BIT_XST;
 
return rtc_write(dev, RTC_CTL2_REG_ADDR, ctl2);
 }
@@ -223,11 +245,12 @@ static const struct rtc_ops rx8025_rtc_ops = {
 };
 
 static const struct udevice_id rx8025_rtc_ids[] = {
-   { .compatible = "epson,rx8025" },
+   { .compatible = "epson,rx8025", .data = model_rx_8025 },
+   { .compatible = "epson,rx8035", .data = model_rx_8035 },
{ }
 };
 
-U_BOOT_DRIVER(rx8010sj_rtc) = {
+U_BOOT_DRIVER(rx8025_rtc) = {
.name = "rx8025_rtc",
.id   = UCLASS_RTC,
.probe= rx8025_probe,
-- 
2.30.1



[PATCH 1/4] rtc: rx8025: drop non-DM support

2021-09-17 Thread Mathew McBride
A search of the tree showed there is only one user
of this driver (soon to be two) - board/socrates

The second user will be the Traverse Ten64 board.

Both these boards have DM_RTC.

Signed-off-by: Mathew McBride 
---
 drivers/rtc/Kconfig  |  1 +
 drivers/rtc/rx8025.c | 80 +++-
 2 files changed, 6 insertions(+), 75 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b6692e62df..71777cdd05 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -136,6 +136,7 @@ config RTC_RX8010SJ
 
 config RTC_RX8025
bool "Enable RX8025 driver"
+   depends on DM_RTC
help
  Support for Epson RX8025 Real Time Clock devices.
 
diff --git a/drivers/rtc/rx8025.c b/drivers/rtc/rx8025.c
index e717dcbbfe..36e5b0122c 100644
--- a/drivers/rtc/rx8025.c
+++ b/drivers/rtc/rx8025.c
@@ -24,22 +24,6 @@
 #endif
 /*-*/
 
-#ifndef CONFIG_SYS_I2C_RTC_ADDR
-# define CONFIG_SYS_I2C_RTC_ADDR   0x32
-#endif
-
-#ifdef CONFIG_DM_RTC
-#define DEV_TYPE struct udevice
-#else
-/* Local udevice */
-struct ludevice {
-   u8 chip;
-};
-
-#define DEV_TYPE struct ludevice
-
-#endif
-
 /*
  * RTC register addresses
  */
@@ -74,39 +58,22 @@ struct ludevice {
  * address in a first cycle that is terminated by
  * a STOP condition. The chips needs a 'restart'
  * sequence (start sequence without a prior stop).
- * This driver has been written for a 4xx board.
- * U-Boot's 4xx i2c driver is currently not capable
- * to generate such cycles to some work arounds
- * are used.
  */
 
-/* static uchar rtc_read (uchar reg); */
-#ifdef CONFIG_DM_RTC
-/*
- * on mpc85xx based board with DM and offset len 1
- * accessing rtc works fine. May we can drop this ?
- */
 #define rtc_read(reg) buf[(reg) & 0xf]
-#else
-#define rtc_read(reg) buf[((reg) + 1) & 0xf]
-#endif
 
-static int rtc_write(DEV_TYPE *dev, uchar reg, uchar val);
+static int rtc_write(struct udevice *dev, uchar reg, uchar val);
 
 /*
  * Get the current time from the RTC
  */
-static int rx8025_rtc_get(DEV_TYPE *dev, struct rtc_time *tmp)
+static int rx8025_rtc_get(struct udevice *dev, struct rtc_time *tmp)
 {
int rel = 0;
uchar sec, min, hour, mday, wday, mon, year, ctl2;
uchar buf[16];
 
-#ifdef CONFIG_DM_RTC
if (dm_i2c_read(dev, 0, buf, sizeof(buf))) {
-#else
-   if (i2c_read(dev->chip, 0, 0, buf, 16)) {
-#endif
printf("Error reading from RTC\n");
return -EIO;
}
@@ -165,7 +132,7 @@ static int rx8025_rtc_get(DEV_TYPE *dev, struct rtc_time 
*tmp)
 /*
  * Set the RTC
  */
-static int rx8025_rtc_set(DEV_TYPE *dev, const struct rtc_time *tmp)
+static int rx8025_rtc_set(struct udevice *dev, const struct rtc_time *tmp)
 {
DEBUGR("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
   tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
@@ -201,16 +168,12 @@ static int rx8025_rtc_set(DEV_TYPE *dev, const struct 
rtc_time *tmp)
 /*
  * Reset the RTC
  */
-static int rx8025_rtc_reset(DEV_TYPE *dev)
+static int rx8025_rtc_reset(struct udevice *dev)
 {
uchar buf[16];
uchar ctl2;
 
-#ifdef CONFIG_DM_RTC
if (dm_i2c_read(dev, 0, buf, sizeof(buf))) {
-#else
-   if (i2c_read(dev->chip, 0, 0, buf, 16)) {
-#endif
printf("Error reading from RTC\n");
return -EIO;
}
@@ -225,17 +188,13 @@ static int rx8025_rtc_reset(DEV_TYPE *dev)
 /*
  * Helper functions
  */
-static int rtc_write(DEV_TYPE *dev, uchar reg, uchar val)
+static int rtc_write(struct udevice *dev, uchar reg, uchar val)
 {
uchar buf[2];
buf[0] = reg << 4;
buf[1] = val;
 
-#ifdef CONFIG_DM_RTC
if (dm_i2c_write(dev, 0, buf, 2)) {
-#else
-   if (i2c_write(dev->chip, 0, 0, buf, 2) != 0) {
-#endif
printf("Error writing to RTC\n");
return -EIO;
}
@@ -243,7 +202,6 @@ static int rtc_write(DEV_TYPE *dev, uchar reg, uchar val)
return 0;
 }
 
-#ifdef CONFIG_DM_RTC
 static int rx8025_probe(struct udevice *dev)
 {
uchar buf[16];
@@ -276,31 +234,3 @@ U_BOOT_DRIVER(rx8010sj_rtc) = {
.of_match = rx8025_rtc_ids,
.ops  = _rtc_ops,
 };
-#else
-int rtc_get(struct rtc_time *tm)
-{
-   struct ludevice dev = {
-   .chip = CONFIG_SYS_I2C_RTC_ADDR,
-   };
-
-   return rx8025_rtc_get(, tm);
-}
-
-int rtc_set(struct rtc_time *tm)
-{
-   struct ludevice dev = {
-   .chip = CONFIG_SYS_I2C_RTC_ADDR,
-   };
-
-   return rx8025_rtc_set(, tm);
-}
-
-void rtc_reset(void)
-{
-   struct ludevice dev = {
-   .chip = CONFIG_SYS_I2C_RTC_ADDR,
-   };
-
-   rx8025_rtc_reset();
-}
-#endif
-- 
2.30.1



[PATCH] image: fit: fix byte order for crc32 hash check

2021-09-14 Thread Mathew McBride
In 92055e138f ("image: Drop if/elseif hash selection in calculate_hash()")
the FIT image hash verification code was simplified to use the hash API.

This broke verification of CRC32 hash FIT images (e.g NXP MC firmware)
as the hash API crc32 calculates in big endian (refer commit
74a18ee8a563, "crc32: Correct endianness of crc32 result"), whereas
the previous call directly to crc32_wd does not do a byteswap.

Example:
dumpimage -l qoriq-mc-binary/ls1088a/mc_ls1088a_10.29.1.itb
FIT description: MC Firmware
Created: Fri Aug 27 14:14:32 2021
...
  Hash algo:crc32
  Hash value:   c09d959c
Was returning FB9D3710 to fit_image_check_hash instead of C09D959C

Correct the byte order in the crc32_uimage_fixup so the little endian
values are returned.

Fixes: 92055e138f "image: Drop if/elseif hash selection in calculate_hash()"
Signed-off-by: Mathew McBride 
---
 common/image-fit.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/image-fit.c b/common/image-fit.c
index 92d9141bcd..97b4f0b4b2 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1195,6 +1195,11 @@ int fit_set_timestamp(void *fit, int noffset, time_t 
timestamp)
 
 static void crc32_uimage_fixup(void *value)
 {
+   /* In the CRC32 case, value will be byte swapped by the hash library
+* function, but the FIT is specified (and checked) in little-endian
+*/
+   *((uint32_t *)value) = ntohl(*((uint32_t *)value));
+
/* TODO: In C, this type punning is undefined behavior: */
*((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
 }
-- 
2.30.1



Re: [PATCH 1/3] mem: spi-mem: define spi_mem_default_supports_op

2021-01-24 Thread Mathew McBride
Hello Pratyush,
On Tue, Jan 19, 2021, at 11:06 PM, Pratyush Yadav wrote:
> Hi Matthew,
> 
> > Subject: [PATCH 1/3] mem: spi-mem: define spi_mem_default_supports_op
> 
> Nitpick: You are declaring spi_mem_default_supports_op() here. It is 
> already defined.
> [snip]
> 
> This block of code was imported verbatim from the Linux driver and then 
> wrapped around with a #ifndef __UBOOT__ to avoid compilation errors. So 
> it will never get "enabled" in U-Boot ever. No driver can use the 
> prototypes you have added.
> 
> And I tested this by applying your patch series and building the 
> fsl_qspi driver using ls1012aqds_qspi_defconfig. Sure enough, the 
> compiler reported "implicit declaration of function 
> spi_mem_default_supports_op". Strangely, the linker did not complain and 
> went through without errors. Not sure which function it would end up 
> linking there.
> 
> Move the declaration outside this ifdef, right beside where
> spi_mem_supports_op() is declared. No need to have the variant below. It 
> is safe to assume CONFIG_SPI_MEM is enabled if spi-mem.h is included.
> 
Many thanks for your feedback - I did not account for the differences in the 
kernel and U-Boot here. 

My revised patch should handle this correctly.

Best Regards,
Mathew


[PATCH v2 3/3] spi: fsl_qspi: apply the same settings for LS1088 as LS208x

2021-01-24 Thread Mathew McBride
The LS1088 requires the same QUADSPI_QURIK_BASE_INTERNAL
workaround as the LS208x and also has a 64 byte TX buffer.

With the previous settings SPI-NAND reads over AHB were
corrupted.

Fixes: 91afd36f3802 ("spi: Transform the FSL QuadSPI driver to use the SPI MEM 
API")
Signed-off-by: Mathew McBride 
---
 drivers/spi/fsl_qspi.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 2a1f3a0c44..f965301d6a 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -259,14 +259,6 @@ static const struct fsl_qspi_devtype_data ls1021a_data = {
.little_endian = false,
 };
 
-static const struct fsl_qspi_devtype_data ls1088a_data = {
-   .rxfifo = SZ_128,
-   .txfifo = SZ_128,
-   .ahb_buf_size = SZ_1K,
-   .quirks = QUADSPI_QUIRK_TKT253890,
-   .little_endian = true,
-};
-
 static const struct fsl_qspi_devtype_data ls2080a_data = {
.rxfifo = SZ_128,
.txfifo = SZ_64,
@@ -877,7 +869,7 @@ static const struct udevice_id fsl_qspi_ids[] = {
{ .compatible = "fsl,imx7d-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,imx7ulp-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,ls1021a-qspi", .data = (ulong)_data, },
-   { .compatible = "fsl,ls1088a-qspi", .data = (ulong)_data, },
+   { .compatible = "fsl,ls1088a-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,ls2080a-qspi", .data = (ulong)_data, },
{ }
 };
-- 
2.30.0



[PATCH v2 2/3] spi: fsl_qspi: Ensure width is respected in spi-mem operations

2021-01-24 Thread Mathew McBride
Adapted from kernel commit b0177aca7aea
From: Michael Walle 

Make use of a core helper to ensure the desired width is respected
when calling spi-mem operators.

Otherwise only the SPI controller will be matched with the flash chip,
which might lead to wrong widths. Also consider the width specified by
the user in the device tree.

Fixes: 91afd36f38 ("spi: Add a driver for the Freescale/NXP QuadSPI controller")
Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20200114154613.8195-1-mich...@walle.cc
Signed-off-by: Mark Brown 
Signed-off-by: Mathew McBride  [adapt for U-Boot]
---
 drivers/spi/fsl_qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 8bc7038a82..2a1f3a0c44 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -409,7 +409,7 @@ static bool fsl_qspi_supports_op(struct spi_slave *slave,
op->data.nbytes > q->devtype_data->txfifo)
return false;
 
-   return true;
+   return spi_mem_default_supports_op(slave, op);
 }
 
 static void fsl_qspi_prepare_lut(struct fsl_qspi *q,
-- 
2.30.0



[PATCH v2 1/3] mem: spi-mem: add declaration for spi_mem_default_supports_op

2021-01-24 Thread Mathew McBride
spi_mem_default_supports_op is used internally by controller
drivers to verify operation semantics are correct.

It is used internally inside spi-mem but has not (in U-Boot)
been declared in spi-mem.h for external use.

Signed-off-by: Mathew McBride 
---
 include/spi-mem.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/spi-mem.h b/include/spi-mem.h
index ca0f55c8fd..8be3e2bf6b 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -240,6 +240,9 @@ bool spi_mem_supports_op(struct spi_slave *slave, const 
struct spi_mem_op *op);
 
 int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op);
 
+bool spi_mem_default_supports_op(struct spi_slave *mem,
+const struct spi_mem_op *op);
+
 #ifndef __UBOOT__
 int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
   struct module *owner);
-- 
2.30.0



[PATCH v2 0/3] Fixes for SPI-NAND issues on LS1088A

2021-01-24 Thread Mathew McBride
This patchset resolves issues seen when using SPI-NAND with the
LS1088A's qspi controller.

The main issue seen is data corruption when reading SPI-NAND, due to a
controller quirk not being applied.
Using the same settings as the LS2088A (the bigger brother of LS1088A) solves 
this issue.

In the course of debugging the above issue, it was found that the fsl_qspi
driver was not correctly reporting the operation width (single/dual/quad)
configured for the device in DTS.
(e.g I configured my device for single-lane reads only but quad operations were 
being issued)

A fix for this issue is already present in Linux and can be adapted for U-Boot,
providing a missing declaration for spi_mem_default_supports_op is added.

Changes in v2:
* Correct addition of declration for spi_mem_default_supports_op
The previous patch attempted to mirror how it was added to the Linux
kernel, which is not relevant to U-Boot

Mathew McBride (3):
  mem: spi-mem: add declaration for spi_mem_default_supports_op
  spi: fsl_qspi: Ensure width is respected in spi-mem operations
  spi: fsl_qspi: apply the same settings for LS1088 as LS208x

 drivers/spi/fsl_qspi.c | 12 ++--
 include/spi-mem.h  |  3 +++
 2 files changed, 5 insertions(+), 10 deletions(-)

-- 
2.30.0



[PATCH 3/3] spi: fsl_qspi: apply the same settings for LS1088 as LS208x

2021-01-18 Thread Mathew McBride
The LS1088 requires the same QUADSPI_QURIK_BASE_INTERNAL
workaround as the LS208x and also has a 64 byte TX buffer.

With the previous settings SPI-NAND reads over AHB were
corrupted.

Fixes: 91afd36f3802 ("spi: Transform the FSL QuadSPI driver to use the SPI MEM 
API")
Signed-off-by: Mathew McBride 
---
 drivers/spi/fsl_qspi.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 2a1f3a0c44..f965301d6a 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -259,14 +259,6 @@ static const struct fsl_qspi_devtype_data ls1021a_data = {
.little_endian = false,
 };
 
-static const struct fsl_qspi_devtype_data ls1088a_data = {
-   .rxfifo = SZ_128,
-   .txfifo = SZ_128,
-   .ahb_buf_size = SZ_1K,
-   .quirks = QUADSPI_QUIRK_TKT253890,
-   .little_endian = true,
-};
-
 static const struct fsl_qspi_devtype_data ls2080a_data = {
.rxfifo = SZ_128,
.txfifo = SZ_64,
@@ -877,7 +869,7 @@ static const struct udevice_id fsl_qspi_ids[] = {
{ .compatible = "fsl,imx7d-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,imx7ulp-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,ls1021a-qspi", .data = (ulong)_data, },
-   { .compatible = "fsl,ls1088a-qspi", .data = (ulong)_data, },
+   { .compatible = "fsl,ls1088a-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,ls2080a-qspi", .data = (ulong)_data, },
{ }
 };
-- 
2.30.0



[PATCH 2/3] spi: fsl_qspi: Ensure width is respected in spi-mem operations

2021-01-18 Thread Mathew McBride
Adapted from kernel commit b0177aca7aea
From: Michael Walle 

Make use of a core helper to ensure the desired width is respected
when calling spi-mem operators.

Otherwise only the SPI controller will be matched with the flash chip,
which might lead to wrong widths. Also consider the width specified by
the user in the device tree.

Fixes: 91afd36f38 ("spi: Add a driver for the Freescale/NXP QuadSPI controller")
Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20200114154613.8195-1-mich...@walle.cc
Signed-off-by: Mark Brown 
Signed-off-by: Mathew McBride  [adapt for U-Boot]
---
 drivers/spi/fsl_qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 8bc7038a82..2a1f3a0c44 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -409,7 +409,7 @@ static bool fsl_qspi_supports_op(struct spi_slave *slave,
op->data.nbytes > q->devtype_data->txfifo)
return false;
 
-   return true;
+   return spi_mem_default_supports_op(slave, op);
 }
 
 static void fsl_qspi_prepare_lut(struct fsl_qspi *q,
-- 
2.30.0



[PATCH 1/3] mem: spi-mem: define spi_mem_default_supports_op

2021-01-18 Thread Mathew McBride
spi_mem_default_supports_op is used internally by controller
drivers to verify operation semantics are correct.

Signed-off-by: Mathew McBride 
---
 include/spi-mem.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/spi-mem.h b/include/spi-mem.h
index ca0f55c8fd..92c640dabe 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -216,6 +216,10 @@ int spi_controller_dma_map_mem_op_data(struct 
spi_controller *ctlr,
 void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
  const struct spi_mem_op *op,
  struct sg_table *sg);
+
+bool spi_mem_default_supports_op(struct spi_mem *mem,
+const struct spi_mem_op *op);
+
 #else
 static inline int
 spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
@@ -231,6 +235,12 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller 
*ctlr,
 struct sg_table *sg)
 {
 }
+
+bool spi_mem_default_supports_op(struct spi_mem *mem,
+const struct spi_mem_op *op)
+{
+   return false;
+}
 #endif /* CONFIG_SPI_MEM */
 #endif /* __UBOOT__ */
 
-- 
2.30.0



[PATCH 0/3] Fixes for SPI-NAND issues on LS1088A

2021-01-18 Thread Mathew McBride
This patchset resolves issues seen when using SPI-NAND
with the LS1088A's qspi controller.

The main issue seen is data corruption when reading SPI-NAND,
due to a controller quirk not being applied. Using the same
settings as the LS2088A (the bigger brother of LS1088A) solves
this issue.

In the course of debugging the above issue, it was found
that the fsl_qspi driver was not correctly reporting the operation
width (single/dual/quad) configured for the device in DTS.
(e.g I configured my device for single-lane reads only
but quad operations were being issued)

A fix for this issue is already present in Linux and can be
adapted for U-Boot, providing a missing export for
spi_mem_default_supports_op is added.

Mathew McBride (3):
  mem: spi-mem: define spi_mem_default_supports_op
  spi: fsl_qspi: Ensure width is respected in spi-mem operations
  spi: fsl_qspi: apply the same settings for LS1088 as LS208x

 drivers/spi/fsl_qspi.c | 12 ++--
 include/spi-mem.h  | 10 ++
 2 files changed, 12 insertions(+), 10 deletions(-)

-- 
2.30.0



Re: [U-Boot] [PATCH 1/2] armv8: dts: ls1088a: add PSCI binding for LS1088A

2019-10-18 Thread Mathew McBride
Hell Priyanka,


>-Original Message-
>From: Mathew McBride 
>Sent: Friday, October 18, 2019 8:58 AM
>To: u-boot@lists.denx.de
>Cc: Priyanka Jain ; Mathew McBride 
>
>Subject: [PATCH 1/2] armv8: dts: ls1088a: add PSCI binding for LS1088A
>
>2.19.1
[snip]
> Mathew, Have you tested this change on any standard NXP ls1088a board?

> --priyankajain

Not yet - I can test it on an LS1088ARDB if needed.

In theory, this should have no effect on the NXP reference boards as they
are all blacklisted from CONFIG_PSCI_RESET in arch/arm/cpu/armv8/Kconfig.

Regards,
Mathew

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/2] armv8: dts: ls1088a: add PSCI binding for LS1088A

2019-10-17 Thread Mathew McBride
This allows the use of PSCI calls to trusted firmware to
initiate reset and poweroff events with CONFIG_PSCI_RESET and
CONFIG_ARM_PSCI_FW. This is desirable, for example, if the target
board has implemented a custom reset or poweroff procedure in EL3.

Signed-off-by: Mathew McBride 
Cc: Priyanka Jain 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 4be1ab87d2..abc8b21a11 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -192,4 +192,9 @@
status = "disabled";
};
 
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
 };
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/2] armv8: fsl-layerscape: do not use layerscape EFI reset if PSCI used

2019-10-17 Thread Mathew McBride
If the secure world reset handlers are used (via CONFIG_PSCI_RESET),
then do not use the layerscape-specific implementation.

Signed-off-by: Mathew McBride 
Cc: Priyanka Jain 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index a5d0b5370f..b4012793fd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1218,7 +1218,7 @@ void __efi_runtime reset_cpu(ulong addr)
 #endif
 }
 
-#ifdef CONFIG_EFI_LOADER
+#if defined(CONFIG_EFI_LOADER) && !defined(CONFIG_PSCI_RESET)
 
 void __efi_runtime EFIAPI efi_reset_system(
   enum efi_reset_type reset_type,
-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 0/2] armv8: fsl-layerscape: Allow use of PSCI handlers for ls1088a

2019-10-17 Thread Mathew McBride
This patch allows the use of PSCI for power operations - this is
desirable if the target board has implemented it's own power operation
handlers in Trusted Firmware/EL3.

Layerscape has it's own EFI service handlers for power operations - if
PSCI is used the generic handlers will be used instead.

Note that all of the existing Layerscape boards in-tree are blacklisted
from PSCI_RESET by default - to use this you must enable it for your
board.

Mathew McBride (2):
  armv8: dts: ls1088a: add PSCI binding for LS1088A
  armv8: fsl-layerscape: do not use layerscape EFI reset if PSCI used

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
 arch/arm/dts/fsl-ls1088a.dtsi   | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.19.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] SquashFS and FIT images

2018-01-25 Thread Mathew McBride

On 26/01/2018 8:01 AM, Bishop, Mark (STRT) wrote:

Is it possible to specify squashFS images in an .its file?  If so, anyone have 
an example or a pointer to the docs I've been searching for?
Hi Mark,

It is possible, here is an example I have used on an NXP LS1043 board:
/dts-v1/;

/ {
description = "ARM64 OpenWrt FIT (Flattened Image Tree)";
#address-cells = <1>;

images {
kernel@1 {
description = "ARM64 OpenWrt Linux-4.4";
data = /incbin/("arch/arm64/boot/Image.gz");
type = "kernel";
arch = "arm64";
os = "linux";
compression = "gzip";
load = <0x8008>;
entry = <0x8008>;
};


ramdisk@1 {
description = "ARM64 OpenWrt ramdisk";
data = /incbin/("root.squashfs");
type = "ramdisk";
arch = "arm64";
os = "linux";
compression = "gzip";
};


fdt@1 {
description = "ARM64 OpenWrt device tree blob";
data = 
/incbin/("arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dtb");

type = "flat_dt";
arch = "arm64";
compression = "none";
load = <0x9000>;
};


};

configurations {
default = "config@1";
config@1 {
description = "OpenWrt";
kernel = "kernel@1";
fdt = "fdt@1";
ramdisk = "ramdisk@1";
};
};
};

Cheers,
Matt


Mark Bishop
Sr. Firmware/Software Engineer - Microwave Subsystems

[cid:image001.png@01D281ED.A45F0A90]

4726 Eisenhower Blvd.
Tampa, FL 33634
USA


T  +1 813 901 7293

mbis...@smithsinterconnectinc.com

smithsinterconnect.com

TRAK MICROWAVE IS NOW SMITHS INTERCONNECT!








___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot




___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] bootefi regression from v2017.9: GRUB fails to see partitions on NXP LS1043A

2017-11-02 Thread Mathew McBride

Hi all,

We are testing EFI support on u-boot for our (Traverse) NXP LS1043 
boards, as being able to only maintain one bootloader codebase (u-boot) 
is very appealing to us.


So far it has worked well, but I have had trouble getting it to work 
under v2017.11-rc*. It works fine on v2017.09.


I've traced the issue to this commit:
95c5553ea268144056c4bafc318b9e8b5c096a6c efi_loader: refactor boot 
device and loaded_image handling


After this commit, GRUB is unable to see the partitions of any attached 
devices, yet alone its own memdisk.
(This is a grub binary which I've built with modules in the memdisk, in 
theory it can function without a storage device)


Before:

Device 0: Vendor: TOSHIBA Rev: 1.00 Prod: TransMemory
Type: Removable Hard Disk
Capacity: 7391.2 MB = 7.2 GB (15137280 x 512)
... is now current device
Scanning usb 0:1...
reading /dtb/fsl-ls1043a-rdb.dtb
23140 bytes read in 43 ms (525.4 KiB/s)
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
238592 bytes read in 153 ms (1.5 MiB/s)
## Starting EFI application at 8100 ...
Scanning disks on scsi...
Scanning disks on usb...
Scanning disks on mmc...
Card did not respond to voltage select!
mmc_init: -95, time 46
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 8 disks
Welcome to GRUB!

error: file `/boot/grub/arm64-efi/normal.mod' not found.
Entering rescue mode...
grub rescue> insmod fat
grub rescue> ls
(memdisk) (hd0) (hd0,gpt2) (hd0,gpt1)
grub rescue> ls (memdisk)/
boot/
grub rescue> ls (hd0,gpt1)/
grub/ vmlinuz-4.14.0-rc5-00018-g52569513daea 
System.map-4.14.0-rc5-00018-g52569513daea 
config-4.14.0-rc5-00018-g52569513daea efi/ dtb/



After:

reading efi/boot/bootaa64.efi
238592 bytes read in 153 ms (1.5 MiB/s)
## Starting EFI application at 8100 ...
Scanning disks on scsi...
Scanning disks on usb...
Scanning disks on mmc...
Card did not respond to voltage select!
mmc_init: -95, time 46
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 8 disks
Welcome to GRUB!

error: variable `root' isn't set.
Entering rescue mode...
grub rescue> ls
(hd0)

The tests above are on a LS1043ARDB (reference board), loading u-boot 
from NAND and booting GRUB from a USB drive.



I am not a EFI expert at all, but is there anything I can do to help 
debug/fix this?




Regards,
Matt


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot