
Dear Simon Glass,
In message CAPnjgZ2mKwMyYVyGyYwMm8dNMfNPwgbJA+YTH_G1X-uzbkDfpQ@mail.gmail.com you wrote:
Searching for "DTB append ARM zImage" provides lots of recent activity. The justification for this series seems to be old boot loaders. ...
True. In my understanding, this is only relevant to less capable boot loaders (which not always are old - things like UEFI are not much better in this respect). But U-Boot has full DT support, and we are even on the way to configure U-Boot itself through a DT, so we should at least optionally be able to use these features.
... Is there a LKML thread about why it should/shouldn't be done
in U-Boot specifically - other boot loaders may require the kernel to do it, but for U-Boot there would need to be some sort of reason I think.
I cannot see a single reason for such format in U-Boot context. We have been using the device tree for years on PPC, and never had any such need. Dt is actually standard technology now. It's only new for ARM, like all the other stuff as FPU support, cache coherency, PCI, SMP, ... you name it.
I am currently using a hybrid solution (U-Boot loads the zImage and DTB, then kernel decompresses zImage) and we have discussed changing this. It may need a new build target in the kernel, but not rocket science.
Patches for this have been submitted (and rejected) several times, years ago. Ditto for other useful things (like being able to pass the kernel a ramdisk / initrd address in NOR flash, so we can avoid copying it into RAM first). Search the ML archives if you are interesteed.
Best regards,
Wolfgang Denk