[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Clay Jones]

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
99019 

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

-----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
CPU

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.
> 
> 
> LPC
> Pro: Available immediately after power on
> Con: Logic needed to decode
> Con: Mechanical issue, hard to hook up
> 
> DRAM
> 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?)
> 
> IDE
> 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? :)

SPI
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

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios