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

On Tue, 19 Nov 2013 14:06:05 -0700, Stephen Warren [off-list ref] wrote:

On 11/19/2013 01:39 PM, Jason Cooper wrote:

quoted

On Tue, Nov 19, 2013 at 12:53:07PM -0700, Stephen Warren wrote:

...

quoted

quoted

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.