Kernel device tree gets modified with bootm command when CONFIG_OFDEVICE is enabled
marcel at solidxs.nl
Fri Oct 6 05:00:10 PDT 2017
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:
>>> (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
>> 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?
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.
More information about the barebox