On Wed, 22 Nov 2023 at 21:34, Caleb Connolly caleb.connolly@linaro.org wrote:
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@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@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.
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.
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.
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.
-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 $ 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
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)