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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
