hey there! (cross-posted to both mailing lists)
i am currently designing a small and cheap platform to recover from coreboot and other failures easily. the reason i am writing this is to get feedback from you regarding desired features of and interest in such a device.
right now my plan is the following: an avr atmegaXXu2 is connected via usb and implements the serprog protocol to let flashrom make use of it. the avr can operate down to 3.0V which would allow easy interfacing with today's spi flashes without any level shifting. to get the desired supply voltage from usb's 5V i will use a fixed 3.3V ldo voltage regulator (ld1117). apart from a few supporting parts (caps, fuse, usb line termination etc.) the only things missing are sockets for the spi chips.
at the moment i am planing to include: - soic8 pads (combined for 150 and 200mil devices) and enough room for a soic8 zif adapter (like the one from http://bios-repair.co.uk)
- vias for a 24 pin zif dip/dil socket (150 and 300mil spacing combined): 8 pins for dip8 flashes and 16 for soic16 flashes (those would require a soic to dip adapter). 8pin and 16pin flashes dont share pins therefore the large socket...
- vias for a single row 8pin header to allow attaching probes/test clips (e.g. http://www.pomonaelectronics.com/images/large/6109.jpg) to hook up in-situ flashes.
parts for this excluding the pcb would be in the 10-25$ range. depending on how many pcbs i/we would produce the whole thing would cost probably about 40$. not THAT cheap, but quite better than the dediprog stuff :) it would also be more convenient and open than the FT2232SPI based on the DLP-USB1232H (http://flashrom.org/FT2232SPI_Programmer). the willem programmers seem to be lpt only? are there any other cheap flashers i dont know?
i am not sure about what to do with soic16 chips. the solution laid out above which requires an additional adapter and wastes a lot of space is awkward. should i just include soic16 pads instead? should i drop support for them altogether and let the user hook them up with clips? are they in use anywhere? my intel desktop board has pads for it, but i am not sure if there are any boards in the wild which really use them...
i was also thinking about an offline mode which uses an SD-card or another flash to store/load an image for the target flash. push buttons would activate a cloning operation. this way one could clone chips easily without a pc, but i am not sure at all if thats worth it.
what do you think?
Stefan Tauner wrote:
i am currently designing a small and cheap platform to recover from coreboot and other failures easily.
Yay more flashers.
right now my plan is the following: an avr atmegaXXu2 is connected via usb and implements the serprog protocol
Please do not! Make good use of USB and design a protocol that actually takes advantage of relevant USB features, instead of pretending that USB is a serial port, which is really lame.
At a very minimum translate the serprog protocol to native USB.
USB is a packet bus. Making it behave like a dumb stream of bytes is almost never a good idea.
Also, make a simple HAL for the AVR, so that your C firmware can be re-used with other processors. I'll make it run on LPC1342/43.
easy interfacing with today's spi flashes
SPI access should also be part of the HAL of course.
without any level shifting.
Yes, is a good feature.
fixed 3.3V ldo voltage regulator (ld1117).
LD? LM? Anyway, that's an 800mA regulator, quite overkill for this application where not even 100mA is required. A smaller one should be cheaper.
- vias for a single row 8pin header to allow attaching probes/test clips (e.g. http://www.pomonaelectronics.com/images/large/6109.jpg) to hook up in-situ flashes.
May want to consider how the test clip is connected to board. The cables on my clips go to a DIP-style connector that plugs into an 8-pin socket.
parts for this excluding the pcb would be in the 10-25$ range. depending on how many pcbs i/we would produce the whole thing would cost probably about 40$. not THAT cheap, but quite better than the dediprog stuff :)
That LPC1343 I mentioned is available on a board from Olimex which is ready made, easy to order at least in Europe, has SPI and power supply on a convenient box header (UEXT) and a small experiment area.
http://olimex.com/dev/lpc-p1343.html
It's 13 EUR + shipping and VAT.
it would also be more convenient and open than the FT2232SPI
Did I mention how I really think USB serial chips are stupid, and FTDI in particular because they have ridiculous prices.
i am not sure about what to do with soic16 chips.
I also don't think they are very common.
drop support for them altogether and let the user hook them up with clips?
Certainly an option.
i was also thinking about an offline mode which uses an SD-card or another flash to store/load an image for the target flash.
SD is not worth the effort. SD cards are very incompatible and it takes a lot of work to implement a well-functioning card reader. And the filesystems are buggy as well.
A second flash chip could be handy for offline mode - but what is supplying the power?
//Peter
Could anyone help in identifying the Phoenix BIOS Chip on the motherboard?
The objective is to replace and possibly experiment with Coreboot and Flashrom
Gateway Nx860X Laptop Motherboard DA0PA6MB6E0 HannStar J MV-4 94V-0 0630
There are pictures and I could collect more if needed.
John
2011/4/22 Schenk, John joschenk@uncc.edu:
Could anyone help in identifying the Phoenix BIOS Chip on the motherboard?
It looks like the chip is just below the lower right corner of the cardbus frame: http://www.techex.biz/ebaybiz/pics/Motherboards/MBD-00544_02.jpg
The objective is to replace and possibly experiment with Coreboot and Flashrom
Gateway Nx860X Laptop Motherboard DA0PA6MB6E0 HannStar J MV-4 94V-0 0630
There are pictures and I could collect more if needed.
John
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
Thank you,
This evening I will attempt to verify the 8 pin device noted, below the lower right corner of the cardbus and below the TI PCI7412 Chip lower left. I will reply to all with the BIOS chip info details later on.
John
-----Original Message----- From: Idwer Vollering [mailto:vidwer@gmail.com] Sent: Fri 4/22/2011 3:38 PM To: Schenk, John Cc: Peter Stuge; Stefan Tauner; flashrom; coreboot@coreboot.org Subject: Re: [flashrom] Failed Flash Dead Board
2011/4/22 Schenk, John joschenk@uncc.edu:
Could anyone help in identifying the Phoenix BIOS Chip on the motherboard?
It looks like the chip is just below the lower right corner of the cardbus frame: http://www.techex.biz/ebaybiz/pics/Motherboards/MBD-00544_02.jpg
The objective is to replace and possibly experiment with Coreboot and Flashrom
Gateway Nx860X Laptop Motherboard DA0PA6MB6E0 HannStar J MV-4 94V-0 0630
There are pictures and I could collect more if needed.
John
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
Hi John,
Schenk, John wrote:
This evening I will attempt to verify the 8 pin device noted, below the lower right corner of the cardbus and below the TI PCI7412 Chip lower left.
Good luck. It should be ok.
I will reply to all with the BIOS chip info details later on.
As far as coreboot goes the chip not so relevant. flashrom could possibly benefit from testing erase and write of the chip, or from you gathering more information and doing testing and development to access the flash chip via the embedded controller which is probably along the path between CPU and flash chip.
A note also to you and to everyone reading the lists who may not know already; please do not ever use reply in your email program when you are sending a message on a new topic to a mailing list.
Even if you write a good new subject line, all email programs will still include references to the email that you replied to in the headers of the message that you send, which creates confusion and disorder where these headers are relied upon for displaying emails grouped by thread; ie. discussion topic, as is the case in numerous email programs, and web-based mailing list archives.
Thanks!
//Peter
On Fri, 22 Apr 2011 05:08:32 +0200 Peter Stuge peter@stuge.se wrote:
right now my plan is the following: an avr atmegaXXu2 is connected via usb and implements the serprog protocol
Please do not! Make good use of USB and design a protocol that actually takes advantage of relevant USB features, instead of pretending that USB is a serial port, which is really lame.
what features do you think _are_ relevant? sure serprog is pretty stupid, but that has nothing to do with its serial property. :)
At a very minimum translate the serprog protocol to native USB.
USB is a packet bus. Making it behave like a dumb stream of bytes is almost never a good idea.
if i had to transfer the content of a file i would choose tcp instead of udp. this is quite similar imho. of course factoring out the control messages is useful, but there are several drawbacks: - we cant tunnel it as easily (e.g. over tcp like serprog) - everything gets way more complicated on the microcontroller
i dont see a lot of performance improvements from it either. dropping cdc and just stream our own protocol via usb's bulk endpoints would be fine with me. i have already done this once. maybe i am missing something though. please layout your basic ideas how an USB flashing protocol should look like, what it could do (what serprog or something similar could not (as easily)).
btw do we want to support non-spi flashes at all?
Also, make a simple HAL for the AVR, so that your C firmware can be re-used with other processors. I'll make it run on LPC1342/43.
sure. spi reads, writes and cs(/hold?/wp?) will be independent. atm i am extending serprog and character reads and writes from the serial stream are basically independent. i do use avr-specific printfs though (those fetch the strings from flash memory instead of ram... harvard architecture, which is not abstracted), but that can be dealt with if need be.
without any level shifting.
Yes, is a good feature.
it costs performance in the case of the avr though... about 8MHz maximum clock instead of 16 with vcc>=4.5V.
i was also thinking about an offline mode which uses an SD-card or another flash to store/load an image for the target flash.
SD is not worth the effort. SD cards are very incompatible and it takes a lot of work to implement a well-functioning card reader.
thats true, i have tried ;)
And the filesystems are buggy as well.
we would not need one... wear leveling is done by the card and we only need a continuous block.
A second flash chip could be handy for offline mode - but what is supplying the power?
a usb power supply for example :) adding another connector for other power supplies wouldnt be a problem either.
BUT.. since there is not really interest in _my_ new flasher anyway and everyone seem to have built his own, i think we should just concentrate on the usb protocol.
-
Idwer Vollering -
Peter Stuge -
Schenk, John -
Stefan Tauner