Hello again, as you may have read yesterday, I'm currently trying to play with some in-system SPI flashing and I need some additional advice.
I just soldered a Pinheader to an Intel D525MW Motherboard (http://www.dont.ru/i/img_1orig/129310882576.jpg - lower right corner) I'm currently not using, but I'm not sure if I should really connect some hardware to it and pull/push on the SPI lines.
I suppose it's generally a bad idea to do this, when the Board is currently operating. If it is completely off, I can supply external power and just flash, right?
And what about the reset state? I don't have any schematics of my motherboards, so I don't know if there are pull-up or pull-down resistors, I don't know if the chipset really switches its SPI lines into a Z-state, if it is held in reset and so on. I don't want to let the magic smoke escape from my motherboard ;)
The only thing I found out is, that the HOLD# ("pauses" the flash chip) and WP# are connected to VCC over a 150 Ohm resistor, each. 150 Ohm is too low for a pull-up, so these two seem to be for limiting the current.
Also the pinout is kind of "weird": 1 #CS 2 #CS 3 SI 4 NC 5 SO 6 VCC 7 SCK 8 GND
Why is CS# connected to two pins? The resistance between those two pins is 1 Ohm, so they are connected directly. Interestingly the are connected through a 0 Ohm resistor. Any ideas on that?
Are there some kind of "best practices" the vendors have when designing those in-system-SPI-flashing-headers? I mean they have to flash these boards in some way by themselves without sending them to heaven, if there is an SPI header.
Any advice is greatly appreciated.
Thanks, Andreas
On 06/07/11 12:23, Andreas Galauner wrote:
Also the pinout is kind of "weird": 1 #CS 2 #CS 3 SI 4 NC 5 SO 6 VCC 7 SCK 8 GND
Why is CS# connected to two pins? The resistance between those two pins is 1 Ohm, so they are connected directly. Interestingly the are connected through a 0 Ohm resistor. Any ideas on that?
I don't know the answer, I'm just having a guess here. It could be that one of the #CS pins is connected to the flash chip, and the other is connected to the SPI controller (or whatever you call the thing an SPI flash chip is connected to on a computer motherboard). If that were the case then if the 0Ω link wasn't there you would be able to connect an SPI chip and a switch to that port. The switch would either short pins 1 and 2, to select the internal flash chip, or would connect whichever #CS pin is connected to the SPI controller to the #CS pin on the external SPI flash chip in order to select that chip instead.
Does that sound like a possibility?
Andrew Morgan wrote:
On 06/07/11 12:23, Andreas Galauner wrote:
Also the pinout is kind of "weird": 1 #CS 2 #CS 3 SI 4 NC 5 SO 6 VCC 7 SCK 8 GND
Why is CS# connected to two pins? The resistance between those two pins is 1 Ohm, so they are connected directly. Interestingly the are connected through a 0 Ohm resistor. Any ideas on that?
I don't know the answer, I'm just having a guess here. It could be that one of the #CS pins is connected to the flash chip, and the other is connected to the SPI controller (or whatever you call the thing an SPI flash chip is connected to on a computer motherboard). If that were the case then if the 0Ω link wasn't there you would be able to connect an SPI chip and a switch to that port. The switch would either short pins 1 and 2, to select the internal flash chip, or would connect whichever #CS pin is connected to the SPI controller to the #CS pin on the external SPI flash chip in order to select that chip instead.
Does that sound like a possibility?
Very likely. Also I would expect that #4 NC is not NC at all, it just does not go to the SPI device. It could very well be some way to allow safe programming of the onboard SPI device such as by putting the board into reset.
Andrew
On 7/7/11 11:35 AM, Andrew Goodbody wrote:
Also I would expect that #4 NC is not NC at all, it just does not go to the SPI device. It could very well be some way to allow safe programming of the onboard SPI device such as by putting the board into reset.
I doubt that. There is no Pin which could lead anywhere ;)
I looked into the NM10 datasheet, which at least indicates, that CS# is input and output. And it seems that the chipset detects if some other SPI master pulls CS# to low.
NM10 Express datasheet, page 58:
SPI Chip Select: This chip select signal is also used as the SPI bus request signal.
If that is the case, this pin is open-drain with an external pull-up. But I don't know what the board does, when it detects this condition. Perhaps it switches MISO, MOSI and SCK into a Z-State.
Also, there is the SPI_ARB pin on the chipset. According to the datasheet it is used for the "shared flash" feature. I couldn't find any information about "shared flash", but I think this pin is used by a jumper to start a recovery mode on the board to reflash the BIOS in case of a previous failure.
I connected my Bus Pirate yesterday, but I didn't get any data out of the flash. I'm just on a way to some place where I have an oscilloscope and logic analyzer to have some more fun :)
- Andreas
On Thu, Jul 7, 2011 at 6:54 AM, Andreas Galauner andreas@galauner.de wrote:
On 7/7/11 11:35 AM, Andrew Goodbody wrote:
Also I would expect that #4 NC is not NC at all, it just does not go to the SPI device. It could very well be some way to allow safe programming of the onboard SPI device such as by putting the board into reset.
I doubt that. There is no Pin which could lead anywhere ;)
I looked into the NM10 datasheet, which at least indicates, that CS# is input and output. And it seems that the chipset detects if some other SPI master pulls CS# to low.
NM10 Express datasheet, page 58:
SPI Chip Select: This chip select signal is also used as the SPI bus request signal.
If that is the case, this pin is open-drain with an external pull-up. But I don't know what the board does, when it detects this condition. Perhaps it switches MISO, MOSI and SCK into a Z-State.
On my NM10 board, I looked into in-system programming, but Carl-Daniel convinced me that there was too much that could go wrong. Instead, I have a small board I built that connects all the pins of 2 different flash chips to the board, except CS# is switched so that the active chip is hooked to CS# on the board, the inactive chip's CS# pin is hooked to VCC via a set of 4 opticouples and a DPDT switch (this was a suggestion from Carl-Daniel and Stepan). You could probably hook CS# with a diode to each chip, then just switch VCC, but I didn't want to fry anything I then have debian set up to boot only to single user mode, pull a flash image off the network, and flash the chip, and if the flash succeeds, shut down to test the data. Since I'm using two different model flash chips (I don't remember the model #s of the top of my head), the script uses flashrom -c [chipname], so if I don't flip the switch in time, it will fail and wait instead of overwriting the stock BIOS. It takes about a minute if I get the chip switched during powerup to do the complete cycle. I could probably shave more time off that with a customized kernel and startup scripts, but so far it's been acceptable enough that it hasn't been worth the trouble.
The next evolution of this will probably be hooking a USB hub, USB->parallel adapter (to do switching and check power light status), and USB->serial adapter up to my dd-wrt powered router, and having the entire process scripted, which would allow me to work entirely wirelessly or even remotely from my laptop. But, first I need to get the board back from Zotac's RMA department (unrelated issue, I've had problems with the memory slots ever since I got it, finally DIMM1 gave out entirely and DIMM2 is a pain to get to work).
I've also had some luck with SerialICE, you may want to consider it as an alternative. Once the board gets back, I need to figure out how to disasseble the stock BIOS to bypass the keyboard wait, then I might be able to get some info on memory init.
BTW, just curious, have you had any luck getting the datasheets from Intel that cover memory init? Or did you even bother trying?
HTH -Corey
On Wed, 06 Jul 2011 13:23:47 +0200 Andreas Galauner andreas@galauner.de wrote:
Hello again, as you may have read yesterday, I'm currently trying to play with some in-system SPI flashing and I need some additional advice.
hello andreas
you may wanna look at the flashrom wiki page about in-system programming: http://flashrom.org/ISP i wrote the most important stuff that i am aware of in there. if you (or anybody else without wiki access) think anything is missing, just drop me a mail. i should add the tip with standby mode probably. that one is new to me (although pretty obvious :) we are talking about S3 here i guess?
-
Andreas Galauner -
Andrew Goodbody -
Andrew Morgan -
Corey Osgood -
Stefan Tauner