It is not seemingly suitable because it is not clear what it entails.
From that linked topic:
It looks like dtc can be used to follow the first sentence.
The second sentence
add dtbo name to your board config file
is highly unclear. Looking at all of the config files I can see for example from jetson-xavier-maxn.conf an env var
OVERLAY_DTB_FILE="${OVERLAY_DTB_FILE},tegra194-p2888-0005-overlay.dtbo";
xavier nx config files do not have any OVERLAY_DTB_FILE env var. They only have a DTB_FILE=tegra194-p3668-0001-p3509-0000.dtb env var.
The third sentence
Reflash the board
brings us to the present issue where flashing from the BSP package I’ve prepped hasn’t been able to succeed (see discussion above). I would want to get this working in some way before attempting the UEFI rebuild and dtb changes for it.
OK so it looks like after some searching I’ve got a rough idea of how to go down this UEFI path. So I can accept this now as likely viable for production rollout, I take that back then.
But what makes no sense at all, and still calls everything into question, is why my “failed” SDKM derived 5.0.2 NVMe disk, combined with my vanilla 5.0.2 (rev.1) SDKM flashed SoM, magically seamlessly boots to NVMe all by itself without manual intervention. Ever since I’ve confirmed this behavior it’s cast so much doubt on everything else. Why should I bother to rebuild UEFI just to get the updated version if 5.0.2(rev.1) via SDKM 1.9.0 provides the required functionality all by itself?
I think my next step will be to use the SDK/BSP directory that was actually prepared by SDKM to do Workflow 7 experiments to try to get a quick path toward massflash. I am willing to accept that although there exists a way to flash the SoM with a way to auto boot NVMe, that I might still never be able find out why it works, given the existence of discussions such as the aforementioned topic, Initrd flash boot order, in which it is clearly stated that 5.0.2 does not come with a way to auto boot to NVMe without deep modifications like the UEFI one above.