On Thu, Jun 20, 2019 at 2:35 AM Leif Lindholm leif.lindholm@linaro.org wrote:
On Wed, Jun 19, 2019 at 09:15:11AM -0700, Rob Clark wrote:
On Wed, Jun 19, 2019 at 8:19 AM Richard Henwood Richard.Henwood@arm.com wrote:
- Create UEFI module for persistently loading DTB
- We have one which handles this for a single boot
- NB: Assuming Leif will handle this
So, one question about this approach, is how do we handle kernel upgrades and new dtb.. I'm not 100% sure what other distro's do, but fedora has set of dtb files per kernel version, but something that runs before grub wouldn't know which kernel version grub will load.
2019 and we're still treating the DT as a property of the kernel image? This is something the distros will need to wean themselves off anyway.
mixed-feelings about this.. on one hand, by the time the dts is upstream it should be fairly safe to just use the most recent one..
But on the other hand, I'm frequently working with stuff which is still in the process of getting upstream, and sometimes bindings change along the way. (And I'm a selfish bastard who cares about his own use-case :-P)
So it would be nice to load a kernel specific dt if present, and then just fallback to whatever the most recent is.
Let's hope we won't need to change bindings incompatibly on every rebuild of the kernel.
Semi-related, I'd suggested[1] addition of dmi-compatible property in DT, to give some mechanism to auto-pick the correct dtb, ie. something like:
dmi-compatible = "LENOVO 81JL/LNVNB161216", "LENOVO 81JL";
This will be useful regardless.
on my lenovo c630, the SMBIOS table has:
vendor: LENOVO product: 81JL board: LNVNB161216
(I'd be curios to see "dmesg | grep DMI" output from other laptops, btw.. to confirm these fields are populated in a reasonably sane way)
Yes. We could set up a wiki page.
that would be a good idea..
fwiw, chatted a bit w/ robher about this on #armlinux.. he suggested maybe just separate dmi-vendor/dmi-product/dmi-board fields.
I don't have a strong opinion one way or another.. I suppose the compatible string type thing makes it easier to prepend something more specific later if needed.
I think we especially need to get examples including non-compatible hw revisions.
I wonder if those exist yet? Maybe we could just look at values on x86 laptops and interpolate..
But I guess we can prepend better compatible strings in future if it turns out these aren't sufficient?
yeah
BR, -R