OSDev.org

Hi,

Mine (link posted previously) checks for details in the following order:

• Int 0x15, eax = 0xE820
  Int 0x15, ax = 0xE881
  Int 0x15, ax = 0xE801
  Int 0x15, ah = 0xC7
  Int 0x15, ah = 0x88
  CMOS locations 0x17 and 0x18
  Manual probing

At each step, all known BIOS bugs and limitations are taken into account, and if anything seems wrong it fails and tries the next step. Each method builds a memory map similar to that returned by Int 0x15, eax = 0xE820 (including ROM areas, etc), sorts the list of memory areas, and combines adjacent areas of the same type.

smiddy wrote:I then use PnP calls to determine RAM, which is very close to the E820 with a MAP, I also use SMBIOS to determine what is says is there from a hardware perspective, and finally I do a memory probe being careful of certain areas where ROM and BIOS are located, I also use PCI and scanning to determine the ROMS.

I intend to do the reverse (disable all PCI option ROMs and re-allocate any address space regions used for memory mapped I/O according to the system memory map I obtained previously).

I'm also allowing for a "chipset driver" to make additional RAM available after the kernel starts. This can be freeing the ACPI reclaimable area, finding more RAM between 0x000C0000 and 0x000F0000, or support for hotplug RAM.

smiddy wrote:This method isn't all encompassing, as you might think it is. I've yet to determine RAM using ACPI tables (if capable), and I haven't even considered GRUB, I've never used it...<shrug>

The ACPI tables don't return any information about the physical address space - the ACPI specification states "Use Int 0x15, eax = 0xE820"...


Cheers,

Brendan

Brendan wrote:Hi,

Mine (link posted previously) checks for details in the following order:

• Int 0x15, eax = 0xE820
  Int 0x15, ax = 0xE881
  Int 0x15, ax = 0xE801
  Int 0x15, ah = 0xC7
  Int 0x15, ah = 0x88
  CMOS locations 0x17 and 0x18
  Manual probing

At each step, all known BIOS bugs and limitations are taken into account, and if anything seems wrong it fails and tries the next step. Each method builds a memory map similar to that returned by Int 0x15, eax = 0xE820 (including ROM areas, etc), sorts the list of memory areas, and combines adjacent areas of the same type.

I noticed, I looked at your code after I saw your post, impressive. I don't look in the same order as you, but you've grabbed most of the errors I've found with implementations (a thurough scrub may yeild differences, but none the less where it doesn't make sense you capture issues, as do I).

Brendan wrote:I intend to do the reverse (disable all PCI option ROMs and re-allocate any address space regions used for memory mapped I/O according to the system memory map I obtained previously).

I can capture current setup for I/O as well as memory regions. I haven't sit down and hashed out an algorithm to make it mine, so to speak. I need to read some information on ACPI and APIC before I move forward.

Brendan wrote:I'm also allowing for a "chipset driver" to make additional RAM available after the kernel starts. This can be freeing the ACPI reclaimable area, finding more RAM between 0x000C0000 and 0x000F0000, or support for hotplug RAM.

I've seen that in a number of your posts. I'm not certain I know what that means "chipset driver"; is that in reference to an Intel, VIA, ASUS, MSI, etcetera motherboard chipset?

I currently reclaim what I know is ACPI, in the upper regions of RAM, but am unaware of any between c0000 and f0000. More to read and learn...as is the way eh?

Brendan wrote:The ACPI tables don't return any information about the physical address space - the ACPI specification states "Use Int 0x15, eax = 0xE820"...

I saw that last week, and I find it interesting. I have found complete differences between E820 and PnP scans. While I realize ROMs aren't capture according to the ACPI doc in the MAP, PnP will have areas identified as not OK to use and E820 does and visa versa. Arbitrating these items is part of my algorithm. Currently I am not assuming using ACPI so my probing will known potential areas (excluding known ROM/BIOS areas) and try to get a better answer. It hasn't failed yet as I know, but the testing hasn't been exhaustive either.

I didn't do a thorough look, but I noticed you identify E820 twice, once as a type 7 and another as type 8. Type 8's comments mentions ACPI 3.0. How do you know, based on the BIOS date? Perhaps I've missed something in the ACPI text...

Hi,

smiddy wrote:

Brendan wrote:I'm also allowing for a "chipset driver" to make additional RAM available after the kernel starts. This can be freeing the ACPI reclaimable area, finding more RAM between 0x000C0000 and 0x000F0000, or support for hotplug RAM.

I've seen that in a number of your posts. I'm not certain I know what that means "chipset driver"; is that in reference to an Intel, VIA, ASUS, MSI, etcetera motherboard chipset?

Yes. For most (all?) chipsets there's some interesting things to play with.

There's usually some registers in the memory host controller that allow parts of the region from 0x000A0000 and 0x000FFFFF to be set so that reads and/or writes are forwarded to the PCI bus, to RAM, etc. For example, imagine there's a PCI/AGP video card with a ROM mapped to 0x000C0000. If you disable this ROM (using the card's PCI configuration space) then you still can't access the RAM at this address until you tell the memory host controller that reads/writes for the area should both go to RAM (instead of the PCI bus).

Then there's things like the PCI IRQ router, serial port and parallel port I/O base addresses, floppy controller I/O base address, flash BIOS support, power management, hotplug RAM, hotlpug PCI devices, etc. For Intel chipsets there's a complete TCO (Total Cost of Ownership) system for monitoring the system (including watchdog timer, heartbeat, remote/ethernet monitoring, etc). For most onboard devices, the chipset has some control over which I/O APIC input the device is connected to, which can be useful for avoiding IRQ sharing (remembering that the PCI IRQ router only effects PIC connections).

Specifications (like ACPI) cover most of this, but not all of it.

The idea is to provide a way of supporting all of this (with or without ACPI), while providing somewhere where chipset bugs can be worked-around, etc. Despite this, it's very likely that most of my "chipset drivers" will do almost nothing or just use generic ACPI...

smiddy wrote:I didn't do a thorough look, but I noticed you identify E820 twice, once as a type 7 and another as type 8. Type 8's comments mentions ACPI 3.0. How do you know, based on the BIOS date? Perhaps I've missed something in the ACPI text...

The ACPI 3.0 version of this function is meant to return 24 bytes of data (including a new "extended attributes" field), while older versions should only return 20 bytes of data. IMHO the ACPI specification messed this up though, as the extended field includes an "ignore this entry" flag that legacy OSs won't even see, so I'm expecting most BIOSs to keep supporting the legacy 20-byte structure anyway. I haven't done code for the ACPI 3.0 version yet - partly because I'm waiting to see if any BIOSs bother supporting it, and partly because I can't test it.


Cheers,

Brendan

Brendan wrote:The ACPI 3.0 version of this function is meant to return 24 bytes of data (including a new "extended attributes" field), while older versions should only return 20 bytes of data. IMHO the ACPI specification messed this up though, as the extended field includes an "ignore this entry" flag that legacy OSs won't even see, so I'm expecting most BIOSs to keep supporting the legacy 20-byte structure anyway. I haven't done code for the ACPI 3.0 version yet - partly because I'm waiting to see if any BIOSs bother supporting it, and partly because I can't test it.

I'll see what I can find on this too and report it here. I hadn't seen a different E820 when I researched in a year and a half ago.

I've seen mention of the 24-byte target and I think I've seen errata for BIOSes that wrote a 24-byte entry even if you specified that you didn't have place for it (which would normally be harmless, since you'd overwrite the last 4 bytes anyway). I'm aligning all my data structures to 24-bytes in any case, both for alignment reasons and for being future-proof for these changes.

Candy wrote:I've seen mention of the 24-byte target and I think I've seen errata for BIOSes that wrote a 24-byte entry even if you specified that you didn't have place for it (which would normally be harmless, since you'd overwrite the last 4 bytes anyway). I'm aligning all my data structures to 24-bytes in any case, both for alignment reasons and for being future-proof for these changes.

Good idea, I'll have to rehash my own.