On Mon, Jan 1, 2024 at 4:02 PM Luca <l...@orpolo.org> wrote: > Hi Sergey,
Hi Luca, > Really great work! To work on gnumach we just need MIG and any armv8 > compiler (also targeting GNU/Linux is fine), and it seems MIG works fine > without adjustments? Maybe there could be some issues once it's run > somewhere, e.g. alignment issues. Well, I have the aarch64-gnu toolchain here, please see the binutils & GCC patches that I posted. But yeah, any aarch64-targeting compiler should work for gnumach, including aarch64-linux-gnu or just a generic embedded aarch64 target. MIG seems to just work (thanks to all the Flávio's work!). I'm using the same message ABI as on x86_64, and haven't seen any issues so far — neither compiler errors / failed static assertions (about struct sizes and such), nor hardware errors from misaligned accesses. Once I post the preliminary gnumach patches, you should be able to build a complete binutils + GCC + MIG aarch64-gnu toolchain. > Another issue with ARM in general is that the hardware support is much > less streamlined than x86, although with v8 there should be some > alignment on basic stuff like IRQ and UEFI. So I've heard, yeah. But yeah I've also heard that newer chips support UEFI, and from UEFI it should be possible to boot GRUB and from there gnumach, so maybe the boot process is not as much of a problem as it was, and we could avoid separate per-board builds of gnumach. But as always, I have no idea what I'm talking about. > Probably even the serial > console needs a platform-specific driver (I'm not sure, I'm more > familiar with older and more embedded variants like Cortex-M) > > To bootstrap gnumach the first thing we'd need would probably be the > console, setting up the virtual memory, then thread states, context > switch, irqs and userspace entry points (list by no means exhaustive). > > I actually have an armv8 server that would be handy for some > development, so I might be able to help with something in the future. Sounds great! (But you should also be able to use qemu, no?) Even before you write any code, it would be great if you helped review my gnumach patches (e.g. aarch64_thread_state & the arm/aarch64 exceptions). Also, there is a bunch of design work to do. Will/can AArch64 use the same mechanism for letting userland handle interrupts? Do we have all the mechanisms required for userland to poke at specific addresses in memory (to replace I/O ports)? — I believe we do, but I haven't looked closely. What should the API for manipulating PAC keys look like? I kind of want it to be just another flavor of thread state, but then it is really supposed to be per-trask, not per-thread, and maybe adding some aarch64-specific RPCs to read and write the PAC keys in mach_aarch64.defs is the right way. But also AFAICS Mach currently has no notion of per-task arch-specific data (unlike for threads, and other than the VM map), so it'd be interesting to add one — could it be useful for something else? What are the debugging facilities available on ARM / AArch64? Should we expose them as more flavors of thread state, or...? What would GDB need? Should gnumach accept tagged addresses (like PR_SET_TAGGED_ADDR_CTRL on Linux)? Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on AArch64? Sergey
