OSDev.org

Just by accident I discovered that the reason my Intel CoreDuo machine didn't want to boot with the ACPICA driver was because I had removed legacy BIOS, DOS & DPMI support + the emulator. Once this is brought back, the driver boots just fine, and outputs a long list of entries. Interestingly, if I remove legacy support from the AMD-configuration, it doesn't boot either, but hangs in a similar manner.

Does anybody know if the AML code refers to BIOS data or code? Because when I remove legacy support, I also remove all mappings of BIOS and below 1MB RAM, and set it as unavailable. Or could it be the SMI manager replacement that does this?

Nothing AML wise should require you to execute any real mode code if that's what you're asking. You'll still potentially need to access the first megabyte of memory though, at a minimum to locate the RSDP on a machine with BIOS. Technically the entirety of system memory space needs to be accessible by ACPI, however most of this should be done on the fly through your VMM via the AcpiOsMapMemory and AcpiOsUnmapMemory calls.

I start to suspect that I place the ACPI tables in the free physical memory pool. That's probably why the two initial steps, which runs at device-driver initialization time work, and the first stage with tasking enabled hangs.

I have checked the OS-provided functions, and there is no direct support for reading linear memory below 1MB, only for reading physical memory below 1MB. Thus if ACPI-tables are not available, it should be because the physical addresses have been overwritten. I cannot see any actual reason why they would become overwritten if the emulator is not present. What the emulator seems to do is to change flat_base (for applications) from 0 to a value above 1MB in order for DOS/BIOS not to colide with flat-memory applications.