public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Frank Rowand <frowand.list@gmail.com>
Subject: Re: [PATCH] of: move empty_root and unittest data DTBs to .init.rodata section
Date: Tue, 27 Aug 2024 10:51:58 -0500	[thread overview]
Message-ID: <20240827155158.GA3940418-robh@kernel.org> (raw)
In-Reply-To: <20240826124802.1552738-1-masahiroy@kernel.org>

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].

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.

Rob

[1] https://lore.kernel.org/all/20240812212139.GA1797954-robh@kernel.org/


  reply	other threads:[~2024-08-27 15:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-26 12:48 [PATCH] of: move empty_root and unittest data DTBs to .init.rodata section Masahiro Yamada
2024-08-27 15:51 ` Rob Herring [this message]
2024-08-27 17:32   ` Masahiro Yamada
2024-08-27 20:57     ` Rob Herring
2024-08-31  8:49 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240827155158.GA3940418-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=saravanak@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox