diff options
Diffstat (limited to 'open_issues/arm_port.mdwn')
| -rw-r--r-- | open_issues/arm_port.mdwn | 463 |
1 files changed, 425 insertions, 38 deletions
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index 26e0b770..cc33b074 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -9,57 +9,444 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Several people have expressed interested in a port of GNU/Hurd for the ARM -architecture. +An experimental AArch64 port of GNU Mach, the Hurd servers, and glibc +is underway. In late September of 2024 the Hurd developers were able +to run a minimal Hurd environment in qemu. It still needs lots of +work before we reccommend it to the casual user. +Typically when one ports the Hurd to a different CPU architecture, one +needs to first port GNU Mach. But Sergey actually did it backward. +He ported the Hurd first! He did some hacking on glibc, binutils, +GCC, and added some headers to GNU Mach. Then He was able to build +the core Hurd servers: ext2fs, proc, exec, and auth. -# IRC, freenode, #hurd, 2012-07-28 +One would think that he would need to port GNU Mach to run the +binaries, but Sergey ran a statically linked hello world executable on +GNU/Linux, under GDB, being careful to skip over and emulate syscalls +and RPCs. The glibc port has the TLS setup, hwcaps / cpu-features, +and ifuncs. Then he went and ported GNU Mach with help from Luca. +Once Sergey's glibc patches are merged, then we can start cross +compiling debian packages for aarch64-gnu. - <mcsim> Has anyone heard about porting hurd and gnu/mach to arm - architecture? - <braunr> mcsim: i think so - <braunr> mcsim: why are you asking ? - <mcsim> I found an article where author stated that he has ported hurd to - arm, but I have never met this information before. - <mcsim> He wrote ethernet driver and managed to use ping command - <mcsim> author's name is Sartakov Vasily - <braunr> well that's possible, a long time ago - <braunr> and it was probably not complete enough to be merged upstream - <braunr> like many other attempts at many other things - <mcsim> Not so long. Article is dated by June 2011. - <braunr> do you have a link ? - <mcsim> Yes, but it is in Russian. - <braunr> oh - <braunr> well i don't remember him sharing that with us - <antrik> mcsim: he did some work on porting Mach, but AIUI never got it - nearly finished - <antrik> nowadays he does L4 stuff - <antrik> was also at FOSDEM +azert on irc can run a minimal GNU Mach userspace on the Olimex A64 +OLinuXino board, which supports a max 2GB of RAM. As of September of +2024, the easiest way to develop on the AArch64 port, is with qemu. +Keep reading and you will see the guide that somes you how to +cross-build a AArch64 Hurd. +Now to some of the more technical things. -## IRC, freenode, #hurd, 2012-10-09 +- The TLS implementation is basically complete and working. We're +using `tpidr_el0` for the thread pointer (as can be seen in the listing +above), like GNU/Linux and unlike Windows (which uses x18, apparently) +and macOS (which uses `tpidrro_el0`). We're using "Variant I" layout, as +described in "ELF Handling for Thread-Local Storage", again same as +GNU/Linux, and unlike what we do on both x86 targets. This actually +ends up being simpler than what we had for x86! The other cool thing +is that we can do `msr tpidr_el0, x0` from userspace without any +gnumach involvement, so that part of the implementation is quite a bit +simpler too. - <mcsim> bootinfdsds: There was an unfinished port to arm, if you're - interested. - <tschwinge> mcsim: Has that ever been published? - <mcsim> tschwinge: I don't think so. But I have an email of that person and - I think that this could be discussed with him. +- Conversely, while on x86 it is possible to perform "cpuid" and +identify CPU features entirely in user space, on AArch64 this requires +access to some EL1-only registers. On Linux and the BSDs, the kernel +exposes info about the CPU features via `AT_HWCAP` (and more recently, +`AT_HWCAP2`) auxval entries. Moreover, Linux allows userland to read +some otherwise EL1-only registers (notably for us, `midr_el1`) by +catching the trap that results from the EL0 code trying to do that, +and emulating its effect. Also, Linux exposes `midr_el1` and +`revidr_el1` values through procfs. +- The Hurd does not use `auxval`, nor is gnumach involved in `execve` anyway. +So I thought the natural way to expose this info would be with an RPC, +and so in `mach_aarch64.defs` I have an `aarch64_get_hwcaps` routine that +returns the two hwcaps values (using the same bits as `AT_HWCAP{,2}`) and +the values of `midr_el1`/`revidr_el1`. This is hooked to `init_cpu_features` +in glibc, and used to initialize `GLRO(dl_hwcap)` / `GLRO(dl_hwcap2)` and +eventually to pick the appropriate ifunc implementations. -## IRC, freenode, #hurd, 2012-10-10 +- The page size (or rather, paging granularity) is notoriously not +necessarily 4096 on ARM, and the best practice is for userland not to +assume any specific page size and always query it dynamically. GNU +Mach will (probably) have to be built support for some specific page +size, but I've cleaned up a few places in glibc where things were +relying on a statically defined page size. - <tschwinge> mcsim: If you have a contact to the ARM porter, could you - please ask him to post what he has? - <antrik> tschwinge: we all have the "contact" -- let me remind you that he - posted his questions to the list... +- There are a number of hardware hardening features available on AArch64 +(PAC, BTI, MTE — why do people keep adding more and more workarounds, +including hardware ones, instead of rewriting software in a properly +memory-safe language...). Those are not really supported right now; all +of them would require some support form gnumach side; we'll probably +need new protection flags (`VM_PROT_BTI`, `VM_PROT_MTE`), for one thing. +We would need to come up with a design for how we want these to work +Hurd-wide. For example I imagine it's the userland that will be +generating PAC keys (and settings them for a newly exec'ed task), +since gnumach does not contain the functionality to generate random +values (nor should it); but this leaves an open question of what +should happen to the early bootstrap tasks and whether they can start +using PAC after initial startup. -## IRC, freenode, #hurd, 2012-10-17 +- Unlike on x86, I believe it is not possible to fully restore +execution context (the values of all registers, including `pc` and +`cpsr`) purely in userland; one of the reasons for that being that we +can apparently no longer do a load from memory straight into `pc`, +like it was possible in previous ARM revisions. So the way `sigreturn +()` works on Linux is of course they have it as a syscall that takes a +`struct sigcontext`, and writes it over the saved thread state, which +is similiar to `thread_set_state ()` in Mach-speak. The difference +being that `thread_set_state ()` explicitly disallows you to set the +calling thread's state, which makes it impossible to use for +implementing `sigreturn ()`. So I'm thinking we should lift that +restriction; there's no reason why `thread_set_state ()` cannot be +made to work on the calling thread; it only requires some careful +coding to make sure the return register (`%eax`/`%rax`/`x0`) is *not* +rewritten with `mach_msg_trap`'s return code, unlike normally. - <mcsim> tschwinge: Hello. The person who I wrote regarding arm port of - gnumach still hasn't answered. And I don't think that he is going to - answer. +- We need an interrupt handling framework with interupt controller + support. Jessica Clark apparently did some of this for FreeBSD. + Perhaps Jessica could give us some pointers. +But other than that, I do have an AArch64 versions of `trampoline.c` +and `intr-msg.h` (complete with `SYSCALL_EXAMINE` & +`MSG_EXAMINE`). Whether they work, we'll only learn once we have +enough of the Hurd running to have the proc server. + +MIG seems to just work (thanks to all the Flávio's work!). We are +using the `x86_64` ABI, and I have not seen any issues so far — +neither compiler errors / failed static assertions (about struct sizes +and such), nor hardware errors from misaligned accesses. + +To bootstrap gnumach someone must fix the console, set up the virtual +memory, thread states, context switches, irqs and userspace entry +points, etc. + +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 be easy. About IRQs, +probably it needs to be arch-specific anyway. + +What should the API for manipulating PAC keys look like? Perhaps it +should be another flavor of thread state, but then it is really +supposed to be per-task, not per-thread. Alternatively, we could add a +few aarch64-specific RPCs in `mach_arrch64.defs` to read and write the +PAC keys. 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 something else? +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? + +One can trivially port pfinet to AArch64. Eventually, we should fix +any remaining issues with lwip. That way we can stop spending time +maintaining pfinet, which is Linux's old abandoned networking stack. + +Developers will have a difficult time porting the in-Mach drivers +(arm64 was probably not even a thing at the time). We can perhaps +port Netdde, but we should instead get our userspace drivers from a +rumpkernel. + +Starting the kernel itself should be easy, 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. + +# Setting up a AArch64 development environment (in qemu) + +Before you follow the below guide, take a look at Flavio's +[[cross-hurd|https://github.com/flavioc/cross-hurd]] project, which +should give you some ideas about how to [[cross +build|toolchain/cross-gnu]] the AArch64 GNU Mach and the Hurd via a +GNU/Linux device. You can also read Sergey's +[[guide|https://mail.gnu.org/archive/html/bug-hurd/2023-01/msg00132.html]] +on how to cross build a X86 Hurd (but you will need a more recent +binutils and gcc). + +## Build gnumach + +Prepare the crosscompiler environment + + $ PREFIX=~/src/crosshurd-aarch64 + $ mkdir $PREFIX + $ mkdir $PREFIX/{src,include,aarch64-gnu}; ln -s ../include + $ $PREFIX/aarch64-gnu/sys-include; ln -s ../lib $PREFIX/aarch64-gnu/lib + +Compile binutils + + $ cd $PREFIX/src + $ git clone https://sourceware.org/git/binutils-gdb.git + $ mv binutils-gdb/ binutils + $ cd binutils + $ mkdir build + $ cd build + $ ../configure --disable-werror --target=aarch64-gnu --prefix=$PREFIX --with-lib-path=$PREFIX/lib + $ make + $ make install + +Verify that e.g. `$PREFIX/bin/i686-gnu-nm -v` works. + +Compile gcc + + $ cd $PREFIX/src + $ git clone https://gcc.gnu.org/git/gcc.git + $ cd gcc + $ mkdir build + $ cd build + $ ../configure --prefix=$PREFIX --target=aarch64-gnu \ + --with-lib-path=$PREFIX/lib --disable-multilib --enable-languages=c + $ make -j2 all-gcc + $ make install-gcc + +Note that at this step we're only building GCC itself, not libgcc. +We can build libgcc after we have installed glibc headers. + +Next, we want to build MIG. MIG needs Mach headers, but we can't build +GNU Mach without MIG. So what we do is we 'make' GNU Mach twice, once +to install the headers, and later on once more to actually build it. + +You might need this +[[patch|https://lists.gnu.org/archive/html/bug-hurd/2024-03/msg00110.html]]. + +Compile gnumach and install headers, Sergey branch + + cd $PREFIX/src + git clone https://git.savannah.gnu.org/git/hurd/gnumach.git + cd gnumach + git remote add bugaevc https://github.com/bugaevc/gnumach.git + git fetch bugaevc + git switch -c wip-aarch64 bugaevc/wip-aarch64 + autoreconf -i && mkdir build && cd build && CC=gcc ../configure + --prefix=$PREFIX --host=aarch64-gnu && make install-data + +Set PATH variable: + + PATH=$PATH:$PREFIX/bin + +Install mig + + $ cd $PREFIX/src + $ git clone https://git.savannah.gnu.org/git/hurd/mig.git + $ cd mig + $ autoreconf -i + $ mkdir build + $ cd build + $ ../configure --target=aarch64-gnu --prefix=$PREFIX + $ make + $ make install + +Install hurd headers + + $ cd $PREFIX/src + $ git clone https://git.savannah.gnu.org/git/hurd/hurd.git + $ cd hurd + $ git remote add bugaevc https://github.com/bugaevc/hurd.git + $ git fetch bugaevc + $ git switch -c aarch64 bugaevc/aarch64 + autoreconf -i && mkdir build && cd build + $ CC=gcc ../configure --host=aarch64-gnu --without-parted \ + --without-libcrypt--without-libbz2 --without-libz \ + --without-rump + $ make no_deps=t prefix=$PREFIX install-headers + +Install glibc headers + + $ cd $PREFIX/src + $ git clone https://sourceware.org/git/glibc.git + $ cd glibc/ + $ git remote add bugaevc https://github.com/bugaevc/glibc.git + $ git fetch bugaevc + $ git switch -c aarch64-gnu bugaevc/aarch64-gnu + $ mkdir build + $ cd build + $ ../configure --disable-mathvec --host=aarch64-gnu --prefix= \ + $ make install-headers DESTDIR=$PREFIX + $ touch $PREFIX/include/gnu/stubs.h $PREFIX/lib/libc.so + $ make csu/subdir_lib install csu/crt1.o csu/crti.o csu/crtn.o $PREFIX/lib + +Make libgcc + + $ cd $PREFIX/src + $ cd gcc/build + $ make configure-target-libgcc + $ make all-target-libgcc + $ make install-target-libgcc + +Make gnumach for real now + + $ cd $PREFIX/src + $ cd gnumach + $ rm -r build + $ mkdir build + $ cd build + $ ../configure --prefix=$PREFIX --host=aarch64-gnu + $ make + +Check booting notes in `aarch64/BOOTING`. + +Test gnumach: + + $ cd $PREFIX/src + $ cd gnumach/build + $ make tests/module-{hello,gsync,mach_host,machmsg,mach_port,syscalls,task,threads,vm,thread-state} + $ qemu-system-aarch64 -m 1G -machine virt -cpu max -kernel gnumach \ + -nographic -append "foo=bar" -device + guest-loader,kernel=tests/module-hello,bootargs="module-hello"'${host-port} + ${device-port} $(task-create) $(task-resume)',addr=0x4000 + for test in gsync hello mach_host machmsg mach_port syscalls task + threads vm; do qemu-system-aarch64 -m 1G -machine virt -cpu max + -kernel gnumach -nographic -append "foo=bar" -device + guest-loader,kernel=tests/module-$test,bootargs="module-$test + "'${host-port} ${device-port} $(task-create) + $(task-resume)',addr=0x4000; done + +## Debug gnumach: + + $ qemu-system-aarch64 -m 1G -machine virt -cpu max -kernel gnumach \ + -nographic -append "foo=bar" -device + guest-loader,kernel=tests/module-hello,bootargs="module-hello + "'${host-port} ${device-port} $(task-create) $(task-resume)',addr=0x4000 + +in another terminal (tab), run gdb, enter tar ext :1234, then p +$pc. $pc is in 0x40000000. Enter si 6 times, $pc should jump to +0x0000000040200000. symbol-file gnumach.elf -o $pc. + +## Build Das U-Boot + +Make Arm Trusted Firmware: + + $ cd $PREFIX/src + $ git clone https://github.com/ARM-software/arm-trusted-firmware.git + $ cd arm-trusted-firmware + $ export CROSS_COMPILE=aarch64-gnu- + $ export ARCH=arm64 + $ make PLAT=sun50i_a64 bl31 + +Make crust: + + $ cd $PREFIX/src + $ git clone https://github.com/crust-firmware/crust + $ cd crust + $ export CROSS_COMPILE=or1k-elf- + $ make a64-olinuxino_defconfig + $ make scp + +Download Das U-boot: + + $ cd $PREFIX/src + $ git clone https://github.com/u-boot/u-boot.git + +Make Das U-boot: + + $ cd $PREFIX/src + $ cd u-boot + $ export CROSS_COMPILE=aarch64-gnu- + $ export BL31=$PREFIX/src/arm-trusted-firmware/build/sun50i_a64/release/bl31.bin + $ export ARCH=arm64 + $ export SCP=$PREFIX/src/crust/build/scp/scp.bin + $ make distclean + $ make a64-olinuxino_defconfig + $ make all + +Install u-boot: + + # dd if=u-boot-sunxi-with-spl.bin of=/dev/[CHANGE THIS] bs=1024 seek=8 + +## Boot gnumach with Das U-boot + +### Boot from serial + +After copying dt.dtb from u-boot, gnumach and tests/module-hello from +gnumach in a local directory. Boot the system in u-boot. Then from a +serial terminal run: + + + loady 0x42000000 + <== load gnumach size:0x00069c58 + + loady 0x60000000 + <== load module-hello size:0x000779e0 + + loady 0x42200000 + <== load dt.dtb size:0x0000a018 + + fdt addr 0x42200000 + fdt resize + fdt set /chosen bootargs "foo=bar" + fdt set /chosen \#address-cells <0x2> + fdt set /chosen \#size-cells <0x2> + fdt mknod /chosen module@0x60000000 + fdt set /chosen/module@0x60000000 compatible "multiboot,kernel" "multiboot,module" + fdt set /chosen/module@0x60000000 reg <0x0 0x60000000 0x0 0x000779e0> + fdt set /chosen/module@0x60000000 bootargs "module-hello + "'${host-port} ${device-port} $(task-create) $(task-resume)' + + fdt print /chosen + + booti 0x42000000 - 0x42200000 + +Where <== load commands are terminal-emulator dependent. + +### Boot from smartcard + +Copy dt.dtb, gnumach, gnumach-tracing and all modules on the sd +card. The tracing version of gnumach is obtained by cherrypicking the +relative commit in a gnumach tree and rebuilding gnumach: + + git cherry-pick ee177f52680116538192b2c0c5d9a08e174c007f + +Create the file boot.cmd on the smartcard: + + if itest $trace != 0; then load mmc 0:1 0x42000000 gnumach-tracing; else load mmc 0:1 0x42000000 gnumach; fi + load mmc 0:1 0x60000000 $module + load mmc 0:1 0x42200000 dt.dtb + + fdt addr 0x42200000 + fdt resize + fdt set /chosen bootargs "foo=bar" + fdt set /chosen \#address-cells <0x2> + fdt set /chosen \#size-cells <0x2> + fdt mknod /chosen module@0x60000000 + fdt set /chosen/module@0x60000000 compatible "multiboot,kernel" "multiboot,module" + fdt set /chosen/module@0x60000000 reg <0x0 0x60000000 0x0 0x04000000> + fdt set /chosen/module@0x60000000 bootargs "$module "'${host-port} + ${device-port} $(task-create) $(task-resume)' + + booti 0x42000000 - 0x42200000 + +Compile it with: + + mkimage -C none -A arm -T script -d boot.cmd boot.scr + +Boot into Das u-boot, interrupt automatic booting to set the variables +before: + + trace=0 + module=module-hello + boot + +modify trace to a different number to start the version of gnumach +compiled with tracing. # IRC, freenode, #hurd, 2012-11-15 |