Hi Dennis, On Wed, 29 Nov 2023 at 22:32, Dennis Gilmore <dgilm...@fedoraproject.org> wrote: > > A big benefit of using the full dtb in u-boot means it can be used to > boot the system without the need to load a replacement file from disk > or elsewhere, which, AFAIK is required for the System Ready standards > and it definitely helps in cases like EFI booting.
The discussion here is all focussed on how to reach a point where u-boot uses unmodified DTB. This would allow the system to be compliant with System Ready standards with DT being directly passed from u-boot via EFI config table to Linux. -Sumit > > Dennis > > On Wed, Nov 29, 2023 at 10:37 AM Neil Armstrong > <neil.armstr...@linaro.org> wrote: > > > > On 29/11/2023 16:34, Caleb Connolly wrote: > > > > > > > > > On 23/11/2023 07:04, Sumit Garg wrote: > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly <caleb.conno...@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 <tr...@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.conno...@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. > > > > > > I've been thinking about and hacking on this for the last week or so, > > > sorry for the delayed reply here. > > > > > > The value is in preventing any of the existing bindings from regressing, > > > and simplifying the bringup process for new platforms (just copy > > > SoC/PMIC DTSI and write a minimal board DTS to enable the needed > > > hardware). > > >> > > >>> 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. > > > > > > The biggest blocker here is USB, on sdm845 and the 4 new platforms I > > > have working, I only support USB high speed, this requires removing the > > > superspeed phy and adding a DTS property. > > > > > > I tried using OF_BOARD_SETUP to make this changes during boot but this > > > approach really isn't scalable (and I couldn't find a way to make it > > > work anyway). > > > > > >> > > >>> > > >>> 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. > > > > > > Ensuring that we don't introduce non-standard bindings (by using Linux > > > DTSI) is one benefit, simplifying new platform bringup is another. > > > > > > The amount of work required to switch to upstream DT is too much to > > > block this series on. We can work on improving the situation there once > > > we have these Qualcomm improvements upstream and new boards added. I do > > > admit that this is quite an awkward middle-ground, and I would not like > > > it to last for too long. > > > > I'm a real supporter of targeting support of unmodified (or very slighly) > > Linux DT, having a reduced version of the Linux DT will be a pain at each > > sync, and you'll need to do this manually. > > > > Simply having to copy the Linux DT without any changes will make sure you > > are in sync with Linux's bindings, and will help making sure you'll boot > > unchanged Linux DTBs you get from previous loaders. > > > > And in bonus, you'll be able to chain it to the next loader like EFI. > > > > So I don't see why any work toward this goal is useless, and if an > > intermediate step is needed, let's do it. > > > > Neil > > > > > > > >> > > >> -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 > > >>>>>>> $ 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 > > >>>>>>> > > >>>>>>> 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) > > > > >