Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

protos/linux_risc: add LoongArch support #439

Open
wants to merge 3 commits into
base: trunk
Choose a base branch
from

Conversation

ziyao233
Copy link
Contributor

This series cleans up linux_risc.c, implements EFI-table-based boot param passing and finally supports Linux boot protocol on LoongArch.

Has been tested with EDK2 firmware on qemu-emulated loongarch64 and riscv64, everything works. I'll verify on loongarch64/aarch64 real hardware when I'm available.

Thanks for your time and review.

Split architecture-dependent code and dtb-specific operations into
different functions to keep condition compilation in the leaf and
prepare for support of ACPi-only systems.

Signed-off-by: Yao Zi <ziyao@disroot.org>
@ziyao233 ziyao233 force-pushed the trunk branch 2 times, most recently from 630735d to a2fe684 Compare December 20, 2024 14:14
@qookei
Copy link
Contributor

qookei commented Dec 20, 2024

There is a regression with booting Linux on AArch64 with this PR. I haven't investigated what exactly goes wrong, but Linux panics(?) and goes into an infinite loop before it even prints anything to earlycon (but after it has set up paging and put itself in the higher half etc).

@ziyao233
Copy link
Contributor Author

There is a regression with booting Linux on AArch64 with this PR. I haven't investigated what exactly goes wrong, but Linux panics(?) and goes into an infinite loop before it even prints anything to earlycon (but after it has set up paging and put itself in the higher half etc).

Thanks for the feedback.

I have tried this kernel1 with EDK2 in qemu-system-aarch64, it boots when ACPI is set to off (with -machine virt,acpi=off). The ACPI-enabled case doesn't work even in the trunk.

What kernel are you trying to boot? A binary file together with the .config will be helpful, thanks.

@ziyao233 ziyao233 closed this Dec 20, 2024
@ziyao233 ziyao233 reopened this Dec 20, 2024
@qookei
Copy link
Contributor

qookei commented Dec 20, 2024

What kernel are you trying to boot?

I'm trying kernel 6.9.7-1-aarch64-ARCH from Arch Linux ARM (just what I had lying around from when I was working on the AArch64 Linux boot protocol support). With the following config it gets far enough to display the 4 penguins on the framebuffer, and panic because it can't mount the root partition.

/Linux Test
    protocol: linux
    kernel_path: boot():/boot/Image
    cmdline: earlycon=pl011,mmio32,0x9000000

The ACPI-enabled case doesn't work even in the trunk.

The kernel I'm testing with boots fine without adding ,acpi=off, and is actually using ACPI according to the kernel logs.

@qookei
Copy link
Contributor

qookei commented Dec 20, 2024

The kernel you have provided also works with ACPI enabled, are you perhaps using an older/newer version of QEMU? I'm testing with QEMU 8.2.3. It also doesn't boot with this PR applied for me.

@ziyao233
Copy link
Contributor Author

ziyao233 commented Dec 20, 2024

What kernel are you trying to boot?

I'm trying kernel 6.9.7-1-aarch64-ARCH from Arch Linux ARM (just what I had lying around from when I was working on the AArch64 Linux boot protocol support). With the following config it gets far enough to display the 4 penguins on the framebuffer, and panic because it can't mount the root partition.

/Linux Test
    protocol: linux
    kernel_path: boot():/boot/Image
    cmdline: earlycon=pl011,mmio32,0x9000000

The ACPI-enabled case doesn't work even in the trunk.

The kernel I'm testing with boots fine without adding ,acpi=off, and is actually using ACPI according to the kernel logs.

My bad, trunk should work. I might mess something up when doing a bisect.

Please try the new HEAD and see whether it's fixed now (it should be).

For the details: currently aarch64 relies a working dtb to pass memory mapping and EFI table. If limine doesn't get one, it was still possible to create one from scratch and fill EFI tables and memory mappings into it. My new code breaks the creation.

Copy link
Contributor

@qookei qookei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, works now, thanks for the PR! And yeah, AArch64 needs at least a dummy DTB with just the cmdline and pointers to the UEFI tables (this is what Linux's EFISTUB does internally as well). IIRC so does RISC-V, but I guess the default is no ACPI there.

Newer Linux kernel supports passing boot params without a devicetree. In
this case, the bootloader should register a Linux-specific EFI
configuration table, which contains memory mapping information or initrd
address.

This is the only option on some new platforms like LoongArch, and is
necessary to allow booting Linux kernel without a DTB on aarch64/riscv64.

Signed-off-by: Yao Zi <ziyao@disroot.org>
LoongArch kernels have more address space requirements than aarch64/
riscv64. All params (commandline, initrd, etc.) should be passed
as EFI configuration tables.

This has been tested on qemu with ACPI on. DTB support isn't tested and
isn't really matter, either. Most LoongArch devices come with an
ACPI-compatible firmware.

Signed-off-by: Yao Zi <ziyao@disroot.org>
@ziyao233
Copy link
Contributor Author

For the details: currently aarch64 relies a working dtb to pass memory mapping and EFI table. If limine doesn't get one, it was still possible to create one from scratch and fill EFI tables and memory mappings into it. My new code breaks the creation.

Now we always have a working dtb (got from VendorTable or created from scratch), so some extra checks could be removed. A new HEAD is pushed.

@qookei
Copy link
Contributor

qookei commented Dec 20, 2024

We could probably factor out loading the DTB from file and getting it via get_device_tree_blob into a helper function to avoid allocating memory for the DTB if we end up using the one from the file (like what prepare_device_tree_blob on trunk does at the start).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants