Booting zImage with appended DTB without ATAGs support

[Tom Rini]

On Fri, Nov 05, 2021 at 04:47:31PM +0100, Pali Rohár wrote:
> On Friday 05 November 2021 11:20:01 Tom Rini wrote:
> > On Fri, Nov 05, 2021 at 04:16:46PM +0100, Pali Rohár wrote:
> > > So now I have a question: Do we want to support booting zImage with
> > > appended DTB in U-Boot when ATAGs support is now disabled by default?
> > 
> > Based on your experience, yes, there are use cases for appended dtb
> > booting still.  So it should be at least documented what you need to do
> > where in order for that to work, and perhaps some platforms will want to
> > enable it by default.
> 
> What could be implemented in U-Boot is extracting DTB from zImage+DTB
> binary and boot it like if user supply separate zImage and separate DTB
> files. With this approach there is no need to have ATAGs support
> enabled. It would mean that kernel's code for using attached DTB would
> not be used anymore as DTB would be passed to kernel separately, like
> any modern boot setup.
> 
> Main issue with this approach is that if you load zImage+DTB binary from
> disk or UART into memory then you loose information about total binary
> size. And if you examine memory after the zImage, you cannot be sure if
> data were loaded by previous command (disk read, UART transfer) or if is
> just some garbage in RAM. So you can have false-positive detection that
> DTB was appended.
> 
> This issue does not happen in case of booting zImage+DTB encapsulated in
> uImage format, as in uImage is stored total size of that concatenated
> binary. So booting via bootm should be fine. IIRC zImage+DTB-in-uImage
> via bootm is used for booting new kernels on Nokia N900.
> 
> Currently affected by this issue is bootz command, which takes only
> start address of the zImage binary and total size is not specified.
> Command bootz takes third argument which specifies location of DTB in
> memory and understand special value "-" which says to atags booting.
> I'm thinking here... what about adding a new special value e.g. "+"
> which would mean that DTB is attached to zImage? This could issue that
> automatic detection of attached DTB into zImage is not reliable.
> 
> Any opinion?
> 
> Another approach instead of extracting DTB from zImage+DTB binary could
> be to teach U-Boot to provide some simple minimalistic ATAGs and then
> boot those zImage+DTB binaries like before with minimalistic ATAGs...

So, there's certainly still valid reasons and times to boot an appended
DTB.  It's just not a generally common case I think.  But it does show
that ATAGs were getting a bit more use still than I had expected.  I
think we should update the help / prompt on SUPPORT_PASSING_ATAGS to
make it clear this is needed for appended dtb booting and if I followed
you right, CMDLINE should at least also be enabled for that case, and
maybe also update something under doc/.  I don't think we should put too
much effort in to making us find and pass the appended dtb for what is
an otherwise niche case.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211105/5ce1aa69/attachment.sig>