[PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
François Ozog
francois.ozog at linaro.org
Wed Nov 3 05:45:00 CET 2021
Hi Simon
Le mer. 3 nov. 2021 à 02:21, Simon Glass <sjg at chromium.org> a écrit :
> Hi François,
>
> On Wed, 27 Oct 2021 at 14:07, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le mer. 27 oct. 2021 à 20:23, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> Hi François,
> >>
> >> On Wed, 27 Oct 2021 at 09:14, François Ozog <francois.ozog at linaro.org>
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, 27 Oct 2021 at 16:08, Simon Glass <sjg at chromium.org> wrote:
> >> >>
> >> >> Hi François,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog <
> francois.ozog at linaro.org> wrote:
> >> >> >
> >> >> > Hi Simon
> >> >> >
> >> >> > Position unchanged on this series: adding fake dts for boards that
> generate their device tree in the dts directory is not good. If you have
> them in documentation the it is acceptable.
> >> >>
> >> >> I think we are going to have to disagree on this one. I actually used
> >> >> the qemu one in testing/development recently. We have to have a way
> to
> >> >> develop in-tree with U-Boot. It does not impinge on any of your use
> >> >> cases, so far as I know.
> >> >
> >> > I am not the only one in disagreement... You just saw Alex Bénée from
> Qemu saying the same thing.
> >> > I understand the advanced debug/development scenario you mention.
> >> > But locating the DT files in the dts directory is mis-leading the
> contributors to think that they need to compile the DT for the targeted
> platforms.
> >> > For your advanced scenario, you can still have the dts in the
> documentation area, or whatever directory (except dts). compile it and
> supply to U-Boot.
> >>
> >> We have this situation with rpi 1, 2 and 3 and I don't believe anyone
> >> has noticed. U-Boot handles the build automatically. If you turn off
> >> OF_BOARD, it will use the U-Boot devicetree always so you know what is
> >> going on.
> >>
> >> We can add a message to U-Boot indicating where the devicetree came
> >> from, perhaps? That might be useful given everything that is going on.
> >>
> >> As in this case, quite often in these discussions I struggle to
> >> understand what is behind the objection. Is it that your customers are
> >> demanding that devicetrees become private, secret data, not included
> >> in open-source projects? Or is it just the strange case of QEMU that
> >> is informing your thinking? I know of at least one project where the
> >> first-stage bootloader produces a devicetree and no one has the source
> >> for it. I believe TF-A was created for licensing reasons...so can you
> >> be a bit clearer about what the problem actually is?
> >
> > there are situations where U-Boot must have a dtb. Then those dTB
> sources are logically found in the dts directory.
> > There are situations where U-Boot should not have a dtb. In that case
> there should be no element in the dts directory. Otherwise it creates
> confusion.
> > Now as you point out, we need “playgrounds” to deal with some situation.
> So having examples in an ad-hoc directory, different from dts is fine. I
> proposed documentation but you may find a better place.
> > In other words, dts shall host only dt source when U-Boot cannot do but
> make a dTB for a platform.
> > As you have seen in different mail thread (firmware sustainability and
> OCP checklist) freedom is important to Linaro and there are no hidden
> Trojan horse for licensing.
>
> I don't understand what you are getting at with the Trojan horse.
I was referring to your statement that “TFA was created for licensing “
reasons. That’s not the case. It was created to address fragmentation in
the secure firmware for which there was no open source at all. SPL is
definitely not architected to be the basis of Arm secure firmware {
TFA/BL31 (secure monitor), TFA/BL32 (OP-TEE), TFA/SEL2(Hafnium), TFA/SCMI
server, SCP…}. That said SPL and TFA/BL2 have similar roles from a
10,000ft perspective.
I felt your comment was alluding to TFA was created to promote binary
components integration, which is also not the case. Hence my reference to
Trojan Horse.
> But
> you have no objection to requiring boards to supply a DT (whether in
> documentation or arch/arm/dts) to be in U-Boot?
I agree that boards need to properly document their DT. For (a) boards that
have defined their standard boot flow to assume U-Boot will only do fix ups
and overlays, the DT shall be in the U-Boot documentation part (either in
full or pointing to their project documentation), in all other cases (b) it
shall be in dts. Boards in the (a) case (may not be exhaustive): Qemu,
SystemReady, RPI (it actually assumes it boot a Linux kernel but U-Boot
smartly interposes). There may be RISCV boards that comply to EBBR too but
I let Heinrich/Atish comment.
>
>
> >
> >
> >> If a board is
> >> in-tree in U-Boot I would like it to have a devicetree there, at least
> >> until we have a better option. At the very least, it MUST be
> >> discoverable and it must be possible to undertake U-Boot development
> >> easily without a lot of messing around.
> >
> > You can if you keep two dts directories separate:
> > dts for boards for which U-Boot must have one
> > debug-dts for boards for which U-Boot get the DT at runtime but for
> which you want a playground for debug/easier development.
> >>
> >>
> >> >>
> >> >>
> >> >> But trying to do any driver / core work for a board where you don't
> >> >> have the devicetree is currently not possible. The devicetree is a
> >> >> core component and being unable to modify it is simply not practical.
> >> >> We are talking here about an option that can be enabled or disabled.
> >> >> In my case I am able to disable it locally and do my development
> work.
> >> >>
> >> >>
> >> >> BTW I've got the bloblist handoff working with a devicetree inside
> it,
> >> >> for qemu_arm. I need to try it on a real board to figure out what the
> >> >> difference is.
> >> >>
> >> > That's great news and much needed for stabilizing the inbound ABI
> from prior loader to U-Boot. Let's create another thread to discuss this
> important topic.
> >> >>
> >>
> >> My scenario is not all that advanced and I am using qemu_arm to test
> >> the bloblist handoff stuff and include it in CI, with a suitable
> >> devicetree and a binman node.
> >>
> >> Regards,
> >> Simon
> >>
> >> >> >
> >> >> > Cheers
> >> >> >
> >> >> > FF
> >> >> >
> >> >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass <sjg at chromium.org> a
> écrit :
> >> >> >>
> >> >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and
> OF_HOSTFILE so
> >> >> >> there are only three ways to obtain a devicetree:
> >> >> >>
> >> >> >> - OF_SEPARATE - the normal way, where the devicetree is built
> and
> >> >> >> appended to U-Boot
> >> >> >> - OF_EMBED - for development purposes, the devicetree is
> embedded in
> >> >> >> the ELF file (also used for EFI)
> >> >> >> - OF_BOARD - the board figures it out on its own
> >> >> >>
> >> >> >> The last one is currently set up so that no devicetree is needed
> at all
> >> >> >> in the U-Boot tree. Most boards do provide one, but some don't.
> Some
> >> >> >> don't even provide instructions on how to boot on the board.
> >> >> >>
> >> >> >> The problems with this approach are documented in another patch
> in this
> >> >> >> series: "doc: Add documentation about devicetree usage"
> >> >> >>
> >> >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE.
> Any board
> >> >> >> can obtain its devicetree at runtime, even it is has a devicetree
> built
> >> >> >> in U-Boot. This is because U-Boot may be a second-stage
> bootloader and its
> >> >> >> caller may have a better idea about the hardware available in the
> machine.
> >> >> >> This is the case with a few QEMU boards, for example.
> >> >> >>
> >> >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be
> an
> >> >> >> option, available with either OF_SEPARATE or OF_EMBED.
> >> >> >>
> >> >> >> This series makes this change, adding various missing devicetree
> files
> >> >> >> (and placeholders) to make the build work.
> >> >> >>
> >> >> >> Note: If board maintainers are able to add their own patch to add
> the
> >> >> >> files, some patches in this series can be dropped.
> >> >> >>
> >> >> >> It also provides a few qemu clean-ups discovered along the way.
> >> >> >>
> >> >> >> Note: This breaks the qemu-riscv64_spl test, which still needs
> >> >> >> investigation.
> >> >> >>
> >> >> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >> >> >>
> >> >> >> Changes in v5:
> >> >> >> - Bring into the OF_BOARD series
> >> >> >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since
> removed
> >> >> >> - Refer to the 'control' DTB in the first paragraph
> >> >> >> - Use QEMU instead of qemu
> >> >> >> - Merge RISC-V and ARM patches since they are similar
> >> >> >> - Add new patches to clean up fdtdec_setup() and surrounds
> >> >> >>
> >> >> >> Changes in v3:
> >> >> >> - Clarify the 'bug' refered to at the top
> >> >> >> - Reword 'This means that there' paragraph to explain
> U-Boot-specific things
> >> >> >> - Move to doc/develop/devicetree now that OF_CONTROL is in the
> docs
> >> >> >>
> >> >> >> Changes in v2:
> >> >> >> - Fix typos per Sean (thank you!) and a few others
> >> >> >> - Add a 'Use of U-Boot /config node' section
> >> >> >> - Drop mention of dm-verity since that actually uses the kernel
> cmdline
> >> >> >> - Explain that OF_BOARD will still work after these changes (in
> >> >> >> 'Once this bug is fixed...' paragraph)
> >> >> >> - Expand a bit on the reason why the 'Current situation' is bad
> >> >> >> - Clarify in a second place that Linux and U-Boot use the same
> devicetree
> >> >> >> in 'To be clear, while U-Boot...'
> >> >> >> - Expand on why we should have rules for other projects in
> >> >> >> 'Devicetree in another project'
> >> >> >> - Add a comment as to why devicetree in U-Boot is not 'bad design'
> >> >> >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in
> U-Boot'
> >> >> >> - Rewrite 'Devicetree generated on-the-fly in another project' to
> cover
> >> >> >> points raised on v1
> >> >> >> - Add 'Why does U-Boot have its nodes and properties?'
> >> >> >> - Add 'Why not have two devicetrees?'
> >> >> >>
> >> >> >> Ilias Apalodimas (1):
> >> >> >> sandbox: Remove OF_HOSTFILE
> >> >> >>
> >> >> >> Simon Glass (25):
> >> >> >> doc: Add documentation about devicetree usage
> >> >> >> arm: qemu: Mention -nographic in the docs
> >> >> >> arm: riscv: qemu: Explain how to extract the generated dt
> >> >> >> arm: qemu: Add a devicetree file for qemu_arm
> >> >> >> arm: qemu: Add a devicetree file for qemu_arm64
> >> >> >> riscv: qemu: Add devicetree files for qemu_riscv32/64
> >> >> >> arm: rpi: Add a devicetree file for rpi_4
> >> >> >> arm: vexpress: Add a devicetree file for juno
> >> >> >> arm: xenguest_arm64: Add a fake devicetree file
> >> >> >> arm: octeontx: Add a fake devicetree file
> >> >> >> arm: xilinx_versal_virt: Add a devicetree file
> >> >> >> arm: bcm7xxx: Add a devicetree file
> >> >> >> arm: qemu-ppce500: Add a devicetree file
> >> >> >> arm: highbank: Add a fake devicetree file
> >> >> >> fdt: Make OF_BOARD a bool option
> >> >> >> Drop CONFIG_BINMAN_STANDALONE_FDT
> >> >> >> doc: Update info on devicetree update
> >> >> >> fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
> >> >> >> fdt: Drop #ifdefs with MULTI_DTB_FIT
> >> >> >> fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
> >> >> >> fdt: Drop #ifdef around board_fdt_blob_setup()
> >> >> >> fdt: Use if() for fdtcontroladdr check
> >> >> >> fdt: Drop OF_CONTROL check in fdtdec_setup()
> >> >> >> fdt: Drop remaining preprocessor macros in fdtdec_setup()
> >> >> >> fdt: Don't call board_fdt_blob_setup() without OF_BOARD
> >> >> >>
> >> >> >> Makefile | 7 +-
> >> >> >> arch/arm/dts/Makefile | 20 +-
> >> >> >> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958
> +++++++++++++++++++++
> >> >> >> arch/arm/dts/bcm7xxx.dts | 15 +
> >> >> >> arch/arm/dts/highbank.dts | 14 +
> >> >> >> arch/arm/dts/juno-r2.dts | 1038 +++++++++++
> >> >> >> arch/arm/dts/octeontx.dts | 14 +
> >> >> >> arch/arm/dts/qemu-arm.dts | 402 +++++
> >> >> >> arch/arm/dts/qemu-arm64.dts | 381 ++++
> >> >> >> arch/arm/dts/xenguest-arm64.dts | 15 +
> >> >> >> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> >> >> >> arch/powerpc/dts/Makefile | 1 +
> >> >> >> arch/powerpc/dts/qemu-ppce500.dts | 264 +++
> >> >> >> arch/riscv/dts/Makefile | 2 +-
> >> >> >> arch/riscv/dts/qemu-virt.dts | 8 -
> >> >> >> arch/riscv/dts/qemu-virt32.dts | 217 +++
> >> >> >> arch/riscv/dts/qemu-virt64.dts | 217 +++
> >> >> >> arch/sandbox/cpu/cpu.c | 21 +-
> >> >> >> arch/sandbox/include/asm/u-boot-sandbox.h | 8 -
> >> >> >> configs/bcm7260_defconfig | 1 +
> >> >> >> configs/bcm7445_defconfig | 1 +
> >> >> >> configs/highbank_defconfig | 2 +-
> >> >> >> configs/octeontx2_95xx_defconfig | 1 +
> >> >> >> configs/octeontx2_96xx_defconfig | 1 +
> >> >> >> configs/octeontx_81xx_defconfig | 1 +
> >> >> >> configs/octeontx_83xx_defconfig | 1 +
> >> >> >> configs/qemu-ppce500_defconfig | 2 +
> >> >> >> configs/qemu-riscv32_defconfig | 1 +
> >> >> >> configs/qemu-riscv32_smode_defconfig | 1 +
> >> >> >> configs/qemu-riscv32_spl_defconfig | 4 +-
> >> >> >> configs/qemu-riscv64_defconfig | 1 +
> >> >> >> configs/qemu-riscv64_smode_defconfig | 1 +
> >> >> >> configs/qemu-riscv64_spl_defconfig | 3 +-
> >> >> >> configs/qemu_arm64_defconfig | 1 +
> >> >> >> configs/qemu_arm_defconfig | 1 +
> >> >> >> configs/rpi_4_32b_defconfig | 1 +
> >> >> >> configs/rpi_4_defconfig | 1 +
> >> >> >> configs/rpi_arm64_defconfig | 1 +
> >> >> >> configs/sandbox64_defconfig | 2 +-
> >> >> >> configs/sandbox_defconfig | 2 +-
> >> >> >> configs/sandbox_flattree_defconfig | 2 +-
> >> >> >> configs/sandbox_noinst_defconfig | 2 +-
> >> >> >> configs/sandbox_spl_defconfig | 2 +-
> >> >> >> configs/tools-only_defconfig | 2 +-
> >> >> >> configs/vexpress_aemv8a_juno_defconfig | 1 +
> >> >> >> configs/xenguest_arm64_defconfig | 1 +
> >> >> >> configs/xilinx_versal_virt_defconfig | 1 +
> >> >> >> doc/board/emulation/qemu-arm.rst | 10 +-
> >> >> >> doc/board/emulation/qemu-riscv.rst | 3 +
> >> >> >> doc/develop/devicetree/control.rst | 7 +-
> >> >> >> doc/develop/devicetree/dt_qemu.rst | 48 +
> >> >> >> doc/develop/devicetree/dt_update.rst | 498 ++++++
> >> >> >> doc/develop/devicetree/index.rst | 2 +
> >> >> >> dts/Kconfig | 37 +-
> >> >> >> include/asm-generic/global_data.h | 8 +
> >> >> >> include/fdtdec.h | 21 +-
> >> >> >> lib/fdtdec.c | 116 +-
> >> >> >> scripts/Makefile.spl | 4 +-
> >> >> >> tools/binman/binman.rst | 20 -
> >> >> >> 59 files changed, 5560 insertions(+), 164 deletions(-)
> >> >> >> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >> >> >> create mode 100644 arch/arm/dts/bcm7xxx.dts
> >> >> >> create mode 100644 arch/arm/dts/highbank.dts
> >> >> >> create mode 100644 arch/arm/dts/juno-r2.dts
> >> >> >> create mode 100644 arch/arm/dts/octeontx.dts
> >> >> >> create mode 100644 arch/arm/dts/qemu-arm.dts
> >> >> >> create mode 100644 arch/arm/dts/qemu-arm64.dts
> >> >> >> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> >> >> >> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> >> >> >> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> >> >> >> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> >> >> >> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> >> >> >> create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >> >> >> create mode 100644 doc/develop/devicetree/dt_qemu.rst
> >> >> >> create mode 100644 doc/develop/devicetree/dt_update.rst
> >> >> >>
> >> >> >> --
> >> >> >> 2.33.0.1079.g6e70778dc9-goog
> >> >> >>
> >> >> > --
> >> >> > François-Frédéric Ozog | Director Business Development
> >> >> > T: +33.67221.6485
> >> >> > francois.ozog at linaro.org | Skype: ffozog
> >> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > François-Frédéric Ozog | Director Business Development
> >> > T: +33.67221.6485
> >> > francois.ozog at linaro.org | Skype: ffozog
> >> >
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog at linaro.org | Skype: ffozog
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog
More information about the U-Boot
mailing list