[RFC 1/4] arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support

[Jeremy McNicoll]

On 2016-09-22 11:39 AM, Stephen Boyd wrote:
> Quoting Jeremy McNicoll (2016-09-20 17:42:02)
>> On 2016-07-08 10:41 AM, Andy Gross wrote:
>>> On Thu, Jul 07, 2016 at 05:41:04PM -0700, Jeremy McNicoll wrote:
>>>> +
>>>> +#include "../qcom/msm8992.dtsi"
>>>> +
>>>> +/ {
>>>> +    model = "LGE MSM8992 BULLHEAD rev-1.01";
>>>> +    compatible = "qcom,msm8992";
>>>> +    qcom,board-id = <0xb64 0>;
>>>
>>> Please work with sboyd to add the board-id to the dtbTool.  We don't put
>>> board-ids in the dts file.  We post-process the dtb file and add them then.
>>>
>>
>> sboyd has all the info he needs for this, I believe its just with legal
>> now.  Will remove for V2.
>
> I've pushed out an update for dtbtool to have these msm ids.
>
>>
>>>> +
>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> +#include <dt-bindings/clock/qcom,gcc-msm8994.h>
>>>> +
>>>> +/ {
>>>> +    model = "Qualcomm Technologies, Inc. MSM 8992";
>>>> +    compatible = "qcom,msm8992";
>>>> +    qcom,msm-id = <251 0>, <252 0>;
>>
>> This is needed or else the LK provides the following error
>>
>> [5380] qcom,msm-id entry not found
>>
>> and refuses to boot.
>>
>>
>>>> +    qcom,pmic-id = <0x10009 0x1000A 0x0 0x0>;
>>>
>>> See above comment on ids.
>>
>> removal of this (pmic-id) seems to be ok.
>>
>
> Having the msm ids (and the pmic ids) in dtbtool isn't going to help
> here though. I believe the bootloader on these devices uses a design of
> appended dtbs where each dtb has the qcom,{msm-id,board-id,pmic-id}
> properties in them. The QCDT "header" that dtbtool generates is not
> used.
>
> To fix that problem we'll need to update dtbtool to inject these
> properties into the dtbs based on the compatible strings. Or get
> maintainers to accept that these ids are now necessary for proper
> functionality.


I will try modifying the tool to inject these values to understand
how easy and/or complicated it will be.  This topic will be raised
during plumbers as most people will be there.

>
> Furthermore, the value of board-id (0xb64) is concerning. qcom only
> supports a certain set of values there for their boards, but vendors are
> free to do whatever they want with that value. This means they can reuse
> existing values that would map to qcom's concept of the "mtp" or "cdp"
> boards, or they can numbers that would alias with other vendors.
> Thankfully, msm-id and pmic-id are values that are under qcom's control,
> so those are always going to be unique and sane. Really all that could
> alias is board-id.
>
> What does this all mean? We can't support non-qcom boards in the same
> boot.img because of the possibility for the board-id property to alias
> between different dtbs. Or at least dtbtool will have to do some alias
> analysis and eject one aliasing dtbs from the blob. It also means that
> we have a lot of work to do in dtbtool to inject these properties based
> on strings, and to have custom parsers for different vendor prefixes so
> that we know what values to inject (the nightmare is growing).
>

This provides a reasonably compelling argument that can be discussed 
with the device tree maintainers during Plumbers.

> I've asked the bootloader folks to fix this in future platforms so that
> we match based on the compatible string, instead of having to do any
> post processing. Basically, put dtbtool logic into the bootloader. The
> discussion is still on-going, but I'm hopeful that we don't need to keep
> doing things here with post-processing and the headache will be reduced.
> That could totally backfire though if vendors decide to leave the
> bootloader unchanged and boot the "qcom,msm8992-mtp" dtb that's been
> slightly tweaked for their design. Let's hope that doesn't happen.
>

Thank you for pushing this internally as it will definitely aid in the
mainline support going forward.

-jeremy