Hardware Spec From BIOS OR RAM

I am beginner and would like to develope a kernel that shows hardware speci know there is an interrupt like int 11 .but i want to show the detail specification like model,vendor ,.... for some devices such as cpu,ram,hard.... and i know there is an address in ram that holds this specification but I dont know that address and dont know how to access this segment,Please

Comments

: Hello: : I am beginner and would like to develope a kernel that shows : hardware spec: i know there is an interrupt like int 11 .but i want to show the : detail specification like model,vendor ,.... for some devices such : as cpu,ram,hard.... and i know there is an address in ram that holds : this specification but I dont know that address and dont know how : to access this segment,Please

: : Hello: : : : I am beginner and would like to develope a kernel that shows : : hardware spec: : i know there is an interrupt like int 11 .but i want to show the : : detail specification like model,vendor ,.... for some devices such : : as cpu,ram,hard.... and i know there is an address in ram that holds : : this specification but I dont know that address and dont know how : : to access this segment,Please : : Are you referring to the SMBIOS? If so, you can download the specs : from [link=http://www.dmtf.org/standards/smbios/]Here[/Link].

Thanks sir.But How should i use that standard?I said i am beginner.Guid in detail please.

This is a really good way to learn hardware and programming-one of the very first programs I wrote in asm was one that detected various bits of hardware and displayed them to the screen. I used int 11 and several others, and then figured out how to talk to hardware directly for more exploring. (this was way before smbios came into being)

SMBIOS is a good resource of information. The method used to get to it is very similar to accessing ACPI information, and I have a program here:

I think with just a little bit of tweaking, this program could dump out the SMBIOS data instead of ACPI, but you'll need to read the spec to really understand what you're doing.

The downside of SMBIOS is that it's boring. It's basically just a bunch of text sitting in memory that you parse out and display. You won't learn much with that, so I always suggest going directly to the hardware if you want to learn how to really detect things and know how to interface into all the chips on your board, and we can help.

You'll need to go slowly at first and then ask specifics like "how do I talk to PCI devices?", so we can narrow down the scope of our responses.

: This is a really good way to learn hardware and programming-one of : the very first programs I wrote in asm was one that detected various : bits of hardware and displayed them to the screen. I used int 11 : and several others, and then figured out how to talk to hardware : directly for more exploring. (this was way before smbios came into : being): : SMBIOS is a good resource of information. The method used to get to : it is very similar to accessing ACPI information, and I have a : program here:: : http://www.programmersheaven.com/download/25319/download.aspx: (It only works under plain DOS.): : I think with just a little bit of tweaking, this program could dump : out the SMBIOS data instead of ACPI, but you'll need to read the : spec to really understand what you're doing.: : The downside of SMBIOS is that it's boring. It's basically just a : bunch of text sitting in memory that you parse out and display. You : won't learn much with that, so I always suggest going directly to : the hardware if you want to learn how to really detect things and : know how to interface into all the chips on your board, and we can : help. : : You'll need to go slowly at first and then ask specifics like "how : do I talk to PCI devices?", so we can narrow down the scope of our : responses.: : -jeff!

How should i use smbios.I read its PDF but there was nothing to help me.Guid please

: How should i use smbios.I read its PDF but there was nothing to help : me.: Guid please

Not true.*Everything* you need is in the PDF, you just didn't understand it.

You are probably trying to do something too complicated, especially since you are new to x86 programming. This is not easy stuff to do, especially in assembly.

Chapter 2 in the spec tells you how to access the SMBIOS information:

"On non-EFI systems, the SMBIOS Entry Point structure, described below, can be located by application software by searching for the anchor-string on paragraph (16-byte) boundaries within the physical memory address range000F0000h to 000FFFFFh."

That means you must write a routine to search memory looking for a key signature. That key is "_SM_"

The code that I pointed you to does something similar with ACPI-it searches for a key named "RSD PTR" in the routine rsdptrSearch. If you change that key in my code to "_SM_" you will now have step 1 completed!

The address you find _SM_ + 18h is the offset of a 32bit pointer to where all the SMBIOS data lives in memory. There is other information in this table that you will also want to know (SMBIOS version at _SM_+6, # of tables at _SM_+1ch)

From DOS (or other real mode environment) in order to access the data at that high location in memory, you will need to put the CPU into protected mode. I put it into flat real mode in my example code. (routine is called himeminit)

From there it's a matter of reading the data out of memory and displaying it the way you want. The structure of each table is defined in section 3.

My ACPI code does the same type of work. If you download the ACPI specification you will find it is very similar in the way tables are organized in memory, and that may help you understand my code a little better too.

: : How should i use smbios.I read its PDF but there was nothing to help : : me.: : Guid please: : Not true.: *Everything* you need is in the PDF, you just didn't understand it.: : You are probably trying to do something too complicated, especially : since you are new to x86 programming. This is not easy stuff to do, : especially in assembly.: : Chapter 2 in the spec tells you how to access the SMBIOS information:: : "On non-EFI systems, the SMBIOS Entry Point structure, described : below, can be located by application software by searching for the : anchor-string on paragraph (16-byte) boundaries within the physical : memory address range: 000F0000h to 000FFFFFh.": : That means you must write a routine to search memory looking for a : key signature. That key is "_SM_": : The code that I pointed you to does something similar with ACPI-it : searches for a key named "RSD PTR" in the routine rsdptrSearch. If : you change that key in my code to "_SM_" you will now have step 1 : completed!: : The address you find _SM_ + 18h is the offset of a 32bit pointer to : where all the SMBIOS data lives in memory. There is other : information in this table that you will also want to know (SMBIOS : version at _SM_+6, # of tables at _SM_+1ch) : : From DOS (or other real mode environment) in order to access the : data at that high location in memory, you will need to put the CPU : into protected mode. I put it into flat real mode in my example : code. (routine is called himeminit): : From there it's a matter of reading the data out of memory and : displaying it the way you want. The structure of each table is : defined in section 3.: : My ACPI code does the same type of work. If you download the ACPI : specification you will find it is very similar in the way tables are : organized in memory, and that may help you understand my code a : little better too.

: Hi.: : I found DMIDecode.c Source code but it is Written in C.: Know i want to Make a disk that in sector 0 is bootloader and in : sector 1 is dmidecode.what should i do?guide please :

Could you possibly make this any more difficult for yourself? Reading DMI and creating bootsector loaders are *not* beginner tasks. I'll be very impressed if you get this to work without giving up after becoming too frustrated.

I'd make the dmicode.c into a DOS .COM program first. It's MUCH easier to debug and test your code by executing it in DOS than putting it onto a bootsector and rebooting the computer to test every change.

Your program will not be able to use any DOS functions (ie, no INT 21h to print a text string) because from a bootsector, you only have BIOS functions available to you.

Once you have a clean .COM program that works the way you want, it is just a matter of copying it to sector 1 (you'll likely need more than just 512 bytes). You shouldn't need to change any code between DOS .COM and a bootsector. There are lots of examples out there of bootsector code, so that should be easy to find.

: : Hi.: : : : I found DMIDecode.c Source code but it is Written in C.: : Know i want to Make a disk that in sector 0 is bootloader and in : : sector 1 is dmidecode.what should i do?guide please : : : : Could you possibly make this any more difficult for yourself? : Reading DMI and creating bootsector loaders are *not* beginner : tasks. I'll be very impressed if you get this to work without giving : up after becoming too frustrated.: : I'd make the dmicode.c into a DOS .COM program first. It's MUCH : easier to debug and test your code by executing it in DOS than : putting it onto a bootsector and rebooting the computer to test : every change.: : Your program will not be able to use any DOS functions (ie, no INT : 21h to print a text string) because from a bootsector, you only have : BIOS functions available to you.: : Once you have a clean .COM program that works the way you want, it : is just a matter of copying it to sector 1 (you'll likely need more : than just 512 bytes). You shouldn't need to change any code between : DOS .COM and a bootsector. There are lots of examples out there of : bootsector code, so that should be easy to find.: : -jeff!: : and now how can u help me?what should i do?can i use lilo bootloader and demidecode mudule?u know dmidecode is linux module

: and now how can u help me?what should i do?can i use lilo bootloader : and demidecode mudule?u know dmidecode is linux module

You probably could use lilo and this dmicode-I don't know linux well, and you're no longer really working in x86 assembly at that point, so I am unable to help you any further.

What I'd do is write some code in DOS. Start with INT 12h like you first stated, get that information printing to the screen. There are lots of other bits of information you can get from the BIOS Data Area and other interrupts.

That will get you familiar with assembly language.

Then move into converting a small DOS program into a bootloader, which is not that difficult of a step. Meanwhile, tackling DMI and other hardware detection, once you've got some of the basics down, isn't a huge task, but there are many more steps involved than just "int 12" to get the data.

assembly is slow. if your goal is to learn assembly, you need to do lots of "hello world!" programs to get the hang of it first. If you want to learn how to detect hardware and display it all to the screen, perhaps assembly is too much work to make nice displays.

I found one of my first assembly programs that detects hardware and prints it to the screen. 1993! I can't believe I'm posting this...

I used MASM to compile this to a DOS .COM file.

[code];info;displays a few system stats. I want to be able to figure out processor speeds!