Stallman rants about FreeBIOS

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

I guess we will need a FreeBIOS eventually before DRM totally stops us
from even booting our PCs.

» Stallman's new campaign to free the BIOS | Open Source | ZDNet.com
http://blogs.zdnet.com/open-source/index.php?p=179

Yousuf Khan

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On 7 Mar 2005 13:31:09 -0800, "YKhan" <yjkhan@gmail.com> wrote:

>I guess we will need a FreeBIOS eventually before DRM totally stops us
>from even booting our PCs.
>
>» Stallman's new campaign to free the BIOS | Open Source | ZDNet.com
>http://blogs.zdnet.com/open-source/index.php?p=179
>

It could all be in silicon. Probably will be. Not just the BIOS.
Everything that makes money.

RM

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <1110231069.202730.243480@z14g2000cwz.googlegroups.com>,
YKhan <yjkhan@gmail.com> wrote:

>I guess we will need a FreeBIOS eventually before DRM totally stops us
>from even booting our PCs.

Old news; the Xbox has this feature. Fortunately, the average PC maker
doesn't have a business reason to do it, yet.

-- greg

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

>> If it can be done in silicon, would that bring boot times down?
>
>If hardware is more uniform/standardized, boot time can
>be reduced. See Xbox or DVD players as an example.

Boot time can be reduced without changing hardware -- see LinuxBIOS
for an example. LinuxBIOS can actually boot a variety of OSes, not
just Linux. However, the information needed to fully initialize a lot
of PC hardware isn't availble -- video cards can be done efficiently
by emulating their BIOSes, but things like the memory controller and
stuff built into southbridges can't be done that way.

-- greg

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Greg Lindahl wrote:
> Boot time can be reduced without changing hardware -- see LinuxBIOS
> for an example. LinuxBIOS can actually boot a variety of OSes, not
> just Linux. However, the information needed to fully initialize a lot
> of PC hardware isn't availble -- video cards can be done efficiently
> by emulating their BIOSes, but things like the memory controller and
> stuff built into southbridges can't be done that way.

Does LinuxBIOS go into Protected Mode or does it stay in Real Mode like
regular BIOSes?

Yousuf Khan

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Robert Myers" <rmyers1400@comcast.net> wrote in message

snip

> >
> Intel wanted to provide a standard way to boot IA-64. A standard PC
> boot couldn't be used because itanium could not start (or execute,
> even) in IA-32 real mode. They had to do something, and EFI is what
> they did.
>
> I haven't had much of a chance to play with EFI, but what I've seen
> (you can get in there between the firmware and the OS, if you have to,
> and EFI applications run on a virtual machine) seems pretty
> attractive.
>

EFI is a small, very simple OS. It's not really a virtual machine
environment.
It provides various IO related interfaces to allow access to hardware in an
abstracted way. From its user interface side, it has a menu interface, and
there is a shell from which you can "run" EFI applications from a FAT
formatted disk partition. Applications can be as varied as a FTP program
(which exists), platform diagnostics, or boot loaders - a special type app
that loads some OS specific code, declares the end of boot services, and
never returns.

EFI also runs the platform and device initialization using ACPI - which
allows
the system vendor to embed a interpreted byte code that describes and
initializes non-standard things like core chip sets.

>
> Sure, the whole OS could migrate into EFI. It's already happened.
> With no disk installed, my itanium box boots into linux. Not an
> especially powerful linux, but that's a detail. You can boot into
> linux, fiddle things if you like, and then boot a disk-based OS.
>

Well... this isn't true as far as I know. Boot loaders are a special form
of EFI application used to load some OS specific code, transfer control
and never return. The Linux method is a EFI application called "elilo"
which is normally resident on a hard drive in the FAT formatted EFI
partition. "elilo" pulls in an image that contains a Linux kernel and
a memory disk. Or you could do a network boot using PXE (bootp on
steroids). But I don't know of anyone who is blasting "elilo" or the boot
kernel into flash ROM.

Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
their own. The advantage with EFI is that you can push things not
needed for booting onto mass storage instead of ever increasing ROM
sizes... things like diagnostics for example.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <wBqXd.1299$Yv2.767@news.cpqcorp.net>,
FredK <fred.nospam@nospam.dec.com> wrote:

>EFI is a small, very simple OS.

This must involve a new definition of "small" and "very simple"!

>Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
>their own. The advantage with EFI is that you can push things not
>needed for booting onto mass storage instead of ever increasing ROM
>sizes... things like diagnostics for example.

Indeed, that's what LinuxBIOS does, too.

LinuxBIOS supports every device Linux does -- does EFI somehow use
drivers from some other OS, or are they unique?

-- greg

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Tue, 08 Mar 2005 23:31:40 GMT, "FredK" <fred.nospam@nospam.dec.com>
wrote:

>
>"Robert Myers" <rmyers1400@comcast.net> wrote in message
>
>snip
>
>> >
>> Intel wanted to provide a standard way to boot IA-64. A standard PC
>> boot couldn't be used because itanium could not start (or execute,
>> even) in IA-32 real mode. They had to do something, and EFI is what
>> they did.
>>
>> I haven't had much of a chance to play with EFI, but what I've seen
>> (you can get in there between the firmware and the OS, if you have to,
>> and EFI applications run on a virtual machine) seems pretty
>> attractive.
>>
>
>EFI is a small, very simple OS. It's not really a virtual machine
>environment.

I'm sorry. I didn't mean to imply that the environment itself, which
as far as I know is linux, runs on a virtual machine. You'd have to
run a byte code interpreter in that environment to execute the kind of
EFI code that is interpreted at boot, but the intent, I believe, is
that device drivers be independent of CPU.

<snip>

>>
>> Sure, the whole OS could migrate into EFI. It's already happened.
>> With no disk installed, my itanium box boots into linux. Not an
>> especially powerful linux, but that's a detail. You can boot into
>> linux, fiddle things if you like, and then boot a disk-based OS.
>>
>
>Well... this isn't true as far as I know. Boot loaders are a special form
>of EFI application used to load some OS specific code, transfer control
>and never return. The Linux method is a EFI application called "elilo"
>which is normally resident on a hard drive in the FAT formatted EFI
>partition. "elilo" pulls in an image that contains a Linux kernel and
>a memory disk. Or you could do a network boot using PXE (bootp on
>steroids). But I don't know of anyone who is blasting "elilo" or the boot
>kernel into flash ROM.
>
I'm not sure what I said that you're disagreeing with. As far as I
know, the prompt I get at boot is linux. It isn't fully functional,
but, as I said, that's a detail. It's as much an OS as the ] prompt
was on an Apple ][--more actually, because it is a disk operating
system.

Sure, the widget that loads Linux (or whatever) loads from disk and
runs as a garden-variety program, but there is no reason at all why
full functionality couldn't be in firmware and, I believe, such a
thing will come to pass for thin, diskless clients. Such a client
will pull its operating system in via PXE? Maybe. No reason why it
has to, though.

RM

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

FredK wrote:
> Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
> their own. The advantage with EFI is that you can push things not
> needed for booting onto mass storage instead of ever increasing ROM
> sizes... things like diagnostics for example.

These days with big & cheap flash available for use as firmware, you
might as well put everything into ROM.

Yousuf Khan

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:422e362f$1@news.meer.net...
> In article <wBqXd.1299$Yv2.767@news.cpqcorp.net>,
> FredK <fred.nospam@nospam.dec.com> wrote:
>
> >EFI is a small, very simple OS.
>
> This must involve a new definition of "small" and "very simple"!
>

Well. Think about it. It is a ROM resident OS. It provides IO services,
memory management services, and a command line interface. It allows
you to write disk resident applications that it will simply run. It isn't
"that" big, or "that" complicated.

Now, EFI is just one *part* of the firmware - there is also ACPI, PAL
and SAL.

> >Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
> >their own. The advantage with EFI is that you can push things not
> >needed for booting onto mass storage instead of ever increasing ROM
> >sizes... things like diagnostics for example.
>
> Indeed, that's what LinuxBIOS does, too.
>
> LinuxBIOS supports every device Linux does -- does EFI somehow use
> drivers from some other OS, or are they unique?
>

Unique. They have a port/class like mechanism as I understand it, where
EFI abstracts the high level, and the devices themselves provide the low
level "port" code. PCI object format was extended so not only does it have
BIOS (ia32), and OpenSource (Forth), but also a new format for EFI.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <murXd.1304$tB2.642@news.cpqcorp.net>,
FredK <fred.nospam@nospam.dec.com> wrote:

>> This must involve a new definition of "small" and "very simple"!
>
>Well. Think about it. It is a ROM resident OS. It provides IO services,
>memory management services, and a command line interface. It allows
>you to write disk resident applications that it will simply run. It isn't
>"that" big, or "that" complicated.

Ah. I wonder if it's bigger or smaller than LinuxBIOS. It certainly is
funny (ok, let's just say expensive) that EFI requires unique device
drivers.

Don Becker, champion of the "3 card monte" boot, which is quite similar
to LinuxBIOS, likes to make fun of EFI as being bloated in comparison.

-- greg

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Robert Myers" <rmyers1400@comcast.net> wrote in message
news:1tcs21ltapnsp1fdb6jn8lk0h1vvuffkvp@4ax.com...
> On Tue, 08 Mar 2005 23:31:40 GMT, "FredK" <fred.nospam@nospam.dec.com>
> wrote:
>
> >
> >"Robert Myers" <rmyers1400@comcast.net> wrote in message
> >
> >snip
> >
> >> >
> >> Intel wanted to provide a standard way to boot IA-64. A standard PC
> >> boot couldn't be used because itanium could not start (or execute,
> >> even) in IA-32 real mode. They had to do something, and EFI is what
> >> they did.
> >>
> >> I haven't had much of a chance to play with EFI, but what I've seen
> >> (you can get in there between the firmware and the OS, if you have to,
> >> and EFI applications run on a virtual machine) seems pretty
> >> attractive.
> >>
> >
> >EFI is a small, very simple OS. It's not really a virtual machine
> >environment.
>
> I'm sorry. I didn't mean to imply that the environment itself, which
> as far as I know is linux, runs on a virtual machine. You'd have to
> run a byte code interpreter in that environment to execute the kind of
> EFI code that is interpreted at boot, but the intent, I believe, is
> that device drivers be independent of CPU.
>

Nope. EFI and EFI applications are architecture specific - IA32 or
IA64 right now. The ACPI layer uses an interpreter for the "code"
that knows how to enumerate the platform and devices, and also
how to access that platform specific hardware (like a core chipset).

I also believe that the object format in the PCI devices ROM may
be an interpreted byte stream - but I don't recall offhand.

> <snip>
>
> >>
> >> Sure, the whole OS could migrate into EFI. It's already happened.
> >> With no disk installed, my itanium box boots into linux. Not an
> >> especially powerful linux, but that's a detail. You can boot into
> >> linux, fiddle things if you like, and then boot a disk-based OS.
> >>
> >
> >Well... this isn't true as far as I know. Boot loaders are a special
form
> >of EFI application used to load some OS specific code, transfer control
> >and never return. The Linux method is a EFI application called "elilo"
> >which is normally resident on a hard drive in the FAT formatted EFI
> >partition. "elilo" pulls in an image that contains a Linux kernel and
> >a memory disk. Or you could do a network boot using PXE (bootp on
> >steroids). But I don't know of anyone who is blasting "elilo" or the
boot
> >kernel into flash ROM.
> >
> I'm not sure what I said that you're disagreeing with. As far as I
> know, the prompt I get at boot is linux.

An Itanium system will initialize to a boot menu. One selection is
"shell" -
this is not Linux. If you put a Linux distribution CD into the system, it
"should" auto-boot it into a simple Linux kernel. But Linux isn't in the
ROM AFAIK on any Itanium system.

>
> Sure, the widget that loads Linux (or whatever) loads from disk and
> runs as a garden-variety program, but there is no reason at all why
> full functionality couldn't be in firmware and, I believe, such a
> thing will come to pass for thin, diskless clients. Such a client
> will pull its operating system in via PXE? Maybe. No reason why it
> has to, though.
>

It is certainly possible to blast it into the ROM or Flash instead of
having it disk resident.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On 2005-03-08 21:14:15 -0600, Yousuf Khan <bbbl67@ezrs.com> said:

> Greg Lindahl wrote:
>> Boot time can be reduced without changing hardware -- see LinuxBIOS
>> for an example. LinuxBIOS can actually boot a variety of OSes, not
>> just Linux. However, the information needed to fully initialize a lot
>> of PC hardware isn't availble -- video cards can be done efficiently
>> by emulating their BIOSes, but things like the memory controller and
>> stuff built into southbridges can't be done that way.
>
> Does LinuxBIOS go into Protected Mode or does it stay in Real Mode like
> regular BIOSes?

IIRC, LinuxBIOS gets into protected mode ASAP, because it's easier to
code for. I don't know what that has to do with Greg's comment, though.

--
Wes Felter - wesley@felter.org - http://felter.org/wesley/

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Myers <rmyers1400@comcast.net> writes:

>> The problem is also that this represents a loophole in the GPL. If
>> you embed DRM in the hardware and require the OS to be signed¹,
>> you could distribute GPL-compliant source code to your hearts content,
>> without granting the users the freedom to actually *run* modified
>> code.

> It is really hard to see how that could happen without turning the
> whole world of Linux software upside down. Maybe I just lack
> imagination.

I agree it's not likely to happen to computing in general. I don't
consider it unlikely to happen to niches -- after all, it is
approximately how the (unmodified) X-box works.

Let's say Sony (since it's more Linux agnostic) sets up PS3 to only
boot signed OSes. I don't think that's very far-fetched. Then they
are free to provides a signed Linux kernel for it, and thus you get to
run GPL software on it, without actually getting the freedoms the GPL
was supposed to ensure.

> Or, rather, the only way I see it happening is if the content owners
> give enough money to get congress to mandate such a thing.

If it is presented as elimination of software piracy and copyright
breach, I'm sure you could get at least some elected officials to
listen (even if very few in the industry actually want this to
happen).

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Ketil Malde wrote:
> The problem is also that this represents a loophole in the GPL. If
> you embed DRM in the hardware and require the OS to be signed¹,
> you could distribute GPL-compliant source code to your hearts content,
> without granting the users the freedom to actually *run* modified
> code.

As I understand, the GPL requires you to ship *all* sources. If the
signature of the OS binary is a fundamental part of its functionality, you
have to include this private key into the source distribution.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

FredK wrote:
> Nope. EFI and EFI applications are architecture specific - IA32 or
> IA64 right now.

I also had the impression that EFI applications could be using
bytecodes. I am sure it is not required, but isn't this a possibility ?

A search for "EFI application bytecode" returned this:
<URL:http://www.kernelthread.com/publications/firmware/>

In all those posts I didn't see a single reference to EFI being
mostly open-sourced already:
<URL:http://www.tianocore.org/>

Intel selected the BSD license for this code. I imagine that
the GPL may have caused quite a few legal issues for hardware
manufacturers. I understand that the code is not complete, however
it shouldn't be a surprise to anyone, given that Intel also needs
the support from traditional BIOS companies to promote EFI.

Eric

(who never had anything to do with EFI besides booting IPF
hardware)

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Wed, 09 Mar 2005 17:26:33 GMT, Eric Gouriou <eric.gouriou@hp.com>
wrote:

>FredK wrote:
>> Nope. EFI and EFI applications are architecture specific - IA32 or
>> IA64 right now.
>
> I also had the impression that EFI applications could be using
>bytecodes. I am sure it is not required, but isn't this a possibility ?
>

http://developer.intel.com/technology/efi/main_specification.htm

<quote>

The EFI Driver Model is designed to be generic and can be adapted to
any type of bus or device. Also included in the EFI 1.10 Specification
is a set of companion documents that describe how to write PCI bus
drivers and PCI device drivers. These companion documents also
describe how to store an EFI driver in a PCI option ROM while
maintaining compatibility with legacy option ROM images. The EFI
Driver may be compiled for EFI Byte Code to enable a single image to
support multiple platforms, including IA-32 and Itanium®.

</quote>

RM

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Bernd Paysan <bernd.paysan@gmx.de> writes:

>Ketil Malde wrote:
>> The problem is also that this represents a loophole in the GPL. If
>> you embed DRM in the hardware and require the OS to be signed¹,
>> you could distribute GPL-compliant source code to your hearts content,
>> without granting the users the freedom to actually *run* modified
>> code.

>As I understand, the GPL requires you to ship *all* sources. If the
>signature of the OS binary is a fundamental part of its functionality, you
>have to include this private key into the source distribution.

Why the private key? Wouldn't just the signature suffice? After
all, it *is* sufficient to reproduce the binary.

I think requiring the private key is a stretch; if are also not
required to ship the sources of whatever else the linker deposits
in the binary, such as crt0.o, any shared data from libc, etc.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Myers <rmyers1400@comcast.net> writes:

>The EFI Driver Model is designed to be generic and can be adapted to
>any type of bus or device. Also included in the EFI 1.10 Specification
>is a set of companion documents that describe how to write PCI bus
>drivers and PCI device drivers. These companion documents also
>describe how to store an EFI driver in a PCI option ROM while
>maintaining compatibility with legacy option ROM images. The EFI
>Driver may be compiled for EFI Byte Code to enable a single image to
>support multiple platforms, including IA-32 and Itanium®.


Ah, the reinvention of IEE1275.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Myers wrote:
> On Wed, 09 Mar 2005 17:26:33 GMT, Eric Gouriou <eric.gouriou@hp.com>
> wrote:
>>FredK wrote:
>>
>>>Nope. EFI and EFI applications are architecture specific - IA32 or
>>>IA64 right now.
>>
>> I also had the impression that EFI applications could be using
>>bytecodes. I am sure it is not required, but isn't this a possibility ?
>
> http://developer.intel.com/technology/efi/main_specification.htm
>
> <quote>
>
> The EFI Driver Model is designed to be generic and can be adapted to
> any type of bus or device. Also included in the EFI 1.10 Specification
> is a set of companion documents that describe how to write PCI bus
> drivers and PCI device drivers. These companion documents also
> describe how to store an EFI driver in a PCI option ROM while
> maintaining compatibility with legacy option ROM images. The EFI
> Driver may be compiled for EFI Byte Code to enable a single image to
> support multiple platforms, including IA-32 and Itanium®.
>
> </quote>

Thanks, however Fred's post already mentioned that drivers could
be using bytecode. The question is about EFI 'applications', since
Fred appeared to make a distinction between driver and application.
I was not aware that there was a distinction between the two.

There were mentions of OpenFirmware in this thread. My understanding
is that OpenFirmware, while defined by some (ISO?) standard, is not
open by the current standards of 'Free Software' proponents. My impression
is that EFI ends up being more open, which probably annoys some zealots
so much that they have to conveniently ignore the facts (I am not
talking about RMS here).

Repeated disclaimer: I am just an interested bystander when it comes
to EFI.

Eric

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Eric Gouriou <eric.gouriou@hp.com> writes:

> There were mentions of OpenFirmware in this thread. My understanding
>is that OpenFirmware, while defined by some (ISO?) standard, is not
>open by the current standards of 'Free Software' proponents. My impression
>is that EFI ends up being more open, which probably annoys some zealots
>so much that they have to conveniently ignore the facts (I am not
>talking about RMS here).

Why is Open Firmware not open? Just because the Free Software
Zealots redefined what open means? C'mon.

I don't think there are free OpenFirmware implementation.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.sys.ibm.pc.hardware.chips David <david.nospam@westcontrol.removethis.com> wrote:
> You also have to include all required tools for building
> your modified code and making it runable, as part of the
> "source" of the gpl'ed code.

Where does it say this in GPL v2 ?

This is a hole I expect closed in v3.

-- Robert

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

YKhan wrote:
> I guess we will need a FreeBIOS eventually before DRM totally stops us
> from even booting our PCs.
>

As a tangential issue, is the term BIOS (Basic Input-Output System)
apposite anymore? Do any modern OSes or applications use the abstraction
layer the BIOS (is supposed to) implement?

As I understand it, and I might be wrong, the BIOS is only active during
the POST and in handing off control to whatever bootloader is installed
on the bootable media (disk, flash drive, network) the PC uses. In the
DOS and CP/M days, applications would actually call into the BIOS to get
the hardware to do stuff (not the fastest applications, but the system
calls were always there).

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Wes Felter wrote:
> On 2005-03-08 21:14:15 -0600, Yousuf Khan <bbbl67@ezrs.com> said:
>
>> Greg Lindahl wrote:
>>
>>> Boot time can be reduced without changing hardware -- see LinuxBIOS
>>> for an example. LinuxBIOS can actually boot a variety of OSes, not
>>> just Linux. However, the information needed to fully initialize a lot
>>> of PC hardware isn't availble -- video cards can be done efficiently
>>> by emulating their BIOSes, but things like the memory controller and
>>> stuff built into southbridges can't be done that way.
>>
>>
>> Does LinuxBIOS go into Protected Mode or does it stay in Real Mode
>> like regular BIOSes?
>
>
> IIRC, LinuxBIOS gets into protected mode ASAP, because it's easier to
> code for. I don't know what that has to do with Greg's comment, though.

Quite simple really, why would it be necessary to emulate the video bios
when all one would need to do is make a call to the actual video bios? I
was trying to figure out why the Linux bios isn't simply making a call
to the other bioses on the system. Obviously, a video bios is Real-mode
code, so the Linux bios cannot possibly make a simple call to it.

Yousuf Khan

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Casper H.S. Dik wrote:
> Why is Open Firmware not open? Just because the Free Software
> Zealots redefined what open means? C'mon.

Note also that the way Open Firmware exchanges drivers is by tokenized
*source*. Not exactly what Free Software Zealots want (comments don't get
tokenized), but close enough for all practical purposes.

> I don't think there are free OpenFirmware implementation.

www.openbios.org

Not completed, but with rapid progress.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/