OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 9:18 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re:Grubs multiboot memory map
PostPosted: Sat Feb 25, 2006 1:40 pm 
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.


Top
  
 
 Post subject: Re:Grubs multiboot memory map
PostPosted: Sat Feb 25, 2006 3:52 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Rob wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re:Grubs multiboot memory map
PostPosted: Sun Feb 26, 2006 4:38 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 2:31 am
Posts: 5964
Location: In a galaxy, far, far away
Brendan wrote:
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 ?

_________________
Image May the source be with you.


Top
 Profile  
 
 Post subject: Re:Grubs multiboot memory map
PostPosted: Sun Feb 26, 2006 11:30 am 
Quote:
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


Top
  
 
 Post subject: Re:Grubs multiboot memory map
PostPosted: Sun Feb 26, 2006 6:26 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Pype.Clicker wrote:
Brendan wrote:
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.

JAAman wrote:
Quote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Re:Grubs multiboot memory map
PostPosted: Tue Aug 01, 2017 2:22 am 
Offline
Member
Member
User avatar

Joined: Sat May 20, 2017 1:25 am
Posts: 51
Location: PCI bus: 3, slot: 9, function: 5
durand wrote:
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.

_________________
How people react when a new update of your OS is coming:
Linux user: Cool, more free stuff!
Mac user: Ooh I have to pay!
Windows user: Ah not again!


Top
 Profile  
 
 Post subject: Re: Re:Grubs multiboot memory map
PostPosted: Tue Aug 01, 2017 4:15 am 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
ARISTOS wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Majestic-12 [Bot], maxtyson123 and 27 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group