On 23 May 2014 14:41, "Ian Campbell" <[email protected]> wrote:
>
> On Fri, 2014-05-23 at 06:44 +0800, Andy Green wrote:
> > 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
>
> I know this.
>
> What I meant was that the boot script on the sd card would be assuming
> that the bootloader was the Fujitsu one which "knows the right dtb
> filename for that SoC", and hence would only work on those systems.
> Unless this knowledge of the right dtb name is to become a standard

No, as I wrote those systems have a board-specific bootloader on the board,
not the OS media, that knows the correct dtb name for the board.  There is
no 'boot script on the SD card' needed for these kind of SoC.

That setup just requires a standard dir to find the already known dtb
filename in and it can boot any OS that put the things in the right places.

Something will need to suggest which kernel to use in multi-kernel case, a
symlink would do.

Otherwise it can work on any sd card image for, eg one aimed at uboot and
the v7 defconfig, it'll just ignore the uboot bits, grab the right dtb and
the kernel from the standard place on the sd card and boot.

-Andy

> also...
>
> > > 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).
>
> ... which it sounds like it might be.
>
> How do other OSes call their DTB files? I expect they aren't consistent
> with Linux...

> Ian.
>
_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro

Reply via email to