All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.