mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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

      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