Since i didn't get any feedback, i was forced to use the force and
go to the source. I found out a few amazing things.
First of all, there is a serious inconsistency between the next
version of the Multiboot Specification and the current code. The
spec mentions: "[..] The header must start with a 32-bit magic
number 0xe85250d6 in native endian [..]'. However, there is no
such magic number defined in the source code!! No wonder i got
"error: No multiboot header found". Grub2 always checks for the
standard magic number 0x1badb002.
So, after i changed the multiboot header to the old magic number i
got over the annoying error message and stumbled onto another. The
cause of this error is this piece of code from
grub2/loader/i386/pc/multiboot.c (line 210, inside
grub_multiboot_load_elf64() ):
if (grub_file_read (file, (void *) ((grub_uint32_t) phdr->p_paddr),
phdr->p_filesz)
!= (grub_ssize_t) phdr->p_filesz)
return grub_error (GRUB_ERR_BAD_OS,
"couldn't read segment from file");
That's right, i get "error: couldn't read segment from file".
For once more i call upon the experience of the Grub2
developers. Is this a bug of grub_read_file()? The loaded elf64
file is so small that it should have no problem fitting into
physical memory. In addition to that, 'objdump -D mykernel' shows
that the kernel is loaded at address 0x400120 which is within the
usable physical RAM map.
Sorry for troubling you with all these emails, but i need to load
an elf64 kernel for an os project i'm working on.
Thanks,
Constantine
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
