Perhaps i2c/smbus.
Clay Jones senior software engineer | c.jones@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@linuxbios.org [mailto:linuxbios-bounces+c.jones=f5.com@linuxbios.org] On Behalf Of Carl-Daniel Hailfinger Sent: Thursday, November 30, 2006 9:07 AM To: linuxbios@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