ACPI DSDT

[Adam Sulmicki]

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-7337_3-5223860.html?tag=nefd.top
>
> 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 at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>