[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c6d40256460614f7aa3d8aab7c0044eb16841876.camel@gmail.com>
Date: Fri, 08 Mar 2019 23:13:55 +0200
From: Yasha Cherikovsky <yasha.che3@...il.com>
To: Paul Burton <paul.burton@...s.com>
Cc: Ralf Baechle <ralf@...ux-mips.org>,
James Hogan <jhogan@...nel.org>,
"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] MIPS: Ensure ELF appended dtb is relocated
Hi Paul,
On Fri, 2019-03-08 at 19:02 +0000, Paul Burton wrote:
> Hi Yasha,
>
> On Fri, Mar 08, 2019 at 02:58:51PM +0200, Yasha Cherikovsky wrote:
> > This fixes booting with the combination of CONFIG_RELOCATABLE=y
> > and CONFIG_MIPS_ELF_APPENDED_DTB=y.
> >
> > Sections that appear after the relocation table are not relocated
> > on system boot (except .bss, which has special handling).
> >
> > With CONFIG_MIPS_ELF_APPENDED_DTB, the dtb is part of the
> > vmlinux ELF, so it must be relocated together with everything else.
>
> Do you have any ideas how CONFIG_RELOCATABLE interacts with
> CONFIG_MIPS_RAW_APPENDED_DTB? I'm wondering whether we should move both
> variants of appended DTB to before .data.reloc, but haven't yet thought
> it through.
>
> Thanks,
> Paul
>
I booted now a image with RELOCATABLE and MIPS_RAW_APPENDED_DTB and it
works.
Behind the scenes it's complicated:
1. MIPS_RAW_APPENDED_DTB works this way (the way I understand it):
In run time, the dtb appears in memory right after the original
vmlinux.bin image (the one that "make" created).
If the dtb was concatenated to vmlinuz.bin: at run time, after vmlinuz
extracts vmlinux.bin,
it takes care of copying the dtb to the end of vmlinux.bin in memory.
If the dtb was concatenated to vmlinux.bin at build time, no run-time
work is needed.
2. Therefore, the __appended_dtb pointer in the linker script must point to
the end of the actual data in vmlinux.bin.
So we can't move it to before .data.reloc.
3. When the kernel relocates itself, it doesn't copy the appended dtb
along with the kernel.
This behavior is documented, see this code comment: [1].
Yasha
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/mips/kernel/relocate.c?h=v5.0#n339
> > Fixes: 069fd766271d ("MIPS: Reserve space for relocation table")
> > Signed-off-by: Yasha Cherikovsky <yasha.che3@...il.com>
> > Cc: Ralf Baechle <ralf@...ux-mips.org>
> > Cc: Paul Burton <paul.burton@...s.com>
> > Cc: James Hogan <jhogan@...nel.org>
> > Cc: linux-mips@...ux-mips.org
> > Cc: linux-kernel@...r.kernel.org
> > ---
> > arch/mips/kernel/vmlinux.lds.S | 12 +++++++-----
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/mips/kernel/vmlinux.lds.S
> > b/arch/mips/kernel/vmlinux.lds.S
> > index cb7e9ed7a453..33ee0d18fb0a 100644
> > --- a/arch/mips/kernel/vmlinux.lds.S
> > +++ b/arch/mips/kernel/vmlinux.lds.S
> > @@ -140,6 +140,13 @@ SECTIONS
> > PERCPU_SECTION(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> > #endif
> >
> > +#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
> > + .appended_dtb : AT(ADDR(.appended_dtb) - LOAD_OFFSET) {
> > + *(.appended_dtb)
> > + KEEP(*(.appended_dtb))
> > + }
> > +#endif
> > +
> > #ifdef CONFIG_RELOCATABLE
> > . = ALIGN(4);
> >
> > @@ -164,11 +171,6 @@ SECTIONS
> > __appended_dtb = .;
> > /* leave space for appended DTB */
> > . += 0x100000;
> > -#elif defined(CONFIG_MIPS_ELF_APPENDED_DTB)
> > - .appended_dtb : AT(ADDR(.appended_dtb) - LOAD_OFFSET) {
> > - *(.appended_dtb)
> > - KEEP(*(.appended_dtb))
> > - }
> > #endif
> > /*
> > * Align to 64K in attempt to eliminate holes before the
> > --
> > 2.21.0
> >
Powered by blists - more mailing lists