[coreboot] Tester devices [was: QA contribution]

[Peter Stuge]

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