[RFC PATCH V2 2/2] kbuild: dtbs_install: new make target

[Grant Likely]

On Tue, 19 Nov 2013 14:06:05 -0700, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 11/19/2013 01:39 PM, Jason Cooper wrote:
> > On Tue, Nov 19, 2013 at 12:53:07PM -0700, Stephen Warren wrote:
> ...
> >> d) Finally, boot.scr needs to load the DTB. This requires knowing which
> >> DTB to load. Again, the distro shouldn't have to detect which board
> >> they're running on, and either install the correct DTB to a static
> >> filename, or make a decision on the DTB filename to load. Instead,
> >> distros should simply install all DTBs generated by the kernel build,
> >> and use some run-time information to calculate the DTB filename using a
> >> completely HW-agnostic and generic algorithm.
> >>
> >> To support this, U-Boot can be configured to add certain standard
> >> environment variables to the default environment. These define which SoC
> >> and board the code is running on. These are ${soc} and ${board}. If you
> >> then calculate the DTB filename as ${soc}-${board}.dtb, that should work
> >> anywhere. This is why keeping the current in-kernel DTB filenames is
> >> important, so they match the assumption that this algorithm works.
> >>
> >> Note: if the firmware contains an embedded DTB, boot.scr could detect
> >> this e.g. by the standard variable $fdt_addr being set, and hence skiip
> >> loading a DTB. IIRC, this is how Calxeda boards are set up.
> > 
> > Ok, so the ${soc}-${board} is a work-around until all bootloaders are
> > providing a dtb, or until all bootloaders are providing a stable dtb?
> 
> I suppose so yes.
> 
> However, I'm not really convinced we'll see that many products with a DT
> embedded into them that's stable, complete[1], and based on upstream
> bindings, in the particularly near future. I think distros will likely
> need to deal with DTs-in-filesystems for a while yet. But anyway, either
> way should work out just fine.
> 
> [1] For example, we aren't that far off some reasonably stable basic
> bindings for Tegra now . However, there are still devices we haven't
> added to DT at all, so while the DT ABI stability issue is fading, the
> need-to-upgrade-your-DTB case still exists to get new features, and
> upgrading the DTB via the filesystem is a lot easier and more convenient
> than doing so via firmware updates or firmware flashing commands.

I'm completely fine with requiring a DT upgrade to enable new features,
so long as keeping the same DT doesn't cause regress when running on
mainline. Keeping that support enabled in firmware is important.

g.