- GECKOOS BOOT.ELF 64 BIT
- GECKOOS BOOT.ELF DRIVER
- GECKOOS BOOT.ELF FULL
- GECKOOS BOOT.ELF CODE
- GECKOOS BOOT.ELF PLUS
You may need to allocate the kernel's buffer with AllocatePages instead using the UEFI allocator. It will boot any ELF file that is static and freestanding and called kernel.elf at the root directory of the ESP partition of your hard-disk.
GECKOOS BOOT.ELF CODE
The code allocates a static 100k bytes of data for the kernel which might not be enough for yours. This is simply a design choice I made to simplify passing the data to my kernel at static positions in RAM. The code will place the RSDP at 0x350000 and info on the framebuffer at 0x351000. MemCpy(&NumberOfEntriesInProgramHeader, KernelBuffer + 56, 2) įor (UINTN i = 0 i BootServices->ExitBootServices(ImageHandle, 0) MemCpy(&ProgramHeaderPosition, KernelBuffer + 32, 8)
MemCpy(&EntryPoint, KernelBuffer + 24, 8) Got the kernel's file in a buffer, now map it #define EFI_ACPI_TABLE_GUID įrameBuffer* VideoPointer = (FrameBuffer*)0x351000 I asked a question on StackOverflow not long ago where I give my 圆4 UEFI bootloader code. You can find the specification for Multiboot2 here: TLDR: You'll probably end up using Multiboot2 (and GRUB). faster kernel updates), but the main reason to think about it is to refine the design of the "environment your kernel expects" (to help determine what the kernel actually wants and avoid introducing baggage from what other environments provide that aren't quite what your kernel really wanted).
This has practical benefits of its own (e.g. Note 4: For the final "environment your kernel expects" it may be worthwhile considering things like "kexec()" where a previous instance of your kernel is used to start the next instance of your kernel. maybe "BIOS -> multi-boot -> UEFI emulator -> something else -> what your kernel expects"). to "the environment your kernel expects") and these "pieces of code that change environments" can be layered (e.g. Note 3: In theory it's really about environments where "boot loader" changes from one environment (e.g. In that case you'd have to either convert your ELF into PE format or insert your ELF file "as is" inside a PE file as data (where the PE file has some code to unpack the ELF contained inside it). Note 2: For UEFI, you could just use UEFI as the "detailed specification designed by someone else" and not bother having a boot loader.
GECKOOS BOOT.ELF PLUS
It's possible to work around this by splitting "boot loader" into halves (many different "1st stages" that handle the differences, plus a common "2nd stage" that handles the similarities). Note 1: typically it's not "one boot loader", but more like a set of them (one for booting from "GPT partitioned hard disk", one for booting from network, another for booting from removable media. This is what almost every well known kernel (Windows, Linux, FreeBSD. The only choice here (that I know of) is the multi-boot specification.Ĭreate your own detailed specification designed for your OS then either write your own boot loader/s or let other people write them from your specification. "The kernel is ELF" is just a small piece of that detailed specification.įind a detailed specification designed by someone else that happens to include "the kernel is ELF" (or at least "the boot loader must support ELF"), and adopt their specification, and then put up with all of their design decisions whether they make sense for your OS or not. how kernel retrieves memory map from boot loader, which format it's in, if there's guarantees like "2 or more entries in the memory map will not describe the same/overlapping area of memory", etc) where both the boot loader (or all boot loaders) and the kernel (or all kernels) comply with the detailed specification.
GECKOOS BOOT.ELF FULL
In other words you need a full detailed specification about how any/all of these things happen (e.g. I expect my boot loaders to set up paging and map kernel at its final virtual address decompression is worth considering to improve boot times when disk IO is slow doing sanity checks to see if kernel's file has been tampered with before trusting it makes sense. Tell the kernel some kind of kernel configuration (could be another file, could be "kernel command line args").
GECKOOS BOOT.ELF DRIVER
initial RAM disk) because (even for a "modular monolithic" kernel) the kernel can't load a disk driver from disk when it hasn't loaded a disk driver from disk yet. ), likely including frame buffer details.Īlso load other files (e.g. Tell the kernel various things about the hardware ("flattened device tree" or ACPI tables or. You have an ELF kernel so you probably need a boot loader that will:
GECKOOS BOOT.ELF 64 BIT
So I need a bootloader that will load my 64 bit ELF file.
0 kommentar(er)
