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

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

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

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

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.

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

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

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.

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.

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

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

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/

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

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

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/