[PATCH 00/21] Qualcomm generic board support

[Caleb Connolly]

On 05/12/2023 07:44, Sumit Garg wrote:
> Hi Simon,
> 
> On Tue, 5 Dec 2023 at 06:22, Simon Glass <sjg at chromium.org> wrote:
>>
>> Hi Sumit,
>>
>> On Tue, 21 Nov 2023 at 23:21, Sumit Garg <sumit.garg at linaro.org> wrote:
>>>
>>> Hi Caleb,
>>>
>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.connolly at linaro.org> wrote:
[...]
>>>> == 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?
>>>
>>> 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
>>
>> What is this?? Who or what uses a gzipped image with a single DT attached?
> 
> The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
> LK). It is the usual way Linux is booted on these platforms. U-boot is
> being brought into this chain to leverage standardized EFI boot
> processes.

Yes, just to clarify, this is the state that _all_ non-WoA Qualcomm
boards/devices are in right now (with the exception of db410c), with
production devices we can't modify the bootloader without vendors
releasing their signing keys.

For devices that haven't been locked with vendor keys ("Secureboot off"
in Qualcomm terminology, note that this has nothing to do with UEFI
secureboot) we can work towards replacing the bootloader entirely with
U-Boot, I have done a PoC of this on SDM845. In that case, we have to
embed the DTB into U-Boot.
> 
>>
>>>
>>> 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.
>>
>> That is not the current situation, unfortunately.
>>
> 
> Hopefully with efforts from Caleb and team we can reach that point soon.
> 
>> U-Boot is moving to using Binman to package the firmware. There needs
>> to be a description of the firmware image for each U-Boot boot. To my
>> way of thinking, rpi is a degenerate form, not something to be copied,
>> due to the closed-source nature of the firmware and its inability to
>> be changed. We do have (in the works) a way to pass a DT using a
>> standard firmware handoff. Perhaps that can be adopted by these
>> closed-source projects?
> 
> Why should we really need firmware handoff if the DT can be passed in
> one of the u-boot boot arguments? Linux kernel does support this
> method to retrieve DT as well.

Unfortunately the chances of Qualcomm releasing bootloader updates to
adopt a standard for chainloading U-Boot on their wholely deprecated
platforms of 5/6/7 years ago, and then having OEMs/ODMs (who have no
reason to care, and may not even be around anymore) apply these patches
to their own hacked up fork of the bootloader and ship it to end-users
is honestly even less likely than OEMs releasing the signing keys for
devices they don't support anymore.
> 
>>
>> BTW I am very pleased to see this series and I hope that Qualcomm (via
>> Linaro) can continue to improve its U-Boot support.
> 
> It's good to know, thanks.
> 
> -Sumit
> 
>>
>> [..]
>>
>> Regards,
>> Simon

-- 
// Caleb (they/them)