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

Grant Likely grant.likely at secretlab.ca
Wed Nov 20 08:18:29 EST 2013

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.


More information about the linux-arm-kernel mailing list