Hi Caleb,
On Tue, 5 Dec 2023 at 03:55, Caleb Connolly caleb.connolly@linaro.org wrote:
On 05/12/2023 07:44, Sumit Garg wrote:
Hi Simon,
On Tue, 5 Dec 2023 at 06:22, Simon Glass sjg@chromium.org wrote:
Hi Sumit,
On Tue, 21 Nov 2023 at 23:21, Sumit Garg sumit.garg@linaro.org wrote:
Hi Caleb,
On Tue, 21 Nov 2023 at 22:39, Caleb Connolly caleb.connolly@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 $ makegzip u-boot::
gzip u-boot-nodtb.binAppend 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.
Or perhaps a shim? It would be good if vendors could provide an unlock mechanism eventually, but I understand it is challenging.
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.
OK, I see, that sounds good. My concern is that the open source approach is preserved and made the easiest option. Decisions which accommodate private binaries while making open source harder should generally be rejected.
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.
Yes, I understand it is challenging. Somehow it works better with Linux, despite hacked up kernels, etc. so perhaps Linaro can help here?
Regards, Simon