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 <pbrobin...@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.
