OSDev.org

Does the BIOS continue to update the BDA and EBDA after you enter PM?

No.
Once you clear interrupts or enter protected mode, the bios code wont be called anymore. So any changes to the (E)BDA are yours.

YES! If you use any BIOS calls, like INT 10h, to update teh cursor position, or the number of rows and columns in text mode, ABSOLUTELY! If the OS uses BIOS, the BIOS updates those areas that are needed for tracking and communication purposes.

However, if you don't intend on using the BIOS you are welcome to destroy those areas. In fact, you can also turn off interrupts and not use them too, to run programs or an OS as a polling type OS (you can potentially move the entire IVT somewhere else too, but that's another story). This way you can use all the memory just for your OS. Now, I wouldn't recommend this since it is likely you'll need some BIOS functions to get started and it is possible you'll need some of the ROMs in the areas between (Linear) C0000h - EFFFFh, not to mention video memory from A0000h to BFFFFh.

I recommend you find out information about INT 15h AX=E820h. Specifically what can potentially be returned and what those areas are and how they can be used. Additionally, it would be wise to buy a book on the Intel Archetecture (or the 68000 series processors, different processors but they give you a perspective of some similarities and the differences and uses) as it were for mainstream desktop/server computing systems.

Hi,

The BDA can be safely trashed as long as you're not using the BIOS (including virtual 80x86 and functions designed for protected mode, like the PCI BIOS functions).

For the EBDA there's things that are used by ACPI and SMM. If your OS doesn't enable "ACPI mode" and lets the BIOS control power management, etc using SMM, then I think it's safe to trash the EBDA. If your OS does enable "ACPI mode" then there's a communication buffer in the EBDA that ACPI uses to communication with the BIOS's SMM handler, and the EBDA can't be trashed.


Cheers,

Brendan

Brendan wrote:For the EBDA there's things that are used by ACPI and SMM. If your OS doesn't enable "ACPI mode" and lets the BIOS control power management, etc using SMM, then I think it's safe to trash the EBDA. If your OS does enable "ACPI mode" then there's a communication buffer in the EBDA that ACPI uses to communication with the BIOS's SMM handler, and the EBDA can't be trashed.

Isn't there another area for ACPI at the top of physical memory? Is that only for the tables or is there communication going on there too? I haven't read that far into it to know yet...and expect you're the SME of ACPI here.

Hi,

smiddy wrote:

Brendan wrote:For the EBDA there's things that are used by ACPI and SMM. If your OS doesn't enable "ACPI mode" and lets the BIOS control power management, etc using SMM, then I think it's safe to trash the EBDA. If your OS does enable "ACPI mode" then there's a communication buffer in the EBDA that ACPI uses to communication with the BIOS's SMM handler, and the EBDA can't be trashed.

Isn't there another area for ACPI at the top of physical memory? Is that only for the tables or is there communication going on there too? I haven't read that far into it to know yet...and expect you're the SME of ACPI here.

There's an "ACPI NVRAM area", which (AFAIK) mostly contains a copy of CMOS contents so that the BIOS's code can access it without worrying about sychronisation issues with other software trying to access the CMOS's index and data ports at the same time. This area may not be present (older BIOSs or BIOSs/chipsets that support an alternative way of accessing CMOS). This is usually at the highest addresses in RAM (if present), and isn't meant to be used by the OS itself.

Then there's an "ACPI reclaimable area", which contains the ACPI tables and associated things used by the OS during boot. This is often also at the highest addresses in RAM (e.g. just below the NVRAM area). When the OS has finished using this area it can overwrite it and use it as normal RAM.

The area I mentioned earlier is the FACS (Firmware ACPI Control Structure). From the ACPI specification:

Firmware ACPI Control Structure (FACS)
A structure in read/write memory that the BIOS uses for handshaking between the firmware and the OS. FACS is passed to an ACPI-compatible OS via the Fixed ACPI Description Table (FADT). The FACS contains the system's hardware signature at last boot, the firmware waking vector, and the Global Lock.

And then later on:

5.2.9.1 Global Lock
The purpose of the ACPI Global Lock is to provide mutual exclusion between the host OS and the ROM BIOS. The Global Lock is a 32-bit (DWORD) value in read/write memory located within the FACS and is accessed and updated by both the OS environment and the SMI environment in a defined manner to provide an exclusive lock. Note: this is not a pointer to the Global Lock, it is the actual memory location of the lock. The FACS and Global lock may be located anywhere in physical memory.

The specification does say "anywhere in physical memory", but where can the BIOS safely put it? You'd be lucky to find more than 8 unused bytes in the BDA (and protected mode OSs have a habit of trashing that anyway), and the ACPI reclaimable area is meant to be re-used. This leaves the ACPI NVRAM area (which may or may not exist) and the EBDA.


Cheers,

Brendan

I assume this is from ACPIspec30a, right?

Is there any publication available commercially about ACPI? (I apologize to those who moderate on my refocus of this thread)

It looks like the FACS is outside the OS' ACPI driver and outside the Differential Definition Block. It also looks like in table 5-12 that the Firmware_Waking_Vector from the table:

• On PCs, the wake function address is in memory below 1 MB
  and the control is transferred while in real mode. OSPM’s
  wake function restores the processors’ context.

I also seem to recall that if E820h recongnizes the EBDA then it is likely to be used for ACPI. But I can't find a reference.

There is some code in there on global lock, but it doesn't reference any particluar address location, it is based off the ACPI table.

Enough reading and writing here. Suffice it to say, you're correct most OS' do trash those areas, however my own work I am very careful not to destroy those areas because I have been currently flip-flopping back-and-forth between realmode and protectedmode with my own OS, so I painstakingly save the IVT, BIOS, and DOS areas and restore them everytime, this also means IRQs too. Everything I'm doing thus far seems to work, but I haven't put it to a very stringent test either since I am not able to load and run external programs yet, since I haven't yet put a strategy in place for it. I have worked on a stratgey for drivers, but have yet to difinitize it mainly because I want to nail down my device manager. It is looking more and more like I will be heading down the ACPI path myself.

Thanks for the input...perhaps I'll get to a point soon where we can colaborate.

Hi,

smiddy wrote:I assume this is from ACPIspec30a, right?

The parts I quoted were from ACPI Version 2.0c I think. It shouldn't make much difference though - the Global Lock and FACS existed since the earliest versions of the specification.

smiddy wrote:Enough reading and writing here. Suffice it to say, you're correct most OS' do trash those areas, however my own work I am very careful not to destroy those areas because I have been currently flip-flopping back-and-forth between realmode and protectedmode with my own OS, so I painstakingly save the IVT, BIOS, and DOS areas and restore them everytime, this also means IRQs too. Everything I'm doing thus far seems to work, but I haven't put it to a very stringent test either since I am not able to load and run external programs yet, since I haven't yet put a strategy in place for it. I have worked on a stratgey for drivers, but have yet to difinitize it mainly because I want to nail down my device manager. It is looking more and more like I will be heading down the ACPI path myself.

I took a long (but superficial) look at ACPI, and to be honest, I'm hoping to avoid it completely. It's a difficult thing to support properly, and has some aspects to it that I didn't quite appreciate. Parts of the AML code may behave differently depending on what version (of Windows) the OS tells the AML code it is (which means an OS developer needs to know how Windows interacts with AML in specific circumstances, which isn't publicly available information AFAIK). I'm also not sure I like the idea of giving control of power management and configuration to some (potentially buggy) interpretted code.

Lastly, I've been wondering how hard it'd be to burn my OS onto ROM chips for embedded devices, where there's a little chipset configuration code and a small boot loader that loads/decompresses my boot image from ROM, with no real BIOS at all. The "very modular" design of my OS should make this relatively easy (individual modules may need to be modified but the majority of the OS could be used without change), but the more I rely on the BIOS the harder this will become.

I guess for now my plan is to be a "non-ACPI" OS, with chipset/motherboard drivers providing the functionality that ACPI would've provided if it was used...


Cheers,

Brendan

Well, when I said I'd stop reading, I didn't. There is a lot of complexity there, I agree. And too, if you want to use the tools from Intel, they make them specifically for Windows mainly. I'm not sure there is an entire connection there, in other owrds, that due to Windows functionality with ACPI, then your OS is bound by that (I'd have to research that more). I have read the fears out there about the potential bugs and the unknowns. I think it is a natural human, for lack of another work, emotion to fear the unknown and put trust into something we don't control.

I did however find this: http://developer.intel.com/technology/i ... rogRef.pdf

As well as other documents from Intel's site linked off that page, but I think that may be moot here.

I can't recall where I read it, it may have been one of the OS Design books out there, that OS/2 did everything to start up, in the early days, I can't say for now, by doing probes of (hopeful) devices. I think that may have been pre-PCI. It covered PnP and I think was tightly woven in the 80286 protected mode.

Could you limit your design to PCI only systems? Or would you want to? your construct has been to use a networked systems design, so potentially you might use another machines resources for one machine, so potentially you only need rudementary designed system with a NIC (assuming Ethernet interface) on some machines, but others might have everything needed in order to compute what is needed, say for instance floating point math at the 128-bit level, which for an 8086/88 would be a tedious task of emulation, but shipping the computational needs off to another computer capable of doing it, then shipping it back for inclusion would be a great thing. Is this right? Interesting!