Grubs multiboot memory map

[Rob]

That's why I would only use the available areas from the memory map. So init the page structure to no memory available and clear available pages based on available memory from the memory map. That way it would not matter if reserved / system / unavailable memory is in the memory map or not.

[Brendan]

Hi,

That's why I would only use the available areas from the memory map. So init the page structure to no memory available and clear available pages based on available memory from the memory map. That way it would not matter if reserved / system / unavailable memory is in the memory map or not.

For the "ACPI reclaimable" area, you can use it just like a normal "available RAM" area as long as you're finished using the ACPI tables - it can be "reclaimed".

For the other areas (system, reserved, ACPI non-volatile), IMHO these mark areas that should be avoided when you're assigning parts of the physical address space to PCI devices. For example, you wouldn't want to put a second video card's display memory mapping where the APIC/s are or where a ROM is.

As long as you do both of these things, and as long as your code can handle areas that don't start or end on a page boundary (e.g. assuming the page at 0x0009F000 is RAM when the EBDA starts at 0x0009FC00), then everything should work well.


Cheers,

Brendan

[Pype.Clicker]

For the other areas (system, reserved, ACPI non-volatile), IMHO these mark areas that should be avoided when you're assigning parts of the physical address space to PCI devices. For example, you wouldn't want to put a second video card's display memory mapping where the APIC/s are or where a ROM is.

maybe i'm just too optimistic, but shouldn't the BIOS handle such things ? Or maybe you consider that BIOS isn't reliable enough when it comes to handle secondary PCI busses behind bridges and that the OS should perform re-assignment of PCI resources when it starts, like Linux does ?

[JAAman]

the area from 0xFEC00000 to the bottom of the BIOS (which is actually just below 4 GB - all or part of it appears to be below 1 MB due to chipset tricks) is mainly reserved for local APICs and I/O APICs (if any).

actually, most of the time, the BIOS ROM chips are not mapped bellow 1MB, rather they are coppied into RAM located at that location -- on older computers (386/486), this was an option to do either way (because RAM is much faster, but the extra few k can be relocated the same way) but afaik, newer computers do not do any remapping (that is why there is RAM behind the ROM spaces that are unused), and simply copy the BIOS code into RAM, and mark it as ReadOnly in the CPUs memory tables -- once you are in PMode, you can simply rewrite these tables, and recover the ram (iirc) though it prob isn't worth it

[Brendan]

Hi,

For the other areas (system, reserved, ACPI non-volatile), IMHO these mark areas that should be avoided when you're assigning parts of the physical address space to PCI devices. For example, you wouldn't want to put a second video card's display memory mapping where the APIC/s are or where a ROM is.

maybe i'm just too optimistic, but shouldn't the BIOS handle such things ? Or maybe you consider that BIOS isn't reliable enough when it comes to handle secondary PCI busses behind bridges and that the OS should perform re-assignment of PCI resources when it starts, like Linux does ?

Most of the time, an OS probably can get by without re-assigning PCI resources. There are a few reasons why I'd do the re-assignement though - dodgy/broken BIOS's, minimizing/tuning traffic through bridges, cards that aren't completely initialized (e.g. second video card), removing any/all PCI device ROMs, and support for hot plug PCI.

the area from 0xFEC00000 to the bottom of the BIOS (which is actually just below 4 GB - all or part of it appears to be below 1 MB due to chipset tricks) is mainly reserved for local APICs and I/O APICs (if any).

actually, most of the time, the BIOS ROM chips are not mapped bellow 1MB, rather they are coppied into RAM located at that location -- on older computers (386/486), this was an option to do either way (because RAM is much faster, but the extra few k can be relocated the same way) but afaik, newer computers do not do any remapping (that is why there is RAM behind the ROM spaces that are unused), and simply copy the BIOS code into RAM, and mark it as ReadOnly in the CPUs memory tables -- once you are in PMode, you can simply rewrite these tables, and recover the ram (iirc) though it prob isn't worth it

Normally the chipset has control flags in the PCI host controller's PCI configuration space which allow "chunks" of the area between 0x000C0000 and 0x000FFFFF to be configured.

For example, the Intel I440FX chipset (Pentium) has "Programmable Attribute Map Registers" at locations 0x59 to 0x5F in it's PCI host controller's PCI configuration space that allows RAM within these "chunks" to be set to read-only, write-only, read-write or disabled. Any access that isn't enabled is forwarded to the PCI bus (for e.g. if you try to read from an area that is set to "write-only", then your read would be forwarded to PCI bus where a PCI card may have it's own ROM and complete the request).

For Intel 845 and 865 chipsets (both Pentium 4) it's identical, except the "Programmable Attribute Map Registers" are at locations 0x90 to 0x96 in the PCI host controller's PCI configuration space.

For AMD CPUs I think it's similar, except that the PCI host controller is built into the CPU and includes a pile of hyper-transport stuff. I haven't looked into this properly yet though.


Cheers,

Brendan

[Coconut9]

The memory map lists different types of memory regions: reserved, available, acpi stuff.. You should use the regions of memory marked as available (and maybe the acpi release ones if you don't want them). These are all physical memory regions.

Just remember that there are still memory mapped devices, modules, legacy code, etc, loaded into this memory. For example, 0xB8000 will be the text screen. The BIOS, ACPI, etc is sitting beneath the 1MB mark. Anything right above your kernel could be the modules that grub has loaded for you.

For the modules, you'll need to parse more of the multiboot structures to determine where they are and reserve those parts of memory. Reserve anything else you want to keep and then it's relatively safe to use the rest.

I have a simple question, I have already done that so is the time for the bitmap. My problem is that by changing the computer changes the ram blocks so the bitmap may be to large to put them into a selected space! I want a way to map all blocks without that problem.

[LtG]

I have a simple question, I have already done that so is the time for the bitmap. My problem is that by changing the computer changes the ram blocks so the bitmap may be to large to put them into a selected space! I want a way to map all blocks without that problem.

Congrats, 11,5 years old thread =)

And based on the topic, it doesn't even seem to be related.

If I understand your question, with different computers there's different amounts of RAM available and because of that you don't know how much RAM you will need for your bitmap?

It's simple, you don't reserve a bitmap, after you get the mmap you then search the mmap for a location for the bitmap.