[U-Boot-Users] [DNX#2007012542000021] [PATCH] Abort booting if the DTB version is incomp [...]
Hello list,
inside the automatic U-Boot patch tracking system a new ticket [DNX#2007012542000021] was created:
<snip>
U-Boot only supports version 16 of the device tree file format, although some versions of the device tree compiler generate version 3 by default. With this patch, U-Boot now checks the version number and aborts the boot process if the version of the device tree passed on the bootm command line is not compatible.
Signed-off-by: Timur Tabi timur@freescale.com
common/cmd_bootm.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 0c092c7..9111cbd 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -741,6 +741,16 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl hdr = (image_header_t *)of_flat_tree;
if (*(ulong *)of_flat_tree == OF_DT_HEADER) {
struct boot_param_header *bph =(struct boot_param_header *) of_flat_tree;if ((OF_DT_VERSION < be32_to_cpu(bph->last_comp_version)) ||(OF_DT_VERSION > be32_to_cpu(bph->version))) {printf("ERROR: DTB version %u is not compatible with version %u " \"(last_comp_version=%u)\n", be32_to_cpu(bph->version),OF_DT_VERSION, be32_to_cpu(bph->last_comp_version));return;}#ifndef CFG_NO_FLASH if (addr2info((ulong)of_flat_tree) != NULL) of_data = (ulong)of_flat_tree; -- 1.4.4
</snip>
Your U-Boot support team
Wolfgang,
Can you tell if and when this patch will be applied?
I also submitted another patch titled "Add support for generating assembly listing files".
OTRS Notification Master wrote:
Hello list,
inside the automatic U-Boot patch tracking system a new ticket [DNX#2007012542000021] was created:
<snip> > U-Boot only supports version 16 of the device tree file format, although > some > versions of the device tree compiler generate version 3 by default. > With > this patch, U-Boot now checks the version number and aborts the boot > process > if the version of the device tree passed on the bootm command line is > not > compatible. > > Signed-off-by: Timur Tabi <timur@freescale.com> > --- > common/cmd_bootm.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > index 0c092c7..9111cbd 100644 > --- a/common/cmd_bootm.c > +++ b/common/cmd_bootm.c > @@ -741,6 +741,16 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > hdr = (image_header_t *)of_flat_tree; > > if (*(ulong *)of_flat_tree == OF_DT_HEADER) { > + struct boot_param_header *bph = > + (struct boot_param_header *) of_flat_tree; > + > + if ((OF_DT_VERSION < be32_to_cpu(bph->last_comp_version)) || > + (OF_DT_VERSION > be32_to_cpu(bph->version))) { > + printf("ERROR: DTB version %u is not compatible with version %u " \ > + "(last_comp_version=%u)\n", be32_to_cpu(bph->version), > + OF_DT_VERSION, be32_to_cpu(bph->last_comp_version)); > + return; > + } > #ifndef CFG_NO_FLASH > if (addr2info((ulong)of_flat_tree) != NULL) > of_data = (ulong)of_flat_tree; > -- > 1.4.4 </snip>
Your U-Boot support team
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 45C78798.1030807@freescale.com you wrote:
Can you tell if and when this patch will be applied?
Yes, and I don't know. After the Embedded World 2007.
I also submitted another patch titled "Add support for generating assembly listing files".
Yes. Sorry.
I'm trying to get the custodians installed and working ASAP, but at the moment not even this finds enough of my time. Sorry again.
Best regards,
Wolfgang Denk
Wolfgang,
I don't want to be annoying, but if you're going to apply this patch, I think it needs to 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.
OTRS Notification Master wrote:
Hello list,
inside the automatic U-Boot patch tracking system a new ticket [DNX#2007012542000021] was created:
<snip> > U-Boot only supports version 16 of the device tree file format, although > some > versions of the device tree compiler generate version 3 by default. > With > this patch, U-Boot now checks the version number and aborts the boot > process > if the version of the device tree passed on the bootm command line is > not > compatible. > > Signed-off-by: Timur Tabi <timur@freescale.com> > --- > common/cmd_bootm.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > index 0c092c7..9111cbd 100644 > --- a/common/cmd_bootm.c > +++ b/common/cmd_bootm.c > @@ -741,6 +741,16 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > hdr = (image_header_t *)of_flat_tree; > > if (*(ulong *)of_flat_tree == OF_DT_HEADER) { > + struct boot_param_header *bph = > + (struct boot_param_header *) of_flat_tree; > + > + if ((OF_DT_VERSION < be32_to_cpu(bph->last_comp_version)) || > + (OF_DT_VERSION > be32_to_cpu(bph->version))) { > + printf("ERROR: DTB version %u is not compatible with version %u " \ > + "(last_comp_version=%u)\n", be32_to_cpu(bph->version), > + OF_DT_VERSION, be32_to_cpu(bph->last_comp_version)); > + return; > + } > #ifndef CFG_NO_FLASH > if (addr2info((ulong)of_flat_tree) != NULL) > of_data = (ulong)of_flat_tree; > -- > 1.4.4 </snip>
Your U-Boot support team
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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
On Wednesday 14 March 2007 21:36, Wolfgang Denk wrote:
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?
Yes. And perhaps we could make a list for other parts of U-Boot, that are not yet covered by custodians. I have already some new suggestions:
- I2C subsystem - PCI subsystem
Any volunteers for those "subsystems"? Any further suggestions?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
In message 200703142201.46263.sr@denx.de you wrote:
Yes. And perhaps we could make a list for other parts of U-Boot, that are not yet covered by custodians. I have already some new suggestions:
- I2C subsystem
- PCI subsystem
Any volunteers for those "subsystems"? Any further suggestions?
I'm also contemplating about adding an "u-boot-testing" respository where patches from the mailing list could be dumped in (as quickly as possible) to allow for easier testing. Opinions welcome?
Best regards,
Wolfgang Denk
On Wed, 2007-03-14 at 22:04 +0100, Wolfgang Denk wrote:
I'm also contemplating about adding an "u-boot-testing" respository where patches from the mailing list could be dumped in (as quickly as possible) to allow for easier testing. Opinions welcome?
Great idea. Would you want to dump from the mailing list, or have a cron job merge in from all custodian trees once every night (or whatever)? This would spread the merging pain and would guarantee a minimum level of review.
regards, Ben
In message 1173907351.32309.19.camel@saruman.qstreams.net you wrote:
I'm also contemplating about adding an "u-boot-testing" respository where patches from the mailing list could be dumped in (as quickly as possible) to allow for easier testing. Opinions welcome?
Great idea. Would you want to dump from the mailing list, or have a cron job merge in from all custodian trees once every night (or whatever)? This would spread the merging pain and would guarantee a minimum level of review.
I was thinking about dump from the mailing list for all those patches that are not picked up by one of the custodians because they don't clearly fall in one group or another.
Usually we have to do this anyway - for example just to know if the patch causes compiler errors or warnings etc., so why not make this available as repo.
Ideally there would be even feedback, and I'd feel more confident to pull that stuff into the public tree every now and then.
As for the custodian trees, I think I'm going to do the merging manually for some time. I need to get a feeling first how good the resonance between me and the respective custodian is ...
Best regards,
Wolfgang Denk
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
participants (6)
-
Ben Warren -
Jerry Van Baren -
OTRS Notification Master -
Stefan Roese -
Timur Tabi -
Wolfgang Denk