On 12/09/2026 12:57, Michael Kelly wrote:
On 12/09/2026 11:34, Samuel Thibault wrote:
Yes, that's what I would hope multiboot/multiboot2 people have thought
about.
OK, thanks for the rapid response. I'll first check that multiboot2
does provide the solution expected and that it can also coexist with
multiboot. If that all goes well, then the first patchset will be
multiboot2 support.
I've completed a multiboot2 implementation. There is no issue in having
both multiboot1 and multiboot2 headers and also determining which is in
effect at boot. There are a few places throughout mach which reference
the boot data via multiboot1 structures and also mach exposes an
"mbinfo" device which is multiboot1 format. For these reasons I thought
the simplest method would be to translate the multiboot2 structure into
multiboot1 during early boot. This is all fine but I think perhaps I've
implemented some unnecessary part.
I wanted to test that the "mbinfo" was showing correctly after a
multiboot2 boot. Some of the data elements are pointers to other memory
locations but these are physical addresses. I'd imagined (without
checking) that one could use /dev/mem and mmap to read memory content at
a given physical address but this only applies to physical addresses
that are not main RAM. I've not found a method of mapping, for example,
the multiboot_raw_info.mmap_addr to check that the memory map is
correctly showing in user space. Is this possible?
Mike.
