[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 at 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.