This is a series of patches to introduce the multiboot2 boot option to the Mach kernel. These patches don't really add anything useful at the moment except to allow future work to find the ACPI information with a boot from UEFI. I've written the patches in quite small chunks to make it easier to review and easier to find any regressions. This applies particularly to the existing multiboot1 code which has been altered only slightly but we obviously want to make sure that is unaffected.
I've compiled all combinations of up, smp, dbg, pae and xen on both 32 and 64 bit. I've tested all except Xen to the point of console login and verified that the memory map and layout is the same or very similar. I don't think that I've made any changes that affect Xen but I do need to get a Xen setup to test that. To use the multiboot2 boot method, you simply change the grub.cfg file to refer to multiboot2/module2 rather than multiboot/module. I've sent this out as an RFC rather than a PATCH because there is still an outstanding issue. I hit a problem whilst testing on hurd-i386 with the boot crashing mysteriously. It took a while to get anywhere with understanding why. I can't fully explain what is going on still but it's connected to the memory addressing during early boot without paging. Patch 4 includes a call to phystovm to convert the physical address of the multiboot2 information structure into a virtual pointer. That pointer is passed up to other functions as a parameter. At least it does in the C code. The generated asm actually inlines the static functions, stores the physical address value in the frame data instead and uses that along with the phystovm offset in various 'MOV' instructions. Somewhere along the way something goes wrong and it compares physical and virtual address values for an iteration condition and loops forever. The root cause is perhaps some type cast error that I'm making in the C or similar. I can work around the problem by Patch 14 which puts the phystokv code in a different compilation unit. Doing that seems to force the compiler to accept it as a 'normal' virtual pointer and very different code is generated. Patch 14 is only for illustration of (possibly) reliable boot. The main points regarding each patch: 1) The multiboot2.h header is mostly taken from grub sources. Do I need to acknowledge that in the header itself ? I have made alterations to the header but the content is very similar. I've altered the Makefrag.am files to install the new header but I'm not sure if there is anything else to do here? 2) Allow multiboot.h to be included out of kernel. There are replicated multiboot1 definitions within hurd/console-client/fb.h which might now be possible to remove with this change. 3) I'm not too up on assembly so if I've made these changes badly then please advise. 5) The multiboot2 header is absent some tags. In particular, EFI tags to find the system table root, the frame buffer information and possibly others. I'll add these together with additional multiboot2 features. 6) There were two stages to find the ELF information. First, the data from the boot_info is capture followed later by using that data to load the symbols for the debugger. I couldn't see what advantage there was in retrieving the boot_info context as that gave the data no additional protection. See the patch description for more information. I also couldn't really see why there are 4 Elf globals maintained in model_dep.c. I wondered if they were perhaps to do with the build or debugger somehow so left them in. They don't however now exist at all in the Xen build. That's all, Mike.
