[PATCH 00/21] Qualcomm generic board support

[Caleb Connolly]

On 22/11/2023 14:27, Tom Rini wrote:
> On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote:
>> On Wed, 22 Nov 2023 at 19:31, Tom Rini <trini at konsulko.com> wrote:
>>>
>>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote:
>>>> Hi Caleb,
>>>>
>>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.connolly at linaro.org> wrote:
>>> [snip]
>>>>> == DT loading ==
>>>>>
>>>>> Previously, boards used the FDT blob embedded into U-Boot (via
>>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
>>>>> bootloader, so we can instead rely on the first-stage bootloader to
>>>>> populate some useful FDT properties for us (notably the /memory node and
>>>>> KASLR seed) and fetch the DTB that it provides. Combined with the memory
>>>>> map changes above, this let's us entirely avoid configuring the memory
>>>>> map explicitly.
>>>>
>>>> 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. 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.

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.
>>>>
>>>> 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)