[LinuxBIOS] Support for recent chipset and powerful desktop CPU

Clay Jones c.jones at f5.com
Thu Nov 30 20:04:16 CET 2006

Perhaps i2c/smbus.


Clay Jones  senior software engineer  |  c.jones at f5.com  | www.f5.com
P.  509 343 3500 |  F.  509 343 3501 | D.  509 343 3519 
F5 Networks  | 1322 North Whitman Lane  |  Liberty Lake, Washington

The Leader in Application Traffic Management
Ensuring secure and optimized application delivery for global

-----Original Message-----
From: linuxbios-bounces+c.jones=f5.com at linuxbios.org
[mailto:linuxbios-bounces+c.jones=f5.com at linuxbios.org] On Behalf Of
Carl-Daniel Hailfinger
Sent: Thursday, November 30, 2006 9:07 AM
To: linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop

Peter Stuge wrote:
> On Wed, Nov 29, 2006 at 05:17:01PM -0700, ron minnich wrote:
>> we are going to have to learn USB debug port. This problem is not
>> going away.
> Maybe we can find some other solution that is even easier to use.
> On Thu, Nov 30, 2006 at 04:19:26AM +0100, Segher Boessenkool wrote:
>> But yes, it's very unfortunate "modern" systems are
>> so unfriendly to low-level bringup.  At the very least
>> it makes it really really hard to have some uniform
>> ("generic") working early setup code.
> What other buses are usually available, that we could abuse to get
> output with little hardware effort required?
> While I would love to see an affordable PLCC thing that implements a
> reads-make-a-write protocol it's not ready today nor tomorrow, while
> the KN9 Ultra is getting older already.
> What signals can be twiddled at, or soon after, power on?
> Ideally we want a channel that is not required at all for bringup.
> Ideally it would be able to run at both kHz and MHz to test/provoke
> timing issues, but if single speed I guess kHz is easier to handle.
> Pro: Available immediately after power on
> Con: Logic needed to decode
> Con: Mechanical issue, hard to hook up
> Pro: Easy to make/get/order PCBs that fit
> Con: Not easily accessible without setting up DRAM controller
> (Is this the case?)
> Con: Need fast logic to decode.
> (Is this the case? Can modern DRAM controllers be set to run slowly?)
> Pro: Simple 8-bit PIO, easy to interface with
> Con: Needs SuperIO running, at least a little, like the serial port.
> What other candidates are there? What can code do that is easy to
> measure? Power? Voltage? One bit is enough. Am I insane? :)

When all vendors move to SPI, hopefully most boards will have a
debugging header or another method to hook into SPI.
Pro: Fast, soon to be the standard
Con: No idea what support we need for writing to SPI


linuxbios mailing list
linuxbios at linuxbios.org

More information about the coreboot mailing list