Too late.
YH
________________________________
From: Simon Labrecque [mailto:agarwal@videotron.ca] Sent: Wednesday, November 29, 2006 1:49 PM To: Lu, Yinghai; linuxbios@linuxbios.org 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:yinghai.lu@amd.com] Sent: Wednesday, November 29, 2006 3:25 PM To: Simon Labrecque; linuxbios@linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU
The MB doesn't have serial port.
YH
________________________________
From: Simon Labrecque [mailto:agarwal@videotron.ca] Sent: Wednesday, November 29, 2006 10:51 AM To: Lu, Yinghai; linuxbios@linuxbios.org 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:yinghai.lu@amd.com] Sent: Wednesday, November 29, 2006 1:05 PM To: Simon Labrecque; linuxbios@linuxbios.org 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=amd.com@linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com@linuxbios.org] On Behalf Of Simon Labrecque Sent: Wednesday, November 22, 2006 4:34 AM To: linuxbios@linuxbios.org 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
I'm sorry but I don't understand your reply. Too late for what exactly?
Simon Labrecque
From: Lu, Yinghai [mailto:yinghai.lu@amd.com] Sent: Wednesday, November 29, 2006 4:56 PM To: Simon Labrecque; linuxbios@linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU
Too late.
YH
_____
From: Simon Labrecque [mailto:agarwal@videotron.ca] Sent: Wednesday, November 29, 2006 1:49 PM To: Lu, Yinghai; linuxbios@linuxbios.org 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:yinghai.lu@amd.com] Sent: Wednesday, November 29, 2006 3:25 PM To: Simon Labrecque; linuxbios@linuxbios.org Subject: RE: [LinuxBIOS] Support for recent chipset and powerful desktop CPU
The MB doesn't have serial port.
YH
_____
From: Simon Labrecque [mailto:agarwal@videotron.ca] Sent: Wednesday, November 29, 2006 10:51 AM To: Lu, Yinghai; linuxbios@linuxbios.org 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:yinghai.lu@amd.com] Sent: Wednesday, November 29, 2006 1:05 PM To: Simon Labrecque; linuxbios@linuxbios.org 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=amd.com@linuxbios.org [mailto:linuxbios-bounces+yinghai.lu=amd.com@linuxbios.org] On Behalf Of Simon Labrecque Sent: Wednesday, November 22, 2006 4:34 AM To: linuxbios@linuxbios.org 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
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.
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
we are going to have to learn USB debug port. This problem is not going away.
ron
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:rminnich@gmail.com] Sent: Wednesday, November 29, 2006 7:17 PM To: Lu, Yinghai Cc: Simon Labrecque; linuxbios@linuxbios.org 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
On 11/29/06, Simon Labrecque agarwal@videotron.ca 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
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
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
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
* Segher Boessenkool segher@kernel.crashing.org [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.
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
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:rminnich@gmail.com] Sent: Wednesday, November 29, 2006 7:17 PM To: Lu, Yinghai Cc: Simon Labrecque; linuxbios@linuxbios.org 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
Nope, unfortunately.
Simon Labrecque
-----Original Message----- From: Russ Whitaker [mailto:russ@ashlandhome.net] Sent: Wednesday, November 29, 2006 11:09 PM To: Simon Labrecque Cc: 'ron minnich'; 'Lu, Yinghai'; linuxbios@linuxbios.org 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:rminnich@gmail.com] Sent: Wednesday, November 29, 2006 7:17 PM To: Lu, Yinghai Cc: Simon Labrecque; linuxbios@linuxbios.org 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
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
On 11/29/06, Simon Labrecque agarwal@videotron.ca wrote:
If someone has a board to suggest, please jump in.
1. one from supermicro 2. one from MSI
YH
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:yinghailu@gmail.com] Sent: Wednesday, November 29, 2006 11:25 PM To: Simon Labrecque Cc: ron minnich; linuxbios@linuxbios.org Subject: Re: [LinuxBIOS] Support for recent chipset and powerful desktop CPU
On 11/29/06, Simon Labrecque agarwal@videotron.ca wrote:
If someone has a board to suggest, please jump in.
1. one from supermicro 2. one from MSI
YH
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
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
Segher Boessenkool segher@kernel.crashing.org 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
On 11/29/06, Lu, Yinghai yinghai.lu@amd.com 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
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
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
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
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
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
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