OSDev.org

Posted: **Fri Aug 12, 2005 9:26 pm**

Hi,

smiddy wrote:I suspect there is a couple of other ways to, SMBIOS in protected mode and perhaps ACPI. Both of which would also require some research before implentation.

SMBIOS is designed to allow "administrators" to assess hardware upgrade options or maintain a catalogue of what hardware a company current has in use (ie. it provides information for use by humans, rather than for use by software). From what I've seen it doesn't give reliable results on many computers, and others seem to agree - see:
http://www.pcpitstop.com/faq/smbios.asp

The ACPI standard will tell you to use the BIOS's "Get System Memory Map" function (http://www.ctyme.com/intr/rb-1741.htm).

There may be other ways of using ACPI, but I doubt it. For ACPI there's 2 parts - the tables used during boot and the interpretted language used after boot. For the tables used during boot the only other possibility I can think of is the "SRAT" table, which shows which memory areas are in each NUMA domain (currently only used for 80x86 for multi-socket AMD motherboards), however I don't think there's a correspondance between each NUMA memory range and RAM areas (e.g. the SRAT might say the first 1 GB of the physical address space is connected to CPU 1, but won't say what the first 1 GB of the physical address space contains).

AFAIK the interpretted language stuff doesn't have anything that will return memory sizes, but if it does you'd need a fully operational physical memory manager (and a lot more) before you got the interpretter working anyway.

I don't know about the Plug & Play BIOS - I've never really looked at it (but probably should when I have more time).

Cheers,

Brendan

Posted: **Fri Aug 12, 2005 11:11 pm**

@NotTheCheat: Here is a link on Microsoft's site: http://www.microsoft.com/whdc/resources ... fault.mspx You can get all the specs there for Plug and Play. Sorry, the only code I have is within realmode and won't do you any good in protected mode.

@Brendan: Both SMBIOS and ACPI are my next adventure on reading their specifications and trying to implement something for use. I got the impression that SMBIOS would be able to report the amount of RAM during my cursory overview of it. ACPI on the otherhand, I read a little on, and it is based on PnP information. My assumption there is it should be able to do the same as Plug and Play and perhaps more.

Plug and play is capable of doing quite a lot, especially for device driver management. Here's a screen dump of a little utility I wrote (I intend to put this in my device manager):

Code: Select all

DeviceTree - 0.08.0001 Attempt to see what devices are installed... -smiddy

PnP BIOS : 
Generic AT Parallel Port
    DMA Channel 7
    IRQ 7
    I/O Port 0378 - 037F
    I/O Port 0378 - 037F
    End of Device Resources
RS-232 is 16550
    IRQ 4
    I/O Port 03F8 - 03FF
    End of Device Resources
RS-232 is 16550
    IRQ 3
    I/O Port 02F8 - 02FF
    End of Device Resources
Floppy Controller
    IRQ 6
    DMA Channel 2
    I/O Port 03F2 - 03F5
    End of Device Resources
Mouse Controller
    IRQ C
    End of Device Resources
RAM Memory 
    Memory: 00000000 - 000A0000h - Available to OS
    Memory: 00100000 - 3FF00000h - Available to OS
    Memory: 000E8000 - 00008000h - ROM
    Memory: 000F0000 - 00004000h - ROM
    Memory: 000F4000 - 00004000h - ROM
    Memory: 000F8000 - 00008000h - ROM
    Memory: 000CB000 - 00001000h - ROM
    Memory: FFF80000 - 00080000h - Available to OS
    End of Device Resources
Other System Peripheral
    Memory: FFB80000 - 00080000h - Available to OS
    End of Device Resources
Programmable Interrupt Controller (8259 Compatible)
    IRQ 2
    I/O Port 0020 - 0021
    I/O Port 00A0 - 00A1
    I/O Port 04D0 - 04D1
    End of Device Resources
System Timer (8254 Compatible)
    IRQ 0
    I/O Port 0040 - 0043
    End of Device Resources
Real Time Clock
    IRQ 8
    I/O Port 0070 - 0071
    End of Device Resources
Keyboard Controller
    IRQ 1
    I/O Port 0060
    I/O Port 0064
    End of Device Resources
486 Based CPU
    IRQ D
    I/O Port 00F0
    End of Device Resources
DMA Controller (8237 Compatible)
    DMA Channel 4
    I/O Port 0000 - 000F
    I/O Port 0080 - 0090
    I/O Port 0094 - 009F
    I/O Port 00C0 - 00DE
    End of Device Resources
Other System Peripheral
    I/O Port 0061
    End of Device Resources
PCI Bridge
    I/O Port 0CF8 - 0CFF
    End of Device Resources
Other System Peripheral
    I/O Port 0290 - 0297
    I/O Port 03F0 - 03F1
    I/O Port E400 - E47F
    I/O Port EC00 - EC3F
    End of Device Resources



Base Add - Size     - Type of Memory
----------------------------------------------------------------
00000000 - 000A0000 - 13
000CB000 - 00001000 - 32
000E8000 - 00008000 - 32
000F0000 - 00004000 - 32
000F4000 - 00004000 - 32
000F8000 - 00008000 - 32
00100000 - 3FF00000 - 13
FFB80000 - 00080000 - 01
FFF80000 - 00080000 - 13
----------------------------------------------------------------
Total Mem: 400A0000 -  1,074,397,184 bytes.

As you can see, this is very useful information. Your device manager wouldn't have to guess at specific ports or memory areas, and can use the BIOS setup for IRQs and DMA channels. I should caveat this though, I noticed on one machine (new) that it didn't correct identify a memory area as writeable when it actually is. So, much like SMBIOS as you say, your mileage may vary depending on the machine.

BTW:

AFAIK the interpretted language stuff doesn't have anything that will return memory sizes, but if it does you'd need a fully operational physical memory manager (and a lot more) before you got the interpretter working anyway.

I already have a physical memory manger working. I don't intend on using paging yet, at least not through 2.0 of my own OS. I have looked at the interpretive language a little and I don't expect too many problems implementing it. The only draw back for me is the time I can spend working on it.

Posted: **Sat Aug 13, 2005 3:04 am**

DeviceTree - 0.08.0001 Attempt to see what devices are installed... -smiddy

PnP BIOS :
Generic AT Parallel Port
DMA Channel 7
IRQ 7
I/O Port 0378 - 037F
I/O Port 0378 - 037F
End of Device Resources
RS-232 is 16550
IRQ 4
I/O Port 03F8 - 03FF
End of Device Resources
RS-232 is 16550
IRQ 3
I/O Port 02F8 - 02FF
End of Device Resources
Floppy Controller
IRQ 6
DMA Channel 2
I/O Port 03F2 - 03F5
End of Device Resources
Mouse Controller
IRQ C
End of Device Resources
RAM Memory
Memory: 00000000 - 000A0000h - Available to OS
Memory: 00100000 - 3FF00000h - Available to OS
Memory: 000E8000 - 00008000h - ROM
Memory: 000F0000 - 00004000h - ROM
Memory: 000F4000 - 00004000h - ROM
Memory: 000F8000 - 00008000h - ROM
Memory: 000CB000 - 00001000h - ROM
Memory: FFF80000 - 00080000h - Available to OS
End of Device Resources
Other System Peripheral
Memory: FFB80000 - 00080000h - Available to OS
End of Device Resources
Programmable Interrupt Controller (8259 Compatible)
IRQ 2
I/O Port 0020 - 0021
I/O Port 00A0 - 00A1
I/O Port 04D0 - 04D1
End of Device Resources
System Timer (8254 Compatible)
IRQ 0
I/O Port 0040 - 0043
End of Device Resources
Real Time Clock
IRQ 8
I/O Port 0070 - 0071
End of Device Resources
Keyboard Controller
IRQ 1
I/O Port 0060
I/O Port 0064
End of Device Resources
486 Based CPU
IRQ D
I/O Port 00F0
End of Device Resources
DMA Controller (8237 Compatible)
DMA Channel 4
I/O Port 0000 - 000F
I/O Port 0080 - 0090
I/O Port 0094 - 009F
I/O Port 00C0 - 00DE
End of Device Resources
Other System Peripheral
I/O Port 0061
End of Device Resources
PCI Bridge
I/O Port 0CF8 - 0CFF
End of Device Resources
Other System Peripheral
I/O Port 0290 - 0297
I/O Port 03F0 - 03F1
I/O Port E400 - E47F
I/O Port EC00 - EC3F
End of Device Resources

Base Add - Size - Type of Memory
----------------------------------------------------------------
00000000 - 000A0000 - 13
000CB000 - 00001000 - 32
000E8000 - 00008000 - 32
000F0000 - 00004000 - 32
000F4000 - 00004000 - 32
000F8000 - 00008000 - 32
00100000 - 3FF00000 - 13
FFB80000 - 00080000 - 01
FFF80000 - 00080000 - 13
----------------------------------------------------------------
Total Mem: 400A0000 - 1,074,397,184 bytes.

thanks for sharing these ports

Posted: **Sat Aug 13, 2005 7:22 am**

After reviewing SMBIOS more I have concluded you can get the memory installed on a machine. It will tell you the number of memory sticks installed and their size in MB. There is no mapping, though this would be the case with most OSes that use INT 15h AX=E801 as their way of determining RAM. SMBIOS can also be used in protected mode as well. I will be working on coding SMBIOS in protected mode in the next couple of days.

Posted: **Sun Aug 14, 2005 12:21 pm**

@Codemaster snake: these ports are returned by PCI config space, so they will work on his computer but might be different on your computer. His utility detects what the ports are on a computer, but they are not necessarily the same on all computers.

Posted: **Sun Aug 14, 2005 5:14 pm**

@nOTthecHEAT, that is not correct. It is from the PnP BIOS, not the PCI config space. PCI enumeration returns entirely different information. However, you are correct that every machine has its own set of ports, not all are the same.

Posted: **Sun Aug 14, 2005 8:57 pm**

Hi,

smiddy wrote:@nOTthecHEAT, that is not correct. It is from the PnP BIOS, not the PCI config space. PCI enumeration returns entirely different information. However, you are correct that every machine has its own set of ports, not all are the same.

Half of these devices (keyboard/mouse controller, PIC, PIT, DMA and RTC) are standard devices that will be the same on all "80x86 PC compatible" computers since the 80286.

The IO ports used for PCI configuration space (listed as "PCI Bridge") are also standard for both "mechanism #A" and "mechanism #B", however from this list you won't know which mechanism is used so you'd need to ask the PCI BIOS (if the PCI BIOS is present you can safely assume the IO ports from 0x0CF8 to 0x0CFF are used by PCI anyway).

Most of the remaining devices (serial, parallel, FDC) are mostly standard, and (if present) can be expected at the IO ports listed. By checking the normal IO ports for these devices they can all be auto-detected (using the similar "is this device present/working" checks you'd expect all to find in all good device drivers).

For example, for serial ports the standard arrangement is for base IO ports at 0x03F8, 0x02E8, 0x03E8 and 0x02F8 for the first, second, third and fourth serial port respectively, using IRQ 3 or IRQ 4.

It should also be noted that the CPU does not always use IRQ 0x13 for the FPU, and it is recommended that any 80486 or above CPU use the native FPU error reporting (by setting the NE bit in CR0) so that FPU errors trigger exception 0x10 immediately rather than IRQ 0x13 after delays caused by the PIC, etc.

The only real exception to this is the parallel port's DMA channel and IRQ, which was something added later when ECP and EPP (enhanced bi-directional modes) were added to the standard parallel port.

I would also expect that the details returned by the BIOS only includes devices that are built into the motherboard and those that support ISA Plug & Play. This leaves some devices that can still not be detected (where probing would be required), for example an ISA "multi-IO" card with 2 serial ports, 1 parallel port and a secondary FDC (I've got 4 of them).

The "Other System Peripheral" list is also a worry. The second entry (0x03F0 to 0x03F1) is usually the FDC controller's status registers. I would assume that the first entry (0x0290 to 0x0297) is the chipset control registers, and that the remaining/last 2 entries are the video and/or IDE controller (although the IO ports don't look right for a PCI IDE controller).

I'm also curious if (for ISA Plug & Play cards) the BIOS returns all information, including possible IO ports the card/device can be configured for and if the device decodes all 16 bits of IO port addresses (or just 10, which is both possible and ugly).

Despite all of this, I can't see how an OS can auto-configure the resources used by PCI devices without prior knowledge of things like the chipset's IO ports (IO ports that should be avoided), and the ISA Plug & Play BIOS functions seem the only way to get this information (another thing to add to my ever-growing TODO list).

@Smiddy: Thanks for this info!

Cheers,

Brendan

Posted: **Mon Aug 15, 2005 3:49 am**

No problem Brendan, my pleasure. Unfortunately, or fortunately, I've gone down this path of determining the devices installed, which has all but derailed me from working on my kernel.

An update on SMBIOS: it seems all manufacturers don't make their systems fully compliant. Take HP Itanium for instance, they live up to the DIG64 specification so their SMBIOS doesn't return all the required device types. But it does do some of them...

I will have working code for SMBIOS by this evening and share ther results of the same machine.

BTW, the other system peripheral is that way because I can not find a listing of the actual device ID for PnP that is up to date. The output there is a generic output base on the device type, not the actual device ID.

OSDev.org

Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed

Re:Detecting RAM installed