Reading ACPI Tables

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
limp
Member
Member
Posts: 90
Joined: Fri Jun 12, 2009 7:18 am

Reading ACPI Tables

Post by limp »

Hi all,

I am trying to read the ACPI - MADT Table but I am having some difficulties, but let's take the things from the beginning:

Initially I am locating successfully the RSDP and from there I am taking the address of the RDST. I then going to the RDST, do a checksum and going at the start of the entry field to start searching for the MADT signature. As far I as I understand, the length of the whole RDST, including the 32-bit entries which have the physical addresses, is given by the "Length" field of the structure. So, I am going to the begging of the entry field and start searching for a maximum of "Length" bytes for the MADT signature. However, I am not able to find it. Am I doing something wrong?

Thank you in advance for any help.
geppyfx
Member
Member
Posts: 87
Joined: Tue Apr 28, 2009 4:58 pm

Re: Reading ACPI Tables

Post by geppyfx »

limp wrote:I am going to the begging of the entry field and start searching for a maximum of "Length" bytes for the MADT signature.
You go to the beginning of the entry filed, subtract 36 from "Length" and go thru every 4bait entry. Each entry contains address. For the MADT table this address will point to the MADT table which starts with "APIC" signature.
Bochs precompiled for windows from official website has MADT table. Test you code there.
limp
Member
Member
Posts: 90
Joined: Fri Jun 12, 2009 7:18 am

Re: Reading ACPI Tables

Post by limp »

Thank you very much for the response.
You go to the beginning of the entry filed, subtract 36 from "Length" and go thru every 4bait entry. Each entry contains address. For the MADT table this address will point to the MADT table which starts with "APIC" signature.
That's what I am doing but I am not finding anything :(

In my case, the RDST is detected at 0x1F6FD038 and the length is 0x38, so I am searching from 0x1F6FD05C for the next 20 bytes (that is 5 possible entries) but I am not finding anything.

The weird thing is that if I continue the searching, I found 5 MADT at 0x31024, 0x109024, 0x196ACC, 0x1F34321C, 0x1F6F6000
(the qemu that runs at the host system founds RSDT at 0x7FF00000 and 5 MADT, at 0x41024, 0x197804, 0x197824, 0x7FF0938, 0x7FF094C)

(It will probably find more MADT's if I leave it scanning more memory)

It's very strange that I am not finding the MADT addresses from the Entry field of the RSDT and that various MADT's exist all around the memory and not in neighbour memory locations. Also, why I have 5 (they should be 4)?

In the RDST structure I have declared (but I don't think that it does matter) only 1 field at the end of the structure like that:

uint32_t table_offset_entry[1];

but I am continuing the searching as long I am below (RDST->lenght - 36)

I've spent quite a time to find out what's going on but unfortunately without any luck.

Any help will much appreciated,

Thanks again.
Post Reply