On 22 May 2014 22:49, Ian Campbell <[email protected]> wrote: > On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote: >> On 22 May 2014 17:50, Ian Campbell <[email protected]> wrote: >> > On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote: >> >> >> >> Hi, >> >> >> >> I've collected a list of where people install their dtb files these >> >> days; >> >> >> >> https://wiki.linaro.org/Platform/DeviceTreeConsolidation >> >> >> >> >> >> Every distribution has a slightly different variation of install >> >> location, which is not good - we can't tell end users that "this is >> >> the place you can expect to find your device tree files regardless of >> >> what distribution you choose". Some questions I have here before we >> >> proceed discussing what would be the standardized location: >> >> >> >> >> >> 1) Anything missing of the pros and cons of different locations? >> > >> > FWIW Debian will now arrange for the correct DTB for the platform to be >> > installed as /boot/dtb-$(uname -r) as well as the /usr/lib location. >> ... >> > I'm more or less ambivalent about installing all of the possible DTB >> > files in a similar location though. I'm not sure what the use case for >> > that is. Wouldn't you also need to standardise on the dtb filename for >> > each platform and effectively make that ABI? >> >> For installs on eg, an SD Card, there's nothing stopping the one SD >> Card being usable on multiple different SoC platforms if the >> bootloader will allow it. > >> For example Fujitsu have various SoC with bootloader in HSSPI NOR, >> which knows the right dtb filename for that SoC. >> >> So if all the dtbs are in /boot/whatever, that same SD Card is capable >> to boot on any of them, since they're all supported by the same single >> kernel binary from the same SD Card, and the bootloader picked out the >> right one for what it happens to be running on. It's very convenient. > > But such an sd card would only work on these Fujitsu SoCs, wouldn't it?
No... if you consider "multi_v7_defconfig" in mainline that one kernel binary is supporting CONFIG_ARCH_MVEBU=y CONFIG_ARCH_BCM=y CONFIG_ARCH_BCM_5301X=y CONFIG_ARCH_BCM_MOBILE=y CONFIG_ARCH_BERLIN=y CONFIG_ARCH_HIGHBANK=y CONFIG_ARCH_HI3xxx=y CONFIG_ARCH_KEYSTONE=y CONFIG_ARCH_MXC=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP4=y CONFIG_ARCH_QCOM=y CONFIG_ARCH_MSM8X60=y CONFIG_ARCH_MSM8960=y CONFIG_ARCH_MSM8974=y CONFIG_ARCH_ROCKCHIP=y CONFIG_ARCH_SOCFPGA=y CONFIG_ARCH_SPEAR13XX=y CONFIG_ARCH_STI=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_SIRF=y CONFIG_ARCH_TEGRA=y CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y CONFIG_ARCH_TEGRA_114_SOC=y CONFIG_ARCH_TEGRA_124_SOC=y CONFIG_ARCH_U8500=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_VEXPRESS_CA9X4=y CONFIG_ARCH_VIRT=y CONFIG_ARCH_WM8850=y CONFIG_ARCH_ZYNQ=y Installing only "correct DTB for the [install] platform" approach will break all that. For that defconfig, you should be installing all the DTB variations for all those supported machines to match the kernel capability. If you're getting the DTBs from outside the kernel, installing them all will solve it, otherwise the kernel should generate the DTB set you need according to the enabled machines and knowing itself which DTBs are related to those and building them. The major discontiguity stopping it globbing up all the machines is "LPAE or not" forces needing a different kernel binary. > In which case a single boot.scr could equally well handle it. ... > Or is there a separate effort to standardise uboot bootcmd settings as > well? As Stephen says, a few weeks ago I installed Fedora 20 on a Cubiebrick for my own web services, I noticed there is a monster U-Boot script coming with Fedora now that is trying to normalize U-Boot across all the boards (a pretty amazing endeavour actually). -Andy >> From that point of view, there isn't really a "correct DTB for the >> platform" because the platform it got installed on may not be the only >> one it's capable and wanting to boot. >> >> -Andy >> >> > Ian. >> > >> > >> > >> > _______________________________________________ >> > cross-distro mailing list >> > [email protected] >> > http://lists.linaro.org/mailman/listinfo/cross-distro >> > > _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
