XIP boot seems to be broken for some time now. A likely reason why no one
seems to have noticed this is that XIP is more difficult to test, as it is
currently not easily testable with QEMU.
These patches fix the XIP boot and allow an XIP build without BUILTIN_DTB,
which in turn makes it easier to test an image with the QEMU virt machine.
Frederik Haxel (3):
riscv: Make XIP bootable again
riscv: Fixed wrong register in XIP_FIXUP_FLASH_OFFSET macro
riscv: Allow disabling of BUILTIN_DTB for XIP
arch/riscv/Kconfig | 6 +++---
arch/riscv/include/asm/xip_fixup.h | 2 +-
arch/riscv/kernel/head.S | 5 ++++-
arch/riscv/mm/init.c | 8 ++++++--
4 files changed, 14 insertions(+), 7 deletions(-)
--
2.34.1
Currently, the XIP kernel seems to fail to boot due to missing
XIP_FIXUP and a wrong page_offset value. A superfluous XIP_FIXUP
has also been removed.
Signed-off-by: Frederik Haxel <[email protected]>
---
arch/riscv/kernel/head.S | 1 +
arch/riscv/mm/init.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index b77397432403..a2e2f0dd3899 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -89,6 +89,7 @@ relocate_enable_mmu:
/* Compute satp for kernel page tables, but don't load it yet */
srl a2, a0, PAGE_SHIFT
la a1, satp_mode
+ XIP_FIXUP_OFFSET a1
REG_L a1, 0(a1)
or a2, a2, a1
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 2e011cbddf3a..a65937336cdc 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -174,6 +174,9 @@ void __init mem_init(void)
/* Limit the memory size via mem. */
static phys_addr_t memory_limit;
+#ifdef CONFIG_XIP_KERNEL
+#define memory_limit (*(phys_addr_t *)XIP_FIXUP(&memory_limit))
+#endif /* CONFIG_XIP_KERNEL */
static int __init early_mem(char *p)
{
@@ -952,7 +955,7 @@ static void __init create_fdt_early_page_table(uintptr_t fix_fdt_va,
* setup_vm_final installs the linear mapping. For 32-bit kernel, as the
* kernel is mapped in the linear mapping, that makes no difference.
*/
- dtb_early_va = kernel_mapping_pa_to_va(XIP_FIXUP(dtb_pa));
+ dtb_early_va = kernel_mapping_pa_to_va(dtb_pa);
#endif
dtb_early_pa = dtb_pa;
@@ -1055,9 +1058,9 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
#endif
kernel_map.virt_addr = KERNEL_LINK_ADDR + kernel_map.virt_offset;
- kernel_map.page_offset = _AC(CONFIG_PAGE_OFFSET, UL);
#ifdef CONFIG_XIP_KERNEL
+ kernel_map.page_offset = PAGE_OFFSET_L3;
kernel_map.xiprom = (uintptr_t)CONFIG_XIP_PHYS_ADDR;
kernel_map.xiprom_sz = (uintptr_t)(&_exiprom) - (uintptr_t)(&_xiprom);
@@ -1067,6 +1070,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
kernel_map.va_kernel_xip_pa_offset = kernel_map.virt_addr - kernel_map.xiprom;
#else
+ kernel_map.page_offset = _AC(CONFIG_PAGE_OFFSET, UL);
kernel_map.phys_addr = (uintptr_t)(&_start);
kernel_map.size = (uintptr_t)(&_end) - kernel_map.phys_addr;
#endif
--
2.34.1
During the refactoring, a bug was introduced in the rarly used
XIP_FIXUP_FLASH_OFFSET macro.
Fixes: bee7fbc38579 ("RISC-V CPU Idle Support")
Fixes: e7681beba992 ("RISC-V: Split out the XIP fixups into their own file")
Signed-off-by: Frederik Haxel <[email protected]>
---
arch/riscv/include/asm/xip_fixup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/xip_fixup.h b/arch/riscv/include/asm/xip_fixup.h
index d4ffc3c37649..b65bf6306f69 100644
--- a/arch/riscv/include/asm/xip_fixup.h
+++ b/arch/riscv/include/asm/xip_fixup.h
@@ -13,7 +13,7 @@
add \reg, \reg, t0
.endm
.macro XIP_FIXUP_FLASH_OFFSET reg
- la t1, __data_loc
+ la t0, __data_loc
REG_L t1, _xip_phys_offset
sub \reg, \reg, t1
add \reg, \reg, t0
--
2.34.1
On Tue, Dec 12, 2023 at 02:01:11PM +0100, Frederik Haxel wrote:
> XIP boot seems to be broken for some time now. A likely reason why no one
> seems to have noticed this is that XIP is more difficult to test, as it is
> currently not easily testable with QEMU.
>
> These patches fix the XIP boot and allow an XIP build without BUILTIN_DTB,
> which in turn makes it easier to test an image with the QEMU virt machine.
Are you actually using XIP in something other than QEMU? The fact that
some of the blamed fixes are over 18 months old suggests that you are
not actively using XIP builds of the mainline kernel.
There is a desire to remove XIP support (among other things), so if you
do actually have a use case for it, speak up.
Firstly, no html mails, they're rejected by the lists and break people's
mail flows.
On Tue, Dec 12, 2023 at 03:16:13PM +0100, Vitaly Wool wrote:
> tis 12 dec. 2023 kl. 14:23 skrev Conor Dooley <[email protected]<mailto:[email protected]>>:
> > On Tue, Dec 12, 2023 at 02:01:11PM +0100, Frederik Haxel wrote:
> > > XIP boot seems to be broken for some time now. A likely reason why no one
> > > seems to have noticed this is that XIP is more difficult to test, as it is
> > > currently not easily testable with QEMU.
> > >
> > > These patches fix the XIP boot and allow an XIP build without BUILTIN_DTB,
> > > which in turn makes it easier to test an image with the QEMU virt machine.
> >
> >
> > Are you actually using XIP in something other than QEMU? The fact that
> > some of the blamed fixes are over 18 months old suggests that you are
> > not actively using XIP builds of the mainline kernel.
> > There is a desire to remove XIP support (among other things), so if you
> > do actually have a use case for it, speak up.
>
> Yes, we surely do, on K210 for instance. It’s using an older kernel and
The k210 and nommu are on the block for removal too :)
Is your use case for either the k210 or XIP something other than
"ooh this works"?
> I haven’t checked the mainline status for a while
I figured that when the request I sent asking if you could test XIP was
ignored. We've been 50-50 on whether it has been broken since Alex put
the dtb in the fixmap ~9 months ago.
> but it is likely that I will come up with some XIP updates
> before Christmas.
May I ask what you intend updating?
Cheers,
Conor.
On Tue, 12 Dec 2023 07:14:54 PST (-0800), Conor Dooley wrote:
>
> Firstly, no html mails, they're rejected by the lists and break people's
> mail flows.
>
> On Tue, Dec 12, 2023 at 03:16:13PM +0100, Vitaly Wool wrote:
>> tis 12 dec. 2023 kl. 14:23 skrev Conor Dooley <[email protected]<mailto:[email protected]>>:
>> > On Tue, Dec 12, 2023 at 02:01:11PM +0100, Frederik Haxel wrote:
>> > > XIP boot seems to be broken for some time now. A likely reason why no one
>> > > seems to have noticed this is that XIP is more difficult to test, as it is
>> > > currently not easily testable with QEMU.
>> > >
>> > > These patches fix the XIP boot and allow an XIP build without BUILTIN_DTB,
>> > > which in turn makes it easier to test an image with the QEMU virt machine.
>> >
>> >
>> > Are you actually using XIP in something other than QEMU? The fact that
>> > some of the blamed fixes are over 18 months old suggests that you are
>> > not actively using XIP builds of the mainline kernel.
>> > There is a desire to remove XIP support (among other things), so if you
>> > do actually have a use case for it, speak up.
>>
>> Yes, we surely do, on K210 for instance. It’s using an older kernel and
>
> The k210 and nommu are on the block for removal too :)
> Is your use case for either the k210 or XIP something other than
> "ooh this works"?
Ya, if someone is actually using the XIP (and/or K210 or NOMMU) stuff
then I'm fine keeping it. We'd just figured it was probably broken
because nobody'd been posting patches and we didn't have any automated
tests. Looks like it was broken, which is always a pretty strong sign
it's not being used.
>> I haven’t checked the mainline status for a while
>
> I figured that when the request I sent asking if you could test XIP was
> ignored. We've been 50-50 on whether it has been broken since Alex put
> the dtb in the fixmap ~9 months ago.
>
>> but it is likely that I will come up with some XIP updates
>> before Christmas.
>
> May I ask what you intend updating?
>
> Cheers,
> Conor.
Hello:
This series was applied to riscv/linux.git (for-next)
by Palmer Dabbelt <[email protected]>:
On Tue, 12 Dec 2023 14:01:11 +0100 you wrote:
> XIP boot seems to be broken for some time now. A likely reason why no one
> seems to have noticed this is that XIP is more difficult to test, as it is
> currently not easily testable with QEMU.
>
> These patches fix the XIP boot and allow an XIP build without BUILTIN_DTB,
> which in turn makes it easier to test an image with the QEMU virt machine.
>
> [...]
Here is the summary with links:
- [1/3] riscv: Make XIP bootable again
https://git.kernel.org/riscv/c/66f1e6809397
- [2/3] riscv: Fixed wrong register in XIP_FIXUP_FLASH_OFFSET macro
https://git.kernel.org/riscv/c/5daa37264102
- [3/3] riscv: Allow disabling of BUILTIN_DTB for XIP
https://git.kernel.org/riscv/c/6c4a2f6329f0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html