Hi Simon, On Tue, 5 Dec 2023 at 06:22, Simon Glass <s...@chromium.org> wrote: > > Hi Sumit, > > On Tue, 21 Nov 2023 at 23:21, Sumit Garg <sumit.g...@linaro.org> wrote: > > > > Hi Caleb, > > > > On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.conno...@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 > > $ 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. > > > > > 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