From: Tom Rini <trini@konsulko.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Stefan Roese" <sr@denx.de>, "Marek Behún" <kabel@kernel.org>,
u-boot@lists.denx.de
Subject: Re: Booting zImage with appended DTB without ATAGs support
Date: Fri, 5 Nov 2021 16:02:29 -0400 [thread overview]
Message-ID: <20211105200229.GI24579@bill-the-cat> (raw)
In-Reply-To: <20211105154731.qsckprgirfhn5rc5@pali>
[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2021-11-05 20:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 10:13 A38x: Broken Linux kernel booting over UART Pali Rohár
2021-10-11 14:03 ` Tom Rini
2021-10-11 14:25 ` Pali Rohár
2021-10-11 14:32 ` Tom Rini
2021-10-11 14:33 ` Pali Rohár
2021-10-11 14:45 ` Tom Rini
2021-10-11 15:49 ` Pali Rohár
2021-11-05 11:38 ` Pali Rohár
2021-11-05 14:35 ` Tom Rini
2021-11-05 15:16 ` Pali Rohár
2021-11-05 15:20 ` Tom Rini
2021-11-05 15:47 ` Booting zImage with appended DTB without ATAGs support Pali Rohár
2021-11-05 20:02 ` Tom Rini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211105200229.GI24579@bill-the-cat \
--to=trini@konsulko.com \
--cc=kabel@kernel.org \
--cc=pali@kernel.org \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox