Hey, On Thu, Oct 21, 2021 at 08:46:06PM +0100, Chris Plant wrote: > Hello, > > I'm continuing to play with Multiboot2 on ARM64 on a Raspberry Pi, and > I've run into something which I'm trying to understand.
Why do you use Multiboot2 on ARM64? > I have an ELF file for my kernel which has two segments (I have no idea > why rust is giving me two segments, but it is). If I boot directly > into the ELF file from the Pi firmware it boots fine, but if I boot via > GRUB I have issues with data corruption in .rodata which is in the > second segment. The first segment (.text) appears to load correctly. Could you share the output from "readelf -Wa <kernel>"? Additionally, how is your Multiboot2 header defined in the kernel? > Digging into this, the ELF headers specify a load base address of > 0x801060 for the second segment, but GRUB allocates and loads this to > 0x802000. If I change my linker to align the second segment onto > 0x1000 everything works fine. The Multiboot2 protocol does not tolerate "holes" in the image. You can find good explanation what I mean by that here [1]. > Is this alignment to 0x1000 a defined behaviour of the GRUB allocator > or Multiboot2? I'm assuming it's not a problem with the ELF file as > it's generated by usual means and runs fine otherwise. I think you should take closer look at grub-core/loader/multiboot_elfxx.c and especially lines starting from 258. It seems to me something around here overwrites part of the image in the memory. Daniel [1] https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg01003.html _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel