IRC channel logs

<damo22>how does the efi system pass on the memory map to gnumach if there is no e820?

<damo22>or maybe there is

<damo22>do you have an early gnumach log

<rrq>well; I'm not exatly sure about that. It's down to the difference(s) between legacy boot and UEFI boot.

<rrq>no serial output at all (and no graphics)

<damo22>oh man

<damo22>what kind of device is this

<rrq>Qemu

<rrq>with ovmf 4M Tianocore

<rrq>I'm targeting a Surface Go

<damo22>yeah maybe the serial port is accessed differently in uefi?

<rrq>yes I'm not sure about that difference; legacy vs UEFI ... especially whether a booted kernel needs to access hardware differently

<damo22>PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x1)/Uart(115200,8,N,1)

<damo22> https://github.com/ibygrave/uefi-rs-serial/blob/main/src/main.rs

<rrq>yes the UEFI boote equipment is certainly different, but does that transfer into the booted software?

<damo22>yes you need efi drivers to drive hardware

<rrq>hmm I thought the booted kernel already had code to drive the hardware at bus level (?)

<rrq>it's different for the boot equipment which is programmed against the UEFI spec

<rrq>but the kernel gains full control of the machine.. so I thought

<damo22>uefi abstracts parts of the machine to other api

<rrq>isn't that just for the boot equipment?

<damo22>so whatever drives the hardware via efi needs an efi driver for that hardware

<damo22>maybe gnumach is supposed to have this

<damo22>im not sure

<rrq>hmm when the UEFI boot calls to the loaded kernel, all it's drivers have normlly been unloaded, but a memory mapping is set up

<rrq>well, I'm also guessing a bit :)

<rrq>I had hoped gnumach implementes had dealt with it

<damo22>nobody tried booting gnumach via uefi

<rrq>ok. now I have done that at least :)

<rrq>it will be rather important for amd64 version.. at least for some 10-20 years to come

<damo22>yep

<rrq>so I'll check in this as a branch in my repo (https://git.rrq.au/rrq/prep-hurd-image.git) and start pursuing the alternative.. to get Legacy boot happening on my Surface Go.

<azert>I don’t think we need new UART drivers for UEFI

<azert>depends on the chip of course but most should be compatible

<azert>what I think is the issue is the cpu initialization that is very different

<azert>UEFI boots directly in protected mose

<azert>mode

<azert>I don’t think GRUB switch nack

<azert>to real mode

<rrq>I don't know enough to deal with that level, but does it mean taht gnumach should have some preamble to (optionally) deal with this?

<rrq>multiboot only loads the images and then jumps to the primary

<azert>I’m not sure

<rrq>(I'm using syslinux btw, but it follows grub on multiboot)

<rrq>(except that it doesn;t handle single-quotes)

<rrq>(i.e. the module arguments are handled slightly different)

<rrq>I scripted the disk image preparation and qemu run for exploring uefi booting, but I don't know enough about x86_64 cpu generally or uefi vs legacy boot or gnumach architecture and design, to explore it usefully

<rrq>especially if it'll involve some more fundamental parts

<damo22>if grub-efi has multiboot support, that should be enough

<damo22>sending SIPI to APs will force them to restart in real mode

<nexussfan>I wonder if hurd works with csmwrap

<damo22>but the graphics console is strange in efi

<damo22>it usually has a GOP driver that configures the display

<damo22>im not sure if multiboot gfx info aligns with the resolution the efi provides

<damo22>or how to do that

<rrq>do you know how to prime a disk image file with grub-efi? a doc pointer would be ideal :)

<rrq>(and even priming for legacy boot I would need help with)

<damo22>grub-efi needs a separate fat16 partition

<damo22>you just set the boot flag and part type = 0xef then put the grub.efi binary into /EFI/BOOT/BOOTX64.EFI

<damo22>thats it

<rrq>eh? and it needs some config file as well I guess?

<damo22>yeah but you can load that at runtime

<rrq>??

<damo22>just that will drop you to a grub> shell

<damo22>you can probably build the efi binary with a config built in

<rrq>everything needed masut be on either the fat partition or in the ext2

<damo22>yes

<rrq>I don't know what that is, that is needed...

<damo22>module commands

<rrq>right; efi modules? or ext2 modules?

<damo22>and static elf binaries for the bootstrap services

<rrq>are you reading a doc? ... yes, hurds modules are required of course

<rrq>I wonder about grub. I thought there would be some utility to help populating the disk image file

<rrq>I can look in a running snapshot, but that's legacy boot setup (which has same

<rrq>same grub conf I guess

<rrq>more or less(?)

<damo22> https://paste.debian.net/plainh/0badd487

<damo22>the doc in my head

<rrq>yes that's the easy bit.. I used that for the syslinux mboot already

<rrq>does grub.efi load from ext2?

<damo22>no

<damo22>the UEFI spec says it has to load from a FAT something partition

<damo22>the firmware actually looks for FAT

<rrq>yes, I meant what the boot loader (grub.efi) itself does

<damo22>once youre in grub, you can load anything

<rrq>right; so grub.efi does load from ext2 .. (syslinux.efi doesn't)

<damo22>the hard part is what i already told you above

<damo22>setting up the FAT partition

<damo22>yes

<rrq>ok; we see different hard parts :)

<rrq>is there any doc of grub.efi ... guess I can search

<damo22>man grub-mkstandalone

<rrq>hmm which debian package contains grub.efi

<rrq>(I'm fussy :)

<damo22>--format=x86_64-efi

<damo22>the problem is if you install grub-efi it will try to install that to your system

<damo22>i think

<rrq>hmm that creates a disk image file

<damo22>or maybe its grub-mkimage

<rrq>I have a disk image file with a fat and an ext2 that I want to prime

<rrq>a bit roundabout, but I guess I can use that and the cherry-pick from it

<damo22>grub-efi-amd64-bin

<damo22>that will give you the modules

<damo22>but not install to your disk

<rrq>right; that's modules, but not the bootloader itself (?)

<rrq>you called it grub.efi before but I can't find an debian package with that file

<damo22>grub-mkimage --format=x86_64-efi -p /boot/grub /usr/lib/grub/x86_64-efi/*.mod > BOOTX64.EFI

<rrq>no no no... the bootloader is a program

<rrq>the modules would reside beside the bootloader

<damo22>grub-mkimage builds a static PE32+ executable for EFI

<damo22>including all the modules

<damo22>demo@zamhurd64:~$ file BOOTX64.EFI

<damo22>BOOTX64.EFI: PE32+ executable for EFI (application), x86-64 (stripped to external PDB), 4 sections

<rrq>thanks. I need to rush off, but you've given me enough pointers I think. thanks.

<damo22>no worries

<azeem>This perl code (basically IO::Socket::UNIX->new(Type=>SOCK_STREAM(), Peer=>$path); following by send()) works fine on Linux but fails with "Cannot determine peer address" on the Hurd: https://paste.debian.net/hidden/c64a1389 is that a known issue?

<youpi>yes, unix sockets don't really have a name

<youpi>we could record what was used to connect, it's todo

<azeem>I'm surprised the Perl testsuite doesn't fail on that, ok

<azeem>(it's also what fails in https://buildd.debian.org/status/fetch.php?pkg=postgresql-18&arch=hurd-amd64&ver=18.2-1&stamp=1770913648&raw=0 but test suite failures are ignored on the hurd for Postgres)

<azeem>.~

<mightysands>I read somewhere that one can write device drivers in any programming language they want on The Hurd, even a Lisp, because the drivers can operate in User Space, as opposed to Kernel Space, but it's hard to track down definitive info regarding this. Anyone here have a link handy or a friendly explanation relating to this ?

<mightysands>Was just wondering if there were any drivers written in a Lisp language whose source code I could read

<youpi>mightysands: for lisp, there is the clisp branch on the incubator repository http://git.savannah.gnu.org/git/hurd/incubator.git/

<youpi>there are apparently a few examples

<mightysands>Thanks, I'll take a look

<mightysands>I've been meaning to get into reverse engineering/ writing device drivers, and I thought it'd be fun to teach myself Lisp at the same time while reading up on The Hurd

<mightysands>Probably nothing will come of it, but I imagine the pursuit will be fun

<mightysands>My internet cut out for a bit. If anyone replied to me since my last message, could they please resend it ? If not, nws

<rrq>damo22: got grub-efi booting happening; (checked in the 03 preparation script) same result that it crashes after start.

IRC channel logs

2026-02-13.log