Question about grub module loading

[nbdd0121]

I managed to let my kernel support Multiboot1. Unfortunately my kernel is 64bit, so I need to load a 32bit loader first and then handle the control to the kernel. I think I will be better to use "module" command in grub to load the kernel. However, I found that the file is loaded as a binary, and it is hard to interpret it as a ELF (The file is loaded at 0x101000, and the kernel should be at 0x100000). Can I manually determine the position where grub load the kernel or can I let grub load the elf for me?

[Combuster]

Read this yet?

[sortie]

I use a neat trick where my entire kernel is purely 64-bit, however that the assembly file containing _start (the actual kernel symbol) has a .code32 directive followed by code to switch to long-mode followed by a .code64 directive and the usual boot code. The result is a ELF64 kernel with a few 32-bit instructions in it. I then objcopy it to an ELF32 kernel that contains mostly 64-bit instructions. GRUB will happily load this, not realizing it just loaded what will become a 64-bit kernel after it has switched to long mode.

[xenos]

I use almost the same trick as sortie, but instead of converting my kernel to ELF32, I leave it as ELF64 and put an "a.out kludge" in there so that GRUB loads it with the kernel command. So there's really no need to load the kernel as a module.

[jnc100]

Personally I do something like the OP describes in his post. There is a 32-bit second stage (unpaged protected mode) loader loaded with the 'multiboot' command, and the kernel is an ELF64 object loaded with the 'module' command. The 32 bit stage has a simple ELF interpreter (this is seriously not too difficult). The thing with 64 bit kernels is that they will always run with paging enabled, so it doesn't actually matter at what physical address GRUB loads your kernel module - you can simply set up the page tables as appropriate.

Regards,
John.

[nbdd0121]

Read this yet?

Maybe I didn't describe my situation very clearly. I've read the wiki article, but the problem is that I use a design that separate kernel and loader. The loader will initialize everything, and the kernel will contains pure kernel code, without any initialization code. The memory occupied by loader than can be completely recycled and used for other purpose. Therefore, I need to load kernel as module any way.

[Combuster]

Read this yet?

Maybe I didn't describe my situation very clearly.

It was obvious that you misunderstood the situation. For instance:

so I need to load a 32bit loader first

The article mentioned explicitly that you don't need a dedicated loader - the only thing you need to do is switch to 64-bit mode which costs very few instructions. Also:

The loader will initialize everything, and the kernel will contains pure kernel code, without any initialization code

Which either means a lot of communication between "loader" and "kernel" to the point you want to have them linked into the same binary, or the setup is sufficiently small that you're overengineering this altogether. Especially when your skills are apparently primitive enough that you can't write the code to move some things around.

It's like asking how to use a screwdriver to drill a hole in wood and subsequently complaining that "you don't do it that way" does not answer the question.

Also, you can equally use the linker script to divide setup and runtime code, and then free part of the binary that's not used anymore.