Re: Broadcom BCM2709, ARMv8, and missing CPU features
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sat, Aug 6, 2016 at 8:15 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> the only big advantage of dtb files (binary compiled) is *IF* the
>> decision is made to respect dtb files and treat them as inviolate
>> and supported forever without needing recompiles, you stand a
>> chance of being able to upgrade linux kernels *without* replacing
>> the dtb file.
>
> That might be true when compared to some potential replacement of DTBs,
> but when compared to what we had before DTBs, then the benefit is much
> more clear: a single linux-image-armhf package which works for "all"
> machines. Personally I don't mind changing the DTB every time I change
> the kernel. Hell, that could/should be integrated with the process
> which refreshes the initrd file anyway.
... are you _sure_ it's clear? :)
the reason i ask that is, i'm not seeing any real difference: you
still have to download the linux kernel source (to submit dtsi
patches), the linux git repo is still the central location for dtsi
management... unless you're happy to set up an alternative parallel
repository (and compile infrastructure) for dtsi management... thus
you still have to download the full git repo, you still have to
compile stuff *from* that same git repo.... where's the actual benefit
to having moved to dtsi, in terms of "work needed to maintain it"?
i appreciate you don't *mind* changing the DTB file each time you
change the kernel, but that defeats one of the very purposes *of* the
DTB file.
also, i don't know if you've looked in arch/arm/boot/dts but it's
already alarmingly full. i appreciate that there's some includes
(dtsi) but realistically over time the sharing process is going to
begin to look like the selinux m4 macro includes or the openembedded
infrastructure: an unintelligeable and unmaintainable dog's dinner
that only a handful of people in the world can understand.
anyway to get back to the original topic, there's very little that
can actually shared - even with devicetree - between different
devices. it's the "N product design types" times "M processors"
thing. which is why i'm designing a hardware standard that's similar
to how things are in the x86 world, so that we can get back to "N PLUS
M" at the linux kernel level.
l.
Reply to: