[LinuxBIOS] LinuxBIOS through PCI

Peter Stuge stuge-linuxbios at cdy.org
Sun Apr 29 19:57:20 CEST 2007


Sorry about this long message.

To clarify, there are two distinct ways in which LB could be loaded
from PCI. I think both are interestng.


* Expansion ROM

Here, LinuxBIOS does not replace the system BIOS, but the system BIOS
would see an expansion ROM on a PCI card and try to call it just like
it does other expansion ROMS. (SCSI, VGA, SATA, NIC, etc.)

This does not requre any hardware support in the system, only that
there is a boot software in the system which will discover and call
the LB expansion ROM.

To test this, old NICs are a pefect target.

One thing to keep in mind with expansion ROMs is that they are
generally small. 128kb is probably the best anyone can hope for.


* 4G addresses decoded to PCI

Here, LinuxBIOS is the system BIOS, just like we normally use it.

Ths requires explicit support where the system BIOS flash chip is
connected, usually the southbridge, and usually there must also be
a jumper on the mainboard that selects this method of reaching the
boot software instead of the normal one. (Usually LPC or SPI.)

So far I've only seen the ICHx southbridges support this, but I have
not looked very hard.

As I understand, this simply does PCI reads on the 4G addresses and
hopes that someone will answer.

This needs to be implemented with a special PCI card designed for
the purpose, possibly with differences depending on each southbridge.
Making hardware is expensive unless in bulk so for testing it the $60
prototype boards may actually not be a bad deal. :(


On Sat, Apr 28, 2007 at 03:09:07PM -0700, ron minnich wrote:
> This would allow us to grab control of the platform, although it is
> pretty late in the process, but we could add this card to nodes and
> force them to use linuxbiosmain and give us control over payload
> and some other parameters.

This would require some puzzling in the v2 Makefile right? And
perhaps a new utility to turn LB into a valid expansion ROM?


> So, are there proto cards out there with nothing but a flash part
> on them?

What Bari sad, try to use a cheap NIC for this. I think I've even
seen Linux flashing software for realtek cards. Don't forget to check
the flash size on the cards.


On Sun, Apr 29, 2007 at 10:11:21AM +0200, Quux wrote:
> would one have to add little switches onboard connected to the
> chipset

No, the chipset would need to already have a switch to select the
decode mode.


On Sun, Apr 29, 2007 at 08:41:51PM +0700, Darmawan Salihun wrote:
> http://www.geocities.com/mamanzip/Articles/Low_Cost_Embedded_x86_Teaching_Tool.html
> Maybe such approach can be used.

Right, this is by far the most cost effective way.


> Nonetheless, it means we needed a code to "clean-up" the original
> vendor BIOS code. Maybe this condition is not a good place to start
> :-(

Well, it may not be all that bad, and as Ron said it's better than no
LB at all.


On Sun, Apr 29, 2007 at 09:18:26PM +0700, Darmawan Salihun wrote:
> http://www.uxd.nl/en/pages/producten/hardware/phdpci2.html

This looks like a diagnostics card. I guess it uses the expansion ROM
method to load it's software.


On Sun, Apr 29, 2007 at 09:24:20AM -0500, Bari Ari wrote:
> If the ROM's on NIC's show up during boot, then cards are available
> for under $5. But I don't recall any of them mapping the ROM to any
> PCI space.

That's right. They would only be useful (but very!) for the expansion
ROM mode.


On Sun, Apr 29, 2007 at 04:38:41PM +0200, Quux wrote:
> that is the point - the issue was discussed here a couple of days ago.

A: No.
Q: Should I include quotations after my reply?

*Please* stop top-posting. See

http://www.catb.org/~esr/jargon/html/T/top-post.html
http://www.faqs.org/qa/rfcc-449.html
http://en.wikipedia.org/wiki/Top-posting

I would be in the TOFU/jeopardy camp.


> a regular PCI expansion BIOS is called too late during POST by
> legacy BIOS.

Late, but not too late. I think there is utility in this method also.


> The Altera MAXII has a patch field to put a flash mem into.

And it has logic that can be used to decode the PCI reads to the
flash chip. This is required since no flash ROM I've seen comes
with a PCI interface. (Probably too expensive and unusual.)


> chipset's provide for booting from PCI space but I wonder whether
> they need to be told to do so by a hardware switch / signal

Yes.


> or whether a small patching of legacy bios would do the trick.

There is no legacy BIOS with the 4G PCI decode method.


While the method can certainly be an alternative I would assume it is
used by the big boys exclusively during board development and because
of that even if southbridges support the mode, the neccessary signal
will never be available for user control on the production run
mainboard. I hope I'm wrong. We need to research it. It seems that at
least the Gigabyte board did have this signal also on the production
boards, at an unpopulated jumper.


On Sun, Apr 29, 2007 at 04:55:21PM +0200, Quux wrote:
> http://www.intel.com/design/intarch/applnots/273121.HTM
> 
> an intel PCI board with fpga & lotsa flash chips only. intel say it
> allows dead-on startup of embedded systems ... what u think ?

--8<-- 3.6 Expansion ROM Operation
The expansion ROM is accessed at power-up through the system BIOS.
-->8--

and

--8<-- 5.0 Software Overview
It is advisable for the card to begin executing after system start.
An expansion ROM serves this function.
-->8--

means this card works exclusively in the expansion ROM mode.

But that would change with a different FPGA bitstream of course. Note
that Intel do not sell this board anyway.


On Sun, Apr 29, 2007 at 05:00:53PM +0200, Quux wrote:
> 5.4.1 BIOS Boot Specification 1.01
[..]
> If the system BIOS supports this specification, the expansion
> ROM within the card can indicate that it is an available IPL
> device.

This is "on top of" an expansion ROM.

This allows a legacy BIOS to boot an OS from a controller with an
expansion ROM by adding some structured information to the expansion
ROM. The BIOS will read the info and then present all bootable
devices to the user.

This is an alternative to, or expansion of, the other legacy BIOS
boot methods. (int 13h, int 18h, int 19h)


//Peter




More information about the coreboot mailing list