On Fri 21 Oct 13:25 PDT 2016, Arnd Bergmann wrote:
> On Friday, October 21, 2016 1:04:09 PM CEST Stephen Boyd wrote:
> > On 10/21, Bjorn Andersson wrote:
> > > On Wed 19 Oct 20:17 PDT 2016, Andy Gross wrote:
> > >
> > > > On Wed, Oct 19, 2016 at 08:07:25PM -0500, Rob Herring wrote:
> > > [..]
> > > > > Makes sense to me for things like Nexus phones here. What about DB410
> > > > > for example? Is there hope for a fix there? My bootloader is only a
> > > > > couple of months old and needs the properties still.
> > > >
> > > > There won't be a fix for the 410c. We barely got them to respin to use PSCI.
> > > > Stephen can correct me if I am wrong on this.
> > > >
> > > > If this is fixed, it would be 8996+. If..........
> > > >
> > > > So this means introducing the msm-id's for the boards that currently require it,
> > > > and for the boards that will require it in the future. And this would stay in
> > > > effect until the bootloader is able to parse the compatible strings or figure
> > > > this out without the msm-ids.
> > > >
> > >
> > > But if the bootloader at any point in the future would support picking a
> > > dtb by compatible strings instead of {msm,board,pmic}-id we wouldn't we
> > > just be back to the ridiculous compatible strings that tipped over into
> > > acceptance to these ids in the first place.
> > >
> > > Or do we expect the boot loader to do a deep scan of the dtb to match on
> > > multiple nodes from the tree?
> >
> > I'm pushing the bootloader team to do the deep scan of the dtb to
> > match up board compatible and pmic compatible strings so that we
> > don't have to keep these numbers around. Basically put what
> > dtbtool is doing into the bootloader so we don't have to post
> > process the dtb anymore. We're currently discussing how to
> > implement it and how to move the internal codebase to the new
> > scheme.
> >
> > At least for 96boards I think we can update the lk bootloaders on
> > there to adopt this code. For other platforms like nexus though I
> > don't see a way we can update those bootloaders, and those
> > bootloaders require these properties exist in the dtbs, so we
> > should just throw the numbers into the dts files there and be
> > done with post processing. For bootloaders that require the QCDT
> > header, we'll have to keep running dtbtool there to generate the
> > header. Having the ids in the dts file or not doesn't really
> > matter there.
>
> I think part of the problem here is the way that the bootloader
> expects multiple dtbs to be appended to the kernel binary, and
> then pick one of them based on its contents. That doesn't really
> change at all when changing the parser from looking at nonstandard
> properties to looking at the compatible strings.
>
This is unrelated to appending images to the zImage. Qualcomm already
supports (their original approach) of storing the multiple DTBs in a
QCDT blob; which contains a header of {msm,board,pmic}-id and offsets to
each blob.
So in this case it's not the boot that parses the dtb, but rather the
tool packaging the factory images.
> It still breaks the last-resort workaround for broken bootloaders
> that we have in the form of appending the DT to the kernel
> with CONFIG_ARM_APPENDED_DTB.
>
Yes, this is a likely reason to why Qualcomm didn't take that route,
until it showed up in Nexus 6 (and 5?).
> I think a better long-term strategy would be to make the bootloader
> load the dtb separately from the kernel and finding the right file
> using some information outside of the dtb. Ideally this is done
> by storing all files on a file system that can also be mounted
> to /boot, but there are probably other options that work equally well.
>
This scheme exists so that you can have a single software image running
on multiple revisions of a SoC and PMIC, something that is essential for
both production and upgrade schemes.
No matter how you package your multiple dtbs there needs to be some sort
of identifier associated that the boot can use to pick the appropriate
image from the bunch.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
