Hi,
one thing that is generically missing in LinuxBIOS' ACPI implementation is the detailed system description table (DSDT The part telling whether there is a lid and how detect whether it is open or closed)
The DSDT is written in ASL which is compiled to AML bytecode using an ASL compiler (ie. Intel's iasl) Thus, a LinuxBIOS port implementing a DSDT needs either to come with a precompiled DSDT or it needs an installed ASL compiler. What is the preferred default behaviour? Do we want to add ASL source code or rather have something that keeps the build requirements for those boards as small as possible. Or we can pack both the ASL and AML version of the DSDT and have the build process use the precompiled code only. This on the other hand requires developers to take care that they check in a new binary version when they change something to the ASL code. CVS is not doing too well with binary stuff..
Opinions?
Stefan
Stefan Reinauer wrote:
Hi,
one thing that is generically missing in LinuxBIOS' ACPI implementation is the detailed system description table (DSDT The part telling whether there is a lid and how detect whether it is open or closed)
The DSDT is written in ASL which is compiled to AML bytecode using an ASL compiler (ie. Intel's iasl) Thus, a LinuxBIOS port implementing a DSDT needs either to come with a precompiled DSDT or it needs an installed ASL compiler. What is the preferred default behaviour? Do we want to add ASL source code or rather have something that keeps the build requirements for those boards as small as possible. Or we can pack both the ASL and AML version of the DSDT and have the build process use the precompiled code only. This on the other hand requires developers to take care that they check in a new binary version when they change something to the ASL code. CVS is not doing too well with binary stuff..
Opinions?
Some links on ASL and DSDT:
http://developer.intel.com/technology/iapc/acpi/downloads.htm
http://www.acpi.info/toolkit.htm
http://www.cpqlinux.com/acpi-howto.html
http://acpi.sourceforge.net/dsdt/index.php
-Bari
or you can translate the acpi tables to Something Else (e.g. e-expressions -- it works) and use that instead.
acpi is a big problem, partly due to the binary nature and partly because it is so broken on so many platforms.
ron
ron minnich wrote:
acpi is a big problem, partly due to the binary nature and partly because it is so broken on so many platforms.
ron
Speaking of ACPI and problems, which are commented on in this article, is this Intel announcement of open sourcing the BIOS something new?
http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-73...
-Steve
Here's the official Intel statement:
http://www.intel.com/pressroom/archive/releases/20040601corp_a.htm
-Bari
Steve Gehlbach wrote:
ron minnich wrote:
acpi is a big problem, partly due to the binary nature and partly because it is so broken on so many platforms.
ron
Speaking of ACPI and problems, which are commented on in this article, is this Intel announcement of open sourcing the BIOS something new?
http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-73...
-Steve
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Tue, 1 Jun 2004, Bari Ari wrote:
Here's the official Intel statement:
http://www.intel.com/pressroom/archive/releases/20040601corp_a.htm
gee, no mention of linuxbios :-)
ron
On Tue, 1 Jun 2004, Steve Gehlbach wrote:
Speaking of ACPI and problems, which are commented on in this article, is this Intel announcement of open sourcing the BIOS something new?
http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-73...
You are not going to get the hardware startup code in Tiano. You're going to get the code that runs on top of the hardware startup code, and gives you a DOS-like startup system. Don't expect to suddenly see northbridge code on the intel web site. Part of the goal of Tiano/EFI is to make the release of such information unneeded.
There is a silver lining. Supposedly, the interfaces from the hidden hardware code to Tiano will be public. This means you can conceivably chuck Tiano and put your own thing in its place, which could be ... a Linux kernel! You might need a small shim from the hidden hardware code to Linux, which could in turn be ... LinuxBIOS!
This is how Linux NetWorx built the Alpha LinuxBIOS: - hidden hardware code (Alpha SROM) [ not changed, left in place] - LinuxBIOS [with Alpha support, minus memory setup code] - Linux
Worked fine, should work for Tiano platforms. In other words, the binary support code for Tiano could solve some problems for us: - if we don't get the specs for the Intel chips (likely), then we can just leave the "hidden hardware code" in place, and flash over Tiano, replacing Tiano with LinuxBIOS. I believe Linux Labs did something like this for their ClearWater port 2 years or so ago. - Makes porting to other Intel mobos easier.
Why the CPL, not the GPL? So that 3rd party vendors can add incompatibilities -- err, value -- and charge you for it.
Put another way, Tiano could be a linuxbios payload. I don't have much use for a Tiano/EFI payload, however. Tiano/EFI is very complex and if I'm going to put a complex thing like that into flash I'd much rather it be linux. I don't want something that's most of the work of an OS but not much of the capability, which pretty much describes Tiano/EFI.
I'm intrigued that they are open sourcing it. I had for years only heard that it would be available under a type of NDA. I think LinuxBIOS is part of the push for open sourcing this type of software. But I doubt you're going to see Phoenix et. al. open source their 'value-added' Tiano, which means a source fork is built into the model. That's trouble for us as customers -- we already suffer daily with all these BIOS extensions and undocumented, hidden gotchas. We already say this once: there was supposed to be a standard "hand off" on IA64 for startup. I found out that this "standard" handoff was modified by several vendors: it was no longer standard. Let's hope the "hidden hardware code" to Tiano interface remains standard.
Also, if this code is anything like the EFI code, it won't build under Linux, only builds under Windows. It won't "just work" for us.
All that said, I think Intel is doing a good thing by open sourcing the Tiano system, and I congratulate them on doing so.
ron
ron minnich rminnich@lanl.gov writes:
Worked fine.
The alpha port worked but it is not something I savor repeating, there were too many real limitations.
There are some things that I find strongly architecturally questionable about Tiano, in the context of Intel hardware. Unfortunately neither Tiano or the Intel hardware I am thinking about has been released...
Consider what it takes to maintain a cache-as-ram implementation.
Eric
On 1 Jun 2004, Eric W. Biederman wrote:
The alpha port worked but it is not something I savor repeating, there were too many real limitations.
yes, but by golly we sure got some use out of it! We appreciated your work :-)
There are some things that I find strongly architecturally questionable about Tiano, in the context of Intel hardware. Unfortunately neither Tiano or the Intel hardware I am thinking about has been released...
agreed. Let's see if we get much more than PR.
ron
also, one of the huge advantages of the linuxBIOS Is that it allows to workaround bugs in the hardware and firmware. If we decide to go with Tiano's hardware startup code we lose some of this flexibility. something to keep in mind.
it reminds me all the nightmare linux has with its binary only modules and hal's. There's no binary only driver for driver foo for linux on ppc? too bad
On Tue, 1 Jun 2004, ron minnich wrote:
On Tue, 1 Jun 2004, Steve Gehlbach wrote:
Speaking of ACPI and problems, which are commented on in this article, is this Intel announcement of open sourcing the BIOS something new?
http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-73...
You are not going to get the hardware startup code in Tiano. You're going to get the code that runs on top of the hardware startup code, and gives you a DOS-like startup system. Don't expect to suddenly see northbridge code on the intel web site. Part of the goal of Tiano/EFI is to make the release of such information unneeded.
There is a silver lining. Supposedly, the interfaces from the hidden hardware code to Tiano will be public. This means you can conceivably chuck Tiano and put your own thing in its place, which could be ... a Linux kernel! You might need a small shim from the hidden hardware code to Linux, which could in turn be ... LinuxBIOS!
This is how Linux NetWorx built the Alpha LinuxBIOS:
- hidden hardware code (Alpha SROM) [ not changed, left in place]
- LinuxBIOS [with Alpha support, minus memory setup code]
- Linux
Worked fine, should work for Tiano platforms. In other words, the binary support code for Tiano could solve some problems for us:
- if we don't get the specs for the Intel chips (likely), then we can just leave the "hidden hardware code" in place, and flash over Tiano, replacing Tiano with LinuxBIOS. I believe Linux Labs did something like this for their ClearWater port 2 years or so ago.
- Makes porting to other Intel mobos easier.
Why the CPL, not the GPL? So that 3rd party vendors can add incompatibilities -- err, value -- and charge you for it.
Put another way, Tiano could be a linuxbios payload. I don't have much use for a Tiano/EFI payload, however. Tiano/EFI is very complex and if I'm going to put a complex thing like that into flash I'd much rather it be linux. I don't want something that's most of the work of an OS but not much of the capability, which pretty much describes Tiano/EFI.
I'm intrigued that they are open sourcing it. I had for years only heard that it would be available under a type of NDA. I think LinuxBIOS is part of the push for open sourcing this type of software. But I doubt you're going to see Phoenix et. al. open source their 'value-added' Tiano, which means a source fork is built into the model. That's trouble for us as customers -- we already suffer daily with all these BIOS extensions and undocumented, hidden gotchas. We already say this once: there was supposed to be a standard "hand off" on IA64 for startup. I found out that this "standard" handoff was modified by several vendors: it was no longer standard. Let's hope the "hidden hardware code" to Tiano interface remains standard.
Also, if this code is anything like the EFI code, it won't build under Linux, only builds under Windows. It won't "just work" for us.
All that said, I think Intel is doing a good thing by open sourcing the Tiano system, and I congratulate them on doing so.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Steve Gehlbach steve@nexpath.com writes:
ron minnich wrote:
acpi is a big problem, partly due to the binary nature and partly because it is so broken on so many platforms.
ron
Speaking of ACPI and problems, which are commented on in this article, is this Intel announcement of open sourcing the BIOS something new?
EFI/Tiano uses ACPI so you don't get out of that loop.
That Intel will be releasing code is new, although there have been some sympathies in that direction. I'm really not interested until they actually release something.
Eric
On 1 Jun 2004, Eric W. Biederman wrote:
That Intel will be releasing code is new, although there have been some sympathies in that direction. I'm really not interested until they actually release something.
Should probably also mention: there's lots of binary in this EFI/Tiano thing. Binary drivers, for example. The goal is that EFI/Tiano should provide a framework for a mostly binary system (chipsets, drivers, etc. are binary).
ron
* Steve Gehlbach steve@nexpath.com [040602 00:35]:
Speaking of ACPI and problems, which are commented on in this article, is this Intel announcement of open sourcing the BIOS something new?
http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-73...
What did they change, the license? They have had parts of EFI sources on their web server for quite some years now. Reading the EFI specification should be enough reason not to look into the code. It's really all-embracing. Besides that the source license was critical for firmware developers (IANAL).
Standards are a fine thing. Let's have everybody implement it's own.
Stefan
Stefan Reinauer stepan@openbios.org writes:
Standards are a fine thing. Let's have everybody implement it's own.
One thing about EFI that really sucks is that it is just absolutely chock full of pointers in it's interfaces. Which makes it extremely ugly to support on platforms with both a 32/64bit platforms. At least that is what it looks like to me.
Eric
Stefan Reinauer stepan@openbios.org writes:
Hi,
one thing that is generically missing in LinuxBIOS' ACPI implementation is the detailed system description table (DSDT The part telling whether there is a lid and how detect whether it is open or closed)
The DSDT is written in ASL which is compiled to AML bytecode using an ASL compiler (ie. Intel's iasl) Thus, a LinuxBIOS port implementing a DSDT needs either to come with a precompiled DSDT or it needs an installed ASL compiler. What is the preferred default behaviour?
Code we can correct and maintain so an ASL compiler.
Do we want to add ASL source code or rather have something that keeps the build requirements for those boards as small as possible.
We can put the code in the tree if necessary.
Or we can pack both the ASL and AML version of the DSDT and have the build process use the precompiled code only. This on the other hand requires developers to take care that they check in a new binary version when they change something to the ASL code. CVS is not doing too well with binary stuff..
Not having the source is really not GPL compatible. We need the preferred form for making modifications.
We certainly need to provide this information, as all motherboard specific information is the province of the motherboard firmware. However I'm not at all convinced that the ACPI tables are the right approach.
At any rate we need to really solve some of the more mundane issues like irq routing properly before we go to far with this.
Eric
Hi,
* Eric W. Biederman ebiederman@lnxi.com [040602 06:33]:
We certainly need to provide this information, as all motherboard specific information is the province of the motherboard firmware. However I'm not at all convinced that the ACPI tables are the right approach.
Can you go a bit into detail with this? In earlier discussions I understood your standpoint as clearly on the table based side. Whether such a table is called ACPI or LBTable is imho just a minor implementation detail with the one being supported by more OSes and companies while the other is definitely the one with the cleaner design.
At any rate we need to really solve some of the more mundane issues like irq routing properly before we go to far with this.
Much of this can be described in ACPI tables, dropping the need for MPtables and PIRQ tables. I think the modular concept of LinuxBIOS really allows developers to address one issue without hurting another. The current way of irq routing is less than elegant, I agree, but it does it's job, taking the all-monthly fixing behind into regard.
Stefan
Stefan Reinauer stepan@openbios.org writes:
Hi,
- Eric W. Biederman ebiederman@lnxi.com [040602 06:33]:
We certainly need to provide this information, as all motherboard specific information is the province of the motherboard firmware. However I'm not at all convinced that the ACPI tables are the right approach.
Can you go a bit into detail with this? In earlier discussions I understood your standpoint as clearly on the table based side. Whether such a table is called ACPI or LBTable is imho just a minor implementation detail with the one being supported by more OSes and companies while the other is definitely the one with the cleaner design.
At that point I was thinking AML... Tables are certainly a good thing. A bad excuse for byte code...
At any rate we need to really solve some of the more mundane issues like irq routing properly before we go to far with this.
Much of this can be described in ACPI tables, dropping the need for MPtables and PIRQ tables. I think the modular concept of LinuxBIOS really allows developers to address one issue without hurting another. The current way of irq routing is less than elegant, I agree, but it does it's job, taking the all-monthly fixing behind into regard.
I guess what I am after is enough structure so that it is hard to implement something wrong. Either it is implemented correctly or it is not implemented. We largely have this in LinuxBIOS because we use the information we export. This is not a property I want to loose.
Eric
-
Adam Sulmicki -
Bari Ari -
ebiederman＠lnxi.com -
ron minnich -
Stefan Reinauer -
Steve Gehlbach