Not very much later. This will get you to the “cannot find any boot partitions” kernel panic until you have a driver for some kind of mass storage (which may also require other drivers for PCI or USB, for example).
1 Like
Raspberry PI 3 also has an EDK 2 port too:
It may be a good idea to pick the RPi3 among the RPi models with UEFI firmware, since it is the cheapest. Its specs are certainly enough to run Haiku.
Not entirely relevant for this proposal, but a consideration for the future is that the RPi3 GPU (Broadcom VideoCore IV) is the most extensively documented and reverse-engineered among the RPi GPUs:
BCM2835 ARM Peripherals datasheet
Broadcom VideoCore IV Architecture Reference Guide
VideoCore IV reverse-engineering repo
Actually, that BCM2835 peripherals documention might be directly relevant here.
1 Like
Doesn’t UEFI abstract away some of these, allowing us to get away with generic drivers? For example, from my experience, Windows on a USB stick works out of the box on most boards with EDK 2.
UEFI abstracts a lot of things until you call ExitBootServices. After that, the OS is expected to take over most tasks.
We can keep some things, for example, once UEFI has set up a framebuffer, we can keep that working as the OS starts. But we can’t call into UEFI to change videomodes.
I don’t know if UEFI provides a “runtime mode” API to access mass storage without specific drivers, at least I have not heard of such a thing. In our case, that means we use UEFI for disk access in the boot menu up to the point where we load and start the kernel. Then the kernel is expected to take over and provide its own mass storage drivers.
3 Likes
It has. Bootstrapping now fails at grep since http://ports-space.haiku-files.org has vanished.
sys-apps::grep_bootstrap-2.14
======================================================================
The following build dependencies were found:
----------------------------------------------------------------------
sys-apps::grep_bootstrap-2.14
/home/trung/haiku/generated.arm64/../../haikuports.cross/sys-apps/grep_bootstrap/grep_bootstrap-2.14.recipe
----------------------------------------------------------------------
Downloading: http://ports-space.haiku-files.org/source/grep-2.14.tar.bz2 ...
--2024-03-05 02:28:28-- http://ports-space.haiku-files.org/source/grep-2.14.tar.bz2
Resolving ports-space.haiku-files.org (ports-space.haiku-files.org)... failed: Name or service not known.
wget: unable to resolve host address ‘ports-space.haiku-files.org’
--2024-03-05 02:28:31-- http://ports-space.haiku-files.org/source/grep-2.14.tar.bz2
Resolving ports-space.haiku-files.org (ports-space.haiku-files.org)... failed: Name or service not known.
wget: unable to resolve host address ‘ports-space.haiku-files.org’
--2024-03-05 02:28:34-- http://ports-space.haiku-files.org/source/grep-2.14.tar.bz2
Resolving ports-space.haiku-files.org (ports-space.haiku-files.org)... failed: Name or service not known.
wget: unable to resolve host address ‘ports-space.haiku-files.org’
Warning: Unable to fetch source from http://ports-space.haiku-files.org/source/grep-2.14.tar.bz2 (error: Command '['wget', '-c', '--tries=1', '--timeout=10', '--progress=dot:mega', '-O', '/home/trung/haiku/generated.arm64/../../haikuports.cross/sys-apps/grep_bootstrap/download/grep-2.14.tar.bz2', 'http://ports-space.haiku-files.org/source/grep-2.14.tar.bz2']' returned non-zero exit status 4.), trying next location.
Downloading: https://ports-mirror.haiku-os.org/grep_bootstrap/grep-2.14.tar.bz2 ...
--2024-03-05 02:28:37-- https://ports-mirror.haiku-os.org/grep_bootstrap/grep-2.14.tar.bz2
Resolving ports-mirror.haiku-os.org (ports-mirror.haiku-os.org)... failed: Name or service not known.
wget: unable to resolve host address ‘ports-mirror.haiku-os.org’
--2024-03-05 02:28:40-- https://ports-mirror.haiku-os.org/grep_bootstrap/grep-2.14.tar.bz2
Resolving ports-mirror.haiku-os.org (ports-mirror.haiku-os.org)... failed: Name or service not known.
wget: unable to resolve host address ‘ports-mirror.haiku-os.org’
--2024-03-05 02:28:44-- https://ports-mirror.haiku-os.org/grep_bootstrap/grep-2.14.tar.bz2
Resolving ports-mirror.haiku-os.org (ports-mirror.haiku-os.org)... failed: Name or service not known.
wget: unable to resolve host address ‘ports-mirror.haiku-os.org’
Warning: Unable to fetch source from https://ports-mirror.haiku-os.org/grep_bootstrap/grep-2.14.tar.bz2 (error: Command '['wget', '-c', '--tries=1', '--timeout=10', '--progress=dot:mega', '-O', '/home/trung/haiku/generated.arm64/../../haikuports.cross/sys-apps/grep_bootstrap/download/grep-2.14.tar.bz2', 'https://ports-mirror.haiku-os.org/grep_bootstrap/grep-2.14.tar.bz2']' returned non-zero exit status 4.)
Error: Failed to fetch source from all known locations.
The core libraries (including libroot) seems to build though.
I wonder if I can gather some objects and make a HyClone just for fun.
2 Likes
Hello guys… good to see some renewed interest in the ARM port. I took some time away from the forum recently… I just saw this activity in an email update.
Anyway, last time I looked at the arm64 port, it was possible to do both regular and bootstrap build and reach the rocket icon (with some minor tweaks) on qemu. I think first we should get back to the same status. Then probably get userspace working on qemu - I hope the already existing virtio drivers can be reused in the process.
I’d say any specific hardware (RPi or RK3399/3566/3588/etc) could come after that.
8 Likes
Yeah, it’s been gone for a few years now. The port mirroring script needs updated to work in s3 buckets. Local attached storage is too expensive to mirror the source code for “every port ever ported”.
The real solution is to fix the missing grep source code url in the receipe. (haikuporter tries to download from all the locations in the recipe, then falls back to ports-space as a last-resort)
1 Like
15 Likes
yep that’s where we are.
We can get to the rocket icon by cheating a little bit: you have to comment out the call to timer_interrupt() in arch_timer.cpp. This gives me the suspicion that there might be some context switch issue, i.e. some of the registers are not properly saved/restored when switching between threads, leading to the invalid memory access in inflate()
So basically that’s the next step here: find out what went wrong.
Maybe some data structures get overwritten? Or we just need to save some additional context on thread switching or in the exception handler entry/exit code.
5 Likes
Nice to see that you’ve gotten this far without much assistance. It seems that the handle_el1h_sync func is the interesting part here.
Not sure how good you know the code so I’ll just give some starting info:
We see it is setup here: haiku/src/system/kernel/arch/arm64/arch_asm.S at 35718d84c3994a9163bb85ef83e99449fd6c27f9 · haiku/haiku · GitHub and the line 165.
It calls do_sync_handler() which panics here: haiku/src/system/kernel/arch/arm64/arch_int.cpp at 35718d84c3994a9163bb85ef83e99449fd6c27f9 · haiku/haiku · GitHub
So either the page handling needs some work or interrupts corrupts things or it is just the timer interrupt that needs some more work perhaps.
Or it is something different altogether 
4 Likes
Here is some info on ESR: Documentation – Arm Developer
And here is an interesting tool: GitHub - google/aarch64-esr-decoder: A utility for decoding aarch64 ESR register values.
2 Likes
To be honest… it’s as if I’m reading a bunch of Chinese characters… Eventually I will work out the meaning, but…
Isn’t that the handler, which “cleans up” after an error has occurred like those signal handlers on the userland? It doesn’t seem to be the root cause…
Also, this time, I made it to the rocket.
Seems like the previous error happens randomly.
7 Likes
I also had some vague memories that it did not always happen consistently… however recently when I tried bootup a few times it came up each time.
There’s also another intermittent issue, a null pointer in ACPI thread, happens on some bootups with u-boot, probabaly not an issue with TianoCore.
3 Likes
Isn’t that the handler, which “cleans up” after an error has occurred like those signal handlers on the userland? It doesn’t seem to be the root cause…
It is an interrupt handler that holds the info on what happened, so it is a good starting point. The ARM developer manual I linked explains more about this in the earlier sections. See Documentation – Arm Developer (read the whole subsection, ie click next)
Since it is a sync exception it is probably not a page fault, but something else. And the ESR value will tell what it is.
With a new port, you can’t expect code to be in a completed stage, so you can’t really trust any messages just as is.
2 Likes
Timer interrupt corruption defeated me back when I was working at this two years ago.
Now when I browse the code I cannot remember whether I attempted to wire up fp register handling in interrupt handling code, but it’s obviously missing. It might be worth trying.
5 Likes
Oh, I looked at the disassembly and I noticed much bigger problem now. Branch inside exception vector slot is emitted through PLT veneer, which clobbers x16 and x17.
4 Likes
arm64: Save/restore FPU state when handling IRQ or syscall · haiku/haiku@06fae14 · GitHub
Maybe it is better to also use this FPU save/restore logic in riscv64. Are you sure that it handle all possible cases including kernel code that use FPU?
In that case, I have written a more formal proposal and posted it on this thread:
8 Likes
I did have some previously unfinished MMU code, I cleaned it up somewhat and submitted to Gerrit.
14 Likes
As from more sides - this - ARM64 port
would “attacked” again …
it could gain a more superior, sooner result !..
Kudos !
