UEFI Haiku boot loader for ARM

After fixing jam problems I managed to display test pattern from kernel module:

haiku_loader5

Test pattern source code:

extern "C" int
_start(kernel_args *bootKernelArgs, int currentCPU)
{
	uint32* colors = (uint32*)(bootKernelArgs->frame_buffer.physical_buffer.start);
	int width = bootKernelArgs->frame_buffer.width;
	int height = bootKernelArgs->frame_buffer.height;
	int stride = bootKernelArgs->frame_buffer.bytes_per_row/4;

	for (int y = 0; y < height; y++) {
		for (int x = 0; x < width; x++) {
			colors[y*stride + x] = x%0x100 + ((y%0x100) << 8);
		}
	}

	for (;;) {}

Now some working method for debug output from kernel is needed to implement.

11 Likes

I found that in my qemu ARM EFI installation ACPI table is not provided, but FDT table (FdtTable {B1B621D5-F19C-41A5-830B-D9152C69AAE0}) is provided. Maybe support of both ACPI and DFT tables is needed.

Contents of kSystemTable->ConfigurationTable:

0: {FC1BCDB0-7D31-49AA-936A-A4600D9DD083}
1: {05AD34BA-6F02-4214-952E-4DA0398E2BB9}
2: {7739F24C-93D7-11D4-9A3A-0090273FC14D}
3: {4C19049F-4137-4DD3-9C10-8B97A83FFDFA}
4: {49152E77-1ADA-4764-B7A2-7AFEFED95E8B}
5: {A4EE0728-E5D7-4AC5-B21E-658ED857E834}
6: SMBIOS_TABLE_GUID
7: SMBIOS3_TABLE_GUID
8: {B1B621D5-F19C-41A5-830B-D9152C69AAE0}
9: {DCFA911D-26EB-469F-A220-38B7DC461220}

EFI GUID list: https://gist.github.com/justinian/071cc90052e2b0bb04ad608409a2628d.

3 Likes

Why doesn’t the existing “On-screen debug output”, already in the bootloader settings, work? This should scroll the syslog contents across the screen during the boot process. I’ve used it many times when diagnosing boot failures or other hangs without a serial port.

QEMU definitely has code for ARM ACPI: qemu/hw/arm/virt-acpi-build.c at master · qemu/qemu · GitHub

Maybe you need to use the virt machine? That should also get you a working PCI bus, so for QEMU we can ignore FDT, and just focus on getting everything working, and then add FDT for other systems later.

1 Like

X512 you are where the arm port project has been “abandoned”.
I bought an rpi4 with 4gb ram, I know it’s 64 bit system but i don’t know how UEFI works on this system? is it standard do you have to upload something extra?

At this point…
…i am confident that this thread is much better way for development and for further reference than an IRC Chat…

1 Like

Raspberry Pi don’t provide EFI compatible firmware by default, but 3-rd party implementations are available. For Raspberry Pi 4 you can extract following archive to memory card root: Releases · pftf/RPi4 · GitHub. Then you should be able to enter EFI configuration interface and EFI shell. Is should be not difficult to build Haiku loader for ARM 64, but I didn’t tried yet. Loader code is mostly CPU independent.

1 Like

Can someone tell current status of ARM kernel, what is working and what is not? Particularly I am interested in:

  1. MMU
  2. KDL stack trace
  3. Exception handling
  4. Thread switching
  5. Interrupt controller
  6. Hardware interrupts dispatching
  7. Monotonic timer (implementation of system_time())
  8. Timer interrupt
  9. Syscall handling
  10. Enter and leave user mode
  11. USB
1 Like

I use qemu-system-arm -M virt -m 1024 -bios QEMU_EFI.fd -serial stdio -net none -device usb-ehci -device ramfb -device usb-kbd -device usb-tablet -drive file=disk.img command to start Qemu. Qemu is from HaikuPorts. QEMU_EFI.fd is from Fedora package.

Output of pci command in EFI shell:

Shell> pci
   Seg  Bus  Dev  Func
   ---  ---  ---  ----
    00   00   00    00 ==> Bridge Device - Host/PCI bridge
             Vendor 1B36 Device 0008 Prog Interface 0
    00   00   01    00 ==> Serial Bus Controllers - USB
             Vendor 8086 Device 24CD Prog Interface 20
    00   00   02    00 ==> Mass Storage Controller - SCSI
             Vendor 1AF4 Device 1001 Prog Interface 0

I don’t see some important devices like system timer or interrupt controller.

Hi – again, it would be easier to have these kinds of discussions on IRC. :slight_smile:

For 32-bit ARM this is at least partially implemented. I don’t know if the userland-related MMU items are implemented, though.

This used to be implemented, but it was back in the ARMv6 days where there was a slightly different (less efficient) mechanism to do it, and maybe it does not work anymore as compiler flags have changed, I’m not sure.

I don’t know if this is implemented or not.

I don’t think these are implemented, though maybe for some older hardware, there is something.

Definitely not implemented.

Probably not implemented.

Not implemented.

The USB stack is still tied to the PCI bus, so at least on QEMU, it should in theory “just work” so long as the PCI bus does. But on bare metal where there is no PCI bus, it won’t.

1 Like

" I added 32 bit kernel support and used arch_start_kernel from https://git.haiku-os.org/haiku/tree/src/system/boot/arch/arm/arch_start_kernel.S and now it freeze after calling kernel:"

This is epic. ARM_dev still fixing ACPI/PPTT. ARMv8a/AArch64 compiles seemed successful under Haiku x86_64 awhile ago.

Didn’t build hrev53990 yet.

1 Like

What do you mean?

“What do you mean?”

The ARM ACPI developer mentioned he is bug fixing ACPI/PPTT and pushing updates upstream soon…
Firmware: 1.5+…

Who is this, exactly? I still don’t know what you are talking about.

“Who is this, exactly? I still don’t know what you are talking about”

Pete Batard - working on the Raspberry Pi 4 UEFI Firmware development.

1 Like

He is? nice, didn’t know that. Can we follow his progress some where?

Whoo whee, a lot of this happened quickly. Nice work so far @X512 ! I’d like to see whatever changes you’re making make it into review.haiku-os.org

A lot of this is on the back of all the ongoing ARM work. I’ve been working on making our EFI loader cross-architecture so we could use it for ARM platforms.

The EFI haiku_loader will work on all ARM boards which support u-boot today (including the Raspberry Pi 2,3,4). u-boot is what will be calling the haiku_loader.efi… so pretty much all of the boards rune supports today should work once the haiku_loader.efi is functional. (aka https://github.com/haiku/firmware/blob/master/manifest.json)

Essentially, with an UEFI loader, we can:

  • Boot on any ARM boards which have a built-in EFI bios (not many for arm, tons for arm64)
  • Boot directly in qemu-system-arm (which does have an EFI bios available via edk2)
  • Boot on ARM boards which are supported in u-boot upstream (Raspberry Pi, Orange Pi, Others)
4 Likes

My work depend on clang compiler, current GCC compiler can’t produce PE modules, which are used by EFI. Current hack with crt0-efi-arm.S don’t work, functions called from efi_main crashes (I posted some details on mailing list).

I heard, that compared to EDK2, u-boot have bad EFI support, I am not sure it will work. Does prebuild u-boot firmware images for Qemu available?

1 Like

Technically it’s not really a hack… it’s also how gnu-efi generates PE binaries under gcc. (Though, yeah… not sure what’s going on under gcc)

Not according to the u-boot folks :stuck_out_tongue:

I build arm u-boot binaries here:
https://github.com/haiku/firmware/tree/master/arm/qemu