| Message ID | 20231121-b4-qcom-common-target-v1-0-9492198e0c15@linaro.org |
|---|---|
| Headers | show |
| Series | Qualcomm generic board support | expand |
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 $ 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. -Sumit > > == defconfig == > > Most of the board defconfigs and config headers were quite similar, to > simplify maintenance going forward, all the fully generic boards (sdm845 > and qcs404-evb so far) are adapted to use the new qcom_defconfig. Going > forward, all new Qualcomm boards should be supported by this defconfig. > A notable exception is for specific usecases (like U-Boot as the primary > bootloader). > > == The older dragonboards == > > The db410c and db820c both have some custom board init code, as a result > they aren't yet binary compatible. mach-snapdragon is adjusted so > that all the necessary config options (e.g. CONFIG_SYS_BOARD) can be set > from their defconfigs, this makes it possible to enable support for new > boards without introducing additional config options. > > The db410c can run U-Boot either chainloaded like the other boards, or > as a first-stage bootloader replacing aboot. However it was hardcoded to > only build for the latter option. This series introduces a new > "chainloaded" defconfig to enable easier testing via fastboot. > > == dynamic environment variables == > > This series also introduces runtime-allocated load addresses via the lmb > allocator. This allows for booting on boards with vastly different > memory layouts without any pre-calculation or macro magic in the config > header. This feature is based on similar code in mach-apple. > > The soc, board, and fdtfile environment variables are also generated > automatically. Many Qualcomm boards follow a similar scheme for DTB > naming such that the name can often be derived from the root compatible > properties. This is intended to cover the most common cases and be a > simple solution for booting generic distro images without having to > explicitly choose the right DTB. The U-Boot DTS can be tweaked if > necessary to produce the correct name, the variable can be overwritten, > or a bootloader like GRUB can load the devicetree instead. > > == Upstream DT == > > All Qualcomm boards have had their devicetree files rewritten to be > based on the upstream SoC/PMIC DTSI files. Previous patch series made > the necessary driver adjustments to fully support the upstream DT > format. All future Qualcomm boards should use upstream DTS by default. > > --- > I have tested this series on the Dragonboard410c, Dragonboard820c, and > Dragonboard845c. I unfortunately don't have access to a QCS404 EVB board > to test. > > This series is based on the qcom-next branch [1] and depends on my PMIC > fixes series [2], an integration branch for testing can be found at [3]. > The non-qualcomm-specific changes (patches 1, 2, and 3) don't have any > dependencies. > > [1]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon > [2]: https://lore.kernel.org/u-boot/20231114-b4-qcom-dt-compat-v3-0-88a92f8f00ba@linaro.org/ > [3]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/tree/b4/qcom-common-target > > To: Neil Armstrong <neil.armstrong@linaro.org> > To: Sumit Garg <sumit.garg@linaro.org> > To: Ramon Fried <rfried.dev@gmail.com> > Cc: Marek Vasut <marex@denx.de> > To: Dzmitry Sankouski <dsankouski@gmail.com> > To: Caleb Connolly <caleb.connolly@linaro.org> > To: Peng Fan <peng.fan@nxp.com> > To: Jaehoon Chung <jh80.chung@samsung.com> > To: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> > To: Lukasz Majewski <lukma@denx.de> > To: Sean Anderson <seanga2@gmail.com> > To: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com> > To: Stephan Gerhold <stephan@gerhold.net> > Cc: <u-boot@lists.denx.de> > > --- > Caleb Connolly (21): > arm: init: export prev_bl_fdt_addr > arm: allow CONFIG_LINUX_KERNEL_IMAGE_HEADER to be set in defconfig > usb: dwc3-generic: support external vbus regulator > mmc: msm_sdhci: use modern clock handling > dt-bindings: drop msm_sdhci binding > clk/qcom: use upstream compatible properties > serial: msm: add debug UART > serial: msm: fix clock handling > configs: add dragonboard410c_chainloaded_defconfig > dts: dragonboard410c: fix compatible and clocks > board: dragonboard410c: import board code from mach-snapdragon > board: dragonboard820c: use LINUX_KERNEL_IMAGE_HEADER > mach-snapdragon: generalise board support > mach-snapdragon: dynamic load addresses > mach-snapdragon: generate fdtfile automatically > doc: board/qualcomm: document generic targets > dts: sdm845: import DT from Linux > dts: msm8916: import DT from Linux > dts: msm8996: import DT from Linux > dts: qcs404-evb: import DT from Linux > MAINTAINERS: Qualcomm: add some missing paths > > MAINTAINERS | 16 +- > arch/arm/Kconfig | 6 +- > arch/arm/dts/Makefile | 9 +- > arch/arm/dts/dragonboard410c-uboot.dtsi | 44 - > arch/arm/dts/dragonboard410c.dts | 198 +- > arch/arm/dts/dragonboard820c-uboot.dtsi | 32 - > arch/arm/dts/dragonboard820c.dts | 129 +- > arch/arm/dts/dragonboard845c-uboot.dtsi | 26 - > arch/arm/dts/dragonboard845c.dts | 23 +- > arch/arm/dts/msm8916-pins.dtsi | 582 ++ > arch/arm/dts/msm8916-pm8916.dtsi | 76 + > arch/arm/dts/msm8916.dtsi | 2194 ++++++++ > arch/arm/dts/msm8996.dtsi | 3959 +++++++++++++ > arch/arm/dts/pm8916.dtsi | 183 + > arch/arm/dts/pm8994.dtsi | 152 + > arch/arm/dts/pm8998.dtsi | 130 + > arch/arm/dts/pms405.dtsi | 149 + > arch/arm/dts/qcs404-evb-uboot.dtsi | 30 - > arch/arm/dts/qcs404-evb.dts | 441 +- > arch/arm/dts/qcs404.dtsi | 1830 ++++++ > arch/arm/dts/sdm845.dtsi | 5850 +++++++++++++++++++- > arch/arm/dts/starqltechn-uboot.dtsi | 27 - > arch/arm/dts/starqltechn.dts | 34 +- > arch/arm/lib/save_prev_bl_data.c | 5 + > arch/arm/mach-snapdragon/Kconfig | 95 +- > arch/arm/mach-snapdragon/Makefile | 8 +- > arch/arm/mach-snapdragon/board.c | 303 + > arch/arm/mach-snapdragon/include/mach/dram.h | 12 - > arch/arm/mach-snapdragon/init_sdm845.c | 73 - > arch/arm/mach-snapdragon/misc.c | 55 - > arch/arm/mach-snapdragon/sysmap-apq8016.c | 31 - > arch/arm/mach-snapdragon/sysmap-apq8096.c | 31 - > arch/arm/mach-snapdragon/sysmap-qcs404.c | 43 - > arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 - > board/qualcomm/dragonboard410c/Kconfig | 15 - > board/qualcomm/dragonboard410c/MAINTAINERS | 1 + > board/qualcomm/dragonboard410c/Makefile | 3 +- > board/qualcomm/dragonboard410c/dragonboard410c.c | 31 +- > .../qualcomm/dragonboard410c/misc.c | 51 +- > .../mach => board/qualcomm/dragonboard410c}/misc.h | 1 + > board/qualcomm/dragonboard820c/Kconfig | 15 - > board/qualcomm/dragonboard820c/Makefile | 1 - > board/qualcomm/dragonboard820c/dragonboard820c.c | 39 +- > board/qualcomm/dragonboard820c/head.S | 33 - > board/qualcomm/dragonboard820c/u-boot.lds | 111 - > board/qualcomm/dragonboard845c/Kconfig | 12 - > board/qualcomm/qcs404-evb/Kconfig | 15 - > board/qualcomm/qcs404-evb/qcs404-evb.c | 21 +- > configs/dragonboard410c_chainloaded_defconfig | 72 + > configs/dragonboard410c_defconfig | 6 +- > configs/dragonboard820c_defconfig | 6 +- > configs/dragonboard845c_defconfig | 29 - > configs/qcom_defconfig | 71 + > configs/qcs404evb_defconfig | 55 - > configs/starqltechn_defconfig | 41 - > doc/board/qualcomm/board.rst | 119 + > doc/board/qualcomm/debugging.rst | 61 + > doc/board/qualcomm/index.rst | 4 +- > doc/board/qualcomm/qcs404.rst | 79 - > doc/board/qualcomm/sdm845.rst | 162 - > doc/device-tree-bindings/mmc/msm_sdhci.txt | 25 - > doc/device-tree-bindings/usb/ehci-msm.txt | 10 - > drivers/clk/qcom/clock-apq8016.c | 9 +- > drivers/clk/qcom/clock-apq8096.c | 7 +- > drivers/mmc/msm_sdhci.c | 69 +- > drivers/phy/qcom/msm8916-usbh-phy.c | 2 +- > drivers/pinctrl/qcom/pinctrl-apq8016.c | 2 +- > drivers/serial/Kconfig | 8 + > drivers/serial/serial_msm.c | 61 +- > drivers/usb/dwc3/dwc3-generic.c | 12 + > drivers/usb/host/ehci-msm.c | 2 +- > include/configs/dragonboard845c.h | 20 - > include/configs/qcom.h | 21 + > include/configs/qcs404-evb.h | 20 - > include/dt-bindings/arm/coresight-cti-dt.h | 37 + > include/dt-bindings/clock/qcom,camcc-sdm845.h | 116 + > include/dt-bindings/clock/qcom,dispcc-sdm845.h | 56 + > include/dt-bindings/clock/qcom,gcc-msm8916.h | 179 + > include/dt-bindings/clock/qcom,gcc-msm8996.h | 360 ++ > include/dt-bindings/clock/qcom,gcc-qcs404.h | 4 + > include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 + > include/dt-bindings/clock/qcom,lpass-sdm845.h | 15 + > include/dt-bindings/clock/qcom,mmcc-msm8996.h | 295 + > include/dt-bindings/clock/qcom,rpmcc.h | 174 + > include/dt-bindings/clock/qcom,rpmh.h | 37 + > include/dt-bindings/clock/qcom,turingcc-qcs404.h | 15 + > include/dt-bindings/clock/qcom,videocc-sdm845.h | 35 + > include/dt-bindings/dma/qcom-gpi.h | 11 + > include/dt-bindings/firmware/qcom,scm.h | 18 + > include/dt-bindings/iio/qcom,spmi-vadc.h | 300 + > include/dt-bindings/interconnect/qcom,msm8916.h | 100 + > .../dt-bindings/interconnect/qcom,msm8996-cbf.h | 12 + > include/dt-bindings/interconnect/qcom,msm8996.h | 163 + > include/dt-bindings/interconnect/qcom,osm-l3.h | 15 + > include/dt-bindings/interconnect/qcom,sdm845.h | 150 + > include/dt-bindings/phy/phy-qcom-qusb2.h | 37 + > include/dt-bindings/pinctrl/qcom,pmic-gpio.h | 164 + > include/dt-bindings/power/qcom-rpmpd.h | 412 ++ > include/dt-bindings/reset/qcom,gcc-msm8916.h | 100 + > include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 + > include/dt-bindings/reset/qcom,sdm845-pdc.h | 22 + > include/dt-bindings/soc/qcom,apr.h | 28 + > include/dt-bindings/soc/qcom,rpmh-rsc.h | 14 + > include/init.h | 11 + > 104 files changed, 18987 insertions(+), 2063 deletions(-) > --- > base-commit: 516584b4d50880cb5e2361e55f8c5b4fc6c35901 > > // Caleb (they/them) >
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. > > 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. > > == defconfig == > > Most of the board defconfigs and config headers were quite similar, to > simplify maintenance going forward, all the fully generic boards (sdm845 > and qcs404-evb so far) are adapted to use the new qcom_defconfig. Going > forward, all new Qualcomm boards should be supported by this defconfig. > A notable exception is for specific usecases (like U-Boot as the primary > bootloader). > > == The older dragonboards == > > The db410c and db820c both have some custom board init code, as a result > they aren't yet binary compatible. mach-snapdragon is adjusted so > that all the necessary config options (e.g. CONFIG_SYS_BOARD) can be set > from their defconfigs, this makes it possible to enable support for new > boards without introducing additional config options. > > The db410c can run U-Boot either chainloaded like the other boards, or > as a first-stage bootloader replacing aboot. However it was hardcoded to > only build for the latter option. This series introduces a new > "chainloaded" defconfig to enable easier testing via fastboot. > > == dynamic environment variables == > > This series also introduces runtime-allocated load addresses via the lmb > allocator. This allows for booting on boards with vastly different > memory layouts without any pre-calculation or macro magic in the config > header. This feature is based on similar code in mach-apple. > > The soc, board, and fdtfile environment variables are also generated > automatically. Many Qualcomm boards follow a similar scheme for DTB > naming such that the name can often be derived from the root compatible > properties. This is intended to cover the most common cases and be a > simple solution for booting generic distro images without having to > explicitly choose the right DTB. The U-Boot DTS can be tweaked if > necessary to produce the correct name, the variable can be overwritten, > or a bootloader like GRUB can load the devicetree instead. > > == Upstream DT == > > All Qualcomm boards have had their devicetree files rewritten to be > based on the upstream SoC/PMIC DTSI files. Previous patch series made > the necessary driver adjustments to fully support the upstream DT > format. All future Qualcomm boards should use upstream DTS by default. > > --- > I have tested this series on the Dragonboard410c, Dragonboard820c, and > Dragonboard845c. I unfortunately don't have access to a QCS404 EVB board > to test. I would be happy to test it on QCS404 but your PMIC fixes series is already broken on QCS404 [1]. Let's get that fixed and applied first. [1] https://lore.kernel.org/u-boot/CAFA6WYP=y+u6si8zo-atTcrFA4SrPXeYBYL3N8RaQW=Dn7AN5Q@mail.gmail.com/ -Sumit > > This series is based on the qcom-next branch [1] and depends on my PMIC > fixes series [2], an integration branch for testing can be found at [3]. > The non-qualcomm-specific changes (patches 1, 2, and 3) don't have any > dependencies. > > [1]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon > [2]: https://lore.kernel.org/u-boot/20231114-b4-qcom-dt-compat-v3-0-88a92f8f00ba@linaro.org/ > [3]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/tree/b4/qcom-common-target > > To: Neil Armstrong <neil.armstrong@linaro.org> > To: Sumit Garg <sumit.garg@linaro.org> > To: Ramon Fried <rfried.dev@gmail.com> > Cc: Marek Vasut <marex@denx.de> > To: Dzmitry Sankouski <dsankouski@gmail.com> > To: Caleb Connolly <caleb.connolly@linaro.org> > To: Peng Fan <peng.fan@nxp.com> > To: Jaehoon Chung <jh80.chung@samsung.com> > To: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> > To: Lukasz Majewski <lukma@denx.de> > To: Sean Anderson <seanga2@gmail.com> > To: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com> > To: Stephan Gerhold <stephan@gerhold.net> > Cc: <u-boot@lists.denx.de> > > --- > Caleb Connolly (21): > arm: init: export prev_bl_fdt_addr > arm: allow CONFIG_LINUX_KERNEL_IMAGE_HEADER to be set in defconfig > usb: dwc3-generic: support external vbus regulator > mmc: msm_sdhci: use modern clock handling > dt-bindings: drop msm_sdhci binding > clk/qcom: use upstream compatible properties > serial: msm: add debug UART > serial: msm: fix clock handling > configs: add dragonboard410c_chainloaded_defconfig > dts: dragonboard410c: fix compatible and clocks > board: dragonboard410c: import board code from mach-snapdragon > board: dragonboard820c: use LINUX_KERNEL_IMAGE_HEADER > mach-snapdragon: generalise board support > mach-snapdragon: dynamic load addresses > mach-snapdragon: generate fdtfile automatically > doc: board/qualcomm: document generic targets > dts: sdm845: import DT from Linux > dts: msm8916: import DT from Linux > dts: msm8996: import DT from Linux > dts: qcs404-evb: import DT from Linux > MAINTAINERS: Qualcomm: add some missing paths > > MAINTAINERS | 16 +- > arch/arm/Kconfig | 6 +- > arch/arm/dts/Makefile | 9 +- > arch/arm/dts/dragonboard410c-uboot.dtsi | 44 - > arch/arm/dts/dragonboard410c.dts | 198 +- > arch/arm/dts/dragonboard820c-uboot.dtsi | 32 - > arch/arm/dts/dragonboard820c.dts | 129 +- > arch/arm/dts/dragonboard845c-uboot.dtsi | 26 - > arch/arm/dts/dragonboard845c.dts | 23 +- > arch/arm/dts/msm8916-pins.dtsi | 582 ++ > arch/arm/dts/msm8916-pm8916.dtsi | 76 + > arch/arm/dts/msm8916.dtsi | 2194 ++++++++ > arch/arm/dts/msm8996.dtsi | 3959 +++++++++++++ > arch/arm/dts/pm8916.dtsi | 183 + > arch/arm/dts/pm8994.dtsi | 152 + > arch/arm/dts/pm8998.dtsi | 130 + > arch/arm/dts/pms405.dtsi | 149 + > arch/arm/dts/qcs404-evb-uboot.dtsi | 30 - > arch/arm/dts/qcs404-evb.dts | 441 +- > arch/arm/dts/qcs404.dtsi | 1830 ++++++ > arch/arm/dts/sdm845.dtsi | 5850 +++++++++++++++++++- > arch/arm/dts/starqltechn-uboot.dtsi | 27 - > arch/arm/dts/starqltechn.dts | 34 +- > arch/arm/lib/save_prev_bl_data.c | 5 + > arch/arm/mach-snapdragon/Kconfig | 95 +- > arch/arm/mach-snapdragon/Makefile | 8 +- > arch/arm/mach-snapdragon/board.c | 303 + > arch/arm/mach-snapdragon/include/mach/dram.h | 12 - > arch/arm/mach-snapdragon/init_sdm845.c | 73 - > arch/arm/mach-snapdragon/misc.c | 55 - > arch/arm/mach-snapdragon/sysmap-apq8016.c | 31 - > arch/arm/mach-snapdragon/sysmap-apq8096.c | 31 - > arch/arm/mach-snapdragon/sysmap-qcs404.c | 43 - > arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 - > board/qualcomm/dragonboard410c/Kconfig | 15 - > board/qualcomm/dragonboard410c/MAINTAINERS | 1 + > board/qualcomm/dragonboard410c/Makefile | 3 +- > board/qualcomm/dragonboard410c/dragonboard410c.c | 31 +- > .../qualcomm/dragonboard410c/misc.c | 51 +- > .../mach => board/qualcomm/dragonboard410c}/misc.h | 1 + > board/qualcomm/dragonboard820c/Kconfig | 15 - > board/qualcomm/dragonboard820c/Makefile | 1 - > board/qualcomm/dragonboard820c/dragonboard820c.c | 39 +- > board/qualcomm/dragonboard820c/head.S | 33 - > board/qualcomm/dragonboard820c/u-boot.lds | 111 - > board/qualcomm/dragonboard845c/Kconfig | 12 - > board/qualcomm/qcs404-evb/Kconfig | 15 - > board/qualcomm/qcs404-evb/qcs404-evb.c | 21 +- > configs/dragonboard410c_chainloaded_defconfig | 72 + > configs/dragonboard410c_defconfig | 6 +- > configs/dragonboard820c_defconfig | 6 +- > configs/dragonboard845c_defconfig | 29 - > configs/qcom_defconfig | 71 + > configs/qcs404evb_defconfig | 55 - > configs/starqltechn_defconfig | 41 - > doc/board/qualcomm/board.rst | 119 + > doc/board/qualcomm/debugging.rst | 61 + > doc/board/qualcomm/index.rst | 4 +- > doc/board/qualcomm/qcs404.rst | 79 - > doc/board/qualcomm/sdm845.rst | 162 - > doc/device-tree-bindings/mmc/msm_sdhci.txt | 25 - > doc/device-tree-bindings/usb/ehci-msm.txt | 10 - > drivers/clk/qcom/clock-apq8016.c | 9 +- > drivers/clk/qcom/clock-apq8096.c | 7 +- > drivers/mmc/msm_sdhci.c | 69 +- > drivers/phy/qcom/msm8916-usbh-phy.c | 2 +- > drivers/pinctrl/qcom/pinctrl-apq8016.c | 2 +- > drivers/serial/Kconfig | 8 + > drivers/serial/serial_msm.c | 61 +- > drivers/usb/dwc3/dwc3-generic.c | 12 + > drivers/usb/host/ehci-msm.c | 2 +- > include/configs/dragonboard845c.h | 20 - > include/configs/qcom.h | 21 + > include/configs/qcs404-evb.h | 20 - > include/dt-bindings/arm/coresight-cti-dt.h | 37 + > include/dt-bindings/clock/qcom,camcc-sdm845.h | 116 + > include/dt-bindings/clock/qcom,dispcc-sdm845.h | 56 + > include/dt-bindings/clock/qcom,gcc-msm8916.h | 179 + > include/dt-bindings/clock/qcom,gcc-msm8996.h | 360 ++ > include/dt-bindings/clock/qcom,gcc-qcs404.h | 4 + > include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 + > include/dt-bindings/clock/qcom,lpass-sdm845.h | 15 + > include/dt-bindings/clock/qcom,mmcc-msm8996.h | 295 + > include/dt-bindings/clock/qcom,rpmcc.h | 174 + > include/dt-bindings/clock/qcom,rpmh.h | 37 + > include/dt-bindings/clock/qcom,turingcc-qcs404.h | 15 + > include/dt-bindings/clock/qcom,videocc-sdm845.h | 35 + > include/dt-bindings/dma/qcom-gpi.h | 11 + > include/dt-bindings/firmware/qcom,scm.h | 18 + > include/dt-bindings/iio/qcom,spmi-vadc.h | 300 + > include/dt-bindings/interconnect/qcom,msm8916.h | 100 + > .../dt-bindings/interconnect/qcom,msm8996-cbf.h | 12 + > include/dt-bindings/interconnect/qcom,msm8996.h | 163 + > include/dt-bindings/interconnect/qcom,osm-l3.h | 15 + > include/dt-bindings/interconnect/qcom,sdm845.h | 150 + > include/dt-bindings/phy/phy-qcom-qusb2.h | 37 + > include/dt-bindings/pinctrl/qcom,pmic-gpio.h | 164 + > include/dt-bindings/power/qcom-rpmpd.h | 412 ++ > include/dt-bindings/reset/qcom,gcc-msm8916.h | 100 + > include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 + > include/dt-bindings/reset/qcom,sdm845-pdc.h | 22 + > include/dt-bindings/soc/qcom,apr.h | 28 + > include/dt-bindings/soc/qcom,rpmh-rsc.h | 14 + > include/init.h | 11 + > 104 files changed, 18987 insertions(+), 2063 deletions(-) > --- > base-commit: 516584b4d50880cb5e2361e55f8c5b4fc6c35901 > > // Caleb (they/them) >
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? > > 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) 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.
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? > > > > 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). > 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. -Sumit > -- > Tom
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? > > > > > > 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.
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. 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. 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. >>>> >>>> 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. >
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 > >>>> $ 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)
On 23/11/2023 07:04, Sumit Garg wrote: > 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. 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. > > -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)
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.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. > > 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) >
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. Dennis On Wed, Nov 29, 2023 at 10:37 AM Neil Armstrong <neil.armstrong@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.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. > > > > 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) > > >
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@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.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. > > > > 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. > > 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. > > > >> > >>> > >>> 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. > > 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. -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) > > >
Hi Dennis, On Wed, 29 Nov 2023 at 22:32, Dennis Gilmore <dgilmore@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.armstrong@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.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. > > > > > > 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) > > > > >
>>>>>>>>> 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) >>> >>
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@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.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. > > > > > > 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. I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
+ Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@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.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. > > > > > > > > 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. > > I would absolutely love for someone to make another attempt at updating > our kbuild infrastucture so that we can run the validation targets. > Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained). But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files. @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. [1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema -Sumit > -- > Tom
Hi Summit, Here are additional elements that you may want to consider. This topic should be thought of with « who provides what » question in mind. For quite a long time, one single entity was providing secure firmware, firmware, boot loader (I think of Grub when I use this overloaded term), and OS. This explains why the Linux kernel community has been maintaining DT (not justifying it is now still a good model). For Software Defined Vehicle and many other scenarios this supply chain is not working. In the context of this separation, OS/Hypervisor supplying any DTB is a non-sense. (Translated in real life: as a French driver, my DTB description of a car is that the steering wheel is on the left hand side. If I get on a UK car, I will complain that my hardware description does not match reality. Conclusion: better use DTB given from the platform!). If I am not mistaken Fedora IOT 39 does not come with any DTBs: that was a theme hinted by Peter Robinson a while ago (Peter you may want to comment on this). My understanding is that SystemReady was proposed and developed to address such a different supply chain where: - the OS may be supplied by a party not controlling the underlying layers - have standard contract between OS and previous entities - The entity controlling the hardware is not an OS but a type-1 hypervisor In all this context, the DT should be consumed by OSes (Linux, Zephyr, Eclipse ThreadX (donated by Microsoft), commercial ones…) and hypervisors. The "DT » passed to a Linux (be it equivalent to Dom0) may not be the definitive vision of the whole platform. You may want to talk with the System Device Tree folks. So there is no such a thing as « THE » device tree of the platform. There can be a DT for BL33 firmware, a DT for OS/Hypervisor, a DT for TrustZone (highly decorated with clocks and power nodes that are often irrelevant to BL33 and OS/Hypervisor). The BL33 and OS/Hypervisor DTs location is not defined by EBBR but my view is that the OS/Hypervisor DT can be located in the HW_CONFIG section of a FIP (this section is made for holding the OS DT). The FIP can come from the SoC vendor, later updated by the Board vendor: fiptool --hw-config <OS-DTB> With a separate signing key. So, you should take into account which markets are targeted by the SoC for which you posted your message. If it is traditional embedded, one-entity provides all. You can surely choose any scheme you want. If it is automotive and other markets where there will be separation in the firmware/OS/Hypervisor supply chain, then you should clearly attach the DT to Secure Firmware. Cheers FF PS1: I see an analogy with Google project Trebble which set clear responsibilities in who can provide/modify what. Before it, it was the jungle and pushing a security fix required months of delays. Now a Google security fix can make its way to smartphones in matter of days. Constraining a little bit the Linux driver developers to what should they focus on (nice drivers and not hardware description) will just make things better. Failure to do so will just push for ACPI and its horrible complex, fragile virtual machine to push out DT from those markets... PS2: By « nice" drivers I mean, for instance, drivers that do not assume they are alone in the world and can do whatever they want with clocks that feed the device: they should use proper clock control such as SCMI (trouble for device assignment to a VM for instance). Le 4 déc. 2023 à 06:32, Sumit Garg <sumit.garg@linaro.org> a écrit : + Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@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.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. 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. I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets. Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained). But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files. @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. [1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema -Sumit -- Tom
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@linaro.org> wrote: > > > > > 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. > > > > I would absolutely love for someone to make another attempt at updating > > our kbuild infrastucture so that we can run the validation targets. > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > not OS to supply the devicetree, it becomes evident that > firmware/bootloaders import DTS from Linux kernel (where it is > maintained). > > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory? Daniel.
On Mon, 4 Dec 2023 at 16:30, Daniel Thompson <daniel.thompson@linaro.org> wrote: > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > + Linux kernel DT bindings maintainers, EBBR ML > > > > On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@linaro.org> wrote: > > > > > > 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. > > > > > > I would absolutely love for someone to make another attempt at updating > > > our kbuild infrastucture so that we can run the validation targets. > > > > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > > not OS to supply the devicetree, it becomes evident that > > firmware/bootloaders import DTS from Linux kernel (where it is > > maintained). > > > > But currently u-boot doesn't have a proper way to validate those DTS > > against DT bindings (maintained in Linux kernel). Although there are > > Devicetree schema tools available here [2], there isn't a versioned > > release package of DT bindings which one should use to validate DTS > > files. > > The kernel is regularly released in multiple forms (including git > tags and tarball). Why isn't the kernel itself sufficient to be a > versioned release of the DT bindings directory? > The Linux kernel may come in various forms (upstream vs stable vs vendor). It's difficult to decide from where the DT bindings should come from. Should they come from upstream or should they come from the kernel which is actually booted onto a particular device? IOW, as of now which kernel version should u-boot pick up for DT validation checks? If we can have a separate release cadence for DT bindings then the platform (firmware/bootloader) can attest the DTB against that. Later one should be able to boot any kernel with the DTB provided by platform. -Sumit > > Daniel.
On 04/12/2023 14:24, Sumit Garg wrote: > On Mon, 4 Dec 2023 at 16:30, Daniel Thompson <daniel.thompson@linaro.org> wrote: >> >> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >>> + Linux kernel DT bindings maintainers, EBBR ML >>> >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: >>>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: >>>>> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@linaro.org> wrote: >>>>>>> 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. >>>> >>>> I would absolutely love for someone to make another attempt at updating >>>> our kbuild infrastucture so that we can run the validation targets. >>>> >>> >>> Given that EBBR requires [1] the platform (firmware/bootloader) and >>> not OS to supply the devicetree, it becomes evident that >>> firmware/bootloaders import DTS from Linux kernel (where it is >>> maintained). >>> >>> But currently u-boot doesn't have a proper way to validate those DTS >>> against DT bindings (maintained in Linux kernel). Although there are >>> Devicetree schema tools available here [2], there isn't a versioned >>> release package of DT bindings which one should use to validate DTS >>> files. >> >> The kernel is regularly released in multiple forms (including git >> tags and tarball). Why isn't the kernel itself sufficient to be a >> versioned release of the DT bindings directory? >> > > The Linux kernel may come in various forms (upstream vs stable vs > vendor). It's difficult to decide from where the DT bindings should > come from. Should they come from upstream or should they come from the > kernel which is actually booted onto a particular device? > > IOW, as of now which kernel version should u-boot pick up for DT > validation checks? The same version as in case of release from separate DT bindings repo. > > If we can have a separate release cadence for DT bindings then the > platform (firmware/bootloader) can attest the DTB against that. Later > one should be able to boot any kernel with the DTB provided by > platform. Separate releases of DT bindings change nothing here - you are going to ask the same question: "which release shall I take"? So the answer could be the same for both: take latest mainline kernel release. You really don't need separate repo just to know which release to take. Best regards, Krzysztof
> Le 4 déc. 2023 à 12:00, Daniel Thompson <daniel.thompson@linaro.org> a écrit : > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >> + Linux kernel DT bindings maintainers, EBBR ML >> >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: >>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: >>>> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@linaro.org> wrote: >>>>>> 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. >>> >>> I would absolutely love for someone to make another attempt at updating >>> our kbuild infrastucture so that we can run the validation targets. >>> >> >> Given that EBBR requires [1] the platform (firmware/bootloader) and >> not OS to supply the devicetree, it becomes evident that >> firmware/bootloaders import DTS from Linux kernel (where it is >> maintained). >> >> But currently u-boot doesn't have a proper way to validate those DTS >> against DT bindings (maintained in Linux kernel). Although there are >> Devicetree schema tools available here [2], there isn't a versioned >> release package of DT bindings which one should use to validate DTS >> files. > > The kernel is regularly released in multiple forms (including git > tags and tarball). Why isn't the kernel itself sufficient to be a > versioned release of the DT bindings directory? > The Linux kernel may not see all devices. For instance it could see a PCI port while the firmware sees a SERDES that is configured to match the board implementation and touting. The firmware shall be responsible to, statically or dynamically make those things available to the kernel. An OS distribution (not necessarily Linux) should not embedded all possible combinations and know all derived boards. > > Daniel. > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On 04/12/2023 15:38, ff wrote: > > >> Le 4 déc. 2023 à 12:00, Daniel Thompson <daniel.thompson@linaro.org> a écrit : >> >> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >>> + Linux kernel DT bindings maintainers, EBBR ML >>> >>>> On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: >>>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: >>>>> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@linaro.org> wrote: >>>>>>> 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. >>>> >>>> I would absolutely love for someone to make another attempt at updating >>>> our kbuild infrastucture so that we can run the validation targets. >>>> >>> >>> Given that EBBR requires [1] the platform (firmware/bootloader) and >>> not OS to supply the devicetree, it becomes evident that >>> firmware/bootloaders import DTS from Linux kernel (where it is >>> maintained). >>> >>> But currently u-boot doesn't have a proper way to validate those DTS >>> against DT bindings (maintained in Linux kernel). Although there are >>> Devicetree schema tools available here [2], there isn't a versioned >>> release package of DT bindings which one should use to validate DTS >>> files. >> >> The kernel is regularly released in multiple forms (including git >> tags and tarball). Why isn't the kernel itself sufficient to be a >> versioned release of the DT bindings directory? >> > The Linux kernel may not see all devices. For instance it could see a PCI port while the firmware sees a SERDES that is configured to match the board implementation and touting. The firmware shall be responsible to, statically or dynamically make those things available to the kernel. > An OS distribution (not necessarily Linux) should not embedded all possible combinations and know all derived boards. Which is nothing related to the discussion here: bindings. The bindings *MUST* cover PCI port and serdes. P.S. Please wrap your replies to match mailing list style / netiquette. Best regards, Krzysztof
> Le 4 déc. 2023 à 14:25, Sumit Garg <sumit.garg@linaro.org> a écrit : > > On Mon, 4 Dec 2023 at 16:30, Daniel Thompson <daniel.thompson@linaro.org> wrote: >> >>> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: >>> + Linux kernel DT bindings maintainers, EBBR ML >>> >>> On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: >>>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: >>>>> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@linaro.org> wrote: >>>>>>> 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. >>>> >>>> I would absolutely love for someone to make another attempt at updating >>>> our kbuild infrastucture so that we can run the validation targets. >>>> >>> >>> Given that EBBR requires [1] the platform (firmware/bootloader) and >>> not OS to supply the devicetree, it becomes evident that >>> firmware/bootloaders import DTS from Linux kernel (where it is >>> maintained). >>> >>> But currently u-boot doesn't have a proper way to validate those DTS >>> against DT bindings (maintained in Linux kernel). Although there are >>> Devicetree schema tools available here [2], there isn't a versioned >>> release package of DT bindings which one should use to validate DTS >>> files. >> >> The kernel is regularly released in multiple forms (including git >> tags and tarball). Why isn't the kernel itself sufficient to be a >> versioned release of the DT bindings directory? >> > > The Linux kernel may come in various forms (upstream vs stable vs > vendor). It's difficult to decide from where the DT bindings should > come from. Should they come from upstream or should they come from the > kernel which is actually booted onto a particular device? > Looks bad from organizing forward portability standpoint . > IOW, as of now which kernel version should u-boot pick up for DT > validation checks? > > If we can have a separate release cadence for DT bindings then the > platform (firmware/bootloader) can attest the DTB against that. Later > one should be able to boot any kernel with the DTB provided by > platform. > That seems a very good step! > -Sumit > >> >> Daniel. > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: > > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@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.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. > > > > > > > > > > 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. > > > > I would absolutely love for someone to make another attempt at updating > > our kbuild infrastucture so that we can run the validation targets. > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > not OS to supply the devicetree, it becomes evident that > firmware/bootloaders import DTS from Linux kernel (where it is > maintained). > > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. > > @DT bindings maintainers, > > Given the ease of maintenance of DT bindings within Linux kernel > source tree, I don't have a specific objection there. But can we ease > DTS testing for firmware/bootloader projects by providing a versioned > release package for DT bindings? Or if someone else has a better idea > here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Note that I would like to revamp this repo to use some modern CI job, use git_filter_repo python module rather than git-filter-branch, and move to devicetree.org GH, but if projects aren't relying on this repo, I'm not motivated to do that work. Rob
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 > $ 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? > > 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. 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? BTW I am very pleased to see this series and I hope that Qualcomm (via Linaro) can continue to improve its U-Boot support. [..] Regards, Simon
On Mon, 4 Dec 2023 at 22:31, Rob Herring <robh+dt@kernel.org> wrote: > > On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > + Linux kernel DT bindings maintainers, EBBR ML > > > > On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstrong@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.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. > > > > > > > > > > > > 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. > > > > > > I would absolutely love for someone to make another attempt at updating > > > our kbuild infrastucture so that we can run the validation targets. > > > > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > > not OS to supply the devicetree, it becomes evident that > > firmware/bootloaders import DTS from Linux kernel (where it is > > maintained). > > > > But currently u-boot doesn't have a proper way to validate those DTS > > against DT bindings (maintained in Linux kernel). Although there are > > Devicetree schema tools available here [2], there isn't a versioned > > release package of DT bindings which one should use to validate DTS > > files. > > > > @DT bindings maintainers, > > > > Given the ease of maintenance of DT bindings within Linux kernel > > source tree, I don't have a specific objection there. But can we ease > > DTS testing for firmware/bootloader projects by providing a versioned > > release package for DT bindings? Or if someone else has a better idea > > here please feel free to chime in. > > This doesn't work for you?: > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. AFAIK, DT bindings should be forwards and backwards compatible. So if you pick up DTS or DTB from any project tree (upstream kernel or stable kernel or u-boot) then DT schema validation would ensure that corresponding DTS or DTB doesn't regress the DT bindings. Ideally, it should be more user/CI friendly if DT bindings can be easily installed alongside devicetree schema tools [1]. [1] https://github.com/devicetree-org/dt-schema > > Note that I would like to revamp this repo to use some modern CI job, > use git_filter_repo python module rather than git-filter-branch, and > move to devicetree.org GH, but if projects aren't relying on this > repo, I'm not motivated to do that work. As Tom has shown interest in this, I think we should be able to add the DT validation checks during normal u-boot builds hidden behind a Makefile option (dtbs_check). -Sumit > > Rob
On 05/12/2023 08:13, Sumit Garg wrote: >>> @DT bindings maintainers, >>> >>> Given the ease of maintenance of DT bindings within Linux kernel >>> source tree, I don't have a specific objection there. But can we ease >>> DTS testing for firmware/bootloader projects by providing a versioned >>> release package for DT bindings? Or if someone else has a better idea >>> here please feel free to chime in. >> >> This doesn't work for you?: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > Thanks, this is certainly a good step which I wasn't aware of. Further > simplification can be done to decouple devicetree source files from DT > bindings. Why? > AFAIK, DT bindings should be forwards and backwards > compatible. The same with DTS. > So if you pick up DTS or DTB from any project tree > (upstream kernel or stable kernel or u-boot) then DT schema validation > would ensure that corresponding DTS or DTB doesn't regress the DT > bindings. And why is this argument to decouple DTS from bindings? > > Ideally, it should be more user/CI friendly if DT bindings can be > easily installed alongside devicetree schema tools [1]. > > [1] https://github.com/devicetree-org/dt-schema Does it mean you will work on this? Best regards, Krzysztof
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 > > $ 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
+ U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 05/12/2023 08:13, Sumit Garg wrote: > >>> @DT bindings maintainers, > >>> > >>> Given the ease of maintenance of DT bindings within Linux kernel > >>> source tree, I don't have a specific objection there. But can we ease > >>> DTS testing for firmware/bootloader projects by providing a versioned > >>> release package for DT bindings? Or if someone else has a better idea > >>> here please feel free to chime in. > >> > >> This doesn't work for you?: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > > > Thanks, this is certainly a good step which I wasn't aware of. Further > > simplification can be done to decouple devicetree source files from DT > > bindings. > > Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers. [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml > > > AFAIK, DT bindings should be forwards and backwards > > compatible. > > The same with DTS. > > > So if you pick up DTS or DTB from any project tree > > (upstream kernel or stable kernel or u-boot) then DT schema validation > > would ensure that corresponding DTS or DTB doesn't regress the DT > > bindings. > > And why is this argument to decouple DTS from bindings? > See above. > > > > Ideally, it should be more user/CI friendly if DT bindings can be > > easily installed alongside devicetree schema tools [1]. > > > > [1] https://github.com/devicetree-org/dt-schema > > Does it mean you will work on this? I am happy to collaboratively work with DT bindings maintainers and the u-boot community once we can reach a consensus on the above. Basically the main motive here is to validate DTS files present in the u-boot tree and be able to reliably pass them to whichever Linux kernel version you are trying to boot. IOW, make Linux distros to reliably boot with devicetree supplied by u-boot. -Sumit > > Best regards, > Krzysztof >
On 05/12/2023 10:45, Sumit Garg wrote: > + U-boot custodians list > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 05/12/2023 08:13, Sumit Garg wrote: >>>>> @DT bindings maintainers, >>>>> >>>>> Given the ease of maintenance of DT bindings within Linux kernel >>>>> source tree, I don't have a specific objection there. But can we ease >>>>> DTS testing for firmware/bootloader projects by providing a versioned >>>>> release package for DT bindings? Or if someone else has a better idea >>>>> here please feel free to chime in. >>>> >>>> This doesn't work for you?: >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ >>> >>> Thanks, this is certainly a good step which I wasn't aware of. Further >>> simplification can be done to decouple devicetree source files from DT >>> bindings. >> >> Why? > > I suppose you are already aware that Linux DTS files are a subset of > what could be supported by devicetree schemas. There can be > firmware/bootloader specific properties (one example being [1]) which > Linux kernel can simply ignore. Will you be willing to add all of > those DT properties to Linux DTS files and maintain them? We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware. > > However, DT bindings are something which should be common, the > hardware description of a device should be universal. IMO, splitting Both DT bindings and DTS should be common. I don't see the difference. > DT bindings alone would ease the compliance process for u-boot drivers > in quite similar manner to Linux drivers. > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml > >> >>> AFAIK, DT bindings should be forwards and backwards >>> compatible. >> >> The same with DTS. >> >>> So if you pick up DTS or DTB from any project tree >>> (upstream kernel or stable kernel or u-boot) then DT schema validation >>> would ensure that corresponding DTS or DTB doesn't regress the DT >>> bindings. >> >> And why is this argument to decouple DTS from bindings? >> > > See above. It's not really explained there. You can pick up DTS from any project and validate it against the repo Rob mentioned or against kernel. Whether DTS is in that repo or not, does not matter for your validation. > >>> >>> Ideally, it should be more user/CI friendly if DT bindings can be >>> easily installed alongside devicetree schema tools [1]. >>> >>> [1] https://github.com/devicetree-org/dt-schema >> >> Does it mean you will work on this? > > I am happy to collaboratively work with DT bindings maintainers and > the u-boot community once we can reach a consensus on the above. > Basically the main motive here is to validate DTS files present in the > u-boot tree and be able to reliably pass them to whichever Linux > kernel version you are trying to boot. IOW, make Linux distros to > reliably boot with devicetree supplied by u-boot. So the answer is "no" on the proposal you mentioned before. Sure, maybe someone will pick it up. Best regards, Krzysztof
> Le 5 déc. 2023 à 10:46, Sumit Garg <sumit.garg@linaro.org> a écrit : > > + U-boot custodians list > >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski >> <krzysztof.kozlowski@linaro.org> wrote: >> >> On 05/12/2023 08:13, Sumit Garg wrote: >>>>> @DT bindings maintainers, >>>>> >>>>> Given the ease of maintenance of DT bindings within Linux kernel >>>>> source tree, I don't have a specific objection there. But can we ease >>>>> DTS testing for firmware/bootloader projects by providing a versioned >>>>> release package for DT bindings? Or if someone else has a better idea >>>>> here please feel free to chime in. >>>> >>>> This doesn't work for you?: >>>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ >>> >>> Thanks, this is certainly a good step which I wasn't aware of. Further >>> simplification can be done to decouple devicetree source files from DT >>> bindings. >> >> Why? > > I suppose you are already aware that Linux DTS files are a subset of > what could be supported by devicetree schemas. There can be > firmware/bootloader specific properties (one example being [1]) which > Linux kernel can simply ignore. Will you be willing to add all of > those DT properties to Linux DTS files and maintain them? > A pre-existing effort to solve the same problem as [1] is System Device Tree, discussed in the context of Linaro supported OpenAMP project. It is not just about cherry picking devices that have bindings in Linux but also information about clock and power domains or devices that are not seen by Linux. It is obvious that the resulting bindings should be maintained upstream in the DT repo regardless of the communities adopted solution. > However, DT bindings are something which should be common, the > hardware description of a device should be universal. IMO, splitting > DT bindings alone would ease the compliance process for u-boot drivers > in quite similar manner to Linux drivers. > I remember a discussion with ST on that topic related to Framebuffer. U-Boot can need a very different representation of the same device to use it while Linux need an in-depth description of all shaders and « stuff » (another reason why [1] is addressing only a portion of the problem) So even if there is a single frame buffer binding, there should be two (at least) conformance tests. > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml > >> >>> AFAIK, DT bindings should be forwards and backwards >>> compatible. >> >> The same with DTS. >> >>> So if you pick up DTS or DTB from any project tree >>> (upstream kernel or stable kernel or u-boot) then DT schema validation >>> would ensure that corresponding DTS or DTB doesn't regress the DT >>> bindings. >> >> And why is this argument to decouple DTS from bindings? >> > > See above. > >>> >>> Ideally, it should be more user/CI friendly if DT bindings can be >>> easily installed alongside devicetree schema tools [1]. >>> >>> [1] https://github.com/devicetree-org/dt-schema >> >> Does it mean you will work on this? > > I am happy to collaboratively work with DT bindings maintainers and > the u-boot community once we can reach a consensus on the above. > Basically the main motive here is to validate DTS files present in the > u-boot tree and be able to reliably pass them to whichever Linux > kernel version you are trying to boot. IOW, make Linux distros to > reliably boot with devicetree supplied by u-boot. > > -Sumit > >> >> Best regards, >> Krzysztof >> > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On 05/12/2023 07:44, Sumit Garg wrote: > 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: [...] >>>> == 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. Yes, just to clarify, this is the state that _all_ non-WoA Qualcomm boards/devices are in right now (with the exception of db410c), with production devices we can't modify the bootloader without vendors releasing their signing keys. For devices that haven't been locked with vendor keys ("Secureboot off" in Qualcomm terminology, note that this has nothing to do with UEFI secureboot) we can work towards replacing the bootloader entirely with U-Boot, I have done a PoC of this on SDM845. In that case, we have to embed the DTB into U-Boot. > >> >>> >>> 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. Unfortunately the chances of Qualcomm releasing bootloader updates to adopt a standard for chainloading U-Boot on their wholely deprecated platforms of 5/6/7 years ago, and then having OEMs/ODMs (who have no reason to care, and may not even be around anymore) apply these patches to their own hacked up fork of the bootloader and ship it to end-users is honestly even less likely than OEMs releasing the signing keys for devices they don't support anymore. > >> >> 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
On Tue, Dec 05, 2023 at 10:36:28AM +0000, ff wrote: > > Le 5 déc. 2023 à 10:46, Sumit Garg <sumit.garg@linaro.org> a écrit : > > > > + U-boot custodians list > > > >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > >> <krzysztof.kozlowski@linaro.org> wrote: > >> > >> On 05/12/2023 08:13, Sumit Garg wrote: > >>>>> @DT bindings maintainers, > >>>>> > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > >>>>> source tree, I don't have a specific objection there. But can we > >>>>> ease DTS testing for firmware/bootloader projects by providing a > >>>>> versioned release package for DT bindings? Or if someone else > >>>>> has a better idea here please feel free to chime in. > >>>> > >>>> This doesn't work for you?: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > >>> > >>> Thanks, this is certainly a good step which I wasn't aware of. > >>> Further simplification can be done to decouple devicetree source > >>> files from DT bindings. > >> > >> Why? > > > > I suppose you are already aware that Linux DTS files are a subset of > > what could be supported by devicetree schemas. There can be > > firmware/bootloader specific properties (one example being [1]) > > which Linux kernel can simply ignore. Will you be willing to add all > > of those DT properties to Linux DTS files and maintain them? > > A pre-existing effort to solve the same problem as [1] is System > Device Tree, discussed in the context of Linaro supported OpenAMP > project. It is not just about cherry picking devices that have > bindings in Linux but also information about clock and power domains > or devices that are not seen by Linux. It is obvious that the > resulting bindings should be maintained upstream in the DT repo > regardless of the communities adopted solution. This seems to be artificially linking two topics: system DT and DT schema validation within u-boot. They are somewhat related but one of not a precondition of the other. > > However, DT bindings are something which should be common, the > > hardware description of a device should be universal. IMO, splitting > > DT bindings alone would ease the compliance process for u-boot > > drivers in quite similar manner to Linux drivers. > > I remember a discussion with ST on that topic related to Framebuffer. > U-Boot can need a very different representation of the same device to > use it while Linux need an in-depth description of all shaders and « > stuff » (another reason why [1] is addressing only a portion of the > problem) So even if there is a single frame buffer binding, there > should be two (at least) conformance tests. I don't follow this, for two reasons. 1. DT describes the hardware, not how it is driven. Having a relationship between u-boot and linux DTs with different representation would imply that the hardware changes between u-boot and the kernel. 2. Even if we were to accept that there must be two device tree instances (beyond transient workarounds for missing features), why would there need to be two conformance tests rather than one conformance test run on the two DTs? Daniel.
Le 5 déc. 2023 à 13:48, Daniel Thompson <daniel.thompson@linaro.org> a écrit : On Tue, Dec 05, 2023 at 10:36:28AM +0000, ff wrote: Le 5 déc. 2023 à 10:46, Sumit Garg <sumit.garg@linaro.org> a écrit : + U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: On 05/12/2023 08:13, Sumit Garg wrote: @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? A pre-existing effort to solve the same problem as [1] is System Device Tree, discussed in the context of Linaro supported OpenAMP project. It is not just about cherry picking devices that have bindings in Linux but also information about clock and power domains or devices that are not seen by Linux. It is obvious that the resulting bindings should be maintained upstream in the DT repo regardless of the communities adopted solution. This seems to be artificially linking two topics: system DT and DT schema validation within u-boot. They are somewhat related but one of not a precondition of the other. Agreed. I am mentioning this because it relates to binding and conformance testing: DT consumers such as OP-TEE , OSes and hypervisors should be considered equally as U-Boot and Linux. Hence it makes sense that all those are decoupled from any consumer and live « standalone ». However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers. I remember a discussion with ST on that topic related to Framebuffer. U-Boot can need a very different representation of the same device to use it while Linux need an in-depth description of all shaders and « stuff » (another reason why [1] is addressing only a portion of the problem) So even if there is a single frame buffer binding, there should be two (at least) conformance tests. I don't follow this, for two reasons. 1. DT describes the hardware, not how it is driven. Having a relationship between u-boot and linux DTs with different representation would imply that the hardware changes between u-boot and the kernel. 2. Even if we were to accept that there must be two device tree instances (beyond transient workarounds for missing features), why would there need to be two conformance tests rather than one conformance test run on the two DTs? Let’s say U-Boot only cares and use legacy SGVA frame buffer, while Linux community only cares and use the full fledged GPU. You end-up with two communities maintaining the conformance test part it cares/need. Isn’t splitting the tests responsibilities a way to get people feel more « empowered » and thus more active? Daniel.
Hi Caleb, On Tue, 5 Dec 2023 at 03:55, Caleb Connolly <caleb.connolly@linaro.org> wrote: > > > > On 05/12/2023 07:44, Sumit Garg wrote: > > 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: > [...] > >>>> == 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. > > Yes, just to clarify, this is the state that _all_ non-WoA Qualcomm > boards/devices are in right now (with the exception of db410c), with > production devices we can't modify the bootloader without vendors > releasing their signing keys. Or perhaps a shim? It would be good if vendors could provide an unlock mechanism eventually, but I understand it is challenging. > > For devices that haven't been locked with vendor keys ("Secureboot off" > in Qualcomm terminology, note that this has nothing to do with UEFI > secureboot) we can work towards replacing the bootloader entirely with > U-Boot, I have done a PoC of this on SDM845. In that case, we have to > embed the DTB into U-Boot. OK, I see, that sounds good. My concern is that the open source approach is preserved and made the easiest option. Decisions which accommodate private binaries while making open source harder should generally be rejected. > > > >> > >>> > >>> 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. > > Unfortunately the chances of Qualcomm releasing bootloader updates to > adopt a standard for chainloading U-Boot on their wholely deprecated > platforms of 5/6/7 years ago, and then having OEMs/ODMs (who have no > reason to care, and may not even be around anymore) apply these patches > to their own hacked up fork of the bootloader and ship it to end-users > is honestly even less likely than OEMs releasing the signing keys for > devices they don't support anymore. Yes, I understand it is challenging. Somehow it works better with Linux, despite hacked up kernels, etc. so perhaps Linaro can help here? Regards, Simon
Hi Sumit, On Tue, 5 Dec 2023 at 00:44, Sumit Garg <sumit.garg@linaro.org> wrote: > > 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 > > > $ 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. LK is Little kernel, I believe. That is an open source project, right? But I suppose it is BSD licensed so in fact the code is not available? Is ABL obsolete? I'm not sure that it matters in any case. We should be able to standardise the U-Boot part and let the private projects implement that, for a seamless boot. What you have written above is not a good way for U-Boot to be packaged or invoked. > > > > > > > > > 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. Here I am not referring to Linux, but to the firmware stages. We need firmware handoff so all these nutty binaries around the place can communicate with the open source (firmware) projects in a sensible fashion. For Linux we can pass the DT using existing mechanisms. > > > > > 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. It is the hiding of the DT that I object to. I would like to see these files in U-Boot, so we can build U-Boot for the platform and boot it with its local DT. Otherwise many of the innovations U-Boot provides, such as firmware packaging, become impossible. My feeling on this might change if the bindings process were easier. Regards, Simon
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 05/12/2023 10:45, Sumit Garg wrote: > > + U-boot custodians list > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > <krzysztof.kozlowski@linaro.org> wrote: > >> > >> On 05/12/2023 08:13, Sumit Garg wrote: > >>>>> @DT bindings maintainers, > >>>>> > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > >>>>> source tree, I don't have a specific objection there. But can we ease > >>>>> DTS testing for firmware/bootloader projects by providing a versioned > >>>>> release package for DT bindings? Or if someone else has a better idea > >>>>> here please feel free to chime in. > >>>> > >>>> This doesn't work for you?: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > >>> > >>> Thanks, this is certainly a good step which I wasn't aware of. Further > >>> simplification can be done to decouple devicetree source files from DT > >>> bindings. > >> > >> Why? > > > > I suppose you are already aware that Linux DTS files are a subset of > > what could be supported by devicetree schemas. There can be > > firmware/bootloader specific properties (one example being [1]) which > > Linux kernel can simply ignore. Will you be willing to add all of > > those DT properties to Linux DTS files and maintain them? > > We already added them and we already maintain them. DTS describes the > hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. > > > > > However, DT bindings are something which should be common, the > > hardware description of a device should be universal. IMO, splitting > > Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. > > > DT bindings alone would ease the compliance process for u-boot drivers > > in quite similar manner to Linux drivers. > > > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml > > > >> > >>> AFAIK, DT bindings should be forwards and backwards > >>> compatible. > >> > >> The same with DTS. > >> > >>> So if you pick up DTS or DTB from any project tree > >>> (upstream kernel or stable kernel or u-boot) then DT schema validation > >>> would ensure that corresponding DTS or DTB doesn't regress the DT > >>> bindings. > >> > >> And why is this argument to decouple DTS from bindings? > >> > > > > See above. > > It's not really explained there. You can pick up DTS from any project > and validate it against the repo Rob mentioned or against kernel. > Whether DTS is in that repo or not, does not matter for your validation. > It is similar to your earlier argument to use the whole mainline kernel repo. What is the real benefit to keep DT bindings and DTS together when every project has to maintain a copy of DTS in its own source tree? It will be just a source of confusion for developers: - One DTS coming from devicetree-rebasing repo - One DTS coming from local project -Sumit
On Wed, 6 Dec 2023 at 09:24, Simon Glass <sjg@chromium.org> wrote: > > Hi Sumit, > > On Tue, 5 Dec 2023 at 00:44, Sumit Garg <sumit.garg@linaro.org> wrote: > > > > 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 > > > > $ 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. > > LK is Little kernel, I believe. That is an open source project, right? > But I suppose it is BSD licensed so in fact the code is not available? > Is ABL obsolete? ABL: Android Boot Loader. I suppose it is somewhat derived from edk2 ABL EFI application. It's not obsolete but rather the one widely used proprietary bootloader on recent SoCs (qcs404, sdm845 and all later SoCs). Infact LK is somewhat obsolete which supports db410c, db820c etc. > > I'm not sure that it matters in any case. We should be able to > standardise the U-Boot part and let the private projects implement > that, for a seamless boot. > > What you have written above is not a good way for U-Boot to be > packaged or invoked. I agree but we have to live with that given the challenges Caleb mentioned in the other thread. > > > > > > > > > > > > > > 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. > > Here I am not referring to Linux, but to the firmware stages. We need > firmware handoff so all these nutty binaries around the place can > communicate with the open source (firmware) projects in a sensible > fashion. AFAIK, firmware handoff is an alternative way alongside DT to communicate among firmware images if each firmware image can't support a DT parser. Qcom proprietary bootloaders support DT parser and hence they can communicate information (memory/reserved memory nodes etc) via DT. Don't you consider DT as a sensible way to pass information to u-boot? > > For Linux we can pass the DT using existing mechanisms. > > > > > > > > > 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. > > It is the hiding of the DT that I object to. I would like to see these > files in U-Boot, so we can build U-Boot for the platform and boot it > with its local DT. Otherwise many of the innovations U-Boot provides, > such as firmware packaging, become impossible. My feeling on this > might change if the bindings process were easier. I agree with your current perspective about DT bindings. As you can see from my conversations with DT bindings maintainers, it is difficult to maintain local u-boot DT copy unless you can easily validate them. -Sumit > > Regards, > Simon
Hi Caleb, Late to the party, but I'll respond to as much as I can On Tue, 21 Nov 2023 at 19:09, 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. > > 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) Note that the kaslr-seed is not so useful when booting with EFI. The kernel's EFI-stub ignores that and instead tries to randomize the physical placement of the kernel if it finds an EFI_RNG protocol. > 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. [...] Cheers /Ilias
Hi Tom, On Wed, 22 Nov 2023 at 16:28, Tom Rini <trini@konsulko.com> 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? > > > > > > > > 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. > IMHO that option isn't that useful. Grepping for OF_HAS_PRIOR_STAGE shows that we use it to print where the DT came from unless I am missing something... On top of that having implies in the Kconfig to control those prints makes little sense to me and it's a half-baked solution anyway, because may boards don't fill this properly. This thing was cleaned up in 2e8d2f88439d, 2ea63271e522f, and d6f8ab30a2af46 but then got reintroduced in 275b4832f6bf91 without anyone acking or reviewing. I am fine with Caleb suggests here, but I think we can do way better. Instead of having that imply we can get rid of it and only have OF_BOARD(and perhaps rename it). So a general cleanup I have in mind is CONFIG_OF_SEPARATE -> rename it to CONFIG_OF_APPEND because it is actually appended at the end of the binary. CONFIG_OF_EMBED -> Leave it as is, it's there for debugging mostly. CONFIG_OF_BOARD perhaps rename it to something more useful, but the semantics are 'The DT comes from an *external* source. A bloblist, some EEPROM location, CPU registers etc' CONFIG_OF_HAS_PRIOR_STAGE -> Get rid of it again. gd already has gd->fdt_src, just add a FDTSRC_UNKNOWN as default and delegate the responsibility of filling this properly at fdtdec_setup(). The boards that use OF_BOARD can fill this in properly, instead of relying on Kconfig imply options and we can even be more explicit on where the DT came from. I can send an RFC if anyone thinks this is a cleaner approach Thanks /Ilias > -- > Tom
> From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > Date: Wed, 6 Dec 2023 12:31:15 +0200 > > Hi Caleb, > > Late to the party, but I'll respond to as much as I can > > On Tue, 21 Nov 2023 at 19:09, 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. > > > > 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) > > Note that the kaslr-seed is not so useful when booting with EFI. The > kernel's EFI-stub ignores that and instead tries to randomize the > physical placement of the kernel if it finds an EFI_RNG protocol. OpenBSD will use it though. And other OSes might as well. > > 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.
Hi Mark, On Wed, 6 Dec 2023 at 13:00, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: > > > From: Ilias Apalodimas <ilias.apalodimas@linaro.org> > > Date: Wed, 6 Dec 2023 12:31:15 +0200 > > > > Hi Caleb, > > > > Late to the party, but I'll respond to as much as I can > > > > On Tue, 21 Nov 2023 at 19:09, 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. > > > > > > 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) > > > > Note that the kaslr-seed is not so useful when booting with EFI. The > > kernel's EFI-stub ignores that and instead tries to randomize the > > physical placement of the kernel if it finds an EFI_RNG protocol. > > OpenBSD will use it though. And other OSes might as well. Yea, I remember that, but efi_try_purge_kaslr_seed() purges it anyway if there's an EFI_RNG protocol installed. U-Boot also has other ways of injecting it. Perhaps we could keep it and combine rng-seeds in the future I guess. Thanks /Ilias > > > > 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.
On 06/12/2023 10:44, Ilias Apalodimas wrote: > Hi Tom, > > On Wed, 22 Nov 2023 at 16:28, Tom Rini <trini@konsulko.com> 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? >>>>> >>>>> 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. This is implicitly enforced by the bootloader on Qualcomm platforms. It will only even boot U-Boot if we gzip u-boot-nodtb.bin, then append some valid DTB to it, and then shove it in an Android boot image. If there is no DTB then the bootloader won't run U-Boot. If we somehow did run U-Boot without a valid DTB then we wouldn't be able to print anything anyway (unless debug UART is enabled). >> > > IMHO that option isn't that useful. Grepping for OF_HAS_PRIOR_STAGE > shows that we use it to print where the DT came from unless I am > missing something... > On top of that having implies in the Kconfig to control those prints > makes little sense to me and it's a half-baked solution anyway, > because may boards don't fill this properly. This thing was cleaned > up in 2e8d2f88439d, 2ea63271e522f, and d6f8ab30a2af46 but then got > reintroduced in 275b4832f6bf91 without anyone acking or reviewing. I > am fine with Caleb suggests here, but I think we can do way better. > > Instead of having that imply we can get rid of it and only have > OF_BOARD(and perhaps rename it). So a general cleanup I have in mind > is > > CONFIG_OF_SEPARATE -> rename it to CONFIG_OF_APPEND because it is > actually appended at the end of the binary. > CONFIG_OF_EMBED -> Leave it as is, it's there for debugging mostly. > CONFIG_OF_BOARD perhaps rename it to something more useful, but the > semantics are 'The DT comes from an *external* source. A bloblist, > some EEPROM location, CPU registers etc' > CONFIG_OF_HAS_PRIOR_STAGE -> Get rid of it again. gd already has > gd->fdt_src, just add a FDTSRC_UNKNOWN as default and delegate the > responsibility of filling this properly at fdtdec_setup(). The boards > that use OF_BOARD can fill this in properly, instead of relying on > Kconfig imply options and we can even be more explicit on where the DT > came from. This sounds good to me, although I guess I'm mostly unaffected anyways. > > I can send an RFC if anyone thinks this is a cleaner approach> > Thanks > /Ilias > > > >> -- >> Tom
Hi Simon, >>>> - 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. > > LK is Little kernel, I believe. That is an open source project, right? > But I suppose it is BSD licensed so in fact the code is not available? > Is ABL obsolete? > > I'm not sure that it matters in any case. We should be able to > standardise the U-Boot part and let the private projects implement > that, for a seamless boot. Realistically we aren't in a position to change the bootflow on Qualcomm boards. This may well change in the future, but for now this is the best we can do. On a personal note, I work on a project called postmarketOS, we try to run upstream Linux and a fully FOSS userspace on phones. I support a few Qualcomm devices there, and currently the biggest annoyance has been the bootloader. We can't change it, most OEMs don't care, we're stuck with it. Below is the MR prototyping UEFI booting postmarketOS with systemd-boot and U-Boot. This will let us do kernel rollbacks, multi-boot with other distros, and all the fun things that UEFI gets us. Only because of the bringup work done here, and (until someone finds an exploit) this is possible only using the boot mechanism explained by Sumit above. https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4599 > > What you have written above is not a good way for U-Boot to be > packaged or invoked. I agree, of course it would be great to have U-Boot be a first-class citizen on Qualcomm devices, but supporting this (admittedly very wonky) bootflow doesn't exclude that possibility. I very much hope we'll see some better options for devices going forwards. >
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 05/12/2023 10:45, Sumit Garg wrote: > > > + U-boot custodians list > > > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > > <krzysztof.kozlowski@linaro.org> wrote: > > >> > > >> On 05/12/2023 08:13, Sumit Garg wrote: > > >>>>> @DT bindings maintainers, > > >>>>> > > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > > >>>>> source tree, I don't have a specific objection there. But can we ease > > >>>>> DTS testing for firmware/bootloader projects by providing a versioned > > >>>>> release package for DT bindings? Or if someone else has a better idea > > >>>>> here please feel free to chime in. > > >>>> > > >>>> This doesn't work for you?: > > >>>> > > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > >>> > > >>> Thanks, this is certainly a good step which I wasn't aware of. Further > > >>> simplification can be done to decouple devicetree source files from DT > > >>> bindings. > > >> > > >> Why? > > > > > > I suppose you are already aware that Linux DTS files are a subset of > > > what could be supported by devicetree schemas. There can be > > > firmware/bootloader specific properties (one example being [1]) which > > > Linux kernel can simply ignore. Will you be willing to add all of > > > those DT properties to Linux DTS files and maintain them? > > > > We already added them and we already maintain them. DTS describes the > > hardware, not the OS-subset of the hardware. > > Let look at some numbers if your statement is justified or not for the > example I gave: > > u-boot$ git grep -nr bootph-* arch/arm* | wc -l > 4079 > > linux$ git grep -nr bootph-* arch/arm* | wc -l > 267 I have no control over whether anyone has submitted the other 3812 instances. > It looks like there is always going to be a catch up game regarding DT > properties which either Linux kernel or u-boot or any other > firmware/bootloader project don't care about. As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not. If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too? > > > However, DT bindings are something which should be common, the > > > hardware description of a device should be universal. IMO, splitting > > > > Both DT bindings and DTS should be common. I don't see the difference. > > If we really care about DTS to be common then the contribution model > has to change where there is a single repo hosting DT bindings and > DTS. All other projects whether it is Linux kernel or u-boot or any > other OS/firmware/bootloader are just consuming DTS files from that > single repo. Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem. > I suppose this is something that Linux DT maintainers > have objected to in the past for ease of maintenance. I am not sure if > you folks are willing to change that stance. The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers. Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? How many years will that take? What do we do with platforms no one is interested in moving? Or do we start with devicetree-rebasing instead (That was the plan at one time) and sync u-boot back to that? All the work needed to get u-boot and kernel dts files in sync has virtually no dependency on a standalone repo. If the dts files aren't already kept in sync, someone has to figure the differences and eliminate them. Maybe some platforms are in good shape, but it is still a manual process. Fix that part, because a standalone repo does nothing for you until you do. > > > DT bindings alone would ease the compliance process for u-boot drivers > > > in quite similar manner to Linux drivers. There's no compliance of drivers really beyond checking if compatible strings used by drivers have a schema. Why is extracting the bindings out a problem? SystemReady has no issue doing just that for its compliance test. Rob
> Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt@kernel.org> a écrit : > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: >> >>> On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski >>> <krzysztof.kozlowski@linaro.org> wrote: >>> >>> On 05/12/2023 10:45, Sumit Garg wrote: >>>> + U-boot custodians list >>>> >>>> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski >>>> <krzysztof.kozlowski@linaro.org> wrote: >>>>> >>>>> On 05/12/2023 08:13, Sumit Garg wrote: >>>>>>>> @DT bindings maintainers, >>>>>>>> >>>>>>>> Given the ease of maintenance of DT bindings within Linux kernel >>>>>>>> source tree, I don't have a specific objection there. But can we ease >>>>>>>> DTS testing for firmware/bootloader projects by providing a versioned >>>>>>>> release package for DT bindings? Or if someone else has a better idea >>>>>>>> here please feel free to chime in. >>>>>>> >>>>>>> This doesn't work for you?: >>>>>>> >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ >>>>>> >>>>>> Thanks, this is certainly a good step which I wasn't aware of. Further >>>>>> simplification can be done to decouple devicetree source files from DT >>>>>> bindings. >>>>> >>>>> Why? >>>> >>>> I suppose you are already aware that Linux DTS files are a subset of >>>> what could be supported by devicetree schemas. There can be >>>> firmware/bootloader specific properties (one example being [1]) which >>>> Linux kernel can simply ignore. Will you be willing to add all of >>>> those DT properties to Linux DTS files and maintain them? >>> >>> We already added them and we already maintain them. DTS describes the >>> hardware, not the OS-subset of the hardware. >> >> Let look at some numbers if your statement is justified or not for the >> example I gave: >> >> u-boot$ git grep -nr bootph-* arch/arm* | wc -l >> 4079 >> >> linux$ git grep -nr bootph-* arch/arm* | wc -l >> 267 > > I have no control over whether anyone has submitted the other 3812 instances. > >> It looks like there is always going to be a catch up game regarding DT >> properties which either Linux kernel or u-boot or any other >> firmware/bootloader project don't care about. > > As long as dts files in u-boot are manually sync'ed, yes. That is the > problem and it doesn't matter if we have a standalone repository or > not. > > If you want to move in that direction, start automating what u-boot > imports. You need to do that for bindings if you want to run > validation, so why not dts files too? > >>>> However, DT bindings are something which should be common, the >>>> hardware description of a device should be universal. IMO, splitting >>> >>> Both DT bindings and DTS should be common. I don't see the difference. >> >> If we really care about DTS to be common then the contribution model >> has to change where there is a single repo hosting DT bindings and >> DTS. All other projects whether it is Linux kernel or u-boot or any >> other OS/firmware/bootloader are just consuming DTS files from that >> single repo. > > Really, only the kernel and u-boot matter. No, I don't mean I don't > care about other projects, but those are the 2 with the widest h/w > support by far and which have a major effort to sync copies of dts > files in both projects. The rest are just noise in terms of this > problem. > >> I suppose this is something that Linux DT maintainers >> have objected to in the past for ease of maintenance. I am not sure if >> you folks are willing to change that stance. > > The issue is no one steps up to help maintain such a repository while > there is lots of review and maintainer work on what goes into the > kernel tree. I'm happy to direct my binding review attention to > wherever the majority of the bindings go. But the work on the DTS side > is mostly SoC tree maintainers and sub-maintainers. > > Assume for a minute we have this standalone repo. What happens next? > We start with an empty repo and then merge and move platforms 1 by 1? What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? > How many years will that take? Should all platforms following that organization be a goal? > What do we do with platforms no one is > interested in moving? Or do we start with devicetree-rebasing instead > (That was the plan at one time) and sync u-boot back to that? > All the work needed to get u-boot and kernel dts files in sync has > virtually no dependency on a standalone repo. If the dts files aren't > already kept in sync, someone has to figure the differences and > eliminate them. Maybe some platforms are in good shape, but it is > still a manual process. Fix that part, because a standalone repo does > nothing for you until you do. > >>>> DT bindings alone would ease the compliance process for u-boot drivers >>>> in quite similar manner to Linux drivers. > > There's no compliance of drivers really beyond checking if compatible > strings used by drivers have a schema. > > Why is extracting the bindings out a problem? SystemReady has no issue > doing just that for its compliance test. > > Rob > _______________________________________________ > boot-architecture mailing list -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Thu, 7 Dec 2023 at 02:12, Rob Herring <robh+dt@kernel.org> wrote: > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > > > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > > <krzysztof.kozlowski@linaro.org> wrote: > > > > > > On 05/12/2023 10:45, Sumit Garg wrote: > > > > + U-boot custodians list > > > > > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > > > <krzysztof.kozlowski@linaro.org> wrote: > > > >> > > > >> On 05/12/2023 08:13, Sumit Garg wrote: > > > >>>>> @DT bindings maintainers, > > > >>>>> > > > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > > > >>>>> source tree, I don't have a specific objection there. But can we ease > > > >>>>> DTS testing for firmware/bootloader projects by providing a versioned > > > >>>>> release package for DT bindings? Or if someone else has a better idea > > > >>>>> here please feel free to chime in. > > > >>>> > > > >>>> This doesn't work for you?: > > > >>>> > > > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > > >>> > > > >>> Thanks, this is certainly a good step which I wasn't aware of. Further > > > >>> simplification can be done to decouple devicetree source files from DT > > > >>> bindings. > > > >> > > > >> Why? > > > > > > > > I suppose you are already aware that Linux DTS files are a subset of > > > > what could be supported by devicetree schemas. There can be > > > > firmware/bootloader specific properties (one example being [1]) which > > > > Linux kernel can simply ignore. Will you be willing to add all of > > > > those DT properties to Linux DTS files and maintain them? > > > > > > We already added them and we already maintain them. DTS describes the > > > hardware, not the OS-subset of the hardware. > > > > Let look at some numbers if your statement is justified or not for the > > example I gave: > > > > u-boot$ git grep -nr bootph-* arch/arm* | wc -l > > 4079 > > > > linux$ git grep -nr bootph-* arch/arm* | wc -l > > 267 > > I have no control over whether anyone has submitted the other 3812 instances. > > > It looks like there is always going to be a catch up game regarding DT > > properties which either Linux kernel or u-boot or any other > > firmware/bootloader project don't care about. > > As long as dts files in u-boot are manually sync'ed, yes. That is the > problem and it doesn't matter if we have a standalone repository or > not. > > If you want to move in that direction, start automating what u-boot > imports. You need to do that for bindings if you want to run > validation, so why not dts files too? > > > > > However, DT bindings are something which should be common, the > > > > hardware description of a device should be universal. IMO, splitting > > > > > > Both DT bindings and DTS should be common. I don't see the difference. > > > > If we really care about DTS to be common then the contribution model > > has to change where there is a single repo hosting DT bindings and > > DTS. All other projects whether it is Linux kernel or u-boot or any > > other OS/firmware/bootloader are just consuming DTS files from that > > single repo. > > Really, only the kernel and u-boot matter. No, I don't mean I don't > care about other projects, but those are the 2 with the widest h/w > support by far and which have a major effort to sync copies of dts > files in both projects. The rest are just noise in terms of this > problem. > > > I suppose this is something that Linux DT maintainers > > have objected to in the past for ease of maintenance. I am not sure if > > you folks are willing to change that stance. > > The issue is no one steps up to help maintain such a repository while > there is lots of review and maintainer work on what goes into the > kernel tree. I'm happy to direct my binding review attention to > wherever the majority of the bindings go. But the work on the DTS side > is mostly SoC tree maintainers and sub-maintainers. > > Assume for a minute we have this standalone repo. What happens next? > We start with an empty repo and then merge and move platforms 1 by 1? > How many years will that take? What do we do with platforms no one is > interested in moving? Or do we start with devicetree-rebasing instead > (That was the plan at one time) and sync u-boot back to that? Thanks Rob for sharing further insights. So I have given this approach a try here [1]. Lets see how it can serve u-boot community needs and thereby bring DT bindings compliance in u-boot. U-boot community, maintainers, custodians, Feel free to play out with this DT bindings compliance idea here [1] and let us know if this approach helps to reduce DT maintainence burden alongside increasing compliance. [1] https://github.com/u-boot/u-boot/pull/451 -Sumit > > All the work needed to get u-boot and kernel dts files in sync has > virtually no dependency on a standalone repo. If the dts files aren't > already kept in sync, someone has to figure the differences and > eliminate them. Maybe some platforms are in good shape, but it is > still a manual process. Fix that part, because a standalone repo does > nothing for you until you do. > > > > > DT bindings alone would ease the compliance process for u-boot drivers > > > > in quite similar manner to Linux drivers. > > There's no compliance of drivers really beyond checking if compatible > strings used by drivers have a schema. > > Why is extracting the bindings out a problem? SystemReady has no issue > doing just that for its compliance test. > > Rob
On Thu, Dec 7, 2023 at 2:08 AM ff <ff@shokubai.tech> wrote: > > > > > Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt@kernel.org> a écrit : > > > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: > >> > >>> On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > >>> <krzysztof.kozlowski@linaro.org> wrote: > >>> > >>> On 05/12/2023 10:45, Sumit Garg wrote: > >>>> + U-boot custodians list > >>>> > >>>> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > >>>> <krzysztof.kozlowski@linaro.org> wrote: > >>>>> > >>>>> On 05/12/2023 08:13, Sumit Garg wrote: > >>>>>>>> @DT bindings maintainers, > >>>>>>>> > >>>>>>>> Given the ease of maintenance of DT bindings within Linux kernel > >>>>>>>> source tree, I don't have a specific objection there. But can we ease > >>>>>>>> DTS testing for firmware/bootloader projects by providing a versioned > >>>>>>>> release package for DT bindings? Or if someone else has a better idea > >>>>>>>> here please feel free to chime in. > >>>>>>> > >>>>>>> This doesn't work for you?: > >>>>>>> > >>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > >>>>>> > >>>>>> Thanks, this is certainly a good step which I wasn't aware of. Further > >>>>>> simplification can be done to decouple devicetree source files from DT > >>>>>> bindings. > >>>>> > >>>>> Why? > >>>> > >>>> I suppose you are already aware that Linux DTS files are a subset of > >>>> what could be supported by devicetree schemas. There can be > >>>> firmware/bootloader specific properties (one example being [1]) which > >>>> Linux kernel can simply ignore. Will you be willing to add all of > >>>> those DT properties to Linux DTS files and maintain them? > >>> > >>> We already added them and we already maintain them. DTS describes the > >>> hardware, not the OS-subset of the hardware. > >> > >> Let look at some numbers if your statement is justified or not for the > >> example I gave: > >> > >> u-boot$ git grep -nr bootph-* arch/arm* | wc -l > >> 4079 > >> > >> linux$ git grep -nr bootph-* arch/arm* | wc -l > >> 267 > > > > I have no control over whether anyone has submitted the other 3812 instances. > > > >> It looks like there is always going to be a catch up game regarding DT > >> properties which either Linux kernel or u-boot or any other > >> firmware/bootloader project don't care about. > > > > As long as dts files in u-boot are manually sync'ed, yes. That is the > > problem and it doesn't matter if we have a standalone repository or > > not. > > > > If you want to move in that direction, start automating what u-boot > > imports. You need to do that for bindings if you want to run > > validation, so why not dts files too? > > > >>>> However, DT bindings are something which should be common, the > >>>> hardware description of a device should be universal. IMO, splitting > >>> > >>> Both DT bindings and DTS should be common. I don't see the difference. > >> > >> If we really care about DTS to be common then the contribution model > >> has to change where there is a single repo hosting DT bindings and > >> DTS. All other projects whether it is Linux kernel or u-boot or any > >> other OS/firmware/bootloader are just consuming DTS files from that > >> single repo. > > > > Really, only the kernel and u-boot matter. No, I don't mean I don't > > care about other projects, but those are the 2 with the widest h/w > > support by far and which have a major effort to sync copies of dts > > files in both projects. The rest are just noise in terms of this > > problem. > > > >> I suppose this is something that Linux DT maintainers > >> have objected to in the past for ease of maintenance. I am not sure if > >> you folks are willing to change that stance. > > > > The issue is no one steps up to help maintain such a repository while > > there is lots of review and maintainer work on what goes into the > > kernel tree. I'm happy to direct my binding review attention to > > wherever the majority of the bindings go. But the work on the DTS side > > is mostly SoC tree maintainers and sub-maintainers. > > > > Assume for a minute we have this standalone repo. What happens next? > > We start with an empty repo and then merge and move platforms 1 by 1? > > What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? I think there are 2 ATM. Synquacer and i.MX8 variants. Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either. Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings. > > How many years will that take? > > Should all platforms following that organization be a goal? You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place. I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work. Rob
Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt@kernel.org> a écrit : On Thu, Dec 7, 2023 at 2:08 AM ff <ff@shokubai.tech> wrote: Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt@kernel.org> a écrit : On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: On 05/12/2023 10:45, Sumit Garg wrote: + U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: On 05/12/2023 08:13, Sumit Garg wrote: @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 I have no control over whether anyone has submitted the other 3812 instances. It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not. If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers. Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? I think there are 2 ATM. Synquacer and i.MX8 variants. Based on https://www.arm.com/architecture/system-architectures/systemready-certification-program/ir roughly 30 boards. Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either. Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings. How many years will that take? Should all platforms following that organization be a goal? You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place. Actually, if we limit he DTS in the third place for SystemReady-IR, there should be no DTB in the Linux distribution. It would be the equivalent as ACPI boards . So is it still an issue ? A reference to the the third repo may be hinted in a text file. I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work. Rob
What on earth has happened here with quoting? Please fix your mail client man, this mail is a mess to read. On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote: > > > Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt@kernel.org> a écrit : > > On Thu, Dec 7, 2023 at 2:08 AM ff <ff@shokubai.tech> wrote: > > > > Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt@kernel.org> a écrit : > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > On 05/12/2023 10:45, Sumit Garg wrote: > + U-boot custodians list > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > On 05/12/2023 08:13, Sumit Garg wrote: > @DT bindings maintainers, > > Given the ease of maintenance of DT bindings within Linux kernel > source tree, I don't have a specific objection there. But can we ease > DTS testing for firmware/bootloader projects by providing a versioned > release package for DT bindings? Or if someone else has a better idea > here please feel free to chime in. > > This doesn't work for you?: > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > Thanks, this is certainly a good step which I wasn't aware of. Further > simplification can be done to decouple devicetree source files from DT > bindings. > > Why? > > I suppose you are already aware that Linux DTS files are a subset of > what could be supported by devicetree schemas. There can be > firmware/bootloader specific properties (one example being [1]) which > Linux kernel can simply ignore. Will you be willing to add all of > those DT properties to Linux DTS files and maintain them? > > We already added them and we already maintain them. DTS describes the > hardware, not the OS-subset of the hardware. > > Let look at some numbers if your statement is justified or not for the > example I gave: > > u-boot$ git grep -nr bootph-* arch/arm* | wc -l > 4079 > > linux$ git grep -nr bootph-* arch/arm* | wc -l > 267 > > I have no control over whether anyone has submitted the other 3812 instances. > > It looks like there is always going to be a catch up game regarding DT > properties which either Linux kernel or u-boot or any other > firmware/bootloader project don't care about. > > As long as dts files in u-boot are manually sync'ed, yes. That is the > problem and it doesn't matter if we have a standalone repository or > not. > > If you want to move in that direction, start automating what u-boot > imports. You need to do that for bindings if you want to run > validation, so why not dts files too? > > However, DT bindings are something which should be common, the > hardware description of a device should be universal. IMO, splitting > > Both DT bindings and DTS should be common. I don't see the difference. > > If we really care about DTS to be common then the contribution model > has to change where there is a single repo hosting DT bindings and > DTS. All other projects whether it is Linux kernel or u-boot or any > other OS/firmware/bootloader are just consuming DTS files from that > single repo. > > Really, only the kernel and u-boot matter. No, I don't mean I don't > care about other projects, but those are the 2 with the widest h/w > support by far and which have a major effort to sync copies of dts > files in both projects. The rest are just noise in terms of this > problem. > > I suppose this is something that Linux DT maintainers > have objected to in the past for ease of maintenance. I am not sure if > you folks are willing to change that stance. > > The issue is no one steps up to help maintain such a repository while > there is lots of review and maintainer work on what goes into the > kernel tree. I'm happy to direct my binding review attention to > wherever the majority of the bindings go. But the work on the DTS side > is mostly SoC tree maintainers and sub-maintainers. > > Assume for a minute we have this standalone repo. What happens next? > We start with an empty repo and then merge and move platforms 1 by 1? > > What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? > > I think there are 2 ATM. Synquacer and i.MX8 variants. > > Based on https://www.arm.com/architecture/system-architectures/systemready-certification-program/ir > roughly 30 boards. > > Synquacer only > has a DT in u-boot, so not really anything to do there. > I'm pretty > sure the certified DTBs for i.MX8 don't match what's in u-boot or the > kernel tree. Hopefully, it's just a subset, but still, there's a gap. > I don't know that there is motivation there either. > Note that SystemReady currently only requires every node with > 'compatible' have a schema. It does not yet require no schema > warnings. If we went with a 1 by 1 approach, I would push that > platforms have to be free of warnings. > > How many years will that take? > > Should all platforms following that organization be a goal? > > You mean should all platforms be moved? Absolutely. I don't think we > want to solve the problem of having DTS files in 2 places by creating > a 3rd place. I think this bit here is the only thing you actually wrote: > Actually, if we limit he DTS in the third place for SystemReady-IR, > there should be no DTB in the Linux distribution. > It would be the equivalent as ACPI boards . So is it still an issue ? > A reference to the the third repo may be hinted in a text file. SystemReady is only for one architecture, why would using it as the centralised point for devicetree files make sense? > > I don't really think 1 by 1 is the right approach. I was just > enumerating how this could work. It's not that useful to say we need a > standalone repo without working thru the logistics of how exactly that > will work. > > Rob
Le 7 déc. 2023 à 21:31, Conor Dooley <conor@kernel.org> a écrit : What on earth has happened here with quoting? Please fix your mail client man, this mail is a mess to read. Conor: Hopefully I have now fixed MacOS Mail configuration… For all: please accept my apologies on past inconveniences. On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote: Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt@kernel.org> a écrit : On Thu, Dec 7, 2023 at 2:08 AM ff <ff@shokubai.tech> wrote: Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt@kernel.org> a écrit : On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: On 05/12/2023 10:45, Sumit Garg wrote: + U-boot custodians list On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: On 05/12/2023 08:13, Sumit Garg wrote: @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. This doesn't work for you?: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. Why? I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them? We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware. Let look at some numbers if your statement is justified or not for the example I gave: u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079 linux$ git grep -nr bootph-* arch/arm* | wc -l 267 I have no control over whether anyone has submitted the other 3812 instances. It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about. As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not. If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too? However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting Both DT bindings and DTS should be common. I don't see the difference. If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance. The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers. Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? I think there are 2 ATM. Synquacer and i.MX8 variants. Based on https://www.arm.com/architecture/system-architectures/systemready-certification-program/ir roughly 30 boards. Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either. Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings. How many years will that take? Should all platforms following that organization be a goal? You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place. I think this bit here is the only thing you actually wrote: Actually, if we limit he DTS in the third place for SystemReady-IR, there should be no DTB in the Linux distribution. It would be the equivalent as ACPI boards . So is it still an issue ? A reference to the the third repo may be hinted in a text file. SystemReady is only for one architecture, why would using it as the centralised point for devicetree files make sense? SystemReady is an Arm certification but built on EBBR which is the important part and also adopted by RISC-V. So when I said SystemReady, one should read EBBR. EBBR is promoting a DT life cycle that is in line with having an out of OS/Firmware repos definitions. I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work. Rob
On Fri, Dec 08, 2023 at 09:39:27AM +0000, ff wrote: > > > Le 7 déc. 2023 à 21:31, Conor Dooley <conor@kernel.org> a écrit : > > What on earth has happened here with quoting? Please fix your mail > client man, this mail is a mess to read. > > Conor: Hopefully I have now fixed MacOS Mail configuration… > For all: please accept my apologies on past inconveniences. Judging by this mail looking like it does, nothing has changed? You can check it on lore too: https://lore.kernel.org/u-boot/CAC_iWjKKwjpD1VAbXJaB=UDQPWMS+k65tv-qL=JnewzSEhGEow@mail.gmail.com/T/#ma8c4fc1268c68aab0b05b96b2cea5c90cc2525b8 I'm not going to fix the quoting by hand, I have better things to do :) Cheers, Conor. > > On Thu, Dec 07, 2023 at 08:24:01PM +0000, ff wrote: > > > Le 7 déc. 2023 à 19:51, Rob Herring <robh+dt@kernel.org> a écrit : > > On Thu, Dec 7, 2023 at 2:08 AM ff <ff@shokubai.tech> wrote: > > > > Le 6 déc. 2023 à 21:42, Rob Herring <robh+dt@kernel.org> a écrit : > > On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > On 05/12/2023 10:45, Sumit Garg wrote: > + U-boot custodians list > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > On 05/12/2023 08:13, Sumit Garg wrote: > @DT bindings maintainers, > > Given the ease of maintenance of DT bindings within Linux kernel > source tree, I don't have a specific objection there. But can we ease > DTS testing for firmware/bootloader projects by providing a versioned > release package for DT bindings? Or if someone else has a better idea > here please feel free to chime in. > > This doesn't work for you?: > > https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > Thanks, this is certainly a good step which I wasn't aware of. Further > simplification can be done to decouple devicetree source files from DT > bindings. > > Why? > > I suppose you are already aware that Linux DTS files are a subset of > what could be supported by devicetree schemas. There can be > firmware/bootloader specific properties (one example being [1]) which > Linux kernel can simply ignore. Will you be willing to add all of > those DT properties to Linux DTS files and maintain them? > > We already added them and we already maintain them. DTS describes the > hardware, not the OS-subset of the hardware. > > Let look at some numbers if your statement is justified or not for the > example I gave: > > u-boot$ git grep -nr bootph-* arch/arm* | wc -l > 4079 > > linux$ git grep -nr bootph-* arch/arm* | wc -l > 267 > > I have no control over whether anyone has submitted the other 3812 instances. > > It looks like there is always going to be a catch up game regarding DT > properties which either Linux kernel or u-boot or any other > firmware/bootloader project don't care about. > > As long as dts files in u-boot are manually sync'ed, yes. That is the > problem and it doesn't matter if we have a standalone repository or > not. > > If you want to move in that direction, start automating what u-boot > imports. You need to do that for bindings if you want to run > validation, so why not dts files too? > > However, DT bindings are something which should be common, the > hardware description of a device should be universal. IMO, splitting > > Both DT bindings and DTS should be common. I don't see the difference. > > If we really care about DTS to be common then the contribution model > has to change where there is a single repo hosting DT bindings and > DTS. All other projects whether it is Linux kernel or u-boot or any > other OS/firmware/bootloader are just consuming DTS files from that > single repo. > > Really, only the kernel and u-boot matter. No, I don't mean I don't > care about other projects, but those are the 2 with the widest h/w > support by far and which have a major effort to sync copies of dts > files in both projects. The rest are just noise in terms of this > problem. > > I suppose this is something that Linux DT maintainers > have objected to in the past for ease of maintenance. I am not sure if > you folks are willing to change that stance. > > The issue is no one steps up to help maintain such a repository while > there is lots of review and maintainer work on what goes into the > kernel tree. I'm happy to direct my binding review attention to > wherever the majority of the bindings go. But the work on the DTS side > is mostly SoC tree maintainers and sub-maintainers. > > Assume for a minute we have this standalone repo. What happens next? > We start with an empty repo and then merge and move platforms 1 by 1? > > What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ? > > I think there are 2 ATM. Synquacer and i.MX8 variants. > > Based on https://www.arm.com/architecture/system-architectures/systemready-certification-program/ir > roughly 30 boards. > > Synquacer only > has a DT in u-boot, so not really anything to do there. > I'm pretty > sure the certified DTBs for i.MX8 don't match what's in u-boot or the > kernel tree. Hopefully, it's just a subset, but still, there's a gap. > I don't know that there is motivation there either. > Note that SystemReady currently only requires every node with > 'compatible' have a schema. It does not yet require no schema > warnings. If we went with a 1 by 1 approach, I would push that > platforms have to be free of warnings. > > How many years will that take? > > Should all platforms following that organization be a goal? > > You mean should all platforms be moved? Absolutely. I don't think we > want to solve the problem of having DTS files in 2 places by creating > a 3rd place. > > I think this bit here is the only thing you actually wrote: > > Actually, if we limit he DTS in the third place for SystemReady-IR, > there should be no DTB in the Linux distribution. > It would be the equivalent as ACPI boards . So is it still an issue ? > A reference to the the third repo may be hinted in a text file. > > SystemReady is only for one architecture, why would using it as the > centralised point for devicetree files make sense? > > SystemReady is an Arm certification but built on EBBR which is > the important part and also adopted by RISC-V. > So when I said SystemReady, one should read EBBR. > EBBR is promoting a DT life cycle that is in line with > having an out of OS/Firmware repos definitions. > > I don't really think 1 by 1 is the right approach. I was just > enumerating how this could work. It's not that useful to say we need a > standalone repo without working thru the logistics of how exactly that > will work. > > Rob >
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: [snip] > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. I will have more / other things to say but I want to chime in here. That U-Boot cannot validate the DTS files is a bug, not a feature. I would very much appreciate if someone(s) with time and skills to do so would re-sync us with the kernel Kbuild again so that we can both stay in sync again and have the validation targets / functionality available here too.
On Wed, Dec 06, 2023 at 12:44:47PM +0200, Ilias Apalodimas wrote: > Hi Tom, > > On Wed, 22 Nov 2023 at 16:28, Tom Rini <trini@konsulko.com> 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? > > > > > > > > > > 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. > > > > IMHO that option isn't that useful. Grepping for OF_HAS_PRIOR_STAGE > shows that we use it to print where the DT came from unless I am > missing something... So first, all of "imply OF_HAS_PRIOR_STAGE" is wrong and should be "select OF_HAS_PRIOR_STAGE". And then yes, it's OF_HAS_PRIOR_STAGE + OF_BOARD (which is default y if OF_HAS_PRIOR_STAGE). That is the set of symbols for lib/fdtdec.c::fdtdec_setup() to know to call board_fdt_blob_setup() and it's up to the board to know where to find the device tree we were given at run time. Generally the case here is that we're being a fake Linux Kernel and our dtb is in memory address $X and that in turn is set in the appropriate register. > On top of that having implies in the Kconfig to control those prints > makes little sense to me and it's a half-baked solution anyway, > because may boards don't fill this properly. This thing was cleaned > up in 2e8d2f88439d, 2ea63271e522f, and d6f8ab30a2af46 but then got > reintroduced in 275b4832f6bf91 without anyone acking or reviewing. I > am fine with Caleb suggests here, but I think we can do way better. I think the tags just got missed in 275b4832f6bf91 because that's close enough to what I wanted at the time. > Instead of having that imply we can get rid of it and only have > OF_BOARD(and perhaps rename it). So a general cleanup I have in mind > is I _think_ the problem is that we wanted to be able to allow developers to still be able to override the device tree. So we imply (should be select) OF_HAS_PRIOR_STAGE so that OF_BOARD=y unless told otherwise. > CONFIG_OF_SEPARATE -> rename it to CONFIG_OF_APPEND because it is > actually appended at the end of the binary. I'm indifferent on this part. Reading lib/fdtdec.c::fdt_find_separate() I can see why it's "separate" and not "append", but one could reword things to read "append" and not "separate". > CONFIG_OF_EMBED -> Leave it as is, it's there for debugging mostly. Agreed. > CONFIG_OF_BOARD perhaps rename it to something more useful, but the > semantics are 'The DT comes from an *external* source. A bloblist, > some EEPROM location, CPU registers etc' > CONFIG_OF_HAS_PRIOR_STAGE -> Get rid of it again. gd already has > gd->fdt_src, just add a FDTSRC_UNKNOWN as default and delegate the > responsibility of filling this properly at fdtdec_setup(). The boards > that use OF_BOARD can fill this in properly, instead of relying on > Kconfig imply options and we can even be more explicit on where the DT > came from. I don't know. All of the things you mention for what CONFIG_OF_BOARD comes down to "the board defines where it comes from", and so OF_BOARD is what we came up with. And maybe that whole "imply" rather than "select" thing is so that a developer can more clearly change to OF_SEPARATE instead.
On Wed, Dec 06, 2023 at 10:35:02AM +0530, Sumit Garg wrote: > On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: > > > > On 05/12/2023 10:45, Sumit Garg wrote: > > > + U-boot custodians list > > > > > > On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > > > <krzysztof.kozlowski@linaro.org> wrote: > > >> > > >> On 05/12/2023 08:13, Sumit Garg wrote: > > >>>>> @DT bindings maintainers, > > >>>>> > > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > > >>>>> source tree, I don't have a specific objection there. But can we ease > > >>>>> DTS testing for firmware/bootloader projects by providing a versioned > > >>>>> release package for DT bindings? Or if someone else has a better idea > > >>>>> here please feel free to chime in. > > >>>> > > >>>> This doesn't work for you?: > > >>>> > > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > > >>> > > >>> Thanks, this is certainly a good step which I wasn't aware of. Further > > >>> simplification can be done to decouple devicetree source files from DT > > >>> bindings. > > >> > > >> Why? > > > > > > I suppose you are already aware that Linux DTS files are a subset of > > > what could be supported by devicetree schemas. There can be > > > firmware/bootloader specific properties (one example being [1]) which > > > Linux kernel can simply ignore. Will you be willing to add all of > > > those DT properties to Linux DTS files and maintain them? > > > > We already added them and we already maintain them. DTS describes the > > hardware, not the OS-subset of the hardware. > > Let look at some numbers if your statement is justified or not for the > example I gave: > > u-boot$ git grep -nr bootph-* arch/arm* | wc -l > 4079 > > linux$ git grep -nr bootph-* arch/arm* | wc -l > 267 > > It looks like there is always going to be a catch up game regarding DT > properties which either Linux kernel or u-boot or any other > firmware/bootloader project don't care about. I want to chime in here just because that specific binding is both relatively new (and so platforms are working on upstreaming it now) and board-maintainers have gotten some feedback which has lead to: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/12 that someone needs to have time to work on and that will in turn reduce the number of instances both in U-Boot and then upstream. It's also one of the first examples of properties not used directly in Linux but that is valid and so there was some initial back-and-forth on getting the dts(i) changes accepted to the kernel tree.
Hi Tom, On Sun, 10 Dec 2023 at 03:33, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > [snip] > > But currently u-boot doesn't have a proper way to validate those DTS > > against DT bindings (maintained in Linux kernel). Although there are > > Devicetree schema tools available here [2], there isn't a versioned > > release package of DT bindings which one should use to validate DTS > > files. > > I will have more / other things to say but I want to chime in here. That > U-Boot cannot validate the DTS files is a bug, not a feature. I would > very much appreciate if someone(s) with time and skills to do so would > re-sync us with the kernel Kbuild again so that we can both stay in sync > again and have the validation targets / functionality available here > too. > Agree, the Kbuild changes to add dtbs_check was the first thing I implemented after importing devicetree-rebasing repo in u-boot (see commit [1] for details). Usage with PR [2] included: While building any u-boot target, just add make target: "dtbs_check" and you will see the DT schema checks being performed. Steps: $ make <target>_defconfig $ make -j`nproc` dtbs_check Currently there are a lot of incompatibility warnings I have seen for the platforms I built. This shows how much difficult it has been to keep DT in sync with upstream DT bindings. TBH, this was the only motivation for me to get into discussion with DT bindings maintainers for a separate repo. But since with devicetree-rebasing, we get devictree files bundled along and then I got into reusing them for building DTBs in u-boot. This has the other benefit of reducing maintainer's pain to keep DT in sync with Linux kernel major releases (see amlogic platforms to be the first migrator [3]). [1] https://github.com/u-boot/u-boot/pull/451/commits/7ea2dc2477992a603fa881d0da563246ee2f02d9 [2] https://github.com/u-boot/u-boot/pull/451 [3] https://github.com/u-boot/u-boot/pull/451/commits/38c2ac62e9134604d1a56179d57baa1877712b3e -Sumit > -- > Tom
On Mon, Dec 11, 2023 at 11:47 PM Sumit Garg <sumit.garg@linaro.org> wrote: > > Hi Tom, > > On Sun, 10 Dec 2023 at 03:33, Tom Rini <trini@konsulko.com> wrote: > > > > On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > > > > [snip] > > > But currently u-boot doesn't have a proper way to validate those DTS > > > against DT bindings (maintained in Linux kernel). Although there are > > > Devicetree schema tools available here [2], there isn't a versioned > > > release package of DT bindings which one should use to validate DTS > > > files. > > > > I will have more / other things to say but I want to chime in here. That > > U-Boot cannot validate the DTS files is a bug, not a feature. I would > > very much appreciate if someone(s) with time and skills to do so would > > re-sync us with the kernel Kbuild again so that we can both stay in sync > > again and have the validation targets / functionality available here > > too. > > > > Agree, the Kbuild changes to add dtbs_check was the first thing I > implemented after importing devicetree-rebasing repo in u-boot (see > commit [1] for details). Usage with PR [2] included: > > While building any u-boot target, just add make target: "dtbs_check" > and you will see the DT schema checks being performed. Steps: > > $ make <target>_defconfig > $ make -j`nproc` dtbs_check > > Currently there are a lot of incompatibility warnings I have seen for > the platforms I built. This shows how much difficult it has been to > keep DT in sync with upstream DT bindings. The versions in the Linux tree generally still have lots of warnings too. It's a mountain of warnings. The warnings get amplified when there are N boards for 1 SoC. Some platforms are more active than others to get rid of them. Newer platforms like Apple are warning free (or nearly so). If you want an overview of the state of platforms, I have a CI job[1] doing just that. Look at platform-warnings.log in the artifacts. It does some deduplicating of the warnings. Linux-next and Linus' master are built daily. Fixing the warnings alone will not solve potential incompatibility issues. The schemas can and do change (and in turn the dts files). We try to catch that in review, but the rule is that the platform must be okay with the ABI change (recent mistake, early stages, limited users, etc.) and the commit message must spell out 'this is an ABI change'. That's all manual and not easily identifiable. I'm working on a tool[2] to compare versions of the schema to identify some ABI changes. Though it is limited by thinking of what schema changes are ABI changes and my ability to write python code to parse those cases. Right now it looks for new required properties, removed properties, and changed number of entries. I'm interested in any ideas for other checks. Rob [1] https://gitlab.com/robherring/linux-dt/-/jobs [2] https://github.com/robherring/dt-schema/tree/abi-check
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. 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. == defconfig == Most of the board defconfigs and config headers were quite similar, to simplify maintenance going forward, all the fully generic boards (sdm845 and qcs404-evb so far) are adapted to use the new qcom_defconfig. Going forward, all new Qualcomm boards should be supported by this defconfig. A notable exception is for specific usecases (like U-Boot as the primary bootloader). == The older dragonboards == The db410c and db820c both have some custom board init code, as a result they aren't yet binary compatible. mach-snapdragon is adjusted so that all the necessary config options (e.g. CONFIG_SYS_BOARD) can be set from their defconfigs, this makes it possible to enable support for new boards without introducing additional config options. The db410c can run U-Boot either chainloaded like the other boards, or as a first-stage bootloader replacing aboot. However it was hardcoded to only build for the latter option. This series introduces a new "chainloaded" defconfig to enable easier testing via fastboot. == dynamic environment variables == This series also introduces runtime-allocated load addresses via the lmb allocator. This allows for booting on boards with vastly different memory layouts without any pre-calculation or macro magic in the config header. This feature is based on similar code in mach-apple. The soc, board, and fdtfile environment variables are also generated automatically. Many Qualcomm boards follow a similar scheme for DTB naming such that the name can often be derived from the root compatible properties. This is intended to cover the most common cases and be a simple solution for booting generic distro images without having to explicitly choose the right DTB. The U-Boot DTS can be tweaked if necessary to produce the correct name, the variable can be overwritten, or a bootloader like GRUB can load the devicetree instead. == Upstream DT == All Qualcomm boards have had their devicetree files rewritten to be based on the upstream SoC/PMIC DTSI files. Previous patch series made the necessary driver adjustments to fully support the upstream DT format. All future Qualcomm boards should use upstream DTS by default. --- I have tested this series on the Dragonboard410c, Dragonboard820c, and Dragonboard845c. I unfortunately don't have access to a QCS404 EVB board to test. This series is based on the qcom-next branch [1] and depends on my PMIC fixes series [2], an integration branch for testing can be found at [3]. The non-qualcomm-specific changes (patches 1, 2, and 3) don't have any dependencies. [1]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon [2]: https://lore.kernel.org/u-boot/20231114-b4-qcom-dt-compat-v3-0-88a92f8f00ba@linaro.org/ [3]: https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/tree/b4/qcom-common-target To: Neil Armstrong <neil.armstrong@linaro.org> To: Sumit Garg <sumit.garg@linaro.org> To: Ramon Fried <rfried.dev@gmail.com> Cc: Marek Vasut <marex@denx.de> To: Dzmitry Sankouski <dsankouski@gmail.com> To: Caleb Connolly <caleb.connolly@linaro.org> To: Peng Fan <peng.fan@nxp.com> To: Jaehoon Chung <jh80.chung@samsung.com> To: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com> To: Lukasz Majewski <lukma@denx.de> To: Sean Anderson <seanga2@gmail.com> To: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com> To: Stephan Gerhold <stephan@gerhold.net> Cc: <u-boot@lists.denx.de> --- Caleb Connolly (21): arm: init: export prev_bl_fdt_addr arm: allow CONFIG_LINUX_KERNEL_IMAGE_HEADER to be set in defconfig usb: dwc3-generic: support external vbus regulator mmc: msm_sdhci: use modern clock handling dt-bindings: drop msm_sdhci binding clk/qcom: use upstream compatible properties serial: msm: add debug UART serial: msm: fix clock handling configs: add dragonboard410c_chainloaded_defconfig dts: dragonboard410c: fix compatible and clocks board: dragonboard410c: import board code from mach-snapdragon board: dragonboard820c: use LINUX_KERNEL_IMAGE_HEADER mach-snapdragon: generalise board support mach-snapdragon: dynamic load addresses mach-snapdragon: generate fdtfile automatically doc: board/qualcomm: document generic targets dts: sdm845: import DT from Linux dts: msm8916: import DT from Linux dts: msm8996: import DT from Linux dts: qcs404-evb: import DT from Linux MAINTAINERS: Qualcomm: add some missing paths MAINTAINERS | 16 +- arch/arm/Kconfig | 6 +- arch/arm/dts/Makefile | 9 +- arch/arm/dts/dragonboard410c-uboot.dtsi | 44 - arch/arm/dts/dragonboard410c.dts | 198 +- arch/arm/dts/dragonboard820c-uboot.dtsi | 32 - arch/arm/dts/dragonboard820c.dts | 129 +- arch/arm/dts/dragonboard845c-uboot.dtsi | 26 - arch/arm/dts/dragonboard845c.dts | 23 +- arch/arm/dts/msm8916-pins.dtsi | 582 ++ arch/arm/dts/msm8916-pm8916.dtsi | 76 + arch/arm/dts/msm8916.dtsi | 2194 ++++++++ arch/arm/dts/msm8996.dtsi | 3959 +++++++++++++ arch/arm/dts/pm8916.dtsi | 183 + arch/arm/dts/pm8994.dtsi | 152 + arch/arm/dts/pm8998.dtsi | 130 + arch/arm/dts/pms405.dtsi | 149 + arch/arm/dts/qcs404-evb-uboot.dtsi | 30 - arch/arm/dts/qcs404-evb.dts | 441 +- arch/arm/dts/qcs404.dtsi | 1830 ++++++ arch/arm/dts/sdm845.dtsi | 5850 +++++++++++++++++++- arch/arm/dts/starqltechn-uboot.dtsi | 27 - arch/arm/dts/starqltechn.dts | 34 +- arch/arm/lib/save_prev_bl_data.c | 5 + arch/arm/mach-snapdragon/Kconfig | 95 +- arch/arm/mach-snapdragon/Makefile | 8 +- arch/arm/mach-snapdragon/board.c | 303 + arch/arm/mach-snapdragon/include/mach/dram.h | 12 - arch/arm/mach-snapdragon/init_sdm845.c | 73 - arch/arm/mach-snapdragon/misc.c | 55 - arch/arm/mach-snapdragon/sysmap-apq8016.c | 31 - arch/arm/mach-snapdragon/sysmap-apq8096.c | 31 - arch/arm/mach-snapdragon/sysmap-qcs404.c | 43 - arch/arm/mach-snapdragon/sysmap-sdm845.c | 31 - board/qualcomm/dragonboard410c/Kconfig | 15 - board/qualcomm/dragonboard410c/MAINTAINERS | 1 + board/qualcomm/dragonboard410c/Makefile | 3 +- board/qualcomm/dragonboard410c/dragonboard410c.c | 31 +- .../qualcomm/dragonboard410c/misc.c | 51 +- .../mach => board/qualcomm/dragonboard410c}/misc.h | 1 + board/qualcomm/dragonboard820c/Kconfig | 15 - board/qualcomm/dragonboard820c/Makefile | 1 - board/qualcomm/dragonboard820c/dragonboard820c.c | 39 +- board/qualcomm/dragonboard820c/head.S | 33 - board/qualcomm/dragonboard820c/u-boot.lds | 111 - board/qualcomm/dragonboard845c/Kconfig | 12 - board/qualcomm/qcs404-evb/Kconfig | 15 - board/qualcomm/qcs404-evb/qcs404-evb.c | 21 +- configs/dragonboard410c_chainloaded_defconfig | 72 + configs/dragonboard410c_defconfig | 6 +- configs/dragonboard820c_defconfig | 6 +- configs/dragonboard845c_defconfig | 29 - configs/qcom_defconfig | 71 + configs/qcs404evb_defconfig | 55 - configs/starqltechn_defconfig | 41 - doc/board/qualcomm/board.rst | 119 + doc/board/qualcomm/debugging.rst | 61 + doc/board/qualcomm/index.rst | 4 +- doc/board/qualcomm/qcs404.rst | 79 - doc/board/qualcomm/sdm845.rst | 162 - doc/device-tree-bindings/mmc/msm_sdhci.txt | 25 - doc/device-tree-bindings/usb/ehci-msm.txt | 10 - drivers/clk/qcom/clock-apq8016.c | 9 +- drivers/clk/qcom/clock-apq8096.c | 7 +- drivers/mmc/msm_sdhci.c | 69 +- drivers/phy/qcom/msm8916-usbh-phy.c | 2 +- drivers/pinctrl/qcom/pinctrl-apq8016.c | 2 +- drivers/serial/Kconfig | 8 + drivers/serial/serial_msm.c | 61 +- drivers/usb/dwc3/dwc3-generic.c | 12 + drivers/usb/host/ehci-msm.c | 2 +- include/configs/dragonboard845c.h | 20 - include/configs/qcom.h | 21 + include/configs/qcs404-evb.h | 20 - include/dt-bindings/arm/coresight-cti-dt.h | 37 + include/dt-bindings/clock/qcom,camcc-sdm845.h | 116 + include/dt-bindings/clock/qcom,dispcc-sdm845.h | 56 + include/dt-bindings/clock/qcom,gcc-msm8916.h | 179 + include/dt-bindings/clock/qcom,gcc-msm8996.h | 360 ++ include/dt-bindings/clock/qcom,gcc-qcs404.h | 4 + include/dt-bindings/clock/qcom,gpucc-sdm845.h | 24 + include/dt-bindings/clock/qcom,lpass-sdm845.h | 15 + include/dt-bindings/clock/qcom,mmcc-msm8996.h | 295 + include/dt-bindings/clock/qcom,rpmcc.h | 174 + include/dt-bindings/clock/qcom,rpmh.h | 37 + include/dt-bindings/clock/qcom,turingcc-qcs404.h | 15 + include/dt-bindings/clock/qcom,videocc-sdm845.h | 35 + include/dt-bindings/dma/qcom-gpi.h | 11 + include/dt-bindings/firmware/qcom,scm.h | 18 + include/dt-bindings/iio/qcom,spmi-vadc.h | 300 + include/dt-bindings/interconnect/qcom,msm8916.h | 100 + .../dt-bindings/interconnect/qcom,msm8996-cbf.h | 12 + include/dt-bindings/interconnect/qcom,msm8996.h | 163 + include/dt-bindings/interconnect/qcom,osm-l3.h | 15 + include/dt-bindings/interconnect/qcom,sdm845.h | 150 + include/dt-bindings/phy/phy-qcom-qusb2.h | 37 + include/dt-bindings/pinctrl/qcom,pmic-gpio.h | 164 + include/dt-bindings/power/qcom-rpmpd.h | 412 ++ include/dt-bindings/reset/qcom,gcc-msm8916.h | 100 + include/dt-bindings/reset/qcom,sdm845-aoss.h | 17 + include/dt-bindings/reset/qcom,sdm845-pdc.h | 22 + include/dt-bindings/soc/qcom,apr.h | 28 + include/dt-bindings/soc/qcom,rpmh-rsc.h | 14 + include/init.h | 11 + 104 files changed, 18987 insertions(+), 2063 deletions(-) --- base-commit: 516584b4d50880cb5e2361e55f8c5b4fc6c35901 // Caleb (they/them)