On Sun, May 24, 2026 at 6:59 PM Paulo Fernando Barbosa Duarte <[email protected]> wrote: > I confess I got a bit lost that one at first, and I ended up getting the wrong > Reasoning, I thought at first the ramdisk was used to store the DTB.
So for what it's worth, I did have a plan for exposing the DTB to userland in a somewhat similar way. We'd have a Mach device named "dtb" (and perhaps a Hurd devnode at /dev/dtb) that you would be able to map (via device_map) to get read-only access to the same DTB memory region. Then userspace device drivers could read it to learn about the system's configuration. We could even have a dtbfs translator that would expose the device tree as a filesystem tree. > > Did you get GNU/Hurd on AArch64 to run without ramdisk, by using some > > other form of storage, somehow? > > > I didn’t get even close yet, long roadmap to get there. > > > For what it's worth, I did not like ramdisk's specifics, because it > > copies out data to the kmalloc heap, which is limited in size, and > > IIRC the data stays on there forever, even once the system no longer > > needs it. My idea was a different way that Mach could expose this, VM > > objects [1]. The userland would then use libstore's vmobj backend, > > instead of its device backend, and the memory would be properly freed > > once the port reference is deallocated. > > > > [1]: https://lists.gnu.org/r/bug-hurd/2023-08/msg00097.html > > > I will look into memory mapping an uncompressed CPIO just to get > the core startup userland and their RPC params, boot_script > this may cleanup the process a little bit, but have to experiment > first. My advice would be, stop focusing on cpio so hard -- it's not standard on AArch64 in any way, it's just the format used by Linux (on all architectures). Try to get things booting with multiboot,module and Mach bootscripts. The Mach/Hurd bootstrap process could use a revamp, but that's a wholly separate task and it's not AArch64-specific, nor about cpio. Have you seen and/or built the wip-aarch64 glibc tree? Then once you can reproduce what I had working (Hurd server bootstrap, basic Unix, signals), focus on various interrupt and driver things. At least get the PL011 driver that I had into a good shape, and hook it up to Mach's console device, so you can actually get an interactive shell. I got stuck in all the chario/tty layers that gnumach has (apparently inherited from the BSD), but maybe you can power through it. Sergey
