Re: [RFC V2 PATCH 10/12] arm64: dts: msm8994 issolate non standard bootloader/LK entries

[Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On Fri 21 Oct 17:07 PDT 2016, Stephen Boyd wrote:

> On 10/21, Arnd Bergmann wrote:
> > On Friday, October 21, 2016 1:04:09 PM CEST Stephen Boyd wrote:
> > > 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.
> > 
> > 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.
> 
> That can be "fixed" by having the bootloader use the single
> appended DTB regardless of the properties existing or not. That's
> a few lines of code to count the number of appended blobs and
> then special case there being one.
> 

This is already the case on at least 8974; if the ids are present they
must be the right ones, otherwise it will just pick the dtb that's
there.

[..]
> > 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.
> > 
> 
> Some bootloaders *cough* LK *cough* aren't always able to read
> filesystems. All they can do is read raw data from partitions.
> That's probably why nobody has thought about reading files from
> some place like /boot (which doesn't even exist in android)
> because these bootloaders don't have filesystem support.
> 

Well, your version of LK has ext2 support - just not in the code path
that loads the kernel. But that's still only a different way to
represent what we today have in QCDT, it doesn't change anything related
to these ids.

Regards,
Bjorn
--
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