Re: [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection

[Paul Kocialkowski]

Le mercredi 21 septembre 2016 Ã 08:34 +0100, Jon Hunter a ÃcritÂ:
> On 20/09/16 19:02, Paul Kocialkowski wrote:
> > 
> > * PGP Signed by an unknown key
> > 
> > Le mardi 20 septembre 2016 Ã 18:56 +0100, Jon Hunter a Ãcrit :
> > > 
> > > On 20/09/16 18:53, Paul Kocialkowski wrote:
> > > > 
> > > > 
> > > > > 
> > > > > Old Signed by an unknown key
> > > > 
> > > > Le mardi 20 septembre 2016 Ã 18:41 +0100, Jon Hunter a Ãcrit :
> > > > > 
> > > > > 
> > > > > On 28/08/16 18:32, Paul Kocialkowski wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Depthcharge (the payload used with cros devices) will attempt to
> > > > > > detect
> > > > > > boards using their revision. This includes all the known revisions
> > > > > > for
> > > > > > the nyan-big board so that the dtb can be selected preferably.
> > > > > 
> > > > > May be I am missing something here, but for the mainline there is only
> > > > > one dtb available and so why is this needed for the mainline?
> > > > 
> > > > There is indeed a single dts in mainline, but depthcharge will use the
> > > > revision
> > > > to match the compatible string (e.g. it will look for google,nyan-big-
> > > > rev5,
> > > > not
> > > > google,nyan-big), so we need to list them all in that single dts.
> > > > Otherwise,
> > > > depthcharge will fall back to the default config, which may or may not
> > > > be
> > > > suitable for nyan.
> > > 
> > > Is tegra124-nyan-big.dtb not the default?
> > 
> > You can't expect that to always be the case. The image format allows many
> > different dts to be provided, so I could easily build with
> > multi_v7_defconfig
> > and have various dts for various devices in the same image, and just select
> > a
> > random one as default.
> 
> Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
> catch all.

Yes, the image format (FIT) allows specifying multiple dtb and zImage
combinations in the same image[0].

See depthcharge[|1] for how the "compatible" property is being matched against.

> > Here, default is really a fallback, the right one is expected to be detected
> > by
> > this mechanism. And it really doesn't hurt to provide that information for
> > proper detection.
> > 
> > Note that this is done with many other cros devices in mainline (such as
> > rk3288
> > veyrons).
> 
> Yes, I guess the same is true for the tegra210-smaug and we do define
> all the revs for that one. May be extend the changelog comment to say
> what may happen without this change and the problem that this is fixing.

Allright, will do!

Thanks

[0]:Âhttp://www.denx.de/wiki/pub/U-Boot/Documentation/multi_image_booting_scenarios.pdf
[1]:Âhttps://chromium.googlesource.com/chromiumos/platform/depthcharge/+/master/src/boot/fit.c#39

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

Attachment: signature.asc
Description: This is a digitally signed message part