64 Bit Elf loader

[nekros]

Does anybody else want a general purpose pure 64 loader (with chainloading also)? I haven't seen any bootloaders like grub but are 64 bit out there? I've been thinking about making one, but is there any reason why I wouldn't want to do this?

[JohnnyTheDon]

A new bootloader would be nice. Look at some of the suggestions in this thread: http://forum.osdev.org/viewtopic.php?f=15&t=18970

[xyzzy]

Does anybody else want a general purpose pure 64 loader (with chainloading also)? I haven't seen any bootloaders like grub but are 64 bit out there? I've been thinking about making one, but is there any reason why I wouldn't want to do this?

Grub is perfectly capable of loading ELF64 files - you just need to provide the "a.out kludge" fields in your kernel's Multiboot header to tell it how to load it, and perform the switch to long mode in your kernel's entry function. Or do you mean you want a loader that puts you in long mode before entering the kernel? IMO that wouldn't be a good idea for a general purpose loader - long mode requires you to have paging enabled, which means setting up paging structures, etc, which the boot loader would have to do. Virtual address space layout is highly OS-specific, and isn't really something a loader should make assumptions about and set up.

[nekros]

Yeah, but the paging tables can always changed, just like grub sets up a gdt for you before you set one up yourself.

EDIT: Or I could support loading into any mode depending on what the user wanted.

[xenos]

Grub is perfectly capable of loading ELF64 files - you just need to provide the "a.out kludge" fields in your kernel's Multiboot header to tell it how to load it, and perform the switch to long mode in your kernel's entry function.

In principle this is true, but for using the "a.out kludge", you have to make sure that all .text and .data sections in your ELF64 kernel file are in a contiguous block, as GRUB simply loads such a block from the kernel file into memory, regardless of any sections present in the kernel file. This may fail if you have an ELF64 kernel with different sections that need to be aligned / padded by the loader when loaded into memory, since these padding overhead is not included in the kernel file. The best way to do this is by using just one section in the ELF64 file, or alternatively several sections with no padding between them in the memory image.

[xyzzy]

In principle this is true, but for using the "a.out kludge", you have to make sure that all .text and .data sections in your ELF64 kernel file are in a contiguous block

I've never found that to be an issue - it's not particularly difficult to just put the .text, .rodata and .data sections together in the linker script.

GRUB simply loads such a block from the kernel file into memory, regardless of any sections present in the kernel file. This may fail if you have an ELF64 kernel with different sections that need to be aligned / padded by the loader when loaded into memory, since these padding overhead is not included in the kernel file. The best way to do this is by using just one section in the ELF64 file, or alternatively several sections with no padding between them in the memory image.

That's simply not correct. This is my linker script: http://trac.exclaim-project.org/browser ... md64.ld.in - note there are several ALIGN statements, all of which are handled correctly when the kernel image is loaded. I think if they weren't I'd have noticed by now...

[xenos]

That's simply not correct. This is my linker script: http://trac.exclaim-project.org/browser ... md64.ld.in - note there are several ALIGN statements, all of which are handled correctly when the kernel image is loaded. I think if they weren't I'd have noticed by now...

I'm not quite sure, but I think it's because you put the ALIGN's within some sections, so the padding is included in the file and there is no additional padding that has to be done by the loader.

[Steve the Pirate]

A 64 bit elf loader would be nice, especially if it had good support for multiple filesystems and media like USB, CD, DVD, Hard drive and so on. And multiboot compliant (or as close as you can get with a 64 bit loader), module loading etc.

Basically just Grub without all the bloat - I mean, why do we need a shell in the bootloader? Why do we need it to display graphics? I think the boot loader should be almost invisible unless you press a key to bring up a simple text based chooser...

[quok]

I wasn't going to post anything just yet, but since this topic came up....

I've pretty much given up on my own OS project for a while, mostly because I was using GRUB and for many reasons, it wasn't working out for me. So I'm focusing all my efforts on a bootloader for now. Although, I'm thinking of it more as a "pre-kernel execution environment" than a bootloader. It'll be multiboot compliant, as well as implement my own boot format that I think everyone will find more useful and better laid out than multiboot. I'll post more about that later when it's finalized, but one of my major design goals with it is to be 64-bit compliant. In fact, all integer variables that represent addresses in the boot format (it's not really a "structure" in the multiboot sense) are 64-bit. It'll be able to load ELF64 binaries into a very well defined environment. For ELF32, you'll have the option of having paging enabled or disabled. I plan on doing native PE support, so there'll be no need for an "a.out kludge" for most people, and I won't support such a thing in my boot format. (If you need that, you'll have to use the multiboot format or chainload your own loader.)

I'll have decent filesystem support as well as a full multiboot implementation (however, it's not bug-for-bug compatible with GRUB; ie. modules may be loaded at a different place than GRUB loads them, and I'm doing that on purpose -- to help expose bugs in your kernel). It'll be able to set VBE modes for you as well, as well as pass all DDC/EDID information it can find, a complete device tree, etc. It's quite ambitious, and it's a mini-kernel in it's own right.

You may call it "bloated", I call it "feature rich."

And for those license snobs, the whole thing is BSD and ISC licensed.

I'll post more about it when I release the first alpha version, which I don't plan on doing until I have all the necessary multiboot bits written. At that point, it won't be a full multiboot implementation, but it'll be capable of at least doing what GRUB does, however filesystem support will likely be limited to ISO9660 (and perhaps some variant of FAT).