Where to get USB-to-Serial or USB-to-USB device mentioned in the doc?
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
YH
Lu, Yinghai wrote:
Where to get USB-to-Serial or USB-to-USB device mentioned in the doc?
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
Here's the info on the PLX Hi-Speed USB 2.0 Debug Cable: http://www.plxtech.com/products/NET2000/NET20DC/default.asp
Here are some other adapters I've found to debug via I2C or SPI:
I2C Bus to USB or serial adapters http://www.mcc-us.com/catalog.htm#I2C%20Bus%20Host%20Adapters
I2C/SPI Host Adapter http://www.totalphase.com/products/aardvark/
I2C Bus to USB or serial adapters http://www.telos.info/products/
QBridge-I2C-USB http://www.qprotos.com/index.html
This adapter even has Linux tools: USB-I2C/SPI/GPIO Interface Adapter http://www.diolan.com/i2c/u2c12.html
with a probe like this that slides into the dimm socket: http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html
-Bari
"Lu, Yinghai" yinghai.lu@amd.com writes:
Where to get USB-to-Serial or USB-to-USB device mentioned in the doc?
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
It looks like Bari already answered this one but: http://tinyurl.com/nq6kc is the short version :)
Eric
Bari Ari wrote:
I2C Bus to USB or serial adapters http://www.mcc-us.com/catalog.htm#I2C%20Bus%20Host%20Adapters
I2C/SPI Host Adapter http://www.totalphase.com/products/aardvark/
I2C Bus to USB or serial adapters http://www.telos.info/products/
QBridge-I2C-USB http://www.qprotos.com/index.html
This adapter even has Linux tools: USB-I2C/SPI/GPIO Interface Adapter http://www.diolan.com/i2c/u2c12.html
Those are a lot of interesting links. They are all pretty expensive, though. A bargain basement option would be an AVR butterfly. The Atmel micros have UART/SPI/I2C built in, and the butterfly is 20USD. You could even probably achieve USB with this, there is software bitbang (!) USB available for AVR.
http://www.dwelch.com/avr/ http://www.obdev.at/products/avrusb/projects.html http://www.harbaum.org/till/i2c_tiny_usb/
with a probe like this that slides into the dimm socket: http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html
That one is a little bit out there. That board is probably $10K, and you need a $100K Tek Logic Analyzer to use it. :)
Tom Sylla wrote:
with a probe like this that slides into the dimm socket: http://www.busboards.com/products/memory/ddrii/ddrii400dc/ddriidc.jpg http://www.busboards.com/products/memory/ddrii/ddrii400dc/index.html
That one is a little bit out there. That board is probably $10K, and you need a $100K Tek Logic Analyzer to use it. :)
It's just a passive DIMM module with cables for each signal connection at the socket. I'm sure it's priced relatively high since it comes with coaxial cables for 8GHz timing analysis and was probably assembled by highly skilled elves. Someone could fab these however as a 2 sided pcb with only the SMBus signals for next to nothing in cost.
-Bari
On Thu, Nov 30, 2006 at 07:44:47PM -0600, Bari Ari wrote:
Someone could fab these however as a 2 sided pcb with only the SMBus signals for next to nothing in cost.
I looked into this yesterday.
The place I normally order prototype boards from (Olimex) don't stock any 1.2mm laminate.
The place I order production boards from (local fab) do have 1.2mm laminate but the minimum order they do is one full panel (about .5m2) - that means a big bag of boards. :)
If there's interest I'll be happy to make a DDR2 board that does high speed SPD<->USB.
I estimate they would go at $150 assembled or a bit cheaper as kits. (All SMD though.)
I need about 20 orders before starting it up, then roughly two months until they're shipping.
This is pretty special-purpose though. Perhaps time would be better spent on the LPC thingy, since they can be used for testing too.
//Peter
On 12/1/06, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Thu, Nov 30, 2006 at 07:44:47PM -0600, Bari Ari wrote:
Someone could fab these however as a 2 sided pcb with only the SMBus signals for next to nothing in cost.
I looked into this yesterday.
The place I normally order prototype boards from (Olimex) don't stock any 1.2mm laminate.
The place I order production boards from (local fab) do have 1.2mm laminate but the minimum order they do is one full panel (about .5m2)
- that means a big bag of boards. :)
If there's interest I'll be happy to make a DDR2 board that does high speed SPD<->USB.
I estimate they would go at $150 assembled or a bit cheaper as kits. (All SMD though.)
I need about 20 orders before starting it up, then roughly two months until they're shipping.
This is pretty special-purpose though. Perhaps time would be better spent on the LPC thingy, since they can be used for testing too.
I am missing something here. If we have enough of PCI up to do SPD->USB, I would bet that we have enough of it up to do USB debug? or not?
LPC is going away on many boards, I understand. I think that we are going into a world where we have to figure out usb debug port. I don't think that the PCI initial setup for USB debug is going to be impossible -- the vendors have to debug these boards too. All the boards I have used lately have a very straightforward path to USB, that could be set up in the ROMCC or CAR code.
ron
On Fri, Dec 01, 2006 at 09:10:08AM -0700, ron minnich wrote:
This is pretty special-purpose though. Perhaps time would be better spent on the LPC thingy, since they can be used for testing too.
I am missing something here. If we have enough of PCI up to do SPD->USB, I would bet that we have enough of it up to do USB debug? or not?
SPD as in instead of reading from an EEPROM on a DIMM you would be talking to a I2C slave on a special DIMM-like board that sends data to a host somehow.
The assumption was that not much needs to happen before the SPD I2C bus is accessible by the CPU - is that valid?
If not, what IS easily accessible besides the boot ROM? (Which we don't want to rely on since we don't know exactly what it will speak when in the future.) We just need one bit that can do kHz signalling. SMI#?
LPC is going away on many boards, I understand.
But DDR(2) SDRAM will probably stay a while longer. Or not?
I think that we are going into a world where we have to figure out usb debug port.
It's certainly one good debugging option but maybe not the only good one.
I don't think that the PCI initial setup for USB debug is going to be impossible -- the vendors have to debug these boards too. All the boards I have used lately have a very straightforward path to USB, that could be set up in the ROMCC or CAR code.
I think it should be fairly simple on x86 too, but we would also like more exotic systems in v3 so exploring other options is good. (And fun!)
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [061201 19:16]:
The assumption was that not much needs to happen before the SPD I2C bus is accessible by the CPU - is that valid?
Since you need I2C, you need to get parts of the south bridge working. So, its basically the same amount of work as with the USB debug port.
Question is: Will we see systems without USB (debug port) but with DDR2 sockets?
If not, what IS easily accessible besides the boot ROM? (Which we don't want to rely on since we don't know exactly what it will speak when in the future.) We just need one bit that can do kHz signalling. SMI#?
Boot rom is a good start I bet. That will always be there (as long as we all do firmware development at least).
It might be parallel yesterday, LPC today and SPI tomorrow, but that is only the interface it connects to. Different connector, different VHDL source and we should be fine, no?
LPC is going away on many boards, I understand.
But DDR(2) SDRAM will probably stay a while longer. Or not?
If LPC goes away, we need to do SPI. Ok. If we get DDR3, we would have to do that. Technical standards come and go,.. I'd prefer a solution that is so cheap that I dont mind throwing the whole kit away after doing a port or two, rather than trying to create something that is good forever.
I think that we are going into a world where we have to figure out usb debug port.
It's certainly one good debugging option but maybe not the only good one.
Especially it does not help for reflashing. Finding something nifty here would be nice.
Stefan
On Fri, Dec 01, 2006 at 07:28:53PM +0100, Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@cdy.org [061201 19:16]:
The assumption was that not much needs to happen before the SPD I2C bus is accessible by the CPU - is that valid?
Since you need I2C, you need to get parts of the south bridge working.
Even though it's on the DIMM? Ugh. :(
So, its basically the same amount of work as with the USB debug port.
Yeah. Not much point to it then.
Question is: Will we see systems without USB (debug port) but with DDR2 sockets?
See wiki page with list of EHCI chips that lack the debug port. On the other hand maybe all boards using them will have a serial port?
If not, what IS easily accessible besides the boot ROM? (Which we don't want to rely on since we don't know exactly what it will speak when in the future.) We just need one bit that can do kHz signalling. SMI#?
Boot rom is a good start I bet. That will always be there (as long as we all do firmware development at least).
It might be parallel yesterday, LPC today and SPI tomorrow, but that is only the interface it connects to. Different connector, different VHDL source and we should be fine, no?
True. TSOPs are a bit unfriendly but still doable with a steady hand.
LPC is going away on many boards, I understand.
But DDR(2) SDRAM will probably stay a while longer. Or not?
If LPC goes away, we need to do SPI. Ok. If we get DDR3, we would have to do that. Technical standards come and go,.. I'd prefer a solution that is so cheap that I dont mind throwing the whole kit away after doing a port or two, rather than trying to create something that is good forever.
Me too. But the kit only gets that cheap if it can be produced in at least a run of 100. And while those are too small quantities for even receiving a quote from some suppliers it's already too big for us. :\
The testing infrastructure is the dealbreaker right now.
I think that we are going into a world where we have to figure out usb debug port.
It's certainly one good debugging option but maybe not the only good one.
Especially it does not help for reflashing. Finding something nifty here would be nice.
I hear you.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [061201 19:46]:
Since you need I2C, you need to get parts of the south bridge working.
Even though it's on the DIMM? Ugh. :(
It's the same as trying to see the SPD ROM, isnt it? That is connected to the south bridge smbus. Not too wild though,..
Me too. But the kit only gets that cheap if it can be produced in at least a run of 100. And while those are too small quantities for even receiving a quote from some suppliers it's already too big for us. :\
The testing infrastructure is the dealbreaker right now.
Ok, I am waiting for the final ok to announce it all. Lets hope people will join in.
Stefan
On Fri, Dec 01, 2006 at 08:10:45PM +0100, Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@cdy.org [061201 19:46]:
Since you need I2C, you need to get parts of the south bridge working.
Even though it's on the DIMM? Ugh. :(
It's the same as trying to see the SPD ROM, isnt it?
Right.
That is connected to the south bridge smbus. Not too wild though,..
Ugh again. :( What a detour. The memory controller is in the CPU or the northbridge, right?
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [061201 20:24]:
That is connected to the south bridge smbus. Not too wild though,..
Ugh again. :( What a detour. The memory controller is in the CPU or the northbridge, right?
Yeah. You need a little bit of everything to make it lit up.
The place I order production boards from (local fab) do have 1.2mm laminate but the minimum order they do is one full panel (about .5m2)
- that means a big bag of boards. :)
Real cheap-skates just demolish an existing (already broken) DIMM ;-)
If there's interest I'll be happy to make a DDR2 board that does high speed SPD<->USB.
Why USB? RS232 is soooo much simpler, can connect to anything without special software / drivers needed.
This is pretty special-purpose though. Perhaps time would be better spent on the LPC thingy, since they can be used for testing too.
Many systems don't have LPC and it's getting worse. An LPC thing would be useful, of course.
Segher
I am missing something here. If we have enough of PCI up to do SPD->USB, I would bet that we have enough of it up to do USB debug? or not?
Many systems don't require any PCI to access their I2C controllers.
LPC is going away on many boards, I understand. I think that we are going into a world where we have to figure out usb debug port. I don't think that the PCI initial setup for USB debug is going to be impossible
It is possible, sure -- *per board*. Anything generic would require a huge amount of code (and data). Not suitable for early boot.
All the boards I have used lately have a very straightforward path to USB, that could be set up in the ROMCC or CAR code.
Yeah. So someone do it please, let's get some hands-on experience with this stuff :-)
Segher
On 12/1/06, Segher Boessenkool segher@kernel.crashing.org wrote:
I am missing something here. If we have enough of PCI up to do SPD->USB, I would bet that we have enough of it up to do USB debug? or not?
Many systems don't require any PCI to access their I2C controllers.
I have never used a PC that doesn't require it. We come from different worlds.
ron
The assumption was that not much needs to happen before the SPD I2C bus is accessible by the CPU - is that valid?
Depends on the system. Intel tends to put the I2C controllers on the south bridge, such a shame.
If not, what IS easily accessible besides the boot ROM?
In general? Nothing, not necessarily the boot ROM even!
LPC is going away on many boards, I understand.
But DDR(2) SDRAM will probably stay a while longer. Or not?
That is the nice thing about the DIMM serial: memory modules will keep using I2C SPD eeproms for the foreseeable future, and (almost) every board uses DIMMs.
I think that we are going into a world where we have to figure out usb debug port.
It's certainly one good debugging option but maybe not the only good one.
And *all* these options require special (extra) debug hardware, no good for the end user.
I don't think that the PCI initial setup for USB debug is going to be impossible -- the vendors have to debug these boards too. All the boards I have used lately have a very straightforward path to USB, that could be set up in the ROMCC or CAR code.
I think it should be fairly simple on x86 too, but we would also like more exotic systems in v3 so exploring other options is good. (And fun!)
It can't be done in a generic way. That doesn't matter of course, the CAR code by very nature isn't generic. It might require our CAR code to be more board-specific than we want though (although perhaps (some of) it can be parametrised in the DT).
Segher
The assumption was that not much needs to happen before the SPD I2C bus is accessible by the CPU - is that valid?
Since you need I2C, you need to get parts of the south bridge working. So, its basically the same amount of work as with the USB debug port.
Most systems I work with have I2C controllers (and typically more than one) in the north bridge, not somewhere south (which is an insane idea).
Question is: Will we see systems without USB (debug port) but with DDR2 sockets?
Yes. They exist already (mostly in the embedded world, of course).
If not, what IS easily accessible besides the boot ROM? (Which we don't want to rely on since we don't know exactly what it will speak when in the future.) We just need one bit that can do kHz signalling. SMI#?
Boot rom is a good start I bet. That will always be there (as long as we all do firmware development at least).
It might be parallel yesterday, LPC today and SPI tomorrow, but that is only the interface it connects to. Different connector, different VHDL source and we should be fine, no?
SPI buses as implemented on most x86 systems for flash, do _not_ support attaching extra devices on the bus (you'd need a separate chip-select signal, and those either don't exist or aren't readily available on the board).
If LPC goes away, we need to do SPI. Ok. If we get DDR3, we would have to do that. Technical standards come and go,.. I'd prefer a solution that is so cheap that I dont mind throwing the whole kit away after doing a port or two, rather than trying to create something that is good forever.
The "SPD" solution works over all families of DIMMs.
I think that we are going into a world where we have to figure out usb debug port.
It's certainly one good debugging option but maybe not the only good one.
Especially it does not help for reflashing. Finding something nifty here would be nice.
JTAG into the north bridge, and you can init all system buses, done ;-)
On some systems you don't even need such init, the PCI starts running -- so you can DMA from a plug-in card to the flash chip.
Again though: none of this is suitable for an "end-user", someone not too hardware savvy to help getting LinuxBIOS going on his board (or to restore flash after an "accident", etc).
Segher
Since you need I2C, you need to get parts of the south bridge working.
Even though it's on the DIMM? Ugh. :(
So, its basically the same amount of work as with the USB debug port.
Yeah. Not much point to it then.
Well at least it's an I/O BAR instead of a memory BAR, quite a bit easier to do portably.
Question is: Will we see systems without USB (debug port) but with DDR2 sockets?
See wiki page with list of EHCI chips that lack the debug port. On the other hand maybe all boards using them will have a serial port?
Lots of boards don't have USB... Remember, the desktop market is only a very small percentage of the total (Linux) market!
Segher
Since you need I2C, you need to get parts of the south bridge working.
Even though it's on the DIMM? Ugh. :(
It's the same as trying to see the SPD ROM, isnt it? That is connected to the south bridge smbus. Not too wild though,..
No, it's on whatever I2C people put it on. Yes it's true intel puts their I2C controllers on the south bridge, they like making life hard. Not every hardware manufacturer is that way :-)
Segher
It seems to me the order of choices is something like this:
Best: 1. USB debug port. This is going to work well in the x86 world, as even the embeddec boards tend to have USB. USB is replacing rs232 in those worlds. Based on the boards we have used in last 7 years, on x86, setting up the PCI infrastructure at very early boot to use this should not be hard. USB is almost always on bus 0. PowerPC sounds a bit harder. 2. JTAG. This is very common on the PPC boards we have used. It is by far the best option, since reflash after a disaster is possible, debugging is easy, and so on. Rare on x86, common on PowerPC and ARM.
The next in line are: 3. SPD. Just as hard to get working as USB debug port on x86, since SPD is on the south. Not useful on most x86 and PowerPC embedded boards I have used, as they have no DRAM sockets of any kind -- and, if you only have one, the usefulness is quite limited, since you have to take the DRAM out to put the debugging in. But, most of the time, you're debugging DRAM ...Requires that we design and build a card. I don't think this approach is that practical. 4. LPC debugger. This one is kind of interesting, requires that we build a card, but could have good use -- as long as LPC doesn't go away. 5. I2C snooper. Just solder onto I2C and use a card you build?
I still see (1) and (2) as the most practical.
ron
* Segher Boessenkool segher@kernel.crashing.org [061201 23:38]:
No, it's on whatever I2C people put it on. Yes it's true intel puts their I2C controllers on the south bridge, they like making life hard. Not every hardware manufacturer is that way :-)
all PC components manufacturers do. 99% of the non-embedded market.
* Segher Boessenkool segher@kernel.crashing.org [061201 23:36]:
See wiki page with list of EHCI chips that lack the debug port. On the other hand maybe all boards using them will have a serial port?
Lots of boards don't have USB... Remember, the desktop market is only a very small percentage of the total (Linux) market!
Linux is only a very small market to begin with. ;-)
* Segher Boessenkool segher@kernel.crashing.org [061201 23:21]:
If not, what IS easily accessible besides the boot ROM?
In general? Nothing, not necessarily the boot ROM even!
Right. The machine might be booting out of the air.
Or have some overlay in the southbridge (our s-word today), like the xbox does.
Besides that we will never see a port to a machine where ROM is not accessible when the firmware starts. I bet.
;-)
It seems to me the order of choices is something like this:
Best:
- USB debug port. This is going to work well in the x86 world, as
even the embeddec boards tend to have USB. USB is replacing rs232 in those worlds. Based on the boards we have used in last 7 years, on x86, setting up the PCI infrastructure at very early boot to use this should not be hard. USB is almost always on bus 0. PowerPC sounds a bit harder.
Not (much) harder in most cases -- x86 has most of the same problems (memory windows (MTRR), HT init, PCI in a completely unknown state at boot time (warm boot), etc.)
- JTAG. This is very common on the PPC boards we have used. It is by
far the best option, since reflash after a disaster is possible, debugging is easy, and so on. Rare on x86, common on PowerPC and ARM.
Common on anything but x86, yes (although almost all x86 CPUs and chipsets have JTAG, it hardly ever is brought out on the board).
This is the #1 choice as it gives you *much* more than just a console; in most cases, it even allows you to boot the whole system without a ROM at all.
The next in line are: 3. SPD. Just as hard to get working as USB debug port on x86, since SPD is on the south. Not useful on most x86 and PowerPC embedded boards I have used, as they have no DRAM sockets of any kind -- and, if you only have one, the usefulness is quite limited, since you have to take the DRAM out to put the debugging in. But, most of the time, you're debugging DRAM ...Requires that we design and build a card. I don't think this approach is that practical.
Seems it would not too useful on most x86, yeah. Most embedded boards have I2C headers (or easily accessible pins) all over the place though, the general idea still holds -- the nice thing about using a DIMM is that the same connector works on many boards.
- LPC debugger. This one is kind of interesting, requires that we
build a card, but could have good use -- as long as LPC doesn't go away.
Not just LPC -- you want a common socket to use too.
- I2C snooper. Just solder onto I2C and use a card you build?
Same as #3 really.
I still see (1) and (2) as the most practical.
JTAG is best, sure. The "get the LPC bus from the flash socket" thing would be very nice for many boards, too.
The other solutions only give you a "UART", and require some work at boot time; EHCI debug works if your board supports it, a UART on an I2C bus (on a DIMM, perhaps) can be used otherwise.
And let's not forget that most boards have 16550-style ports still ;-)
Segher
On Fri, Dec 01, 2006 at 11:21:15PM +0100, Segher Boessenkool wrote:
If not, what IS easily accessible besides the boot ROM?
In general? Nothing, not necessarily the boot ROM even!
I was trying to think outside the box. Is there any way to affect the system in a way that is easy to measure? Power? Voltage? Any bit that is easy to tap works. It must not be intended for communication, a side-effect is fine, as long as it is portable. (Ie. certain instructions executed in a certain order => CPU draws more power.) A bit wild, but simple to implement.
I think that we are going into a world where we have to figure out usb debug port.
It's certainly one good debugging option but maybe not the only good one.
And *all* these options require special (extra) debug hardware, no good for the end user.
We have to make sure the code never fails that early then. He-he.
I don't think that the PCI initial setup for USB debug is going to be impossible -- the vendors have to debug these boards too. All the boards I have used lately have a very straightforward path to USB, that could be set up in the ROMCC or CAR code.
I think it should be fairly simple on x86 too,
It can't be done in a generic way.
This is an interesting topic. See other thread about RAM.
//Peter
Turns out it's the same thread.
On Fri, Dec 01, 2006 at 11:15:16PM +0100, Segher Boessenkool wrote:
I don't think that the PCI initial setup for USB debug is going to be impossible
It is possible, sure -- *per board*. Anything generic would require a huge amount of code (and data).
The low-level specifics of "init enough PCI to reach EHCI" and "init the DRAM controller" obviously differ between boards.
Both these tasks will however share at least some code between boards. It would be nice if we could re-use code instead of having duplicates.
For the EHCI PCI init I guess we will have to wait for experience and improve when we see problems, all I can come up with is that the early EHCI finder could use common PCI functions, which it probably already does.
Perhaps we could do better with RAM init though.
Would a RAM init API make sense?
How different is SDRAM, DDR and DDR2 init on one controller compared to another? Do the controllers usually work in similar ways so that the higher level sequence of things to do is the same on them all?
If so, it would be nice to encode these init sequences into lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to implement.
This is especially nice if there are many high-level steps. It will also help new ports and new porters a great deal since it wont be neccessary to learn all about RAM init before a new port - only how to do a certain task (eg. set CAS latency) on the given chipset, which may be easier to find in the data sheet, or from vendor support. Such an (internal) interface might make it easier for chipset vendors to support LinuxBIOS too.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [061203 19:28]:
Perhaps we could do better with RAM init though.
Would a RAM init API make sense?
How different is SDRAM, DDR and DDR2 init on one controller compared to another? Do the controllers usually work in similar ways so that the higher level sequence of things to do is the same on them all?
Many things are different, but I think we could seriously gain from anything we can APIfy. DRAM init is our biggest time waster nowadays.
If so, it would be nice to encode these init sequences into lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to implement.
Yes!!
And *all* these options require special (extra) debug hardware, no good for the end user.
We have to make sure the code never fails that early then. He-he.
That is of course the plan, but we all know that problems _will_ show up (not often hopefully), for example, a user has a hardware configuration that we never thought of (or didn't test on, at least); it would be quite helpful to get some debug data out in such a case.
That being so hard, I guess we have to focus on making our code as bullet-proof as possible; i.e., even if half the hardware setup fails, make sure the rest works irrespectively, so we get the debug text out.
Segher
The low-level specifics of "init enough PCI to reach EHCI" and "init the DRAM controller" obviously differ between boards.
Both these tasks will however share at least some code between boards. It would be nice if we could re-use code instead of having duplicates.
Yes.
For the EHCI PCI init I guess we will have to wait for experience and improve when we see problems,
Yes -- it helps to think about the problem before coding it, and to discuss the problems, though. Which we did. Let's move on now :-)
Perhaps we could do better with RAM init though.
Would a RAM init API make sense?
How different is SDRAM, DDR and DDR2 init on one controller compared to another?
Very different.
Do the controllers usually work in similar ways so that the higher level sequence of things to do is the same on them all?
Well the signals on the actual DIMM bus end up being very similar; the registers to set, and what they do, vary wildly.
If so, it would be nice to encode these init sequences into lib/{sdram,ddr,ddr2} and make an API that the northbridge code has to implement.
An API that the memory controller code has to implement isn't going to work. Having a bunch of helper functions that the memory controller code can call as it wishes, is a good plan though.
This is especially nice if there are many high-level steps. It will also help new ports and new porters a great deal since it wont be neccessary to learn all about RAM init before a new port -
To successfully (and correctly!) program any memory controller, you really have to know both how the supported memory types work, and how the specific memory controller works. In detail.
only how to do a certain task (eg. set CAS latency) on the given chipset, which may be easier to find in the data sheet, or from vendor support. Such an (internal) interface might make it easier for chipset vendors to support LinuxBIOS too.
It sure would help porting to have many nice helper hooks, and to have a clear overview what a new port should look like (a flowchart, or some pseudo code; or we can just point to some port and say "this one is really good"). We shouldn't make the framework too stringent as boards/systems really do vary *wildly*.
Segher
On Mon, Dec 04, 2006 at 02:01:21AM +0100, Segher Boessenkool wrote:
Both these tasks will however share at least some code between boards. It would be nice if we could re-use code instead of having duplicates.
Yes.
Yes.
An API that the memory controller code has to implement isn't going to work. Having a bunch of helper functions that the memory controller code can call as it wishes, is a good plan though.
Yes, I agree. For example there are lots of very similar functions in current raminit.c implementations which deal mostly only with SPD registers and don't even access any controller registers. Those are perfect candidates to go into lib/spd or something.
But yes, we must make sure that we do not hard-code anything which might work differently on more exotic systems...
only how to do a certain task (eg. set CAS latency) on the given chipset, which may be easier to find in the data sheet, or from vendor support. Such an (internal) interface might make it easier for chipset vendors to support LinuxBIOS too.
It sure would help porting to have many nice helper hooks, and to have a clear overview what a new port should look like (a flowchart
Yeah, that would be a nice addition for the wiki.
As for an API/flowchart, I currently only know of this very tiny "API" from src/sdram/generic_sdram.c:
In auto.c (per-mainboard) you call * sdram_initialize(sizeof(cpu)/sizeof(cpu[0]), cpu);
This, in turn, calls three functions which must be implemented by any raminit.c AFAIK:
* sdram_set_registers() * sdram_set_spd_registers() * sdram_enable()
Something similar, and more elaborate, for other types of RAM would be nice.
Uwe.
-
Bari Ari -
ebiederman＠lnxi.com -
Lu, Yinghai -
Peter Stuge -
ron minnich -
Segher Boessenkool -
Stefan Reinauer -
Tom Sylla -
Uwe Hermann