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?! > > 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. > > 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. 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. Regards, Simon
