OSDev.org

I've been attempting to write a function that initializes the bitmaps that will handle my kernel's physical memory management, and except for one case (which I don't think'll come up too often) it should work correctly. However, currently, the system has one bitmap for memory under 4GB (representing 16MB-highest type 1 address) and a set of variables for bitmap ptrs, sizes (in longs), and 64bit start addresses. Each contiguous amount of memory >4GB is given it's own bitmap. All of this as far as I can tell works as the logic of the code isn't terribly difficult (or at least it's fixable if it isn't).

The case that my code does not handle is when the base is under 4GB, but the range takes the entry above 4GB.
I can probably handle this just fine with a little tweak, but I'm wondering if it's worth it. Is there almost always a reserved
area right before 4GB?

Hi,

Hangin10 wrote:The case that my code does not handle is when the base is under 4GB, but the range takes the entry above 4GB.
I can probably handle this just fine with a little tweak, but I'm wondering if it's worth it. Is there almost always a reserved
area right before 4GB?

There's always an area just below 4 GiB that's used for the BIOS, APICs, HPET, etc, and another area below that that's used for memory mapped PCI devices.

However, (AFAIK) all my code does handle areas that cross the first 4 GiB boundary, so that (for e.g.) if there's RAM from 2 GiB to 6 GiB, or if there's a reserved area from 3 GiB to 5 GiB, then both cases would be handled correctly. This is mostly because I'm fussy (not for any practical reason); but in theory it would be possible for someone to create a system that isn't "PC Compatible" but does use 80x86 CPUs, and does have areas that cross this 4 GiB boundary (and eventually, it should be possible to make my OS run on a system like this by providing a suitable boot loader, where generic code that's run after the boot loader would need to handle areas that cross the first 4 GiB boundary properly).


Cheers,

Brendan