[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: aarch64-gnu (and Happy New Year!)

From: Luca
Subject: Re: aarch64-gnu (and Happy New Year!)
Date: Mon, 1 Jan 2024 20:21:25 +0100

Il 01/01/24 14:51, Sergey Bugaev ha scritto:
On Mon, Jan 1, 2024 at 4:02 PM Luca <luca@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.

Good to hear! so if I understand it correctly you tested it on aarch64 GNU/Linux?

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.

Starting the kernel itself will probably not a problem, thanks to GRUB, but it shouldn't be too hard to add support for U-Boot either if needed.

I think more issues might come out setting up the various pieces of the system. For example, some chips have heterogeneous cores, (e.g.mine has two A72 cores and four A53 cores) so SMP will be more complicated.

Also, about the serial console, it might be useful at some point to use a driver from userspace, if we can reuse some drivers from netbsd or linux, to avoid embedding all of them in 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?)

You can emulate aarch64 from an amd64 machine, but it's not very efficient. Also, I would realay like to run GNU/Hurd natively :)

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

sure, but I'll have to get a bit more familiar with the aarch64 details first.

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.

AFAIK there are no I/O ports in ARM, the usual way to configure things is with memory-mapped registers, so this might become even easier. About IRQs, probably it needs to be arch-specific anyway.

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?

Do you mean Pointer Authentication Code? That seems quite a new feature, so maybe not fundamental to have a first working kernel, but anyway I don't see issues in having arch-specific data in tasks.

What are the debugging facilities available on ARM / AArch64? Should
we expose them as more flavors of thread state, or...? What would GDB

For gnumach, it might be easier to debug on real hw than x86 if we can use openocd as gdbserver (but JTAG lines are not always reachable).

For user space tasks I don't know.

Should gnumach accept tagged addresses (like PR_SET_TAGGED_ADDR_CTRL on Linux)?

It could, but also it doesn't seem mandatory, so I would start without it.

Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on AArch64?

I think nowadays LKL would be a better target, unless there are drivers in netdde used also on aarch64. however AFAIK LKL doesn't support aarch64, and it's not yet upstream, so I'd look at rump for drivers first.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]