From: Marcel Hamer <marcel@solidxs.nl>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Kernel device tree gets modified with bootm command when CONFIG_OFDEVICE is enabled
Date: Fri, 6 Oct 2017 09:45:24 +0200 [thread overview]
Message-ID: <4201a4ed-f5ae-2cae-e07c-1e95dbb538df@solidxs.nl> (raw)
In-Reply-To: <20171006041153.xgrjynzwido3mjfj@pengutronix.de>
Hi,
On 10/06/2017 06:11 AM, Sascha Hauer wrote:
> Hi Marcel,
>
> On Tue, Oct 03, 2017 at 11:36:49AM +0200, Marcel Hamer wrote:
>> Hello,
>>
>> When passing a custom device tree to the kernel using the 'bootm' command I
>> see the device tree gets 'fixed up' when the CONFIG_OFDEVICE option is
>> enabled. Probably this should not be the case when the dtb is passed to the
>> kernel?
>>
>> This happens on line common/bootm.c:395:
>>
>> oftree = of_get_fixed_tree(data->of_root_node);
>>
>> Should this not be changed to:
>>
>> oftree = of_flatten_db(data->of_root_node);
> No. Getting the fixed up tree is exactly what we want here. There are
> some cases in which it's absolutely mandatory to use the fixed tree
> (memory banks, they are oftem empty in the Linux provided dts files)
> and other in which is convenient (mtd, to make sure the kernel sees the
> same partitions as the bootloader).
> There might be some cases where we want to have more control over which
> fixups run and which don't, but generally we want to have the fixed tree
> here.
>
> Sascha
>
Ok, I kind of get the reasoning behind the fixing up, but I don't think
it is very welcome in all situations. Not considering the '/chosen'
node, because I can see that is a requirement to be added to the dtb.
When I specifically specify a custom dtb to be used for the Linux kernel
I would not prefer the boot loader to modify it. If there should be a
system to fix it up it should be the kernel in this case, at least in my
opinion.
It kind of sounds like the boot loader is deciding it is smarter than
the developer and overriding the settings in the dtb before it passes it
to the kernel. I also see it as kind of strange, when you configure a
partition table in your dtb for the kernel and once you boot the kernel
you get the partition table from the boot loader. Especially since I
don't think this is documented anywhere, at least not in the bootm
command documentation as far as I know.
When you want to update your dtb in the future, for whatever reason,
this also becomes an issue. For instance if you would want to add a
label to your mtd partition, then you would have to update your boot
loader to get it into the kernel. Or maybe you want part of the
partitions configurable depending on the system configuration. In this
case this would no longer be possible, because the boot loader overrides
it by default.
Would it be an option to make the fixing up configurable by a
configuration setting for the bootm command?
Kind regards,
Marcel
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2017-10-06 7:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 9:36 Marcel Hamer
2017-10-06 4:11 ` Sascha Hauer
2017-10-06 7:45 ` Marcel Hamer [this message]
2017-10-06 9:55 ` Ian Abbott
2017-10-06 10:28 ` Marcel Hamer
2017-10-06 11:04 ` gianluca
2017-10-06 12:00 ` Marcel Hamer
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=4201a4ed-f5ae-2cae-e07c-1e95dbb538df@solidxs.nl \
--to=marcel@solidxs.nl \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.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