From: Marcel Hamer <marcel@solidxs.nl>
To: gianluca <gianlucarenzi@eurekelettronica.it>,
barebox@lists.infradead.org
Subject: Re: Kernel device tree gets modified with bootm command when CONFIG_OFDEVICE is enabled
Date: Fri, 6 Oct 2017 14:00:10 +0200 [thread overview]
Message-ID: <4003f255-1257-fefe-fbcf-814f7c025755@solidxs.nl> (raw)
In-Reply-To: <724ccd1e-493c-b6dd-e0aa-ea65828fb6bf@eurekelettronica.it>
Hello,
On 10/06/2017 01:04 PM, gianluca wrote:
> On 10/06/2017 12:28 PM, Marcel Hamer wrote:
>> Hello Ian,
>>
>>> There is a magic variable setting to leave the partition entries alone:
>>>
>>> global.of_partition_binding="donttouch"
>>>
>>> (Other meaningful values for this variable are "new" and "legacy",
>>> which controls whether the individual partitions are placed within a
>>> "partitions" node ("new") or not ("legacy").)
>>>
>>
>> Thank you for pointing that option out, I will certainly have a look at
>> that.
>>
>> I took the partitioning as an example, because it gave me the biggest
>> burden. But I guess in general I think the principle of fixing up the
>> kernel device tree should be optional to my opinion.
>>
>
> IMHO you Marcel, are missing the point.
>
> Do not changing device tree and passing it as-is to the kernel has the
> reason on systems non upgradable, non changeable during their
> life-time. i.e. routers and or smartphones.
>
> Usually they are provided with all stuff attached and normally
> everyting is working out-of-the-box.
>
> To my experience, we have a bunch of boards, and they are different
> each other by little stuff, such as number of uarts, gpios,
> screens/lcd, memory and storage size.
>
> I am letting BareBox to adapt a "generic-all-inclusive" device-tree
> with the correct "device-tree" to the kernel, so it can be used
> without hassle having and managing a single device-tree in our
> develpement studio.
>
> It is simpler to have a single device-tree which can be used over a
> plethora of boards based on the same root-hardware, than having a
> plethora of device-trees perfectly adapted with your plethora of devices.
>
> Do you agree?
>
> Regards,
> Gianluca
But that is more a matter of how you decide to manage your device trees
in your development process, right? You can do that in many ways and you
have the freedom of choice there, I don't directly see the relation to
my question to be honest. It is not a matter of what devices are covered
in the device tree.
With systems that have root file systems and Linux kernels that can be
updated, for instance in a Rauc kind of setup, you want to be able to
control your dtb as well. What if you upgrade to a Linux kernel version
that has incompatible changes in some areas, you might in theory end up
to be forced to update your boot loader as well? I would prefer to be
able to update my kernel dtb independent of the boot loader, because I
can do that redundantly. And in that case I don't want to be dependent
on the boot loader source code.
Kind regards,
Marcel
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2017-10-06 12:00 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
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 [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=4003f255-1257-fefe-fbcf-814f7c025755@solidxs.nl \
--to=marcel@solidxs.nl \
--cc=barebox@lists.infradead.org \
--cc=gianlucarenzi@eurekelettronica.it \
/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