Page 1 of 1

Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 11:45 am
by lopidas
Does anybody have working assembler code for getting:
memory ranges of physical memory arrays from smbios data which are free for use?
Note: I am trying to get list of memory ranges which can be used for detecting if range is partially unusable or free for use.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 12:21 pm
by mathematician
"Note: I am trying to get list of memory ranges which can be used for detecting if range is partially unusable or free for use."

Isn't that the information which bios interrupt 15h, fn 0e820h is supposed to deliver? At least, I hope it doesn't mark as available, memory used by things like memory mapped devices.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 12:30 pm
by lopidas
Not exactly, this looks like returning info about IVT and BDA too, so I am trying it.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 12:35 pm
by mathematician
lopidas wrote:Not exactly, this looks like returning info about IVT and BDA too, so I am trying it.
Well, the real mode IVT occupies memory between 0-0x400, and the EBDA occupies memory between 0x90000 and 0xA0000. Both of which you are free to overwrite once in protected mode (if you were really that hard up for memory).

Personally, I tend to think of the first megabyte (and the old DMA controller) as a junk yard, full of relics from a bygone era.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 12:41 pm
by Combuster
mathematician wrote:
lopidas wrote:Not exactly, this looks like returning info about IVT and BDA too, so I am trying it.
Well, the real mode IVT occupies memory between 0-0x400, and the EBA occupies memory between 0x90000 and 0xA0000. Both of which you are free to overwrite once in protected mode (if you were really that hard up for memory).
Correction: the BDA's location and size are fixed (immediately follows after the IVT), the EBDA's size isn't, and you can't overwrite it in protected mode as the BIOS needs it for various things out of your control. This is why e820 returns the IVT/BDA as free and the EBDA as reserved.

Also, SMBios is considered unreliable.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 12:48 pm
by mathematician
Combuster wrote:
mathematician wrote:
lopidas wrote:Not exactly, this looks like returning info about IVT and BDA too, so I am trying it.
Well, the real mode IVT occupies memory between 0-0x400, and the EBA occupies memory between 0x90000 and 0xA0000. Both of which you are free to overwrite once in protected mode (if you were really that hard up for memory).
Correction: the BDA's location and size are fixed (immediately follows after the IVT), the EBDA's size isn't, and you can't overwrite it in protected mode as the BIOS needs it for various things out of your control. This is why e820 returns the IVT/BDA as free and the EBDA as reserved.
I misread BDA for EBDA.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 1:01 pm
by Brendan
Hi,
lopidas wrote:Does anybody have working assembler code for getting:
memory ranges of physical memory arrays from smbios data which are free for use?
Note: I am trying to get list of memory ranges which can be used for detecting if range is partially unusable or free for use.
Which one (there's several)? All of them are completely and utterly useless for an OS. None of them tell you the physical address of the RAM or which parts of it are used by firmware or available for the OS. That shouldn't be a surprise because this is not what SMBIOS was intended for in the first place.

What it does have is things like what type of RAM it is (EDO, SDRAM, etc), where the memory is (which slot on the motherboard), the size of the memory module, etc. All of this information is really useful if you're a "PC repair" person looking at upgrading the computer's hardware, or someone working at a company that has to keep spare parts on hand, or someone that has to create a list of "company assets" to make accountants (or insurance people) happy. This is exactly what SMBIOS is designed for.


Cheers,

Brendan

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 2:13 pm
by lopidas
What is then use of
memory array - use field
which holds value like "system memory" and "flash memory"

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 2:21 pm
by Combuster
Exactly what it says on the tin. I suggest you read Brendan's post properly.

Re: Assembler for SMBIOS memory detection

Posted: Wed Feb 12, 2014 2:33 pm
by Brendan
Hi,
lopidas wrote:What is then use of
memory array - use field
which holds value like "system memory" and "flash memory"
If you mean "Physical Memory Array (Type 16)" in the SMBIOS spec; then this describes an array of memory modules - how many slots, where it is (motherboard, PCI card, etc), max. capacity, current capacity, etc). Then there's "Memory Device (Type 17)" which describes things that are in the array (e.g. if a slot is empty, what sort of RAM is in the slot, etc).

These things combined allow someone to (e.g.) look at a computer and say "Hmm, there's 4 memory slots, 2 are empty and 2 are 1234 MHz SDRAM; so I can order 2 more SDRAM modules now and upgrade that computer when the RAM arrives" without opening the case. This can include logging in to a (suitably setup) computer via. network and finding out what you need for the upgrade before travelling 1234 Km to a remote site. It can also include running a tool to search a company LAN and gather statistics (e.g. "If we decided to only keep spare SDRAM on hand from now on, how many computers on our network would be unable to support SDRAM?").


Cheers,

Brendan