Solved MMIO in FreeBSD

Hello guys,

As you know, we're used to thinking of memory only in terms of RAM.
If most of the memory requests from the processor are routed to RAM modules by the northbridge, physical memory addresses are also used for communication with assorted devices on the motherboard (memory-mapped I/O). These devices include video cards, most PCI cards (scanner or SCSI card), and also the flash memory that stores the BIOS.

Can you tell me please if is it possible and how to retrieve the memory layout in FeeBSD (a little bit shown in the attached picture) ?

I've tried with

dmesg | grep iomem

but without good results.

Tips are appreciated.

Bye !
 

Attachments

  • memoryLayout.png
    memoryLayout.png
    20.1 KB · Views: 340
Last edited:
Yuck. This is VERY complicated. And the answer depends on processor architecture (so you'll get different answers for Intel in 32- versus 64-bit mode). It also depends on process context: Clearly, different processes have different physical memory mapped in the same place; the kernel has its own memory map. And IO from PCI devices (which importantly include all network and disk IO, including the stuff on the motherboard) has a yet different memory map. Which on some CPU types uses physical memory addresses, on others it uses virtual ones (I vaguely remember some strange problem porting code between Intel and PowerPC, which were different in that regard, but I don't remember the details).

If you find a complete and concise answer, please post it here.
 
Maybe sysctl vm.phys_segs will list this and that? Maybe grep mem /var/run/dmesg.boot. But why would you possibly need such info?
 
Hello guys,
If you find a complete and concise answer, please post it here.

my apologize.

My question, so posted, is not clear and really it would be difficult find a complete and concise answer.

I was referring to the Boot Memory Regions during the pre-POST phase, when the CPU starts up.

I was reading an article about the boot process of a CPU.

"Most registers in the CPU have well-defined values after power up, including the instruction pointer (EIP) which holds the memory address for the instruction being executed by the CPU. Intel CPUs use a hack whereby even though only 1MB of memory can be addressed at power up, a hidden base address (an offset, essentially) is applied to EIP so that the first instruction executed is at address 0xFFFFFFF0 (16 bytes short of the end of 4 gigs of memory and well above one megabyte). This magical address is called the reset vector and is standard for modern Intel CPUs.

The motherboard ensures that the instruction at the reset vector is a jump to the memory location mapped to the BIOS entry point. This jump implicitly clears the hidden base address present at power up. All of these memory locations have the right contents needed by the CPU thanks to the memory map kept by the chipset. They are all mapped to flash memory containing the BIOS since at this point the RAM modules have random crap in them."

An example of the Boot Memory Regions is shown in the attached figure.

So, I was trying to understand if FreeBSD can retrieve (and how) the memory map the article speaks about, also if I think it's hard because the memory map is kept by the chipset.

However it seems Linux maintains this information in the file /proc/iomem.

Comments are welcome.

Bye !!!
 

Attachments

  • bootMemoryRegions.png
    bootMemoryRegions.png
    18.6 KB · Views: 517
On FreeBSD the newbus subsystem abstracts architecture-specific I/O mechanisms, such as MMIO addresses. So maybe the documentation and sources for newbus can be at least a starting point?
 
Hello,

sincerely I don't know the newbus subsystem mechanism ... however are you sure that it implement memory mapping at so low level (pre-POSTphase) ?
 
Hello Sir,

I think I've learned by your continuous lessons and tips the way to post a question before write a thread here: giving a look at the FreeBSD Handbook !:):):);)

So, I've already seen the Cap. 14 before reply o_O


My question is a little bit different:

Is it the newbus subsystem mechanism the one that implements the memory mapping at so low level (pre-POSTphase) ?
By reading it, I didn't understand if it's so or not. I'm sorry. :mad:

If so, I can study it in more details also because the cap. 14 gives only few bases about that mechanism.

Bye !!!!:p
 
Before the POST there's no OS running, so FreeBSD has zero influence at that point. Assuming by POST you mean the Power On Self Test.
 
Everything pre-POST is done by the firmware "behind" the BIOS and on the various installed chipsets and devices. This is the ultimate proprietary hell, so I highly doubt you will find much documentation let alone code for that.
At least for the BIOS-level you could refer to projects like Libreboot to get a glimpse of what happens at the BIOS level.

In the olden days there was a IO.SYS file (or IIRC IBMIO.SYS for IBM-compatibles) on DOS-systems, which did the heavy lifting of interfacing between the OS and hardware back when the BIOS on most systems was very minimalistic. It also contained a _very_ basic set of drivers to get a machine up at least to a point where more elaborated mechanisms can pick up.
Microsoft released the source code of some very early MS-DOS versions, so as a learning experience it might be interesting to have a look at that - especially because it should be way less code than any modern BIOS let alone UEFI, so one can easier grasp the underlying concepts of what is happening at the lowest levels.
 
VERY IMPORTANT.

Everything pre-POST is done by the firmware "behind" the BIOS and on the various installed chipsets and devices. This is the ultimate proprietary hell, so I highly doubt you will find much documentation let alone code for that.
At least for the BIOS-level you could refer to projects like Libreboot to get a glimpse of what happens at the BIOS level.

In the olden days there was a IO.SYS file (or IIRC IBMIO.SYS for IBM-compatibles) on DOS-systems, which did the heavy lifting of interfacing between the OS and hardware back when the BIOS on most systems was very minimalistic. It also contained a _very_ basic set of drivers to get a machine up at least to a point where more elaborated mechanisms can pick up.
Microsoft released the source code of some very early MS-DOS versions, so as a learning experience it might be interesting to have a look at that - especially because it should be way less code than any modern BIOS let alone UEFI, so one can easier grasp the underlying concepts of what is happening at the lowest levels.
 
Back
Top