[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6522c82-01bd-8a03-579d-a5b294784480@ghiti.fr>
Date: Sat, 27 May 2023 11:13:18 +0200
From: Alexandre Ghiti <alex@...ti.fr>
To: Conor Dooley <conor@...nel.org>,
Alexandre Ghiti <alexghiti@...osinc.com>
Cc: Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Andreas Schwab <schwab@...ux-m68k.org>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -fixes] riscv: Fix relocatable kernels with early
alternatives using -fno-pie
On 26/05/2023 18:35, Conor Dooley wrote:
> On Fri, May 26, 2023 at 05:24:41PM +0100, Conor Dooley wrote:
>> On Fri, May 26, 2023 at 05:46:30PM +0200, Alexandre Ghiti wrote:
>>> Early alternatives are called with the mmu disabled, and then should not
>>> access any global symbols through the GOT since it requires relocations,
>>> relocations that we do before but *virtually*. So only use medany code
>>> model for this early code.
>>>
>>> Signed-off-by: Alexandre Ghiti <alexghiti@...osinc.com>
>>> ---
>>>
>>> Note that I'm not very happy with this fix, I think we need to put more
>>> effort into "harmonizing" this very early code (ie before the mmu is
>>> enabled) as it is spread between different locations and compiled
>>> differently.
>> Totally & I'll happily spend the time trying to review that work.
>>
>>> I'll work on that later, but for now, this fix does what is
>>> needed to work (from my testing at least). Any Tested-by on the Unmatched
>>> and T-head boards is welcome!
>> On 6.4-rc1 & v6.4-rc1 + this patch, with CONFIG_RELOCATABLE added to my
>> config, my Nezha fails to boot. There is no output whatsoever from the
>> kernel. Turning off CONFIG_RELOCATABLE boots again.
> I don't know if this is better or worse news, but same thing happens on
> an icicle kit. What systems, other than QEMU, has the relocatable
> eries been tested with, btw?
I tested it on the Unmatched (Andreas did too).
Very weird it does not work on the icicle kit, there is no errata for
this soc, so what gets executed this early for this soc? Do you know
where it fails to boot? If you can debug, you should break on the
address of the entry point (usually 0x8020_0000) since this is the stvec
address, so when you get a trap, you will branch there, and then could
you dump $sepc, $ra and $stval when you get there?
Regarding the thead issue, I think the following should fix it:
diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
index b85e9e82f082..a9bf3f8c7cb4 100644
--- a/arch/riscv/mm/Makefile
+++ b/arch/riscv/mm/Makefile
@@ -3,6 +3,7 @@
CFLAGS_init.o := -mcmodel=medany
ifdef CONFIG_RELOCATABLE
CFLAGS_init.o += -fno-pie
+CFLAGS_dma-noncoherent.o += -fno-pie
endif
ifdef CONFIG_FTRACE
>
> Cheers,
> Conor.
>
>> I didn't test on my unmatched.
>>
>> Thanks,
>> Conor.
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Powered by blists - more mailing lists