From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Tue, 19 Nov 2013 14:06:05 -0700 Subject: [RFC PATCH V2 2/2] kbuild: dtbs_install: new make target In-Reply-To: <20131119203923.GF28859@titan.lakedaemon.net> References: <20131118191955.GG10335@titan.lakedaemon.net> <528A6944.3070303@wwwdotorg.org> <20131118192852.GI10335@titan.lakedaemon.net> <528A6CA3.9030904@wwwdotorg.org> <20131118195243.GJ10335@titan.lakedaemon.net> <528A98C8.9040803@wwwdotorg.org> <20131119122801.GL16735@n2100.arm.linux.org.uk> <528BB109.2060201@wwwdotorg.org> <20131119185729.GD28859@titan.lakedaemon.net> <528BC1A3.70202@wwwdotorg.org> <20131119203923.GF28859@titan.lakedaemon.net> Message-ID: <528BD2BD.8090304@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [RFC PATCH V2 2/2] kbuild: dtbs_install: new make target Date: Tue, 19 Nov 2013 14:06:05 -0700 Message-ID: <528BD2BD.8090304@wwwdotorg.org> References: <20131118191955.GG10335@titan.lakedaemon.net> <528A6944.3070303@wwwdotorg.org> <20131118192852.GI10335@titan.lakedaemon.net> <528A6CA3.9030904@wwwdotorg.org> <20131118195243.GJ10335@titan.lakedaemon.net> <528A98C8.9040803@wwwdotorg.org> <20131119122801.GL16735@n2100.arm.linux.org.uk> <528BB109.2060201@wwwdotorg.org> <20131119185729.GD28859@titan.lakedaemon.net> <528BC1A3.70202@wwwdotorg.org> <20131119203923.GF28859@titan.lakedaemon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131119203923.GF28859-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jason Cooper Cc: Russell King - ARM Linux , Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll , Ian Campbell , Rob Herring , Olof Johansson , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html