Re: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Lu, Yinghai]

Too late.

YH

________________________________

From: Simon Labrecque [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 1:49 PM
To: Lu, Yinghai; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop
CPU

Does it *need* a serial port? Can't one be added via a PCI card, for
instance?

Simon Labrecque

From: Lu, Yinghai [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 3:25 PM
To: Simon Labrecque; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop
CPU

The MB doesn't have serial port.

YH

________________________________

From: Simon Labrecque [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 10:51 AM
To: Lu, Yinghai; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop
CPU

Would that board be OK (MCP55-Ultra)?

http://www2.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODE
L_NAME=KN9+Ultra&fMTYPE=Socket+AM2

If so, it would be a good choice I think.

Simon Labrecque

From: Lu, Yinghai [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 1:05 PM
To: Simon Labrecque; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop
CPU

If you select one AM2 + MCP55 MB, It would only take me one or two hours
to get it done.

If so, I'd like to do that for free.

YH

________________________________

From: linuxbios-bounces+yinghai.lu=[e-mail]
[mailto:linuxbios-bounces+yinghai.lu=[e-mail]] On Behalf Of
Simon Labrecque
Sent: Wednesday, November 22, 2006 4:34 AM
To: [e-mail]
Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

Hi,

We're starting development of a (pretty much high-end)
PVR/MediaCenter which will of course run linux. Now, one of the avenue
we're looking at is using standard x86 hardware (as opposed to custom
built embedded hardware). Since the product will need a lot of
processing power (since if we're using x86 hardware, we'll do most
processing in software), we would like to use a dual-core CPU, something
powerful. But it must also be low  power/low heat, as you can't have a
12" fan running at 8000rpm to cool your CPU in the living now...

The device should also feel "appliance-like". That means that it must
boot very quickly, at least displaying some nice animated loading screen
within 5 seconds. And that's where LinuxBIOS comes into play.

Are there any supported board/CPU combo that would fit our needs? For
an AMD board, something with an AM2 socket would be ideal as it's a
recent chipset and will stay longer on the market than say socket 939,
but it's not a requirement per se. We would need standard stuff on the
board: USB, IDE, ideally PCI-E and pci and maybe onboard sound and video
(although that's more optional than anything).

If no such board/cpu combo is supported by LinuxBIOS currently, we
would be willing to evaluate the possibility of hiring someone to port
LinuxBIOS to the chosen platform. Do you know of any individual/company
that would do such work and an idea of how much such work might cost?

Thanks a lot.

Simon Labrecque

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Simon Labrecque]

I'm sorry but I don't understand your reply. Too late for what exactly?

Simon Labrecque

From: Lu, Yinghai [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 4:56 PM
To: Simon Labrecque; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

Too late.

YH

_____

From: Simon Labrecque [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 1:49 PM
To: Lu, Yinghai; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

Does it *need* a serial port? Can't one be added via a PCI card, for
instance?

Simon Labrecque

From: Lu, Yinghai [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 3:25 PM
To: Simon Labrecque; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

The MB doesn't have serial port.

YH

_____

From: Simon Labrecque [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 10:51 AM
To: Lu, Yinghai; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

Would that board be OK (MCP55-Ultra)?

http://www2.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_NA
ME=KN9+Ultra
http://www2.abit.com.tw/page/en/motherboard/motherboard_detail.php?pMODEL_N
AME=KN9+Ultra&fMTYPE=Socket+AM2 &fMTYPE=Socket+AM2

If so, it would be a good choice I think.

Simon Labrecque

From: Lu, Yinghai [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 1:05 PM
To: Simon Labrecque; [e-mail]
Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

If you select one AM2 + MCP55 MB, It would only take me one or two hours to
get it done.

If so, I'd like to do that for free.

YH

_____

From: linuxbios-bounces+yinghai.lu=[e-mail]
[mailto:linuxbios-bounces+yinghai.lu=[e-mail]] On Behalf Of
Simon Labrecque
Sent: Wednesday, November 22, 2006 4:34 AM
To: [e-mail]
Subject: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

Hi,

We're starting development of a (pretty much high-end) PVR/MediaCenter
which will of course run linux. Now, one of the avenue we're looking at is
using standard x86 hardware (as opposed to custom built embedded hardware).
Since the product will need a lot of processing power (since if we're using
x86 hardware, we'll do most processing in software), we would like to use a
dual-core CPU, something powerful. But it must also be low  power/low heat,
as you can't have a 12" fan running at 8000rpm to cool your CPU in the
living now.

The device should also feel "appliance-like". That means that it must
boot very quickly, at least displaying some nice animated loading screen
within 5 seconds. And that's where LinuxBIOS comes into play.

Are there any supported board/CPU combo that would fit our needs? For an
AMD board, something with an AM2 socket would be ideal as it's a recent
chipset and will stay longer on the market than say socket 939, but it's not
a requirement per se. We would need standard stuff on the board: USB, IDE,
ideally PCI-E and pci and maybe onboard sound and video (although that's
more optional than anything).

If no such board/cpu combo is supported by LinuxBIOS currently, we would
be willing to evaluate the possibility of hiring someone to port LinuxBIOS
to the chosen platform. Do you know of any individual/company that would do
such work and an idea of how much such work might cost?

Thanks a lot.

Simon Labrecque

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Richard Smith]

Simon Labrecque wrote:
> I'm sorry but I don't understand your reply. Too late for what exactly?

Simon,

What he is trying to describe is that to use a PCI serial port card you
fist have to enumerate the PCI bus and assign resources.  Thats done
after RAM + a bunch more is functional. So it doesn't help you bring up
a northbridge.

Bringing up a northbridge requires that you have some sort of debug IO
that can happen almost immediately after the CPU starts up.

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> What he is trying to describe is that to use a PCI serial port card  
> you
> fist have to enumerate the PCI bus and assign resources.  Thats done
> after RAM + a bunch more is functional.

That's not true on all systems and all firmwares, FWIW;
on your average x86 box though, it would be quite inconvenient
to have to do the whole PCI setup (or even only part of
it) before RAM is up.
> So it doesn't help you bring up
> a northbridge.
>
> Bringing up a northbridge requires that you have some sort of debug IO
> that can happen almost immediately after the CPU starts up.

Here's a wacko idea: for systems that use LPC memory, you
can use a "biossaviour" like plugin board, with not just
flash but also a superio chip on it.  Only useful for
developers of course, not for the end user.

On systems where an I2C controller is easily reachable at
boot time, you can use that (if you can't find a header to
connect your debug cable to, use a DIMM slot :-) ).

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[ron minnich]

we are going to have to learn USB debug port. This problem is not going away.

ron

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Simon Labrecque]

I'm asking because obviously I don't know the answer, but can't a serial
port on a PCI card be used? Wouldn't that be simpler than through-USB
debugging?

If not, well I'll find a new board, but I like the fact that this board is
already passively cooled (a requirement, or at least a strong plus, in our
product), is quite cheap and from a reputable company.

If someone has a board to suggest, please jump in.

Simon Labrecque

-----Original Message-----
From: ron minnich [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 7:17 PM
To: Lu, Yinghai
Cc: Simon Labrecque; [e-mail]
Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

we are going to have to learn USB debug port. This problem is not going
away.

ron

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[ron minnich]

On 11/29/06, Simon Labrecque  wrote:
> I'm asking because obviously I don't know the answer, but can't a serial
> port on a PCI card be used? Wouldn't that be simpler than through-USB
> debugging?

yeah, but how do you debug the PCI bringup code if PCI is not up to
drive the card in the PCI slot ... assuming there *is* a PCI slot.
That's the problem. The USB debug capability is supposed to work even
when almost nothing is work. Serial ports are no longer that way.

"Progress!"
> If not, well I'll find a new board, but I like the fact that this board is
> already passively cooled (a requirement, or at least a strong plus, in our
> product), is quite cheap and from a reputable company.

we have to solve this. So, let's solve it.

ron

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> > I'm asking because obviously I don't know the answer, but can't a  
> > serial
> > port on a PCI card be used? Wouldn't that be simpler than through-USB
> > debugging?
>
> yeah, but how do you debug the PCI bringup code if PCI is not up to
> drive the card in the PCI slot ... assuming there *is* a PCI slot.
> That's the problem. The USB debug capability is supposed to work even
> when almost nothing is work.

EHCI debug port requires PCI to be set up (at least
partially) -- it requires a BAR.
> Serial ports are no longer that way.
>
> "Progress!"

Yeah.  It's time that all CPU manufacturers see the
light and attach the "system I/O" (serial, I2C, SPI,
some GPIOs, flash) directly to the CPU.
> > If not, well I'll find a new board, but I like the fact that this  
> > board is
> > already passively cooled (a requirement, or at least a strong  
> > plus, in our
> > product), is quite cheap and from a reputable company.
>
> we have to solve this. So, let's solve it.

Yep.  It's going to be a pain though, for the reasons
you outlined yourself already.

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Peter Stuge]

On Thu, Nov 30, 2006 at 05:16:52AM +0100, Segher Boessenkool wrote:
> > The USB debug capability is supposed to work even when almost
> > nothing is work.
>
> EHCI debug port requires PCI to be set up (at least
> partially) -- it requires a BAR.

Am I correct in understanding that this is about the same amount
of work as is needed to reach the serial port super IO chips?

The BAR is just an address at which the controller will listen -
right - or does it have to be backed by system RAM?

Indeed PCI accesses must be seen by the controller for it to matter
in the first place.

(Did my other message about abusing buses come through?)

//Peter

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> > > The USB debug capability is supposed to work even when almost
> > > nothing is work.
> >
> > EHCI debug port requires PCI to be set up (at least
> > partially) -- it requires a BAR.
>
> Am I correct in understanding that this is about the same amount
> of work as is needed to reach the serial port super IO chips?

No, it's more work.
> The BAR is just an address at which the controller will listen -
> right

Sort of.
> or does it have to be backed by system RAM?

Nope.

You typically need to set up quite a bit of the PCI subsystem
for it to work -- including not only bridges and devices on
the path to the PCI function you're interested in, but also
any siblings of any such.  And you need to do some work with
the north bridge typically (open up some window there).

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Stefan Reinauer]

* Segher Boessenkool  [061130 18:22]:
> You typically need to set up quite a bit of the PCI subsystem
> for it to work -- including not only bridges and devices on
> the path to the PCI function you're interested in, but also
> any siblings of any such.

Why would that be?
> And you need to do some work with
> the north bridge typically (open up some window there).

thanks for the compat chain that we reliably have on x86, all of the
above is a noop on 100% of our currently supported machines.

If we happen to see a system where this actually matters, we can 
still decide not to go ehci if we find a simpler solution, but lets not
talk this dead for no realworld reason now.

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> > You typically need to set up quite a bit of the PCI subsystem
> > for it to work -- including not only bridges and devices on
> > the path to the PCI function you're interested in, but also
> > any siblings of any such.
>
> Why would that be?

Because you don't want two devices claiming the same
transaction.
> > And you need to do some work with
> > the north bridge typically (open up some window there).
>
> thanks for the compat chain that we reliably have on x86, all of the
> above is a noop on 100% of our currently supported machines.

But the EHCI controller's BAR isn't on the "compat chain".
It's not subtractively decoded.  It's a memory BAR as well
(is it?), so on x86 you need to set MTRR regs, etc.
> If we happen to see a system where this actually matters, we can
> still decide not to go ehci if we find a simpler solution, but lets  
> not
> talk this dead for no realworld reason now.

I'm not saying not to use the EHCI debug port.  I'm just
saying it's not nearly as simple as legacy serial to get
working.

But yes, let's drop the discussion for now, someone should
write some code for this and we can discuss that instead :-)

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Russ Whitaker]

On Wed, 29 Nov 2006, Simon Labrecque wrote:
> I'm asking because obviously I don't know the answer, but can't a serial
> port on a PCI card be used? Wouldn't that be simpler than through-USB
> debugging?
>
> If not, well I'll find a new board, but I like the fact that this board is
> already passively cooled (a requirement, or at least a strong plus, in our
> product), is quite cheap and from a reputable company.
>
> If someone has a board to suggest, please jump in.
>
> Simon Labrecque
>
> -----Original Message-----
> From: ron minnich [mailto:[e-mail]]
> Sent: Wednesday, November 29, 2006 7:17 PM
> To: Lu, Yinghai
> Cc: Simon Labrecque; [e-mail]
> Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop CPU
>
> we are going to have to learn USB debug port. This problem is not going
> away.

Does the board have a parallel (printer) port?
Just an idea
   Russ

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Simon Labrecque]

Nope, unfortunately.

Simon Labrecque

-----Original Message-----
From: Russ Whitaker [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 11:09 PM
To: Simon Labrecque
Cc: 'ron minnich'; 'Lu, Yinghai'; [e-mail]
Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

On Wed, 29 Nov 2006, Simon Labrecque wrote:
> I'm asking because obviously I don't know the answer, but can't a serial
> port on a PCI card be used? Wouldn't that be simpler than through-USB
> debugging?
>
> If not, well I'll find a new board, but I like the fact that this board is
> already passively cooled (a requirement, or at least a strong plus, in our
> product), is quite cheap and from a reputable company.
>
> If someone has a board to suggest, please jump in.
>
> Simon Labrecque
>
> -----Original Message-----
> From: ron minnich [mailto:[e-mail]]
> Sent: Wednesday, November 29, 2006 7:17 PM
> To: Lu, Yinghai
> Cc: Simon Labrecque; [e-mail]
> Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop

CPU
> we are going to have to learn USB debug port. This problem is not going
> away.

Does the board have a parallel (printer) port?
Just an idea
   Russ

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[yhlu]

find one MB, even only have pin connecter in MB is good.

for USB, some chipset, you need to
1. init ht chain
2. find SB
3. patch SB, to make USB working...

otherwise USB will not work.

YH

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[yhlu]

On 11/29/06, Simon Labrecque  wrote:
> If someone has a board to suggest, please jump in.

1. one from supermicro
2. one from MSI

YH

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Simon Labrecque]

Suggestions:
- Asus M2N-E
(http://www.asus.com/products4.aspx?l1=3&l2=101&l3=308&model=1181...
2)
- MSI K9N Platinum
(http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID
=730)
- MSI K9N Neo-F
(http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID
=733)
- Gigabyte GA-M57SLI-S4
(http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?Prod
uctID=2287)
- GIGABYTE GA-M59SLI-S5
(http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?Prod
uctID=2302)

Here's a small list, pretty much in the order I'd choose them. We can
accommodate for any of these boards, though.

Is one of those OK with you?

Simon Labrecque

-----Original Message-----
From: yhlu [mailto:[e-mail]] 
Sent: Wednesday, November 29, 2006 11:25 PM
To: Simon Labrecque
Cc: ron minnich; [e-mail]
Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop CPU

On 11/29/06, Simon Labrecque  wrote:
> If someone has a board to suggest, please jump in.

1. one from supermicro
2. one from MSI

YH

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Carl-Daniel Hailfinger]

Simon Labrecque wrote:
> Suggestions:
> MSI K9N Platinum
>
> (http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID
> =730)
> MSI K9N Neo-F
>
> (http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID
> =733)

Both of them would be good targets. Both have onboard serial ports and both
are passively cooled.

Differences between the two boards:
K9N Platinum
* nForce 570
* 6 internal USB ports
* 6 SATA ports
* 2x Gbit LAN
* Firewire <------ good for Media Center

K9N Neo
* nForce 550
* 4 internal USB ports
* 4 SATA ports
* 1x Gbit LAN

Regards,
Carl-Daniel

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> we are going to have to learn USB debug port. This problem is not  
> going away.

The EHCI debug port requires slightly _more_ setup than
plugin PCI 16550 cards do...

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

Segher Boessenkool  writes:
> > we are going to have to learn USB debug port. This problem is not  
> > going away.
>
> The EHCI debug port requires slightly _more_ setup than
> plugin PCI 16550 cards do...

True.  But it is generally available and you don't need DMA to use it.
It would not too be hard for bring up to use a plug in PCI serial port
card.  But it doesn't solve the problem in general and you would have
take out all of the serial port code when you are done.

Has anyone made in progress sorting out the EHCI USB debug port yet.  I'm about
1/4 of the way from implementing kernel support.  Currently I have just gotten
as far as a user space client that can detect debug port support and send characters
across.  A low level driver you can use early I have yet to implement, possibly
in the next couple of days.  But if someone has done something I can compare
notes with that would be great.

As far as LinuxBIOS goes going from a simple kernel driver to a driver you can use
during memory initialization shouldn't be too hard.  Just a little more setup.

Eric

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Ed Swierk]

On 11/29/06, Lu, Yinghai  wrote:
> Too late.

Translation: LinuxBIOS cannot access the serial port on a PCI card
until late in the boot process, after initializing and scanning the
PCI bus. Only a serial port integrated into the mainboard chipset can
be initialized early enough to be useful for debugging.

--Ed

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> > Too late.
>
> Translation: LinuxBIOS cannot access the serial port on a PCI card
> until late in the boot process, after initializing and scanning the
> PCI bus. Only a serial port integrated into the mainboard chipset can
> be initialized early enough to be useful for debugging.

That's not exactly true.  A serial port that has its
address space subtractively decoded (at least at boot
time) certainly is easier to set up; but it certainly
isn't impossible to set up just enough of the PCI fan-out
to reach a plugin card; esp. if you do this for debug
purposes only (i.e., not for the end-user), you can
hardcode all of this.

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.

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Peter Stuge]

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? :)

//Peter

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Carl-Daniel Hailfinger]

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

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Clay Jones]

Perhaps i2c/smbus.

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

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> SPI
> When all vendors move to SPI,

If, not when.  And it's never going to happen, SPI is
just too slow for many applications.
> 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

Con: SPI as implemented on most boards can only support
a single device (the flash chip).

Segher

[LinuxBIOS] Support for recent chipset and powerful desktop CPU

[Segher Boessenkool]

> What signals can be twiddled at, or soon after, power on?

Stuff attached directly to the CPU; stuff attached directly
to the north bridge; stuff on a subtractive decode path
anywhere further on the I/O fan-out.
> DRAM
> Pro: Easy to make/get/order PCBs that fit
> Con: Not easily accessible without setting up DRAM controller
> (Is this the case?)

Nope; I suggested using the I2C bus only!  Only issue is
getting the correct voltages onto the board.
> IDE
> Pro: Simple 8-bit PIO, easy to interface with
> Con: Needs SuperIO running, at least a little, like the serial port.

Most superio chips don't do IDE these days.

Segher