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.