Hello everybody,
I recently started to discover this great project you have here. I want to play with it a bit and port it to an AMD E-350 Motherboard (Sapphire Pure Fusion Mini E-350 - what a name...) I have at home in my spare time.
Now I don't think that the development work is much fun, when you have to take the SPI chip off the motherboard, program it, put it back into the board, see the code failing and repeat the whole process ;) So, I had the idea of developing a small Board which contains a USB port and an SPI flash. I first thought about emulating the SPI flash completely by an AVR, but I think the clock rates of the SPI bus are too high to do this. My new approach is a SPI flash which resides on the AVR board which can be multiplexed between the AVR to program it and the motherboard. If I want to test a new BIOS, the AVR puts the motherboard into reset, detaches the flash chip with a multiplexer from the motherboard, programs it, switches it back to the motherboard and let off the reset.
Rapid BIOS development :)
As an added bonus, I'm thinking about using a USB 2.0 port of an USB-capable AVR as a USB debug interface (those USB debugging cables are expensive for a poor student ;) ) and add a second USB 1.1 port with a MAX3420 for host-communication, but that's step 2. I know that I won't get the full 480MBit/s with this, but I think I can live with that.
As I am currently looking for suitable parts, I need to know some basic parameters of the SPI communication. Does anybody of you know what the typical clock rates between the chipset and the flash are?
Andy
Hello Andreas,
Your ideas sound pretty good, but here are a couple of ideas that might make your life easier (and cheaper).
I found some high-res pictures of your board on the web, and it looks like that board has a footprint for a SPI programming header (labelled SPI1, between USB1 and the SPI ROM). Board manufacturers put these headers on the board for BIOS development, to do exactly what you are trying to do: in-system SPI flash programming (they are often called in-system programming headers). One common commercial programmer is the SF100 from dediprog: http://www.dediprog.com/SPI-flash-in-circuit-programming
You can solder in a header (looks like a 2mm), or even just wires, and connect whatever USB to SPI adapter you want. You just leave the SPI ROM installed, and program it through the header. The header is designed so that even with the board off, the programmer hardware supplies power to the ROM device (only). Your board manual may have the pinout, or just use a meter to figure out how it connects to the SPI ROM.
Also, if you haven't seen it yet, take a look at the flashrom project: http://www.flashrom.org/Flashrom which can update flash from an OS, but also supports external programmers like you are trying to achieve: http://www.flashrom.org/FT2232SPI_Programmer
To answer your question, SPI clock rates are often about 33MHz, but some devices support faster speeds. You can usually run it much slower though.
Tom
On Mon, Jul 4, 2011 at 1:42 PM, Andreas Galauner andreas@galauner.de wrote:
Hello everybody,
I recently started to discover this great project you have here. I want to play with it a bit and port it to an AMD E-350 Motherboard (Sapphire Pure Fusion Mini E-350 - what a name...) I have at home in my spare time.
Now I don't think that the development work is much fun, when you have to take the SPI chip off the motherboard, program it, put it back into the board, see the code failing and repeat the whole process ;) So, I had the idea of developing a small Board which contains a USB port and an SPI flash. I first thought about emulating the SPI flash completely by an AVR, but I think the clock rates of the SPI bus are too high to do this. My new approach is a SPI flash which resides on the AVR board which can be multiplexed between the AVR to program it and the motherboard. If I want to test a new BIOS, the AVR puts the motherboard into reset, detaches the flash chip with a multiplexer from the motherboard, programs it, switches it back to the motherboard and let off the reset.
Rapid BIOS development :)
As an added bonus, I'm thinking about using a USB 2.0 port of an USB-capable AVR as a USB debug interface (those USB debugging cables are expensive for a poor student ;) ) and add a second USB 1.1 port with a MAX3420 for host-communication, but that's step 2. I know that I won't get the full 480MBit/s with this, but I think I can live with that.
As I am currently looking for suitable parts, I need to know some basic parameters of the SPI communication. Does anybody of you know what the typical clock rates between the chipset and the flash are?
Andy
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Andreas Galauner wrote:
I had the idea of developing a small Board which contains a USB port and an SPI flash.
Sure. Or just follow Tom's tip and wire a second SPI bus master directly onto the mainboard.
I first thought about emulating the SPI flash completely by an AVR,
What do you mean by AVR? It's relevant for much of what you write.
SPI flash must respond with data immediately after the last address bit is received. It's really inconvenient to emulate this.
new approach is a SPI flash which resides on the AVR board
Sure. But simpler to just connect directly to the SPI on the mainboard.
If I want to test a new BIOS, the AVR puts the motherboard into reset, detaches the flash chip with a multiplexer from the motherboard, programs it, switches it back to the motherboard and let off the reset.
Make that:
Hold reset Program flash chip on mainboard Release reset
As an added bonus, I'm thinking about using a USB 2.0 port of an USB-capable AVR as a USB debug interface
Note that the Debug Class Device must be able to handle high speed communication ("USB 2.0" is orthogonal to "high speed") and it must be able to handle some out-of-spec transfers. It's not at all certain that your controller does this.
As I am currently looking for suitable parts, I need to know some basic parameters of the SPI communication. Does anybody of you know what the typical clock rates between the chipset and the flash are?
Any SPI bus master works, the SPI flashes are generally modern enough to not have a problem with very slow clocks.
Since you seem interested in doing development for SPI flashing over USB, you may want to look at the preliminary USB protocol document that me and Stefan Tauner have been working on. Unfortunately it's been idle for a while, but it's nearly complete. The missing parts are the things that can vary between flash chips; erase command sequence and write command sequence. They need to be expressed in some nice way in the protocol. The intended development hardware is the Olimex LPC-P1343 board with an NXP LPC1343 Cortex-M3. Once software works, and once they become available, I want to put a LPC11U00 on a flexpcb cheap enough to be soldered permanently onto mainboards. (NXP promise <$1 for "quantity", probably 1k.)
//Peter
Peter Stuge wrote:
you may want to look at the preliminary USB protocol document that me and Stefan Tauner have been working on.
http://titanpad.com/x8M9ZvNeMN
//Peter
On 7/5/11 2:25 AM, Peter Stuge wrote:
Andreas Galauner wrote:
I had the idea of developing a small Board which contains a USB port and an SPI flash.
Sure. Or just follow Tom's tip and wire a second SPI bus master directly onto the mainboard.
Yep, I just found the pinheader. Seems to be 1.27x1.27mm. I also created a support ticket for the pinout on Sapphire's website. It would be nice if they give that to me, but I really doubt it. I'll try to measure the pinout tomorrow with a multimeter.
I first thought about emulating the SPI flash completely by an AVR,
What do you mean by AVR? It's relevant for much of what you write.
Oh, sorry. I mean those Atmel AVR microcontrollers. I have a few of them lying around here and wanted to give them some new lifes apart from laying in my part box.
SPI flash must respond with data immediately after the last address bit is received. It's really inconvenient to emulate this.
new approach is a SPI flash which resides on the AVR board
Sure. But simpler to just connect directly to the SPI on the mainboard.
If I want to test a new BIOS, the AVR puts the motherboard into reset, detaches the flash chip with a multiplexer from the motherboard, programs it, switches it back to the motherboard and let off the reset.
Make that:
Hold reset Program flash chip on mainboard Release reset
I'll try to figure out the pinout tomorow. And try to read the flash with flashrom and a bus pirate
As an added bonus, I'm thinking about using a USB 2.0 port of an USB-capable AVR as a USB debug interface
Note that the Debug Class Device must be able to handle high speed communication ("USB 2.0" is orthogonal to "high speed") and it must be able to handle some out-of-spec transfers. It's not at all certain that your controller does this.
Yes, I know. And I just saw that my microcontrollers only do full speed and the specification requires high speed. So, this isn't possible.
As I am currently looking for suitable parts, I need to know some basic parameters of the SPI communication. Does anybody of you know what the typical clock rates between the chipset and the flash are?
Any SPI bus master works, the SPI flashes are generally modern enough to not have a problem with very slow clocks.
Since you seem interested in doing development for SPI flashing over USB, you may want to look at the preliminary USB protocol document that me and Stefan Tauner have been working on. Unfortunately it's been idle for a while, but it's nearly complete. The missing parts are the things that can vary between flash chips; erase command sequence and write command sequence. They need to be expressed in some nice way in the protocol. The intended development hardware is the Olimex LPC-P1343 board with an NXP LPC1343 Cortex-M3. Once software works, and once they become available, I want to put a LPC11U00 on a flexpcb cheap enough to be soldered permanently onto mainboards. (NXP promise <$1 for "quantity", probably 1k.)
I haven't done very much with SPI flashes until now. I know how the physical protocol works and used it a few times in some smaller microcontroller projects, but I definetely would want to take a look at it.
And the development board is easily available and cheap in Germany. Cool.
Andreas
Andreas Galauner wrote:
Yep, I just found the pinheader. Seems to be 1.27x1.27mm. I also created a support ticket for the pinout on Sapphire's website. It would be nice if they give that to me, but I really doubt it.
Did you check that it's not documented in the manual already?
I'll try to measure the pinout tomorrow with a multimeter.
Sure, that will work fine. Each pin will be directly connected to a pin on the flash chip.
What do you mean by AVR? It's relevant for much of what you write.
Oh, sorry. I mean those Atmel AVR microcontrollers.
Yes Atmel, but "AVR" says nothing about which family of devices you mean. If it's the wee small 8-bit ones I wouldn't bother, on the other hand if you have a toolchain then sure, why not!
I haven't done very much with SPI flashes until now. I know how the physical protocol works and used it a few times in some smaller microcontroller projects, but I definetely would want to take a look at it.
It's fairly simple. Pick up a flash chip datasheet and you've actually already got mostly all you need to know. The flashrom source code can also help, but be careful to not get unneccessarily confused by the code to deal with different types of SPI bus masters in there.
And the development board is easily available and cheap in Germany.
Yup. What city are you in?
//Peter
On 7/5/11 3:02 AM, Peter Stuge wrote:
Andreas Galauner wrote:
Yep, I just found the pinheader. Seems to be 1.27x1.27mm. I also created a support ticket for the pinout on Sapphire's website. It would be nice if they give that to me, but I really doubt it.
Did you check that it's not documented in the manual already?
Yes. It's not in there. They labled the POST-Code display, they have huge tables of really cool POST code error message explanations and on one pciture of the POST display there even is a header on those SPI pins installed, but there is nothing about the pinout.
I'll try to measure the pinout tomorrow with a multimeter.
Sure, that will work fine. Each pin will be directly connected to a pin on the flash chip.
I'm just asking myself all the time what to do with the supply lines. If the board is without power or in standby, I obviously need to supply power (assuming that there is a VCC line on the header), but if it is on and I just pull the reset line before starting the programming, this sounds a bad idea to me. So the user needs to specify, if he wants to supply power or not, right?
What do you mean by AVR? It's relevant for much of what you write.
Oh, sorry. I mean those Atmel AVR microcontrollers.
Yes Atmel, but "AVR" says nothing about which family of devices you mean. If it's the wee small 8-bit ones I wouldn't bother, on the other hand if you have a toolchain then sure, why not!
I think I'll get one of those Olimex boards. I always wanted to do something with ARM CPUs and it makes porting the firmware to your suggested final device much easier. Nice idea, BTW.
I haven't done very much with SPI flashes until now. I know how the physical protocol works and used it a few times in some smaller microcontroller projects, but I definetely would want to take a look at it.
It's fairly simple. Pick up a flash chip datasheet and you've actually already got mostly all you need to know. The flashrom source code can also help, but be careful to not get unneccessarily confused by the code to deal with different types of SPI bus masters in there.
I just had a look at some datasheets.
And the development board is easily available and cheap in Germany.
Yup. What city are you in?
Aachen or Cologne. Choose one ;)
Andreas
Andreas Galauner wrote:
So, I had the idea of developing a small Board which contains a USB port and an SPI flash. I first thought about emulating the SPI flash completely by an AVR, but I think the clock rates of the SPI bus are too high to do this. My new approach is a SPI flash which resides on the AVR board which can be multiplexed between the AVR to program it and the motherboard. If I want to test a new BIOS, the AVR puts the motherboard into reset, detaches the flash chip with a multiplexer from the motherboard, programs it, switches it back to the motherboard and let off the reset.
Rapid BIOS development :)
Hello Andreas,
I agree with you that emulating a SPI ROM chip in software on AVR, or on any microcontroller, is near impossible because of the fast response times required. There is very little time between the last incoming address bit and the expected transmission of the data, if the SPI clock (generated by the mainboard) is in the order of 16...50 MHz.
Regarding your idea of multiplexing SPI ROM between mainboard and AVR, some of the work has already been done here:
http://www.coreboot.org/InSystemFlasher
Perhaps you could use it as a starting point?
Best Regards, Juhana Helovuo
-
Andreas Galauner -
Juhana Helovuo -
Peter Stuge -
Tom Sylla