Hi..
well
searching both the wiki, and google, im not able to find any information on the EBDA layout ( what it excatly contain, and where....)
so i woul like to hear if any had some documents on it, or just something, since all says that it is usefull for os ..
KMT dk
EBDA layout ????
EBDA layout ????
well, what to say, to much to do in too little space.
when it goes up hill, increase work, when it goes straight, test yourself but when going down, slow down.
when it goes up hill, increase work, when it goes straight, test yourself but when going down, slow down.
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: EBDA layout ????
The EBDA isn't standard, unlike a good chunk of the BDA. It really depends on the BIOS itself, unfortunately
- NickJohnson
- Member
- Posts: 1249
- Joined: Tue Mar 24, 2009 8:11 pm
- Location: Sunnyvale, California
Re: EBDA layout ????
So what exactly is the point of the EBDA if there's no way you can consistently interface with it? It seems like it benefits no one for the BIOS writers to be inconsistent.
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: EBDA layout ????
Let me rephrase that; the EBDA isn't universally standardized, therefore there may be three or four different "standards" and implementations. I'm not sure what the most "standard" of these standards is, however.
Re: EBDA layout ????
Hi,
It's the same for the BIOS. During run-time the BIOS can only modify data in the BDA or the EBDA, and the BDA must comply with established standards dating back several decades. Thankfully, the BIOS can use the EBDA in any way it likes, which is the only reason why the BIOS is able to support things that didn't exist when the EBDA was first invented.
Of course the downside here is that the EBDA isn't standardized, but that only means that software can't understand data that it doesn't need to understand.
Cheers,
Brendan
Could you imagine writing a kernel, where during run-time the kernel can only modify data in 2 areas (".bss1" and ".bss2"), and both areas must comply with established standards dating back several decades? It'd be virtually impossible to do anything differently - no new features, no improvements on old features, no support for new hardware, etc.NickJohnson wrote:So what exactly is the point of the EBDA if there's no way you can consistently interface with it? It seems like it benefits no one for the BIOS writers to be inconsistent.
It's the same for the BIOS. During run-time the BIOS can only modify data in the BDA or the EBDA, and the BDA must comply with established standards dating back several decades. Thankfully, the BIOS can use the EBDA in any way it likes, which is the only reason why the BIOS is able to support things that didn't exist when the EBDA was first invented.
Of course the downside here is that the EBDA isn't standardized, but that only means that software can't understand data that it doesn't need to understand.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- Troy Martin
- Member
- Posts: 1686
- Joined: Fri Apr 18, 2008 4:40 pm
- Location: Langley, Vancouver, BC, Canada
- Contact:
Re: EBDA layout ????
Brendan, you're more knowledgeable about this kind of crap than me; is there at least a chunk of the EBDA that is either standardized or roughly the same in most implementations?
Re: EBDA layout ????
Hi,
There's also some things that may be inside the EBDA that do comply with certain specifications; like the MP specification tables (the floating pointer structure and/or the tables themselves), the ACPI "FACS" (Firmware ACPI Control Structure), and maybe data for SMBIOS, APM, etc. The corresponding specifications will tell you how you're meant to find things - you can't assume that any of these things will be at any specific address in the EBDA, or that they'll actually be in the EBDA at all.
Cheers,
Brendan
From what I remember, the first word is meant to contain the size of the EBDA in KiB. Of course "meant to" doesn't necessarily imply "always will, on all past, present and future systems".Troy Martin wrote:Brendan, you're more knowledgeable about this kind of crap than me; is there at least a chunk of the EBDA that is either standardized or roughly the same in most implementations?
There's also some things that may be inside the EBDA that do comply with certain specifications; like the MP specification tables (the floating pointer structure and/or the tables themselves), the ACPI "FACS" (Firmware ACPI Control Structure), and maybe data for SMBIOS, APM, etc. The corresponding specifications will tell you how you're meant to find things - you can't assume that any of these things will be at any specific address in the EBDA, or that they'll actually be in the EBDA at all.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.