After fixing jam problems I managed to display test pattern from kernel module:
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.
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.
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.
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.
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?
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.
Hi – again, it would be easier to have these kinds of discussions on IRC.
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.
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)
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).