starfive/vic7100: add reserved efi memory region

[mbgg]

This fixes efiboot, 0x80200000 is occupied with SYS_TEXT_BASE

Signed-off-by: Matthias Brugger mbrugger@suse.com

[mbgg]

@xypron any feedback on this approach is very much welcome. I see it more as a proof of concept of the root cause, and wonder if there is a way to add SYS_TEXT_BASE to the reserved memory region of EFI directly, so that this does not happen. Or maybe we need a different approach, as I suppose if the memory range is reserved by EFI it's not part of the kernel.

[xypron]

@mbgg It is unclear why you want to reserve memory for U-Boot. U-Boot relocates itself and in add_u_boot_and_runtime() reserves memory for the relocated code. Please, describe what issue you have observed.

[mbgg]

@mbgg It is unclear why you want to reserve memory for U-Boot. U-Boot relocates itself and in add_u_boot_and_runtime() reserves memory for the relocated code. Please, describe what issue you have observed.

Linux kernel EFI stub reserves memory for relocation in efi_relocate_kernel. It gets free memory at 0x80200000 and tries to relocate to that address which fails. You can see the crash with some debug messages in U-Boot EFI implementation here: https://paste.opensuse.org/39812051

[xypron]

What is located at 0x80200000? Is it OpenSBI?

It is preferable to add reserved regions to the device-tree. The region used by OpenSBI should be marked as no-map.

[avpatel]

Yes, OpenSBI usually runs in first 2MB of RAM unless U-Boot loads it somewhere else.

Regards, Anup

[xypron]

So the change could look like

diff --git a/arch/riscv/dts/starfive_vic7100_beagle_v.dts b/arch/riscv/dts/starfive_vic7100_beagle_v.dts
index e92a2ad7cf..dbdc2a30bf 100644
--- a/arch/riscv/dts/starfive_vic7100_beagle_v.dts
+++ b/arch/riscv/dts/starfive_vic7100_beagle_v.dts
@@ -97,6 +97,11 @@
                #size-cells = <2>;
                ranges;

+               opensbi@80000000 {
+                       no-map;
+                       reg = <0x0 0x80000000 0x0 0x200000>;
+               };
+
                linux,cma {
                        compatible = "shared-dma-pool";
                        reusable;

[avpatel]

Actually OpenSBI does add reserved memory node in the FDT before passing to next booting stage.

Even U-Boot has mechanism to pass-on reservations to Linux.

Regards, Anup

[xypron]

When booting we already see the reservation for OpenSBI in action:

[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000

[damien-lemoal]

OpenSBI is loaded at 0x80200000, no ? So this one is not for OpenSBI...

[avpatel]

The ignoring message from kernel is because PAGE_OFFSET maps RAM from 0x80200000 but actual RAM starts at 0x80000000 so first 2MB of RAM are not usable by kernel hence kernel ignores it.

Please note that kernel (RV32 as well as RV64) can be booted directly from 0x80000000 if there is nothing at start of RAM.

Regards, Anup

[xypron]

@damien-lemoal OpenSBI has FW_TEXT_START = 0x80000000. This is where OpenSBI is loaded. U-Boot is loaded at 0x80200000 from where it relocates itself to the top of RAM. You can verify this by using U-Boot's md command.

Using U-Boot's md command with an address in the range 0x80000000 - 0x8001ffff leads to a "load access fault". So this is the region that is protected for OpenSBI.

[xypron]

BeagleV # bdinfo
relocaddr   = 0x00000000fff4b000
reloc off   = 0x000000007fd4b000

U-Boot relocates itself to the end of the first 4GiB of the address space. Maybe we want to change that to the very end of the RAM.

BeagleV # efidebug memmap
Type             Start            End              Attributes
================ ================ ================ ==========
RUNTIME CODE     00000000fff4b000-00000000fff4c000 WB|RT
LOADER DATA      00000000fff4c000-0000000100000000 WB
BOOT DATA        0000000100000000-0000000280000000 WB