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.
Stefan Tauner 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?
The fundamental feature is that USB communication is highly structured on the very lowest level. It is a tremendous waste not to take full advantage of this property.
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.
That comparison isn't valid because USB does not always resemble UDP, only when using isochronouse transfers. Consider this:
Would you use telnet+Zmodem to transfer the file, or rather FTP?
(Remember that you are implementing both ends of the connection and disregard the complications in FTP caused by worldwide NAT.)
there are several drawbacks:
- we cant tunnel it as easily (e.g. over tcp like serprog)
Any protocol can be tunneled over any other protocol. In fact I think what I suggest would be even easier to network enable than serprog.
- everything gets way more complicated on the microcontroller
I don't know about *way* more, but yes, more complicated. The flip side is that the interface is tremendously more elegant, and easy to use. This is more important than saving a few hours of development IMNSHO.
i dont see a lot of performance improvements from it either.
Not about performance, about usability and elegance. Concepts not very common in software development worldwide. But in fact they may be the only worthy goals in software development. They also tend to go hand in hand.
maybe i am missing something though. please layout your basic ideas how an USB flashing protocol should look like,
I've tried to explain the general idea to several people but noone has really gotten what I mean, so to answer your question I have been thinking a bit more about the details of the protocol.
The design goal is to be able to cat a .rom file into a device node created by standard Linux kernel drivers, and have that .rom file written to a flash chip. In practise the goal is unreachable because the kernel doesn't expose endpoints as device nodes anymore, but we want to come as close to the goal as possible. Consider a usbcat program being used instead of regular cat.
The question is what other information the hardware must be given before it can accomplish this. This is the SPI flashing data model that I have been asking for several times.
1. Flash bus - SPI or LPC/FWH (only SPI first, but keep LPC in mind) 2. What SPI commands to use for identify, erase and program 3. Max SCK speed (4. How to do identify, erase and program on LPC)
I think flashrom already knows these things except maybe 3, the data is just not exported in any suitable way yet.
So far I can think of two ideas for how this data is sent to a microcontroller:
1. Oneshot transfer of a datastructure with some or all parameters, followed by one single transfer of the data to be programmed
2. An instruction set is created that gets executed by a simple state machine in the microcontroller, and instead of the parameterized data structure above, one microcode snippet would be sent for each operation identify/erase/program.
Of course it's also possible to do both of the above, and in fact they might complement each other. 1. assumes that we can design a very future proof data model for SPI programming, or the microcontroller firmware might have to be updated for a future SPI chip. While I think we could actually do this, it's still nice to have a completely generic interface such as 2. since then the user can always create the needed microcode snippets from a data sheet, without having to upgrade the firmware. (OTOH, the LPC1343 is extremely easy to reprogram, so this may be moot as long as microcontroller developers are eager and quick.)
I hope this is not too abstract for people to understand the idea?
To spell it out even more, in USB terms, there would be, at least:
* a control transfer to set the SPI clock speed * a control transfer to set the current address in memory * a control transfer to switch power supply to the flash chip * bulk out sends SPI bytes * bulk in reads SPI bytes
The above is the simplest interface, even simpler and more stupid than any of 1. and 2. I describe above. But it would be the minimum to start with, to guarantee a completely future proof hardware. It's also easy to implement.
The next step would be:
* a control transfer to set command(s) used for identify * a control transfer to set command(s) used for erase * a control transfer to set command(s) used for program
These command(s) are not just one byte, a "language" (data model 1., or microcode 2.) is needed to express the various sequences.
btw do we want to support non-spi flashes at all?
Yes, but one thing at a time. The microcontroller will not likely have LPC master hardware so it will have to be bit-banged, and will thus not be too fast. Good use of USB to speak SPI is more important.
i was also thinking about an offline mode which uses an SD-card
..
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.
Then the use of the SD card as media is significantly reduced, because a PC with a card reader can not use the default file transfer tools (Explorer, Finder, mount/mtools) to put an image to-be-flashed onto the card.
//Peter
hey!
peter and i have started to discuss and lay out the details of a native usb flashing protocol. the WIP document can be found at http://titanpad.com/x8M9ZvNeMN
we need to design abstract representations of a few things like erase blocks, instruction sequences for various operations etc. some of which are (probably) already implemented in flashrom in one form or another while others might be useful to have in there and have been discussed or at least thought through already by someone. so feel free to contribute please. ;)
-
Idwer Vollering -
Peter Stuge -
Schenk, John -
Stefan Tauner