On 16/10/2026 23:11, [email protected] wrote:
October 13, 2026 at 5:12 PM, "Michael Kelly" <[email protected]
mailto:[email protected]?to=%22Michael%20Kelly%22%20%3Cmike%40weatherwax.co.uk%3E >
wrote:
I have a working prototype with an embedded font of size 8x14 which adds an
array of 1344 bytes if the characters 32-128 have bitmaps and characters
outside this range show as '?'. It's obviously even smaller with 8x8 but it
didn't look too good although it was perfectly readable. I'm now starting to
progress it to something that can be merged.
Perhaps this is an unhelpful tip, but maybe it'll help...
I personally am a fan of OpenBSD's spleen font. Again, maybe it's not
helpful...
https://github.com/fcambus/spleen
It's possible that it could be although the font used by gnumach during
early boot is only really for presenting boot debug and so on. It gets
replaced by the font used by the Hurd console or whatever other
graphical interface is configured.
Here is a brief listing of the current issues with my UEFI development.
1) I've finally managed to get a partial boot of gnumach on my 2
hardware platforms. They are both asserting in the vm_page loading phase
suggesting there is something wrong in the page transfer from biosmem.
This is the next job on the list.
2) I spent a number of days debugging grub as both hardware platforms
were failing to boot at all. It was a bit tricky to debug having no
serial console for either but eventually I determined that neither
platform was launching gnumach at all. Debugging grub was tricky because
it has to disable the frame buffer and freeze memory allocations at a
certain point but I eventually determined that it was launching gnumach
with the wrong starting address.
I've not worked out precisely why it behaves this way but I believe the
underlying cause is that the memory for the default starting address is
actually still in use within the UEFI. Grub allocates a different memory
address but doesn't report that it has done so even though gnumach is
not relocatable. I'll return to this later but in the mean time I've
worked around it by building gnumach with '--with-_START_MAP=0x1200000'.
I'm not suggesting this is a permanent solution, but will changing this
have any other side effects that I'm not aware of?
3) There are issues mapping the frame buffer in early boot. Both
hardware platforms have an address outside that mapped by gnumach and at
this stage of the boot mapping the buffer using the interfaces available
does not work. For the moment I have simply cobbled a fixed mapping for
my purpose in the boothdr.S page table and later in the kernel page
table (pmap). Initially it is identity mapped but later I mapped it at
0xfffffffe00000000. Possibly I should have identity mapped it here too
although I don't believe that address space is in use. I emphasise that
this is just a temporary local hack to progress boot to a point where I
have a machine I can work with.
I don't think there is a problem mapping it 'properly' once the memory
management is up and running (eg. at console init) but that is too late
for debugging on my hardware. What I'd like to achieve is the capability
to present debug immediately but done properly. This would be a
comparable option to the 'immediate console'.
Mike.
