[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
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
More information about the coreboot
mailing list