-
Notifications
You must be signed in to change notification settings - Fork 143
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
base: trunk
Are you sure you want to change the base?
Conversation
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>
630735d
to
a2fe684
Compare
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 |
Thanks for the feedback. I have tried this kernel1 with EDK2 in qemu-system-aarch64, it boots when ACPI is set to off (with What kernel are you trying to boot? A binary file together with the |
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.
The kernel I'm testing with boots fine without adding |
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. |
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. |
There was a problem hiding this 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>
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. |
We could probably factor out loading the DTB from file and getting it via |
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.