[PATCH 00/21] Qualcomm generic board support

[Caleb Connolly]

>>>>>>>>> Since with this change, we don't need to embed FDT blob in the u-boot
>>>>>>>>> binary, so I was thinking if we really need to import DTs from Linux
>>>>>>>>> for different platforms and then play a catchup game?
>>>>>
>>>>> For now, yes.
>>>>
>>>> But why? Is there any value added by larger u-boot specific DT (most
>>>> of the nodes being unused by u-boot) than what currently u-boot
>>>> supports? The more important part is to get alignment with Linux DT
>>>> bindings. If you need to have memory/reserved-memory nodes in u-boot
>>>> DT for generalization purposes then you should import those particular
>>>> nodes only.
>>>
>>> I've been thinking about and hacking on this for the last week or so,
>>> sorry for the delayed reply here.
>>>
>>> The value is in preventing any of the existing bindings from regressing,
> 
> That is actually best addressed in Linux by checking the DTS against
> yaml DT bindings. We don't have that testing available in u-boot and
> only depend on careful reviews.

Sorry, I didn't explain myself very well here. By having .dtsi files be
identical to Linux, we ensure that U-Boot drivers will remain compatible
with them. Just as an argument not to use custom SoC dts in U-Boot
(which is what we do currently).
> 
>>> and simplifying the bringup process for new platforms (just copy
>>> SoC/PMIC DTSI and write a minimal board DTS to enable the needed hardware).
>>>>
>>>>> There are quite a few features which aren't handled by
>>>>> U-Boot that it shouldn't need to handle (rpm/h resources for example).
>>>>> Also the fixed-regulator / regulator-gpio binding differences.
>>>>
>>>> IMO, we should fix them first and then use Linux DT as it is.
>>>
>>> The biggest blocker here is USB, on sdm845 and the 4 new platforms I
>>> have working, I only support USB high speed, this requires removing the
>>> superspeed phy and adding a DTS property.
>>>
>>> I tried using OF_BOARD_SETUP to make this changes during boot but this
>>> approach really isn't scalable (and I couldn't find a way to make it
>>> work anyway).
> 
> Okay so let's try an alternative intermediate step then. We import the
> Linux DT files *as it is* and then keep the u-boot specific custom
> changes in <soc>-u-boot.dtsi file which is included by the board DTS
> file. This has been the approach that other u-boot platforms follow
> and allow us to easily sync them with Linux while reducing custom
> u-boot specific bits. Eventually we should target at dropping u-boot
> specific custom bits and then directly pick up DTB from Linux and boot
> it.

Ok, I think this is a reasonable approach. Will do that for the next
revision
> 
>>>
>>>>
>>>>>
>>>>> I would definitely like to move towards supporting Linux DT directly,
>>>>> but this approach gives us a nice middleground of minimising the U-Boot
>>>>> specific DT parts.
>>>>
>>>> I don't see any real benefits here apart from the maintenance burden.
>>>> If it had been an actual Linux DT then that can be passed to Linux as
>>>> it is. However, the current modified import you are trying to do
>>>> doesn't solve that purpose as well.
>>>
>>> Ensuring that we don't introduce non-standard bindings (by using Linux
>>> DTSI) is one benefit, simplifying new platform bringup is another.
>>>
>>> The amount of work required to switch to upstream DT is too much to
>>> block this series on. We can work on improving the situation there once
>>> we have these Qualcomm improvements upstream and new boards added. I do
>>> admit that this is quite an awkward middle-ground, and I would not like
>>> it to last for too long.
>>
>> I'm a real supporter of targeting support of unmodified (or very slighly)
>> Linux DT, having a reduced version of the Linux DT will be a pain at each
>> sync, and you'll need to do this manually.
> 
> We have to choose the middle-ground carefully here. It shouldn't give
> the impression that it is an actual Linux DT that you can pass
> directly to Linux via EFI. As otherwise users will hit problems due to
> the partially modified DTs in u-boot.
> 
>>
>> Simply having to copy the Linux DT without any changes will make sure you
>> are in sync with Linux's bindings, and will help making sure you'll boot
>> unchanged Linux DTBs you get from previous loaders.
> 
> Once we have the previous loaders (ABL or LK) providing u-boot fully
> fledged DTB then we don't need to maintain Linux DT copy in u-boot
> which is always a pain to keep in sync.

Yes
> 
>>
>> And in bonus, you'll be able to chain it to the next loader like EFI.
>>
>> So I don't see why any work toward this goal is useless, and if an
>> intermediate step is needed, let's do it.
> 
> See the side effects of an intermediate step mentioned above. Having
> <soc>-u-boot.dtsi clearly separates the changes we have to make for
> u-boot.

Sounds good.

Thanks,
> 
> -Sumit
> 
>>
>> Neil
>>
>>>
>>>>
>>>> -Sumit
>>>>
>>>>>>>>>
>>>>>>>>> IMO, the build command would look like following if we import
>>>>>>>>> pre-built FDT blob from Linux:
>>>>>>>>>
>>>>>>>>> - Build u-boot::
>>>>>>>>>
>>>>>>>>>          $ export CROSS_COMPILE=<aarch64 toolchain prefix>
>>>>>>>>>          $ make qcom_defconfig
>>>>>>>>>          $ make
>>>>>>>>>
>>>>>>>>> - gzip u-boot::
>>>>>>>>>
>>>>>>>>>          gzip u-boot-nodtb.bin
>>>>>>>>>
>>>>>>>>> - Append dtb to gzipped u-boot::
>>>>>>>>>
>>>>>>>>>           cat u-boot-nodtb.bin.gz
>>>>>>>>> <linux-tree>/arch/arm64/boot/dts/qcom/your-board.dtb >
>>>>>>>>> u-boot-nodtb.bin.gz-dtb
>>>>>>>>>
>>>>>>>>> This would avoid the maintenance burden to keep DT in sync with that
>>>>>>>>> of Linux. And since DT bindings in Linux are backwards compatible, we
>>>>>>>>> can say u-boot should work with DTB picked up from any Linux kernel
>>>>>>>>> stable release.
>>>>>>>>
>>>>>>>> I guess one question I have is, are we being passed the device tree
>>>>>>>> (since we're acting like the Linux Kernel)
>>>>>>>
>>>>>>> Yeah that is the case here, see patch #1 in this series regarding how
>>>>>>> FDT address is being retrieved from previous stage bootloader (ABL on
>>>>>>> sdm845 and qcs404 SoCs).
>>>>>>
>>>>>> That's what I thought.
>>>>>>
>>>>>>>> or knowing that we have the
>>>>>>>> dtb attached to the end of us and making use of the old kernel appended
>>>>>>>> dtb option? We're fine in for example the rpi_arm64 case of just being
>>>>>>>> given a device tree from the previous stage and not needing one in-tree.
>>>>>>>
>>>>>>> That's good to know and we can replicate that for Qcom platforms which
>>>>>>> are chainloaded and don't need an embedded DT.
>>>>>>
>>>>>> So yes, moving these towards the direction of rpi_arm64 and specifically
>>>>>> using imply OF_HAS_PRIOR_STAGE or select OF_HAS_PRIOR_STAGE (force that
>>>>>> the dtb must be provided to us) sounds like the right direction to take
>>>>>> these platforms
>>>>>>
>>>>>
>>>>> --
>>>>> // Caleb (they/them)
>>>
>>

-- 
// Caleb (they/them)