Page 1 of 1

ACPI Revision 2 Problem Detecting MADT

Posted: Tue Mar 17, 2015 11:06 am
by kemosparc
Hi,

I am trying to parse the ACPI tables.

On QEMU I have ACPI version 1 and as soon as I detect the signature of the RSDP "RSD PTR " I load the RSDT pointer and can parse it successfully. I just basically find the APIC signature and I can parse the MADT.

When I run my OS on a real computer with ACPI Revision 2, instead of following the rsdtAddr field in the RSDP struct I followed the address in xsdtAddr.

My problem is that while looping on the address range, I can only detect FADT (0x50434146) signature but I can not detect the APIC signature (0x43495041).

I printed the SMI_CommandPort, AcpiEnable, and AcpiDisable and I found them not zero, so I guessed that I need to enable it through writing to the port SMI_CommandPort with the value AcpiEnable as described in http://wiki.osdev.org/ACPI, but I still cannot detect the APIC signature to be able to detect the APIC records and the count number of cores.

I tried this with different real hardware that has revision 2 and it gives the same symptom.

Anything I could be missing?

Thanks
Karim.

Re: ACPI Revision 2 Problem Detecting MADT

Posted: Tue Mar 17, 2015 12:01 pm
by jnc100
Do you mean you only have one entry in the XSDT, and its the FACP, or you have lots but none is the MADT? Have you tried enumerating all the entries to see which tables you actually do have and printing them somehow. Also, do you definitely start enumerating in the right place (i.e. is sizeof(xsdt_header) == 36)?

Regards,
John.

Re: ACPI Revision 2 Problem Detecting MADT

Posted: Tue Mar 17, 2015 2:19 pm
by Brendan
Hi,
kemosparc wrote:I printed the SMI_CommandPort, AcpiEnable, and AcpiDisable and I found them not zero, so I guessed that I need to enable it through writing to the port SMI_CommandPort with the value AcpiEnable as described in http://wiki.osdev.org/ACPI, but I still cannot detect the APIC signature to be able to detect the APIC records and the count number of cores.
Do not write to the SMI_CommandPort until after you have a full AML interpreter that is ready to take control of power management from the firmware's SMI handler that is capable of handling ACPI events properly (including "your motherboard is going to melt if you don't do something now" events).


Cheers,

Brendan