OSDev.org

Hi!

I set my page structure at the end of my second stage loader. Then through NASM-directives, I align the table to 4kb bondaries. All work fine. Then I enable in my hypervisor the "legacy network adapter ". What I know for sure is that when doing this, the hypervisor add an PCI device, and in such device everyone of the legacy network adapters appears like a function. The problem was that when I enable legacy network adapter, something like hole appears in the palce whrere my page structure is and remap my first 2MB entry, and entering long mode don't work properly, this is what I know.
To avoid this problem I put the page structure in 1000h and now work fine.
But soon my second stage code will grow enough to touch the "hole" of the legacy network adapter. I am definitively not capable to program decent hardware detection and driver loading in less code. I don't know where exactly this "hole" appears but it is about 5KB + 100000h.
So first, correct me if I am wrong with my assumptions.
Second if I am correct, how do you face this problem? How big is your second stage? What this hole can be?

Cheers!

Hi,

smoothCoder wrote:I don't know where exactly this "hole" appears but it is about 5KB + 100000h.

In practice (on a "PC BIOS" system); there shouldn't be a hole anywhere near that. You should have the (read-only) BIOS below it (ending at 0x000FFFFF), and the nearest possible hole above it would be the hole for memory mapped ISA cards at 0x00F00000 (which is fairly unlikely on a modern computer, as there's no ISA cards). The closest I've ever heard of is an ancient (80386) system that only had 1 MiB of RAM, that relocated some of the RAM that would've been underneath the ROM and video area to the end of memory (e.g. 640 KiB of RAM from 0x00000000 to 0x000A0000 and another 384 KiB of RAM from 0x00100000 to 0x00160000).

In theory (on a "PC BIOS" system); the only real guarantee (mostly caused by DOS compatibility) is that if there's more than 512 KiB of RAM then the area from 0x00000000 to 0x00080000 is RAM. For example, nothing really prevents the BIOS from creating an "ACPI reclaimable" or "ACPI non-volatile" area at 0x00100000 (or anywhere above that). It would be bad design, but would've violate any specs. More likely might be an ACPI 3.0 system with some dodgy RAM where an area is marked as "faulty" by "int 0x15, eax = 0xE820" (but I still haven't seen a BIOS that supports the additions to "int 0x15, eax = 0xE820" that were introduced by ACPI 3.0).

smoothCoder wrote:Second if I am correct, how do you face this problem? How big is your second stage?

I'm a little unusual, in that my OS is designed to tolerate arbitrary areas of faulty RAM. My early boot code (running in RAM below the EBDA) sets up a memory manager and enables "temporary paging", and everything after that uses pages allocated from the memory manager where the physical address of the RAM doesn't matter (due to paging). Because of this it'll work fine regardless of how messed up (or how badly fragmented) physical RAM is. For example, as long as there's about 100 KiB of contiguous usable RAM at 0x00000000 and the OS doesn't have an "out of memory" error; the OS can fail to enable A20 (so that every "even" MiB is unusable) and every second page of extended memory can be marked as faulty or unusable (e.g. the page at 0x00100000 is unusable, 0x00101000 is OK, 0x00102000 is unusable, 0x00103000 is OK, etc), and it will still boot without problems (including loading a "boot image" that could be larger than 200 MiB).

Of course most people would consider my boot code to be "over-engineered", and I'd probably agree with them...


Cheers,

Brendan