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

On 10/21, Arnd Bergmann wrote:

quoted

On Friday, October 21, 2016 1:04:09 PM CEST Stephen Boyd wrote:

quoted

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.

[..]

quoted

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