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:
Historically, Qualcomm boards in U-Boot have all had their own board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their own hardcoded sysmap-xyz.c file, and their own U-Boot specific devicetree with little/no compatibility with upstream DT.
This series makes a few final prepatory changes, and then replaces almost all of the board specific code with generic alternatives. The end result is that all Qualcomm boards both current and future (with the exception of the db410c and db820c) can be supported by a single U-Boot binary by just providing the correct DT. New boards can be added without introducing any addition mach/ or board/ code or config options.
Due to the nature of this change, the patch ("mach-snapdragon: generalise board support") has become pretty big, I tried a few different ways to represent this in git history, but the other methods (e.g. adding a stub "generic" target and removing it again) were more confusing and made for much messier git history. The current patch is mostly atomic, but requires regenerating the config.
The QCS404 EVB board had some code to enable the USB VBUS regulator, this is dropped in favour of a adding a new vbus-supply property to the dwc3-generic driver. This will also be used by the dragonboard845c in a future patch. This handles the common case of a board requiring some regulator be enabled for USB host mode.
Thanks for your work. It is a good step towards a generalized u-boot on Qcom platforms. Although I would like to give it an in-depth review, I have a common discussion point about DT, see below.
A more detailed description of the changes is below.
== Memory map ==
The memory map was historically hardcoded into U-Boot, this meant that U-Boot had to be built for a specific variant of a device. This is changed to instead read the memory map from the DT /memory node.
Additionally, most boards mapped addresss 0x0 as valid, as a result if a null pointer access happens then it will cause a bus stall (and board hang). This is fixed so that null pointer accesses will now correctly throw an exception.
== 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.
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.
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