On Tue, Aug 27, 2024 at 12:32 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> On Wed, Aug 28, 2024 at 12:52 AM Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > On Mon, Aug 26, 2024 at 09:48:01PM +0900, Masahiro Yamada wrote:
> > > Some architectures can embed DTB(s) in vmlinux. Most of them expect a
> > > single DTB in the .dtb.init.rodata section.
> > >
> > > For example, RISC-V previously allowed embedding multiple DTBs in
> > > vmlinux, but only the first DTB in the .dtb.init.rodata section was
> > > used. Which DTB was used was unpredictable, as it depended on the link
> > > order (i.e., the order in Makefile).
> > >
> > > Commit 2672031b20f6 ("riscv: dts: Move BUILTIN_DTB_SOURCE to common
> > > Kconfig") changed the Makefiles to ensure only one DTB is embedded.
> > >
> > > However, commit 7b937cc243e5 ("of: Create of_root if no dtb provided by
> > > firmware") introduced another DTB into the .dtb.init.rodata section.
> > >
> > > Since then, the symbol dump (sorted by address) for ARCH=riscv
> > > nommu_k210_defconfig is as follows:
> > >
> > > 00000000801290e0 D __dtb_k210_generic_begin
> > > 00000000801290e0 D __dtb_start
> > > 000000008012b571 D __dtb_k210_generic_end
> > > 000000008012b580 D __dtb_empty_root_begin
> > > 000000008012b5c8 D __dtb_empty_root_end
> > > 000000008012b5e0 D __dtb_end
> > >
> > > The .dtb.init.rodata section now contains the following two DTB files:
> > >
> > > arch/riscv/boot/dts/canaan/k210_generic.dtb
> > > drivers/of/empty_root.dtb
> > >
> > > This is not an immediate problem because the boot code picks up the
> > > first DTB. The second one, empty_root.dtb is just ignored.
> > >
> > > However, as mentioned above, it is fragile to rely on the link order,
> > > as future Makefile changes may break the behavior.
> > >
> > > The cmd_wrap_S_dtb rule in scripts/Makefile.lib is used for embedding a
> > > DTB into the .dtb.init.rodata, so that the arch boot code can find it by
> > > the __dtb_start symbol.
> > >
> > > empty_root.dtb is looked up by its own symbol, so it does not need to
> > > be located in the .dtb.init.rodata. It can be moved to the .init.rodata
> > > section.
> > >
> > > When CONFIG_OF_UNITTEST is enabled, more unittest DTBOs are embedded in
> > > the .dtb.init.rodata section. These are also looked up by name and for
> > > generic purposes, so they can be moved to the .init.rodata section as
> > > well.
> > >
> > > I added a wrapper source file, drivers/of/empty_root_dtb.S, because this
> > > is the only wrapper used in driver/of/Makefile. I moved the rule for
> > > generating *.dtbo.S to drivers/of/unittest-data/Makefile because it is
> > > not used anywhere else.
> >
> > That is likely to change. We've had fixup overlays (fixup an old dt
> > to a new binding) added into the kernel from time to time. There were 2,
> > but they've been removed. However, I just recently suggested adding some
> > new ones[1].
>
>
> Heh, surprising.
>
> Will something like commit 841281fe52a7 come back?
Yeah, I expect the QCom DWC3 stuff is going to have N overlays for N SoCs.
> > It seems we need a named section when we access the dtb by variable
> > name and an unnamed or boot dt section for the one boot dtb.
>
>
> built-in boot dtb --> stay in .dtb.init.rodata
> (arch boot code does not know the DTB name)
>
> drivers and drivers/of/ --> can be moved to .init.rodata section
> because look-up by name is possible.
Right.
> So, do you want to keep the build rule in scripts/Makefile.lib,
> but for a different section?
Yes.
Rob
