>>>>>>>>> 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, > > That is actually best addressed in Linux by checking the DTS against > yaml DT bindings. We don't have that testing available in u-boot and > only depend on careful reviews.
Sorry, I didn't explain myself very well here. By having .dtsi files be identical to Linux, we ensure that U-Boot drivers will remain compatible with them. Just as an argument not to use custom SoC dts in U-Boot (which is what we do currently). > >>> 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). > > Okay so let's try an alternative intermediate step then. We import the > Linux DT files *as it is* and then keep the u-boot specific custom > changes in <soc>-u-boot.dtsi file which is included by the board DTS > file. This has been the approach that other u-boot platforms follow > and allow us to easily sync them with Linux while reducing custom > u-boot specific bits. Eventually we should target at dropping u-boot > specific custom bits and then directly pick up DTB from Linux and boot > it. Ok, I think this is a reasonable approach. Will do that for the next revision > >>> >>>> >>>>> >>>>> 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. > > We have to choose the middle-ground carefully here. It shouldn't give > the impression that it is an actual Linux DT that you can pass > directly to Linux via EFI. As otherwise users will hit problems due to > the partially modified DTs in u-boot. > >> >> 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. > > Once we have the previous loaders (ABL or LK) providing u-boot fully > fledged DTB then we don't need to maintain Linux DT copy in u-boot > which is always a pain to keep in sync. Yes > >> >> 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. > > See the side effects of an intermediate step mentioned above. Having > <soc>-u-boot.dtsi clearly separates the changes we have to make for > u-boot. Sounds good. Thanks, > > -Sumit > >> >> 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) >>> >> -- // Caleb (they/them)