On 08/10/2026 08:14, Mike Kelly wrote:
As far as I can see, the most significant issue remaining for true UEFI support is finding a solution to presenting the boot output in the case where a serial console is not available. I'm looking at the UEFI Graphics Output Protocol as a possibility.
I can't find a way of getting boot output graphically displayed early enough to be useful without embedding some code in the kernel itself. I don't think that a great deal of new code is required though if the following strategy proves successful. I think it will be essential to have an early console visible on screen as there are bound to be strange bugs that show early once Hurd is tested on UEFI hardware.
1) The frame buffer set up by UEFI is a feature of that system and should be available on all UEFI machines. I don't think therefore that worries about hardware specifics come into it and the framebuffer offered by multiboot should be good enough on all machines. There's no need to worry about performance for this application.
2) There is already some code to draw fonts via a frame buffer although it seems unused and perhaps out of step with current needs (i386/i386at/kd.c). This might some development but it is integrated into the current EGA/VGA output design to a degree anyway.
3) My biggest worry was how to get a font loaded into the kernel. I think that the multiboot module can do that and all that is needed is to strip out a special 'boot_font' module from the list as they are translated from multiboot2 to multiboot. No need to worry about file system access or embedding a font in the kernel itself. The font could be unloaded after boot when the user console takes over.
4) Some code would need to be added to parse a font. I've no knowledge on font formats but perhaps there is a suitable format that has minimal parsing requirements.
I think that would be about all that is needed to make the boot output appear as it does now.
Does this seem a reasonable approach? Cheers, Mike.
