Is there any chance for non-continuos memory between 1M-8M?

[bluemoon]

I'm currently rewriting the PMM and want to just use the memory from physical 4M to 8M for page stack,
before the PMM itself have a concept on the memory layout.
So it become easy to just push usable address on that stack while walking on the memory map.

I have a simple validation on the BIOS memory map and it will panic if there is hole,
but do anyone actually see a memory hole exists from 1M-8M for 386+?
I know some system offer a hole at 15M but not sure if it's safe to abuse the lowest 8M.

ps. assume the machine have reasonable enough memory.

[JackScott]

As far as I am aware, there aren't any holes in memory between 0x10000 and 0x7FFFFF (assuming the computer has sufficient memory). That said, never assume anything when it comes to memory holes.

For example, a specially-designed computer could come out next week that has the controls to a nuclear weapon memory-mapped in somewhere between 1M and 8M. It would be a perfectly valid (if not a little stupid) thing to do. If your operating system was booted on this computer, and you abused the memory in this area, you might set off a nuclear weapon. Nobody wants that, so it's safest to check with the BIOS beforehand as to which memory you can use.

Alternatively, it could be something boring like a badly-designed ISA card. Still, it's best not to peek and poke where you're not supposed to.

[Brendan]

Hi,

I have a simple validation on the BIOS memory map and it will panic if there is hole,
but do anyone actually see a memory hole exists from 1M-8M for 386+?
I know some system offer a hole at 15M but not sure if it's safe to abuse the lowest 8M.

ps. assume the machine have reasonable enough memory.

There's no formal specification or anything that says any areas above 0x00100000 will or won't be present (it's mostly just convention); and now that ACPI 3 allows "int 0x15, eax=0xE820" to mark areas as faulty (rather than the firmware failing POST checks and refusing to boot) there's even less guarantees. For a worst case theoretical scenario, it would even be possible for a system to have 128 KiB of RAM at 0x00000000 and the remaining RAM above 4 GiB (where you can't access it with 32-bit addressing), and still be able to call itself "PC compatible".

However, it's very unlikely that any "PC compatible" motherboard/chipset manufacturer would intentionally break compatibility (even with software that makes unfounded assumptions about the memory map), and therefore it's very unlikely that there won't be RAM from 0x00100000 to 0x007FFFFF.

Mostly your question is about risk assessment. The risk of your OS failing to boot because of a memory hole in that area is extremely small (maybe one computer out of 500 thousand computers might have trouble), but I don't know if that's "too small" or "not small enough" for your project. The risk of your OS failing to boot because the computer has less than 8 MiB of RAM installed is probably 50 times higher (maybe one computer out of 10 thousand computers might not have enough RAM), so if you can accept that risk then...


Cheers,

Brendan

[egos]

The probability is smallest, but...

Therefore I don't use fixed physical addresses in my kernel except base memory region.

[Combuster]

I got a collection of PCs with 8M ram or less - even in the 8M case you can't access it all as ACPI will also use a part of it.

[bluemoon]

Thanks all.

Since the chance is slim, I'll just make it an requirement to have enough memory (eg 16M, or 32M).
It will be a pain to handle a hole, not only within the kernel, but the boot loader itself must find a chunk big enough to hold the kernel (reserved 4M for it); that the kernel must aware where it is loaded. (as there might just a hole right near 1M region)

Handling such conner case provides no entertainment at current development stage,
and I'll treat it as known issue with low priority until someday a hundred thousand years later a user complain on the issue :p

edit: fixed typo

[Brendan]

Hi,

Since the chance is slim, I'll just make it an requirement to have enough memory (eg 16M, or 32M).

That's fair - just add it to the list of requirements for the OS.

It will be a pain to handle a hole, not only within the kernel, but the boot loader itself must find a chunk big enough to hold the kernel (reserved 4M for it); that the kernel must aware where it is loaded. (as there might just a hole right near 1M region)

Handling such conner case provides no entertainment at current development stage,
and I'll treat it as known issue with low priority until someday a hundred thousand years later a user complain on the issue :p

I've been shifting my boot code to "32-bit with paging" for this reason.

For example, (for "PC BIOS"), the first stage (at 0x00001000) loads a "boot abstraction layer" (BAL) into memory immediately after it (e.g. below 0x0007FFFF somewhere), sets up paging, and maps the BAL at 0x80000000 in the virtual address space. The BAL initialises a temporary memory manager, and all pages used after that are dynamically allocated (and don't need to be physically contiguous) but are mapped at fixed and/or contiguous virtual addresses. After that a "boot image" (that can be quite large, as it contains more modules used during boot, several kernels, various device drivers, etc) is loaded. For testing purposes, I've had special boot loaders that deliberately disable A20 (rather than enable it) to make sure the rest of the boot code can cope with an extremely messed up physical address space without problems. Mostly the only restriction is that usable physical RAM must exist from 0x00001000 to about 0x0002FFFF.

For the EFI boot loader, pages for the BAL are allocated from EFI's memory manager before the BAL's own memory manager is initialised, so the BAL itself doesn't need physically contiguous pages in that case. Because of the way EFI is designed, the first stage has to be position independent code, so the only restriction is that there's about 64 KiB of physically contiguous pages somewhere.

Basically, as long as you make use of paging as early as possible, it's not that hard to support systems where the physical memory map looks like it came from a random number generator.


Cheers,

Brendan

[tom9876543]

There is an easy answer to this problem.

When you do int 0x15, eax=0xE820 in real mode, make sure one of the memory blocks has start address <= 1mb and end address >= 8mb.
If its not found give up immediately.