Hi Mark, On Thu, 26 Aug 2021 at 14:27, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > From: Simon Glass <s...@chromium.org> > > Date: Thu, 26 Aug 2021 14:00:12 -0600 > > > > Hi Mark, > > > > On Thu, 26 Aug 2021 at 06:55, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > > > From: Simon Glass <s...@chromium.org> > > > > Date: Wed, 25 Aug 2021 21:15:00 -0600 > > > > > > > > Hi Heinrich, > > > > > > > > On Wed, 25 Aug 2021 at 02:05, Heinrich Schuchardt <xypron.g...@gmx.de> > > > > wrote: > > > > > > > > > > Hello Simon, > > > > > > > > > > some boards like qemu-riscv64_defconfig do not use any device-tree at > > > > > build time. A device-tree is only supplied at runtime by the prior > > > > > boot > > > > > stage (CONFIG_OF_PRIOR_STAGE=y). > > > > > > > > > > In doc/develop/devicetree/intro.rst you suggest to put binary blobs > > > > > into > > > > > the device-tree. > > > > > > > > > > Could you, please, update the documentation to explain how adding > > > > > blobs > > > > > to the device-tree works in the different scenarios depending on the > > > > > values of: > > > > > > > > > > CONFIG_OF_EMBED > > > > > CONFIG_OF_SEPARATE > > > > > CONFIG_OF_BOARD > > > > > CONFIG_OF_HOSTFILE > > > > > CONFIG_OF_PRIOR_STAGE > > > > > > > > > > It would be especially important to understand how one can develop a > > > > > board independent feature which works for all of these settings. > > > > > > > > OK I will take a crack at this tomorrow. > > > > > > > > But I think there is a disconnect here, since the only options that > > > > matter within U-Boot are OF_SEPARATE and OF_HOSTFILE, which both use a > > > > u-boot.dtb file. There is nothing tricky here. > > > > > > > > The OF_BOARD business is for when the board does special things. > > > > Presumably signing will do special things too. We cannot really know > > > > what those things are because the board as 'opted out' of the standard > > > > options. > > > > > > > > > > > > > > Please, describe CONFIG_OF_PRIOR_STAGE in > > > > > doc/develop/devicetree/control.rst. > > > > > > > > So I'm not allowed to delete that option? :-) It seems to me to be > > > > extremely sparse on documentation. We need an explanation of what it > > > > means and what effect it has on the build system, U-Boot and some > > > > discussion of how qemu works. It seems to have been added as part of > > > > an unrelated broadcom commit. The tags were incorrect so I doubt > > > > anyone noticed it. Since then it has apparently proved useful > > > > elsewhere, but no one has added more docs. > > > > > > > > So perhaps you can help me with my doc by explaining how > > > > OF_PRIOR_STAGE works in qmeu, why the DT in U-Boot cannot be used, and > > > > which project actually hosts the DT that qemu provides? Armed with > > > > that information, I might be able to make sense of it all. > > > > > > Well, QEMU allows configuration of (emulated/paravirtualised) devices > > > from the command line. So it is pretty much impossible for U-Boot to > > > provide a DT that matches that configuration without adding a lot of > > > code the dynamically build it from some sort of configuration > > > specification provided by QEMU to U-Boot. But at that point QEMU > > > might as well provide the DT itself, don't you agree? > > > > Don't these devices have a DT in U-Boot? Is qemu enabling them (status > > = "okay") or actually inventing them?! > > I actually invents them. See the mail I just sent for a reference to > the code.
OK I see. > > > > Anyway, replying to this thread since for the Apple M1 support that > > > I'm working on we're in a somewhat similar situation. The Asahi Linux > > > project has implemented m1n1 as a bootloader and plans to use U-Boot > > > as a "payload" to implement booting a standard Linux distribution (and > > > other OSes). In this scenario m1n1 actually provides the DT since it > > > parses Apple's version of the DT (which isn't in the standard DT > > > format) and adds/updates certain properties that depend on the actual > > > hardware it is running on. > > > > Yes I see. Still I'd like a basic DT in U-Boot, even if just for > > discoverability. > > Discoverability of what? Devices that are available / used on the board. > > > > For this code I use CONFIG_OF_BOARD and implement > > > board_fdt_blob_setup() to simple return a pointer to the DT that m1n1 > > > set up. But that seems to be exactly what CONFIG_OF_PRIOR_STAGE > > > does... > > > > Right, and neither is really documented to the level that people can > > understand the purpose. They just come across as hacks to me. > > Well, I think U-Boot by its very nature is a giant hack ;). I'm not even sure where to go with that one... > > > I'd like to see an API for passing a info (including DT) to U-Boot. I > > think riscv has it? I suggest we use a register that points to a > > bloblist. > > Well, having a generic API will be hard. It will depend on the > low-level firmware. On RISC-V the SBI specification defines such an > API. For the Apple M1 I just use the existing code that makes U-Boot > look like a Linux kernel and use the same API that is used to pass the > DTB to the kernel. The Raspberry Pi code does something similar. In > the end it just boils down to passing a pointer to the DT in a > specific register. Yes that's what I'm talking about. if RISC-V does it, great. Perhaps ARM can also? Regards, Simon
