Juhana Helovuo wrote:
Thanks for your supportive comments. I think I was a bit unclear on some points, so you misunderstood some details.
I just have a few different design ideas. :)
I can't seem to let go of the thought that I would prefer a tester device to be connected directly to the internet
That would be another design strategy.
Yes certainly.
However, I wanted to make the tester device to be just a simple interface between USB and the target mainboard. That makes it easier to design and fabricate with hobbyist methods and budget.
Yes indeed! I think both approaches are equally useful. Some will prefer to buy a device, and some, who have the ability, may prefer to build their own.
A design constraint for me is e.g. using only components that I can solder into a self-designed, self-made PCB. Using small pitch SMD devices or a components requiring reflow soldering seems a bit too much right now.
I understand. One thing that makes this design constraint a bit tricky is that everyone has different equipment and ability here, but I agree that no smaller than SO components would make the build very accessible.
Also the tester device firmware will be simpler this way.
Even if the device is doing a bit more the task is pretty simple, so firmware would in any case be manageable I think.
I discovered that flashrom utility alone is quite a complicated piece.
Ok. I haven't followed it for a good while.
Flash emulator would be nice, but emulating a SPI flash ROM would require single clock cycle response times for ordinary read commands. There is very little time for the ROM from receiving the last address bit to start transmitting the data.
Yep, an emulator should be SRAM backed.
I do not have a document at hand, but I recall that for the AMD SB7x0 this should be done at 16...33 MHz clock rate. Some SPI controllers could do it even faster, since many ROM chips are rated to operate up to 60 MHz or more.
I think in practise not much more than 16MHz is used, even though some chips go up to 75 or 90.
ATmega U chips
I am currently working with AT90USB162.
All right. With QFP on the table there's suddenly a whole lot more possibilities for the design.
The choice was also influenced by easy availability and ease of soldering.
Right. I've understood that Atmel are having some difficulties shipping the U series.
One problem with FETs is that they must be plugged in to the mainboard the right way.
..
significantly simpler to use .. if it had a solid state switch instead,
The FET switch device I am using is this: http://focus.ti.com/docs/prod/folders/print/sn74cbt3306.html
I believe it should work with the terminals plugged either way around. It should also work regardless of the voltage used in the mainboard switch sensing pins. E.g. in my test mainbaord the reset and atx power switch pins have different operating voltages (5V and 3.3V).
A switch like that should indeed work perfectly, and the price is right. Sorry, I was thinking of a discrete FET.
http://www.gembird.nl/default.aspx?op=products&op2=item&id=3234
Do you know where these units can be purchased, with the various voltage ratings and power plugs that are needed around the world?
I haven't tried internationally. In Finland, Jimm's PC claims to have them in stock a total of 4 pcs.
http://www.jimms.fi/tuote/SIS-PMS
No idea about different plug types, but I believe this one would work at least in Finland, Sweden, and Germany.
Since coreboot is very much an international project I think we'll have to spend some effort on supporting various types of these power switches.
we will simply implement the serprog protocol properly using native USB concepts. It should be very easy.
Yes, communication from flashrom program to SPI ROM should go over native USB, no serial emulation needed.
Let's look at designing that protocol. Are you on IRC?
I used serial port only for testing that I can actually talk to the SPI ROM from the microcontroller.
Yup.
The test setup was based on Arduino Uno, which can do only serial-over-USB.
Actually the Uno has an ATmega U for the USB interface, with firmware released, specifically so that it can be reprogrammed with different descriptors and make better use of USB. It requires a standalone AVR programmer though, and is beyond the level of many Arduino users, so it hasn't really taken off..
OK, so.. Do you like svn or git? Let's set up a repository or two for this work.
//Peter