From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [DNX#2007012542000021] [PATCH] Abort booting if the DTB version is incomp [...]
Date: Wed, 14 Mar 2007 17:07:49 -0400 [thread overview]
Message-ID: <45F86425.5050400@smiths-aerospace.com> (raw)
In-Reply-To: <20070314203640.82C113525B0@atlas.denx.de>
Wolfgang Denk wrote:
> Dear Timur,
>
> in message <45F853ED.2060005@freescale.com> you wrote:
>> I don't want to be annoying, but if you're going to apply this patch, I think it needs to
>
> Unfortunately there is a difference between the things I want to do,
> the things I am capable of doing, the things I can do, and the things
> I'm actually doing.
>
>> be applied now. There's a patch for the device tree compiler (DTC) that updates it to
>> version 17, which claims to be compatible with V16. Soon, we're going to have V3, V16,
>> and V16 DTBs flying around, so U-Boot needs to make a stand on what it considers
>> compatible and what it doesn't.
>
> If I'm realistic, I have to admit that I won't find much time for
> merging patches in the next days or maybe even weeks. Sorry.
>
> Maybe we can find a custodian for the device tree related things?
>
> Best regards,
>
> Wolfgang Denk
Hi Timur, Wolfgang,
If I understand this, currently there is _no_ version checking and bootm
will mysteriously fail if it is fed a version 3 blob and just as
mysteriously work if fed a v16 (or v17) blob.
Version 17 is 100% compatible with version 16, it adds a new field in
the header that is reserved (0x00000000) in v16 and sets the
"comp_version" field to 17 instead of 16 ("last_comp_version" remains at
16).
Version checking is good. Having said that, if the patch is or is not
applied, I don't see how anything changes materially from where we are
right now, other than it will detect and abort if a v3 blob is passed in
(which is good). Currently u-boot will accept and properly process a
v16 or v17 blob (theoretically - I have not had a chance to run a v17
blob, but I've looked quite hard at the change).
I've been working with fdt blobs, implementing a "fdt" command. It
currently can print individual properties, recursively print nodes
starting at any point in the tree, and set property values (but if the
size is the same).
I would consider being a fdt-related custodian, but I don't have a lot
of time to work on it so I'm not sure my response time would be an
improvement over Wolfgang's. :-(
gvb
prev parent reply other threads:[~2007-03-14 21:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 16:20 [U-Boot-Users] [DNX#2007012542000021] [PATCH] Abort booting if the DTB version is incomp [...] OTRS Notification Master
2007-02-05 19:38 ` Timur Tabi
2007-02-06 0:40 ` Wolfgang Denk
2007-03-14 19:58 ` Timur Tabi
2007-03-14 20:36 ` Wolfgang Denk
2007-03-14 21:01 ` Stefan Roese
2007-03-14 21:04 ` Wolfgang Denk
2007-03-14 21:22 ` Ben Warren
2007-03-14 23:12 ` Wolfgang Denk
2007-03-14 21:07 ` Jerry Van Baren [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=45F86425.5050400@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.