Hi there!
I'm a QA guy interested in coreboot project. I have two mobos supported by coreboot; also I have some QA and dev skills (but mostly QA). I also have the ability to check the coreboot on some other mobos - I have them in my hands from time to time.
How is it possible for me to start contributing the project in such a role? Is there some guide, some list of open tasks, or list of fixes pending review?..
I've looked over the site but have not found clear answer to my question.
Thanks, -- Dan
* Danila Sukharev mambet@gmail.com [110130 06:00]:
Hi there!
I'm a QA guy interested in coreboot project. I have two mobos supported by coreboot; also I have some QA and dev skills (but mostly QA). I also have the ability to check the coreboot on some other mobos - I have them in my hands from time to time.
Awesome! Welcome!
How is it possible for me to start contributing the project in such a role? Is there some guide, some list of open tasks, or list of fixes pending review?..
You might be interested in checking out our testing efforts: http://www.coreboot.org/Distributed_and_Automated_Testsystem
Unfortunately no machines actually run tests these days.
Would love to hear your ideas on this.
Stefan
As I see these docs are quite outdated... (about five years old) Anyway I'll walk through them and try to understand where I'll be able to help you.
Another question -- what is the best way contacting the team with QA questions? Who is coordinator/PM?
-- Dan
You might be interested in checking out our testing efforts: http://www.coreboot.org/Distributed_and_Automated_Testsystem
Unfortunately no machines actually run tests these days.
Hi Danila,
I'd also like to say welcome, qa is definately something that coreboot can benefit from.
Danila Sukharev wrote:
As I see these docs are quite outdated... (about five years old)
Please do not assume outdated just because they are old. :) Some details are outdated, e.g. the BIOS savior is partially not available anymore, and partially it is not suitable for modern boards using SPI flash, but I think the general principle of the testing infrastructure is still sound.
Although it was developed several years I believe it can still serve us well going forward. The function of coreboot has not really changed, and probably will not change much, so the test tools might also not need to change much. Note that I'm not saying that change is resisted in any way here, quite the opposite, just looking back at the years I've been involved in the project.
Anyway I'll walk through them and try to understand where I'll be able to help you.
Great!
Personally I believe that development is what is missing to get corebot testing going to a greater extent. As you will see in the documentation there are fairly many requirements for an individual mainboard to actually be hooked up to the test system. It's fully automated once it runs, but it's too complicated to get there.
I think this needs to be optimized and to some degree productized, into an easy to buy and fairly affordable (<100$) unit that can administer testing of one or even better several mainboards. I have plenty of design and implementation ideas if you'd like to go into that.
Another question -- what is the best way contacting the team with QA questions?
Please always use the mailing list.
Who is coordinator/PM?
There's no manager. Contributors have equal possibilities to commit source code. In discussions it comes naturally that more senior and more active contributors in the project will have more insight to the project, but other than that it's very much a group effort..
If there is a good reason of course efforts could be segmented, but on the other hand contributors are a scarce resource which means that segmentation is better avoided.
//Peter
30.1.2011 13:16, Peter Stuge kirjoitti:
Personally I believe that development is what is missing to get corebot testing going to a greater extent. As you will see in the documentation there are fairly many requirements for an individual mainboard to actually be hooked up to the test system. It's fully automated once it runs, but it's too complicated to get there.
I think this needs to be optimized and to some degree productized, into an easy to buy and fairly affordable (<100$) unit that can administer testing of one or even better several mainboards. I have plenty of design and implementation ideas if you'd like to go into that.
Hello all,
I started building a tester device to hook up a mainboard into an automated test host.
The basic plan is as follows: The host computer is connected to tester device via USB. The tester is connected to the target mainboard so that it can take control of the BIOS ROM and reprogram it regardless of the state of the target mainbaord.
The tester device can also connect to the serial port of the target mainboard, so it can act as a serial-over-USB-device. This is because otherwise controlling the test of N mainboards would require N serial ports in the host.
The tester also has two FET switches for controlling the reset and ATX power buttons on the target mainboard.
The actual AC power control of the target mainboard is not included and should be done by another device, such as this: http://www.gembird.nl/default.aspx?op=products&op2=item&id=3234
So far there is support only for SPI ROMs, but the design could be modified to support LPC and FWH also.
The tester device is basically an Atmel Atmega microcontroller, which can talk USB, RS232, SPI, and generic digital I/O.
Here are some images of my first (incomplete) prototype:
http://alpskari.asiantuntijat.org/~juhe/spi-flasher-piirilevyt/
The images were originally taken just to illustrate the PCB making experiment via the toner transfer method, but you can also see what the device looks like. The smaller board is specific to SPI ROMs and attaches to the SPI ROM socket on the mainbaord. The larger PCB is a microcontroller, which connects all the parts together.
Both the software and hardware are incomplete. Hardware is missing some parts and work.
The software is not yet done, except a prototype microcontroller program that can read and program SPI ROMs. It is controlled by "flashrom" from Linux host. It can communicate via serial port using the "serial programmer" protocol. Flashrom program was modified by adding a "serprog-spi"-module, which is modified from "serprog", mainly by adapting it to suit SPI.
Best regards, Juhana Helovuo
On Tue, 01 Feb 2011 13:05:24 +0200, Juhana Helovuo juhe@iki.fi wrote:
30.1.2011 13:16, Peter Stuge kirjoitti:
Personally I believe that development is what is missing to get corebot testing going to a greater extent. As you will see in the documentation there are fairly many requirements for an individual mainboard to actually be hooked up to the test system. It's fully automated once it runs, but it's too complicated to get there.
I think this needs to be optimized and to some degree productized, into an easy to buy and fairly affordable (<100$) unit that can administer testing of one or even better several mainboards. I have plenty of design and implementation ideas if you'd like to go into that.
Hello all,
I started building a tester device to hook up a mainboard into an automated test host.
The basic plan is as follows: The host computer is connected to tester device via USB. The tester is connected to the target mainboard so that it can take control of the BIOS ROM and reprogram it regardless of the state of the target mainbaord.
The tester device can also connect to the serial port of the target mainboard, so it can act as a serial-over-USB-device. This is because otherwise controlling the test of N mainboards would require N serial ports in the host.
The tester also has two FET switches for controlling the reset and ATX power buttons on the target mainboard.
The actual AC power control of the target mainboard is not included and should be done by another device, such as this: http://www.gembird.nl/default.aspx?op=products&op2=item&id=3234
So far there is support only for SPI ROMs, but the design could be modified to support LPC and FWH also.
The tester device is basically an Atmel Atmega microcontroller, which can talk USB, RS232, SPI, and generic digital I/O.
Here are some images of my first (incomplete) prototype:
http://alpskari.asiantuntijat.org/~juhe/spi-flasher-piirilevyt/
The images were originally taken just to illustrate the PCB making experiment via the toner transfer method, but you can also see what the device looks like. The smaller board is specific to SPI ROMs and attaches to the SPI ROM socket on the mainbaord. The larger PCB is a microcontroller, which connects all the parts together.
Both the software and hardware are incomplete. Hardware is missing some parts and work.
The software is not yet done, except a prototype microcontroller program that can read and program SPI ROMs. It is controlled by "flashrom" from Linux host. It can communicate via serial port using the "serial programmer" protocol. Flashrom program was modified by adding a "serprog-spi"-module, which is modified from "serprog", mainly by adapting it to suit SPI.
Best regards, Juhana Helovuo
Wow! that is really cool! I hope it works out as planned :-)
Juhana Helovuo wrote:
unit that can administer testing of one or even better several mainboards. I have plenty of design and implementation ideas if you'd like to go into that.
I started building a tester device to hook up a mainboard into an automated test host.
Nice.
The basic plan is as follows: The host computer is connected to tester device via USB.
This certainly makes the device itself simpler. But it requires *another* system to be monitoring all these devices.. I can't seem to let go of the thought that I would prefer a tester device to be connected directly to the internet, and work autonomously. Ethernet is simple enough with something like an LM3S6965 ARM. WiFi would be a nice option, but will also increase the unit cost..
The tester is connected to the target mainboard so that it can take control of the BIOS ROM and reprogram it regardless of the state of the target mainbaord.
Yes. A flash emulator would of course be ideal, but also requires some programmable logic, ie. either one more component, or a larger component. In some cases board size is critical, e.g. to fit a tester inside a tight case.
The tester device can also connect to the serial port of the target mainboard, so it can act as a serial-over-USB-device.
Right. Either the tester just has a UART, or if it is networked then it will itself do the checkpointing. As for the USB device, it's fairly important to use a generic USB hardware. The ATmega U chips would work fine I believe. The key is to have multiple interfaces, ie. at least one bulk IN endpoint for the serial port, and one bulk OUT endpoint for downloading flash data, but it might be a good idea to make both of them bidirectional, which then needs four bulk endpoints. And it's important to be able to provide custom descriptors, which the ATmega U and many other micros with USB allows.
The tester also has two FET switches for controlling the reset and ATX power buttons on the target mainboard.
Yep. I've also been thinking that the power good signal could be used. One problem with FETs is that they must be plugged in to the mainboard the right way. It would be significantly simpler to use the device if it had a solid state switch instead, but that's also more expensive.
The actual AC power control of the target mainboard is not included and should be done by another device, such as this: 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?
Here are some images of my first (incomplete) prototype:
http://alpskari.asiantuntijat.org/~juhe/spi-flasher-piirilevyt/
Looks like a great start!
The software is not yet done, except a prototype microcontroller program that can read and program SPI ROMs. It is controlled by "flashrom" from Linux host. It can communicate via serial port using the "serial programmer" protocol.
With USB connectivity I think it is important to really take advantage of the simplicity and efficiency of USB, rather than emulating a serial port on top of it. Also, having a serial port over USB both for target connectivity, *and* for flash programming, is IMO unneccssarily confusing. For the flashing we will simply implement the serprog protocol properly using native USB concepts. It should be very easy.
Flashrom program was modified by adding a "serprog-spi"-module, which is modified from "serprog", mainly by adapting it to suit SPI.
Hm, ok. Yeah maybe some hacking will be needed in flashrom. I've tried to get a design discussion going with Carl-Daniel for a data model that can describe any SPI programming algorithm, but he's very busy. I believe that data model is really what is needed to make the programming really fast. But of course, serprog works right now!
You're doing really nice work! :)
//Peter
1.2.2011 14:58, Peter Stuge kirjoitti:
Juhana Helovuo wrote:
unit that can administer testing of one or even better several mainboards. I have plenty of design and implementation ideas if you'd like to go into that.
I started building a tester device to hook up a mainboard into an automated test host.
Nice.
Thanks for your supportive comments. I think I was a bit unclear on some points, so you misunderstood some details.
The basic plan is as follows: The host computer is connected to tester device via USB.
This certainly makes the device itself simpler. But it requires *another* system to be monitoring all these devices.. I can't seem to let go of the thought that I would prefer a tester device to be connected directly to the internet, and work autonomously. Ethernet is simple enough with something like an LM3S6965 ARM. WiFi would be a nice option, but will also increase the unit cost..
That would be another design strategy. 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.
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.
Also the tester device firmware will be simpler this way. I discovered that flashrom utility alone is quite a complicated piece.
The tester is connected to the target mainboard so that it can take control of the BIOS ROM and reprogram it regardless of the state of the target mainbaord.
Yes. A flash emulator would of course be ideal, but also requires some programmable logic, ie. either one more component, or a larger component. In some cases board size is critical, e.g. to fit a tester inside a tight case.
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. 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.
The tester device can also connect to the serial port of the target mainboard, so it can act as a serial-over-USB-device.
Right. Either the tester just has a UART, or if it is networked then it will itself do the checkpointing. As for the USB device, it's fairly important to use a generic USB hardware. The ATmega U chips
I am currently working with AT90USB162. The choice was also influenced by easy availability and ease of soldering.
The tester also has two FET switches for controlling the reset and ATX power buttons on the target mainboard.
Yep. I've also been thinking that the power good signal could be used. One problem with FETs is that they must be plugged in to the mainboard the right way. It would be significantly simpler to use the device if it had a solid state switch instead, but that's also more expensive.
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).
The actual AC power control of the target mainboard is not included and should be done by another device, such as this: 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.
With USB connectivity I think it is important to really take advantage of the simplicity and efficiency of USB, rather than emulating a serial port on top of it. Also, having a serial port over USB both for target connectivity, *and* for flash programming, is IMO unneccssarily confusing. For the flashing 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.
I used serial port only for testing that I can actually talk to the SPI ROM from the microcontroller. The test setup was based on Arduino Uno, which can do only serial-over-USB.
Best regards, Juhana Helovuo
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
[ Note: There seems to be something wrong with mailing list delivery. I did not receive this Peter's latest message at all, but found it in the mailing list archive instead. Other coreboot lists messages have arrived to my inbox after that. ]
Peter Stuge wrote:
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.
True, and additionally the controller between SPI and SRAM has to be able to react very quickly, which would mean using an FPGA or similar.
A microcontroller would have to have quite a high frequency to be able to react to a command within 1 cycle, even at 16 MHz.
All right. With QFP on the table there's suddenly a whole lot more possibilities for the design.
Actully I was surprised myself how good the result with QFP-32 package was. However, that is already quite near the limit of my current skills and tools.
OK, so.. Do you like svn or git? Let's set up a repository or two for this work.
Good idea! I suppose git would do better for this job, since I expect that the development is quite decentralized. Right now I have only the prototype board schematics and layout, but I suppose that is already better than nothing. Do have a good home for a git repository available?
Best regards, Juhana Helovuo
Peter Stuge wrote:
Juhana Helovuo wrote:
Here are some images of my first (incomplete) prototype:
http://alpskari.asiantuntijat.org/~juhe/spi-flasher-piirilevyt/
Looks like a great start!
Now there is more progress. After some building, coding, and debugging I have the tester sort-of-working.
The first version of the hardware works.
In this image you can see the tester plugged into an Asus mainboard:
http://alpskari.asiantuntijat.org/~juhe/in-system-flasher/DSC08430.jpg
Today I successfully used this setup to reflash the mainboard from the host PC via flashrom.
The USB cable goes to a host computer, which is running a modified flashrom program. The flashrom is extended with a serprog_spi module, which can transfer SPI over the serprog protocol, and additionally toggle SPI bus multiplexer between the MCU and mainboard at the beginning and end of programming.
Target reset switch is still operated manually, but there is hardware support for operating also that from the tester board. Reset pins on the mainboard need to be connected to pin header in the corner of the bigger PCB, and flashrom needs to be extended to send also the reset command to the tester. The ATX power button can be operated in the same fashion.
The tester hardware has the following features:
* Single USB connection to host PC, tester is USB powered. * RS-232 serial port to collect boot log from the target mainboard. Tested to work at 115200 bps. * Two software-controllable switches for controlling mainboard pushbutton inputs. Button-sensing voltage on mainboard need not be the same as Vcc on tester. * Small PCB mounted to mainboard can be powered by tester PCB or mainboard. * Mainboard can operate normally even when tester has no power. * Tester can access the ROM also when disconnected from the target mainboard. * Two software-controllable LEDs to impress people.
The work is still quite incomplete:
* The first PCB had two layout errors (corrected by jumper wires), so it needs some rework.
* Some host-side software is missing. Flashrom extension or a separate program is needed to control the pushbutton inputs.
* The PCB could be extended to include a software-controlled isolated switch to control a relay, which can switch mains power of the target mainboard on or off. I am still uncertain whether I want to have self-hacked devices with 230 VAC parts in my house.
* Currently there is no tester firmware that could operate both the SPI and RS-232. The main problem is that the AT90USB162 microcontroller supports only up to five USB endpoints (including default control EP). I do not know if it is possible to implement two USB CDC class virtual serial ports with less than seven EPs. With two serial ports, one could represent the RS-232 interface, and other be used to control the programmer without writing any custom USB drivers.
This could be solved either in software by writing a custom USB driver for both the tester and the host, or in hardware by replacing the microcontroller with a more capable model. If anyone on the list can suggest any easier solutions, I'd be glad to hear about them.
* The handling of SPI ROM is horribly slow. Programming and verifying 1 MByte ROM takes about half an hour. The main suspect is nonexistent USB data buffering in the tester firmware.
Best regards, Juhana Helovuo
Hi,
Juhana Helovuo wrote:
Now there is more progress. After some building, coding, and debugging I have the tester sort-of-working.
Cool.
In this image you can see the tester plugged into an Asus mainboard:
http://alpskari.asiantuntijat.org/~juhe/in-system-flasher/DSC08430.jpg
Sadly this URL does not work for me. :\
The work is still quite incomplete:
- The first PCB had two layout errors (corrected by jumper wires),
so it needs some rework.
All right.
- Some host-side software is missing. Flashrom extension or a
separate program is needed to control the pushbutton inputs.
This has nothing to do with flashrom, and should certainly be a separate program.
- The PCB could be extended to include a software-controlled isolated
switch to control a relay, which can switch mains power of the target mainboard on or off. I am still uncertain whether I want to have self-hacked devices with 230 VAC parts in my house.
Well yes and no. It's not something we want to promote, but switching AC is of course the ideal power cycle.
- Currently there is no tester firmware that could operate both the
SPI and RS-232. The main problem is that the AT90USB162 microcontroller supports only up to five USB endpoints
Sorry, but the problem is how the USB firmware has been implemented.
I do not know if it is possible to implement two USB CDC class virtual serial ports with less than seven EPs. With two serial ports, one could represent the RS-232 interface, and other be used to control the programmer without writing any custom USB drivers.
I thought we agreed that in particular the flash programming must be implemented with a custom protocol directly on top of USB, rather than something on top of a serial port emulation on top of USB.
And as far as the serial port goes.. We can and should just make the coreboot tester software support the tester hardware directly. This means using a custom protocol directly on top of USB also for the serial console.
Abusing USB to emulate a UART is always a bad idea. Sometimes the only way, but not the case here. We can do much better.
This could be solved either in software by writing a custom USB driver for both the tester and the host, or in hardware by replacing the microcontroller with a more capable model. If anyone on the list can suggest any easier solutions, I'd be glad to hear about them.
I think it's a good idea to support more than a single microcontroller, but I also think the AT90USB is capable enough to do this task pretty well.
Per-interface classes, vendor specific on each interface, I'd need to look into the serprog protocol to suggest the first interface, but the second would just need one bulk IN endpoint for the serial input stream from mainboard UART.
Should not be more than five endpoints including 0 IN and OUT.
- The handling of SPI ROM is horribly slow. Programming and
verifying 1 MByte ROM takes about half an hour. The main suspect is nonexistent USB data buffering in the tester firmware.
No need to suspect. The serprog protocol is simply too stupid for SPI. I have brought up the need for a data model that can describe SPI flash programming on numerous occasions; this is one application where it is absolutely neccessary. The SPI extension I created for the Artec FlexyICE is another. flashrom currently has a good grasp on how to program SPI flash, but that needs to be abstracted into data, so that flashrom can send a "task" to a flashing device, rather than being in the all-wrong business of fiddling with bits over serprog.
Ideally data can be buffered as well. How much RAM is available in the AT90USB you are using?
//Peter
Hi Juhana,
I've added the flashrom mailing list to CC.
Auf 12.02.2011 19:55, Juhana Helovuo schrieb:
Now there is more progress. After some building, coding, and debugging I have the tester sort-of-working.
The first version of the hardware works.
In this image you can see the tester plugged into an Asus mainboard:
http://alpskari.asiantuntijat.org/~juhe/in-system-flasher/DSC08430.jpg
Today I successfully used this setup to reflash the mainboard from the host PC via flashrom.
The USB cable goes to a host computer, which is running a modified flashrom program. The flashrom is extended with a serprog_spi module, which can transfer SPI over the serprog protocol, and additionally toggle SPI bus multiplexer between the MCU and mainboard at the beginning and end of programming.
The tester hardware has the following features:
- Tester can access the ROM also when disconnected from the target
mainboard.
The work is still quite incomplete:
- Currently there is no tester firmware that could operate both the
SPI and RS-232. The main problem is that the AT90USB162 microcontroller supports only up to five USB endpoints (including default control EP). I do not know if it is possible to implement two USB CDC class virtual serial ports with less than seven EPs. With two serial ports, one could represent the RS-232 interface, and other be used to control the programmer without writing any custom USB drivers.
This could be solved either in software by writing a custom USB driver for both the tester and the host, or in hardware by replacing the microcontroller with a more capable model. If anyone on the list can suggest any easier solutions, I'd be glad to hear about them.
- The handling of SPI ROM is horribly slow. Programming and verifying
1 MByte ROM takes about half an hour. The main suspect is nonexistent USB data buffering in the tester firmware.
There are a few tricks we could use to speed up SPI programming with your hardware. flashrom already supports the Dediprog SF100 USB-based SPI programmer, and that works well. Maybe we could use a similar communication protocol, and/or use a serprog-like protocol directly on top of libusb without the need of serial port emulation. The serial port emulation is probably the biggest reason why anything is slow.
If you tell me about the design constraints of your device, I can probably come up with a flashrom driver which can reflash an 1 MByte ROM in ~5 minutes or so. That will require some cooperation from your device, but should be doable with ~270 bytes of RAM. Even with ~140 bytes of RAM we should be able to get some decent performance. As long as we can optimize the protocol, it should be possible to get acceptable performance even with only 50 bytes of RAM, but generally more RAM will give you better performance.
Side note: I think there once was a SPI-serprog design on the flashrom mailing list, but I can't find it right now.
Regards, Carl-Daniel
Hi Peter,
Peter Stuge wrote:
In this image you can see the tester plugged into an Asus mainboard:
http://alpskari.asiantuntijat.org/~juhe/in-system-flasher/DSC08430.jpg
Sadly this URL does not work for me. :\
We have been suffering from a server crash, because of a power failure in our ISP's machine room. This particular server did not start after power was restored. It has also hampered my email access.
Now that server is back online and works at least for me.
I do not know if it is possible to implement two USB CDC class virtual serial ports with less than seven EPs. With two serial ports, one could represent the RS-232 interface, and other be used to control the programmer without writing any custom USB drivers.
I thought we agreed that in particular the flash programming must be implemented with a custom protocol directly on top of USB, rather than something on top of a serial port emulation on top of USB.
You are right, serial port on top of USB is not a good final design.
I wrote the first version with serial port emulation, because that was the quickest way to see that all the hardware parts work, and the whole concept is usable at all.
Now that I have seen the hardware working, it is a good time to design a better protocol on top of USB.
Ideally data can be buffered as well. How much RAM is available in the AT90USB you are using?
There is 512 bytes RAM available. Additionally, there is 176 bytes USB packet buffer RAM in the USB controller.
Best regards, Juhana Helovuo
Carl-Daniel Hailfinger wrote:
If you tell me about the design constraints of your device, I can probably come up with a flashrom driver which can reflash an 1 MByte ROM in ~5 minutes or so. That will require some cooperation from your device, but should be doable with ~270 bytes of RAM. Even with ~140 bytes of RAM we should be able to get some decent performance. As long as we can optimize the protocol, it should be possible to get acceptable performance even with only 50 bytes of RAM, but generally more RAM will give you better performance.
The tester device is basically an Atmel AT90USB162, which has USB and SPI ports. Data sheet and a detailed manual are available on Atmel web pages. The USB is connected to the Linux host. SPI and some I/O pins are used to control a multiplexer and an SPI flash chip.
The microcontroller can be programmed in C with gcc, and I am using the open-source LUFA library for USB drivers on the device side.
The microcontroller has 16 Kbytes Flash ROM, 512 bytes SRAM, and a separate 176 byte buffer RAM in the USB controller. The CPU runs at 16 MHz. I have so far used the SPI bus at 1 MHz.
The USB controller supports up to 5 endpoints, including default control endpoint. Maximum packet size is 64 bytes. Two of the endpoints can be double buffered in hardware.
Is this enough details, or do you need something else?
Best regards, Juhana Helovuo
-
Carl-Daniel Hailfinger -
Danila Sukharev -
Joseph Smith -
Juhana Helovuo -
Peter Stuge -
Stefan Reinauer