How many sectors to load yhe whole kernel

[neon]

Hi,

We just load it as any other file, so the number of clusters loaded is provided from the file system. The loader loads a config file which then tells it to load a kernel. Then just load the file, relocate it, and execute it. Although the kernel is expected to be at 1MB physical it relocates itself at a later stage when paging is enabled.

[Octocontrabass]

Although the kernel is expected to be at 1MB physical it relocates itself at a later stage when paging is enabled.

Even if you're writing a BIOS bootloader, you should avoid depending on specific physical addresses like this in your kernel. UEFI doesn't guarantee any particular physical address will be available, and in the future you might want a UEFI bootloader so your OS can run on modern PCs.

[neon]

Hi,

Even if you're writing a BIOS bootloader, you should avoid depending on specific physical addresses like this in your kernel. UEFI doesn't guarantee any particular physical address will be available, and in the future you might want a UEFI bootloader so your OS can run on modern PCs.

Just clarifying as our loader is BIOS and UEFI; it can be built to target both. I would expect 1MB physical to always be available. I cannot imagine a scenario where that wouldnt be: but... I suppose if you want to be on the safe side, well.... can just introduce a region based zone allocator and map the file into an available zone. That 1MB comes from the kernel header / boot protocol information. So I suppose we can introduce logic like "if the kernel requested image base is not available, allocate it to an available zone and attempt to perform a relocation if possible. Fatal error if image format not understood."

[Octocontrabass]

I would expect 1MB physical to always be available. I cannot imagine a scenario where that wouldnt be

Why would it always be available? The "standard" PC memory map is only needed for BIOS compatibility, there's nothing about UEFI that requires available memory at 1MB.

introduce a region based zone allocator and map the file into an available zone.

You can use the allocator provided by UEFI boot services. Your allocations will even appear in the firmware's memory map. The only limitation is that you can't define your own memory types, you have to use the defaults.

So I suppose we can introduce logic like "if the kernel requested image base is not available, allocate it to an available zone and attempt to perform a relocation if possible. Fatal error if image format not understood."

I would recommend using paging to map the kernel directly to its desired virtual address.

[neon]

Hi,

At this time, we enable paging in the kernel initial startup rather then the boot loader in order to facilitate creating the PFN free stack used by the kernel (which is easiest to set up with direct access to physical memory.) It was also for compatibility with MultiBoot. However... we did originally use paging in the loader in older versions and I believe still have the code. If we were to enable paging in the loader again (which has been in consideration for some time) then we would need to adjust how we build the PFN free stack. So...paging in the loader... we'll see. It is an option that we may go back to, whenever time allows it. The firmware interfaces have a "Alloc Pages" and "Free Pages" which, for UEFI builds, does indeed call the UEFI boot services. We just have a separate firmware independent allocator to handle the low memory pool (not used in UEFI builds) and conventional memory pool (heap).

If the loader enables paging, we can certainly do what you suggested and just map them to the requested virtual address. Honestly though, for most people, this would be the way to go.