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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
