The idea was to add some hardcoded devices there. But it would be better to use an FDT for this (we can define one for the peripherals on the Atari machines). mmu_man already agreed that this would be better. But somehow no one actually does the jobs, and hours of work are wasted in figuring out what it is and what it is supposed to do, over and over again. Just delete it so everyone can forget about it and spend their efforts on more useful things.
It is on my todo-list. I just didn’t want ARM and ARM64 to need to wait for that. Also not sure if the PR we discussed it earlier ever was finished. Anyway, I’ll clean it up so you can focus on other things.
config_manager can be useful to store fixed x86 devices (PS/2, COM/LPT ports, PCI host controller) instead of hardcoding registers in each driver.
Why? This could be done with an FDT describing the hardware, which is easier than hardcoding it in a C++ file.
2 Likes
BeOS allowed to manually configure devices with GUI that can’t be recognized automatically. Isn’t it related to config_manager?
I agree that usefulness of config_manager is low for now.
hello everyone… i promised an update on the arm64 port so here we go:
I was able to spend some time testing and integrating the patches from @milek7 and there are some promising results.
Basically I was able to reproduce the rocket icon on qemu with u-boot and TianoCore - see the screenshot below.
There are still a few reviews outstanding though.
review #4717 seems to be a critical one, to get virtio working
We can reach the rocket icon with the following combos, using the code from one or more open reviews:
u-boot + virtio-mmio detected from FDT - merged
TianoCore + virtio-mmio detected from ACPI - merged
TianoCore + virtio-pci with PCI detected from ACPI - merged
The following combo needs some additional effort:
u-boot + virtio-pci with PCI detected from FDT, I have an initial patch but interrupt handling is not there yet - under review. - merged.
This last one can also be generalized to the 32-bit ARM port with minimal effort. - merged
No entry to user space yet, as translation map creation for user mode is not implemented.
39 Likes
Did you have issues with packagefs? I had to add HAIKU_PACKAGE_COMPRESSION_LEVEL = 0 ; to my UserBuildConfig in order to boot as far as the rocket. It would page fault with the zlib-compressed packages.
3 Likes
Looks like we can almost smell ARM Tracker and Bfriends!
Great news!
2 Likes
I had some strange exceptions during startup, I was able to reach the rocket icon by commenting out the timer interrupts in src/system/kernel/arch/arm64/arch_timer.cpp.
e.g.
arch_timer_interrupt(void *data)
{
WRITE_SPECIALREG(CNTP_CTL_EL0, TIMER_MASKED);
- return timer_interrupt();
+ //return timer_interrupt();
+ return 0;
}
5 Likes
guys I look forward to it!, I can’t wait to see HAIKU running on these ARM single boards integrated in small keyboards like the raspberry pi 400 or better the new orange pi 800… 
10 Likes
I had an ARM Thinkpad X13s delivered last week.
I’d like to have a go at trying to get Haiku to boot on this thing, but not sure where to start tbh
Are there any docs besides this one, or an ARM specific forked repo I can clone and start hacking on?
3 Likes
I’d first see if you can run Linux on it. From what I’ve read, most of the ARM laptops which run Windows are locked to Windows, and I don’t see Lenovo selling an ARM Linux laptop.
Second, see if you can run Haiku ARM in a virtual machine. I don’t think Haiku on ARM is far enough along to boot your laptop, not yet at least. It’s actively in progress though!
I’m running Debian on it already.
Debian Installer for Snapdragon 8cx Gen 3 laptops - Google Docs
I’ve forked Haiku and cloned it for now. Have a lot of googling and reading to do.
6 Likes
Awesome! Keep us posted.
1 Like
The devs who are up to date with ARM development are @davidkaroly & @pengphei they get you up to speed, then you can help getting haiku to boot on ARM.
2 Likes
I’m more familiar with the 32-bit ARM port, on the 64-bit port I mostly did some testing and patch formatting based on the contributions from @milek7
In any case here are some notes on where the arm64 port was when I last looked at it
- the arm64 port is built for ARMv8.2 which should be OK for the Snapdragon but not for RasPi or PineBookPro/RockPro
- sometimes I get null pointer exception in ACPI thread during bootup, I haven’t noticed any consistent pattern when this happens
- there are some other exceptions in various points of the bootup. Disabling timer interrupt helps with this (see above) or disabling packagefs compression also helps according to @jessicah
- there was some kind of build issue with zstd, @tqh should know more details on that
Having said that, if you apply enough kludges the arm64 port is able to reach the rocket icon on qemu. We’re able to detect many things from FDT or ACPI e.g. PCI, Virtio, maybe also USB. User mode doesn’t start as most of the user mode stuff is not implemented (page table creation etc). For the time being probably it’s easier to continue hacking in qemu, then move on to real hardware once userspace works.
I was also playing around with a driver and accelerant for qemu’s ramfb device as that could simplify testing in qemu - this way we can have a framebuffer that is recognized by both the bootloader and the OS. This is more relevant for u-boot on qemu-arm/aarch64 (i don’t remember what was the situation with TianoCore)
4 Likes
Zstd is why we use ARMV8.2. It seems quite a mess on non x86, so personally I think we should avoid it. The ARM 64 code in zstd was only added for server grade ARM, and the only way to get it to compile with gcc was to enable 16 bit floating point.
Zstd might have improved since then, but to me I don’t really believe zstandard will be easy to support on non x86 platforms.
I already implemented it in haiku_loader.riscv: haiku/src/system/boot/platform/riscv/FwCfg.cpp at master · haiku/haiku · GitHub.
kernel/app_server graphics driver should be not needed if boot loader framebuffer is working.
2 Likes
the existing framebuffer driver did not work correctly for me, afaict it looks for PCI addresses related to the frame buffer which is not there in case of mmio-based fwcfg