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
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