[PATCH 1/2] arm: tegra: define fdtfile option for distro boot

[PATCH 1/2] arm: tegra: define fdtfile option for distro boot

[Peter Robinson]

For booting via UEFI we need to define the fdtfile option so
bootefi has the option to load a fdtfile from disk. For arm64
the kernel dtb is located in a vendor directory so we define
that as nvidia for that architecture.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
---

Without this the aarch64 tegra devices don't find the kernel
device tree when booting using UEFI so fall back to the firmware
DT in U-Boot which alone isn't enough to boot the Linux kernel
and you end up with a boot failure in very early boot due to
being unable to find the architecture timer. This fixes the
issue when booting Fedora using UEFI for me.

 include/configs/tegra-common.h    | 6 ++++++
 include/configs/tegra114-common.h | 1 +
 include/configs/tegra124-common.h | 1 +
 include/configs/tegra186-common.h | 1 +
 include/configs/tegra20-common.h  | 1 +
 include/configs/tegra210-common.h | 1 +
 include/configs/tegra30-common.h  | 1 +
 7 files changed, 12 insertions(+)

diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h
index f2cdd9c019..997b50394b 100644
--- a/include/configs/tegra-common.h
+++ b/include/configs/tegra-common.h
@@ -55,6 +55,12 @@
 #define CONFIG_SYS_MEMTEST_START	(NV_PA_SDRC_CS0 + 0x600000)
 #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + 0x100000)
 
+#ifdef CONFIG_ARM64
+#define FDTFILE "nvidia/" CONFIG_DEFAULT_DEVICE_TREE ".dtb"
+#else
+#define FDTFILE CONFIG_DEFAULT_DEVICE_TREE ".dtb"
+#endif
+
 /*-----------------------------------------------------------------------
  * Physical Memory Map
  */
diff --git a/include/configs/tegra114-common.h b/include/configs/tegra114-common.h
index d3a7045697..9d751b6740 100644
--- a/include/configs/tegra114-common.h
+++ b/include/configs/tegra114-common.h
@@ -50,6 +50,7 @@
 	"scriptaddr=0x90000000\0" \
 	"pxefile_addr_r=0x90100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x83000000\0" \
 	"ramdisk_addr_r=0x83100000\0"
 
diff --git a/include/configs/tegra124-common.h b/include/configs/tegra124-common.h
index 522993b958..0eb8f92809 100644
--- a/include/configs/tegra124-common.h
+++ b/include/configs/tegra124-common.h
@@ -52,6 +52,7 @@
 	"scriptaddr=0x90000000\0" \
 	"pxefile_addr_r=0x90100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x83000000\0" \
 	"ramdisk_addr_r=0x83100000\0"
 
diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h
index b4936cc731..5c3ad35c76 100644
--- a/include/configs/tegra186-common.h
+++ b/include/configs/tegra186-common.h
@@ -49,6 +49,7 @@
 	"scriptaddr=0x90000000\0" \
 	"pxefile_addr_r=0x90100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x82000000\0" \
 	"ramdisk_addr_r=0x82100000\0"
 
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
index 1e31d82574..fdd8996955 100644
--- a/include/configs/tegra20-common.h
+++ b/include/configs/tegra20-common.h
@@ -51,6 +51,7 @@
 	"scriptaddr=0x10000000\0" \
 	"pxefile_addr_r=0x10100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x03000000\0" \
 	"ramdisk_addr_r=0x03100000\0"
 
diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h
index 1b8e94b60c..2226effe16 100644
--- a/include/configs/tegra210-common.h
+++ b/include/configs/tegra210-common.h
@@ -46,6 +46,7 @@
 	"scriptaddr=0x90000000\0" \
 	"pxefile_addr_r=0x90100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x83000000\0" \
 	"ramdisk_addr_r=0x83200000\0"
 
diff --git a/include/configs/tegra30-common.h b/include/configs/tegra30-common.h
index 54bc6756ab..6c5dc24b26 100644
--- a/include/configs/tegra30-common.h
+++ b/include/configs/tegra30-common.h
@@ -47,6 +47,7 @@
 	"scriptaddr=0x90000000\0" \
 	"pxefile_addr_r=0x90100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x83000000\0" \
 	"ramdisk_addr_r=0x83100000\0"
 
-- 
2.26.0

[PATCH 2/2] arm: tegra: add options for BOOTENV_EFI_SET_FDTFILE_FALLBACK for tegra186

[Peter Robinson]

Upstream linux DT naming doesn't align with the U-Boot DT, which may
not always be the case so this allows using BOOTENV_EFI_SET_FDTFILE_FALLBACK
where it might be appropriate for some boards.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
---

This is a bit of a hack for the Jetson TX2 because the U-Boot config
using a different naming for the DT naming to upstream Linux, I'm not
sure what naming L4T uses, and whether the 000/500 variants are widely
enough available or whether they use differnet DTs in L4T.

Welcome to suggestions of a better way to fix this one but it works
for booting the TX2 on Fedora using UEFI..

 include/config_distro_bootcmd.h   | 2 ++
 include/configs/tegra186-common.h | 7 ++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index fc0935fa21..fd1c5f5afa 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -118,8 +118,10 @@
 	  "setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; "           \
 	"fi; "
 #else
+#ifndef BOOTENV_EFI_SET_FDTFILE_FALLBACK
 #define BOOTENV_EFI_SET_FDTFILE_FALLBACK
 #endif
+#endif
 
 
 #define BOOTENV_SHARED_EFI                                                \
diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h
index 5c3ad35c76..d5f21e0907 100644
--- a/include/configs/tegra186-common.h
+++ b/include/configs/tegra186-common.h
@@ -20,6 +20,12 @@
 /* Generic Interrupt Controller */
 #define CONFIG_GICV2
 
+#undef FDTFILE
+#define BOOTENV_EFI_SET_FDTFILE_FALLBACK                                  \
+        "if test -z \"${fdtfile}\" -a -n \"${soc}\"; then "               \
+          "setenv efi_fdtfile ${vendor}/${soc}-${board}${boardver}.dtb; "           \
+        "fi; "
+
 /*
  * Memory layout for where various images get loaded by boot scripts:
  *
@@ -49,7 +55,6 @@
 	"scriptaddr=0x90000000\0" \
 	"pxefile_addr_r=0x90100000\0" \
 	"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
-	"fdtfile=" FDTFILE "\0" \
 	"fdt_addr_r=0x82000000\0" \
 	"ramdisk_addr_r=0x82100000\0"
 
-- 
2.26.0

[PATCH 2/2] arm: tegra: add options for BOOTENV_EFI_SET_FDTFILE_FALLBACK for tegra186

[Stephen Warren]

On 4/1/20 5:28 PM, Peter Robinson wrote:
> Upstream linux DT naming doesn't align with the U-Boot DT, which may
> not always be the case so this allows using BOOTENV_EFI_SET_FDTFILE_FALLBACK
> where it might be appropriate for some boards.
> 
> Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
> ---
> 
> This is a bit of a hack for the Jetson TX2 because the U-Boot config
> using a different naming for the DT naming to upstream Linux, I'm not
> sure what naming L4T uses, and whether the 000/500 variants are widely
> enough available or whether they use differnet DTs in L4T.
> 
> Welcome to suggestions of a better way to fix this one but it works
> for booting the TX2 on Fedora using UEFI..

Does the default fdtfile value set up in patch 1 work in even a majority
of cases? In other words, is there a list of boards where the DT names
do match and where they don't?

>  include/config_distro_bootcmd.h   | 2 ++
>  include/configs/tegra186-common.h | 7 ++++++-

For T186, rather than adding fdtfile in patch 1, then removing it in
patch 2, shouldn't we drop the T186 changes from patch 1 and go direct
to the final solution in patch 2?

For downstream SW stacks at least, the best approach is to pass through
the cboot-supplied DTB to the kernel rather than loading a new one. This
is the only way we have at present to cater for:
- Different HW revisions.
- Runtime-generated data like memory settings, carve-out locations, ...
- Optional daughter boards detected at run-time.
- HW modifications/configurations indicated by NV-custom "ODMDATA"
values in the BCT.

That said, the upstream SW stacks don't currently support or use any of
that information, and only support a single specific HW revision of each
board (or the common subset between revisions), so perhaps this aspect
isn't too relevant.