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.
>
> 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.
Can you please explain why that's a better long term strategy? So
far I've had a hard time selling this internally so I could use
the help to come up with a laundry list of reasons why this is a
better design than what we have today.
> 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.
If the bootloader supports filesystems, then it would work to
encode the qcom,{msm-id,board-id,pmic-id} properties into some
long filename and then have the bootloader pick the right file
based on that. Fuzzy matching would be interesting, but it should
still work.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
