RE: Need help with LinuxBIOS speech

[STEPHAN,YANN (HP-France,ex1)]

I love this one:

Less buggy <== Currently the Bios does some many things in order to
support all OS, that the code is huge and still written in assembly
language.

I will say more debuggable than normal bios.

Regards

-----Original Message-----
From: Christer Weinigel [mailto:[e-mail]] 
Sent: Thursday, September 05, 2002 5:01 PM
To: [e-mail]
Subject: Need help with LinuxBIOS speech

Hi,

it looks as if I might have to jump in and hold a 30 minute speech about
LinuxBIOS at a conference here in Stockholm since the original speaker can't
make it.  I have about a week to prepare.  *panics*

The information I have about this so far is:
> Target audience: Hardware designers, driver programmers, kernel 
> programmers but also people interested in faster startup times in 
> their embedded systems.

(possible) things to talk about:
> What is a BIOS and especially, LinuxBIOS?
> What are the main benefits in using LinuxBIOS?
> What chipsets are supported by LinuxBIOS today?
> How does the Linux boot system work?
> How does a common x86-based board work?
> How does the initialization sequence work.
> What are the steps involved in creating a LinuxBIOS for this
>
> board?

Points that I do need help with are:
> What is a BIOS and especially, LinuxBIOS?

I think I need a short introduction to LinuxBIOS and also a short history of
where it came from.
> What are the main benefits in using LinuxBIOS?

Maybe the rationale behind writing LinuxBIOS at all.
> What are the pros and cons with LinuxBIOS?

Pros:

Faster bootup.
    Tiny code.
    Tailored to the hardware.
    Written in C and uses 32 bit mode.
    Less buggy
    Portable (in theory) across architectures so that x86 and Alpha
    can boot the same way.

Cons:

Not as flexible as a normal BIOS.
    Requires hardware and chipset documentation, it's hard to keep up
    with the hardware development..
    Hard to handle PCI cards with expansion ROMs on them that expect a
    standard PC BIOS.
> What chipsets are supported by LinuxBIOS today?

Is there a list of supported chipsets?
> How does the Linux boot system work?
> How does a common x86-based board work?
> How does the initialization sequence work.

These I think I have a rather good handle on.
> What are the steps involved in creating a LinuxBIOS for this
>
> board?

I can take the SC2200 port I did as an example here.

By the way, one thing I'm not sure about, what is actually stored in the
LinuxBIOS table?  As far as I can tell right now the only thing there is the
amount of memory in the system and the kernel command line.  Is there
anything else?  (The PIRQ table is stored in the BIOS image itself if I
understand correctly).

Is there anything else missing from the list that I should talk about?

Any help would be appreciated.

/Christer

Need help with LinuxBIOS speech

"STEPHAN,YANN (HP-France,ex1)"  writes:
> I love this one:
> Less buggy <== Currently the Bios does some many things in order to
>
> support all OS, that the code is huge and still written in assembly
> language.
>
> I will say more debuggable than normal bios.

If you have something that will log the serial console output it is
also immensely more debuggable.  The key is that the serial port
is trivial and can be initialized before ram. In fact before just
about everything else.

There are two great challenges when debugging a BIOS.
1) Identical hardware works differently.
2) Hardware bugs get to be worked around in software.

A classic case of identical hardware working differently is many times
hardware designers do not initial registers (like pci bars) at reset
and just clamp onto whatever value they floated to.   This has
caused the LinuxBIOS pci code to think rw BARS are readonly.  This
kind of thing is annoying as the problem only shows up in the when
you have a large number of systems using LinuxBIOS.

With the supermicro p4dpr in the MCR cluster I am currently tracking a
number of issues that don't reproduce on every motherboard, and are
actually workarounds for hardware bugs.  After small scale testing
the most efficient way for me to track and see if a bug has been fixed
is to flash the BIOS onto the cluster.

Then I can review the serial console boot logs and see where/how the
BIOS hung to see how well my fixes worked.

The most interesting fix relates to the intel P64H2 and it's errata
of a race between a good power signal and a clock signal.  When it
gets the clock signal before it gets good power the pci busses do
strange things.  Typicall locking up when scanning the pci bus, but
not always.

The initial work around was to reboot the machine multiple times
hopeing to avoid the race.  Just recently I was able to implement the
intel recommended work around which involved stopping and starting the
reference clock.  The pll that generates the reference clock is
accessible on the smbus but it's interface on the i2c bus is buggy.
So I had to add code to detect when the pll's i2c interface was not
responding and continue on with life.

The proper function of this code I have been able to verify with
serial console log messages.  In addition when there is bad hardware
or a BIOS issue the bug report isn't that the node refuses to boot.
The bug report is that the node dies doing X.  Which much much easier
to start with when debugging a problem.

Eric

Need help with LinuxBIOS speech

[Ronald G Minnich]

One thing that I am hoping an open source BIOS might get us to is less
buggy hardware. The bugginess of this PC hardware is really amazing. The
bugginess has persisted because the vendors know they can hide all the
ugly problems in the BIOS. These problems lead to memory running slow,
weird PCI bus problems, and other failures.

Open source BIOSes reveal the ugly bugs. Possibly this will make the
hardware vendors more responsible. We can certainly hope so.

ron

Need help with LinuxBIOS speech

[ollie lho]

On Mon, 2002-09-16 at 07:08, Ronald G Minnich wrote:
> One thing that I am hoping an open source BIOS might get us to is less
> buggy hardware. The bugginess of this PC hardware is really amazing. The
> bugginess has persisted because the vendors know they can hide all the
> ugly problems in the BIOS. These problems lead to memory running slow,
> weird PCI bus problems, and other failures.
>
> Open source BIOSes reveal the ugly bugs. Possibly this will make the
> hardware vendors more responsible. We can certainly hope so.

I doubt. From what I have seen, vendors just go the other way. It is 
really bad for PR (from marketing dept. point of view) if Open Source
projects finding out that your HW is buggy. This is why now most PC 
chipset vendor don't release register specs now.

Ollie