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.
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.
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.
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)
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.
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
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.
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.
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.
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.
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?
