Hi,
The following patch adds support for the FT2232D based Olimex ARM-USB-TINY JTAG programmer [1].
I have successfully tested it against an ASUS motherboard, with a Winbond W25x80 (1MB) BIOS, and everything seemed to work as expected. Yet another great way for flashrom to shine in BIOS recovery!
The patch should be very straightforward, though it is possible you may want to use something else than "usbtiny" for the new type (flashrom -p ft2232_spi:type=usbtiny) in case you find it not explicit enough.
Please note that the External_flashers/programmers section of the Supported_hardware wiki [2] should probably also be updated to only mention FT2232/FT4232 (without the H), as we now have evidence that FT2232D/FT2232L are working just as well for SPI access.
Finally, since external users cannot edit the wiki, I am also attaching a proposed update for the FT2232SPI_Programmer wiki page [3], to go with the patch. A preview of what this edit should look like can be found here [4]. I also fixed a few other minor items on the page, such as the "still pending review" Amontec JTAGkey2 section.
Regards,
/Pete
[1] http://www.olimex.com/dev/arm-usb-tiny.html [2] http://www.flashrom.org/Supported_hardware#External_flashers.2Fprogrammers [3] http://www.flashrom.org/FT2232SPI_Programmer [4] https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_...
2011/6/2 Pete Batard pbatard@gmail.com:
Hi,
Hi,
The following patch adds support for the FT2232D based Olimex ARM-USB-TINY JTAG programmer [1].
I have successfully tested it against an ASUS motherboard, with a Winbond W25x80 (1MB) BIOS, and everything seemed to work as expected. Yet another great way for flashrom to shine in BIOS recovery!
The patch should be very straightforward, though it is possible you may want to use something else than "usbtiny" for the new type (flashrom -p ft2232_spi:type=usbtiny) in case you find it not explicit enough.
Can you re-send your patch with a sign-off? http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
Please note that the External_flashers/programmers section of the Supported_hardware wiki [2] should probably also be updated to only mention FT2232/FT4232 (without the H), as we now have evidence that FT2232D/FT2232L are working just as well for SPI access.
Finally, since external users cannot edit the wiki, I am also attaching a proposed update for the FT2232SPI_Programmer wiki page [3], to go with the patch. A preview of what this edit should look like can be found here [4]. I also fixed a few other minor items on the page, such as the "still pending review" Amontec JTAGkey2 section.
Regards,
/Pete
[1] http://www.olimex.com/dev/arm-usb-tiny.html [2] http://www.flashrom.org/Supported_hardware#External_flashers.2Fprogrammers [3] http://www.flashrom.org/FT2232SPI_Programmer [4] https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_...
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
On 2011.06.02 12:27, Idwer Vollering wrote:
Can you re-send your patch with a sign-off? http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
My bad. Here you go:
The following patch adds support for the FT2232D based Olimex ARM-USB-TINY JTAG programmer [1].
Signed-off-by: Pete Batard <pbatard at gmail.com>
Regards,
/Pete
On Thu, 02 Jun 2011 02:32:00 +0100 Pete Batard pbatard@gmail.com wrote:
The following patch adds support for the FT2232D based Olimex ARM-USB-TINY JTAG programmer [1].
I have successfully tested it against an ASUS motherboard, with a Winbond W25x80 (1MB) BIOS, and everything seemed to work as expected. Yet another great way for flashrom to shine in BIOS recovery!
The patch should be very straightforward, though it is possible you may want to use something else than "usbtiny" for the new type (flashrom -p ft2232_spi:type=usbtiny) in case you find it not explicit enough.
i think armusbtiny or arm-usb-tiny would be better. is the name without dashes used anywhere in the docs, software etc. supplied by olimex? if so please resend the patch with "armusbtiny", else its probably better to use the original name the vendor chose(?) as you know there is also a -h version available from olimex. you dont happen to know the ids i guess? :) also if it's not too much of a hassle, please also post a verbose log showing the device in action. apart from the parameter name it looks ok and ill commit it after the name change, thanks a lot for your work!
Please note that the External_flashers/programmers section of the Supported_hardware wiki [2] should probably also be updated to only mention FT2232/FT4232 (without the H), as we now have evidence that FT2232D/FT2232L are working just as well for SPI access.
i dont know the ft chips very well, but ill trust you on this one :)
Finally, since external users cannot edit the wiki, I am also attaching a proposed update for the FT2232SPI_Programmer wiki page [3], to go with the patch. A preview of what this edit should look like can be found here [4]. I also fixed a few other minor items on the page, such as the "still pending review" Amontec JTAGkey2 section.
very nice work! i'll update the wiki as soon as your patch is committed.
i forgot about the documentation inside the source repository. if you like then you could also update the manpage. the new model needs to be added to the ft2232_spi section (also openmoko is missing there). and i think the general description of the ft2232_spi should be changed... the H should be removed as you suggested for the wiki and i think the JTAGkey shouldnt be mentioned there at all (the jtagkey IS a ft based programmer(?)).
On 2011.06.05 02:19, Stefan Tauner wrote:
i forgot about the documentation inside the source repository. if you like then you could also update the manpage. the new model needs to be added to the ft2232_spi section (also openmoko is missing there). and i think the general description of the ft2232_spi should be changed... the H should be removed as you suggested for the wiki and i think the JTAGkey shouldnt be mentioned there at all (the jtagkey IS a ft based programmer(?)).
OK, I'll look into that too.
Regards,
/Pete
Hi Stephan. Thanks for looking at the patch.
On 2011.06.05 01:45, Stefan Tauner wrote:
i think armusbtiny or arm-usb-tiny would be better. is the name without dashes used anywhere in the docs, software etc. supplied by olimex?
I always seem to see the name used with dashes and all caps when referenced by Olimex in its documentation, but I too agree that it's fairly ugly, and I wouldn't mind doing away with both. Right now I'm planning to go with 'armusbtiny', unless you prefer to keep the dashes there. The Olimex website does use lowercase + dashes for the product (eg: http://www.olimex.com/dev/arm-usb-tiny-h.html or http://www.olimex.com/dev/arm-usb-ocd.html)
if so please resend the patch with "armusbtiny", else its probably better to use the original name the vendor chose(?) as you know there is also a -h version available from olimex. you dont happen to know the ids i guess? :)
Say no more... ;) I think the -H version, as well as ARM-USB-OCD(-H), which are pretty much the same thing as ARM-USB-TINY(-H), only with an RS232 port added, should be safe to include even if these are untested right now. Unless you object, I'll add these devices to v2 of the patch. Names would be 'armusbtinyh', 'armusbocd' and 'armusbocdh'.
also if it's not too much of a hassle, please also post a verbose log showing the device in action.
I'll do that.
Regards,
/Pete
On Sun, 05 Jun 2011 18:49:55 +0100 Pete Batard pbatard@gmail.com wrote:
On 2011.06.05 01:45, Stefan Tauner wrote:
as you know there is also a -h version available from olimex. you dont happen to know the ids i guess? :)
Say no more... ;) I think the -H version, as well as ARM-USB-OCD(-H), which are pretty much the same thing as ARM-USB-TINY(-H), only with an RS232 port added, should be safe to include even if these are untested right now.
ah i see the ids are published on their website.. cool. jup then please add them and just mark them as NT in the array. thanks!
Unless you object, I'll add these devices to v2 of the patch. Names would be 'armusbtinyh', 'armusbocd' and 'armusbocdh'.
personally i think arm-usb-tiny-h etc. would be easier on the eyes, but i will leave the decision to you - or the majority, in case someone else expresses his opinion.
thanks a lot of your work!
As promised, here's v2 of the patch.
It adds support for the ARM-USB-OCD, as well as the -H versions (untested). I eventually settled on "arm-usb-###(-h)" for the new designations. I've also edited the mock-up wiki to reflect these changes [1] (you can pick the wiki source at [2]). I'll send a separate patch for the updated man page later.
Also attached the verbose logs for probe/read/write against an Asus P5B Deluxe motherboard, using an ARM-USB-TINY.
Signed-off-by: Pete Batard <pbatard at gmail.com>
Regards,
/Pete
[1] https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_... [2] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_p...
And here's the man patch.
Signed-off-by: Pete Batard <pbatard at gmail.com>
Regards,
/Pete
On Thu, 09 Jun 2011 16:38:40 +0100 Pete Batard pbatard@gmail.com wrote:
- {OLIMEX_VID, OLIMEX_ARM_OCD_PID, OK, "Olimex", "ARM-USB-OCD"},
- {OLIMEX_VID, OLIMEX_ARM_TINY_PID, OK, "Olimex", "ARM-USB-TINY"},
- {OLIMEX_VID, OLIMEX_ARM_OCD_H_PID, OK, "Olimex", "ARM-USB-OCD-H"},
- {OLIMEX_VID, OLIMEX_ARM_TINY_H_PID, OK, "Olimex", "ARM-USB-TINY-H"},
hello pete, thanks for your patch(es)!
in the table above all programmers are marked ok although they were not all tested... i am quoting my last mail: "please add them and just mark them as NT in the array".
i also do not recognize the reason to order the devices like that (not only the table, but also the macros and the if/elses). grouping OCDs and TINYs together respectively, or ordering them by PID could make more sense? i am not necessarily demanding that you change the order. it just looked odd when i looked at the patch and would probably look odd to others when the see the source or the output of flashrom -L.
regarding the man page patch:
-can be any of +can be one of
how is that better (non-native speaker here...)?
-.BR "* ft2232_spi" " (for SPI flash ROMs attached to a FT2232H/FT4232H/JTAGkey \ +.BR "* ft2232_spi" " (for SPI flash ROMs attached to an FT2232(H) or FT4232(H) \
you said in your previous mail...
Please note that the External_flashers/programmers section of the Supported_hardware wiki [2] should probably also be updated to only mention FT2232/FT4232 (without the H), as we now have evidence that FT2232D/FT2232L are working just as well for SPI access.
why not drop the 'H' altogether? or list the other versions there too (like in "FT2232D/H/L" or similar)?
if you resubmit the patches, could you please merge them? they belong together imho. sorry to be so picky... your work is greatly appreciated!
On 2011.06.10 19:21, Stefan Tauner wrote:
in the table above all programmers are marked ok although they were not all tested... i am quoting my last mail: "please add them and just mark them as NT in the array".
Ah, sorry, I completely overlooked that one. Thanks for the reminder.
i also do not recognize the reason to order the devices like that
Well, first from Olimex came the ARM-USB-OCD (PID 3), then came the ARM-USB-TINY (PID 4), so that's our start. But then when the H versions came along, Olimex curiously "released" the OCD-H (PID 2B) after the TINY-H (PID 2A). It only felt more natural to me to have both the H and non H versions listed in the same order in the source, but if you want to reorganize them around as you see fit, just go ahead.
regarding the man page patch:
-can be any of +can be one of
how is that better (non-native speaker here...)?
Non native speaker either, but I think (feel) "any of" is better applied to very short lists, whereas "one of" is better applied to long ones, and our list has grown long. As the matter above, just a matter of individual perception.
Please note that the External_flashers/programmers section of the Supported_hardware wiki [2] should probably also be updated to only mention FT2232/FT4232 (without the H), as we now have evidence that FT2232D/FT2232L are working just as well for SPI access.
why not drop the 'H' altogether? or list the other versions there too (like in "FT2232D/H/L" or similar)?
Considering that I have just found out that there also exists HL and HQ versions of the above chips, I think it's safer to go without the suffix there, so I amended the man page.
if you resubmit the patches, could you please merge them?
Here you go. Signed-off-by: Pete Batard <pbatard at gmail.com>
Regards,
/Pete
Hi Pete,
thanks for your patch.
Am 11.06.2011 00:31 schrieb Pete Batard:
Signed-off-by: Pete Batard <pbatard at gmail.com>
Looks good, I'll let Stefan commit because he did the review.
Regards, Carl-Daniel
On Fri, 10 Jun 2011 23:31:03 +0100 Pete Batard pbatard@gmail.com wrote:
Here you go. Signed-off-by: Pete Batard <pbatard at gmail.com>
hey!
Acked-by: Stefan Tauner stefan.tauner@student.tuwien.ac.at after a short irc discussion i have changed your patch a bit and committed it in r1331. thanks!
On 2011.06.11 13:22, Stefan Tauner wrote:
Acked-by: Stefan Taunerstefan.tauner@student.tuwien.ac.at after a short irc discussion i have changed your patch a bit and committed it in r1331. thanks!
Many thanks for this.
With regards to the wiki, the photo indeed was the one found on the Olimex website. If people want to see a photo, I can take one, but unless there's an explicit request, I'm not planning to at this stage.
Note that the top of the Supported Hardware page [1] still uses"FT2232H" instead of the more generic "FT2232". Apart from that, it all looks good. Thanks again!
/Pete
On 10/06/11 23:31, Pete Batard wrote:
regarding the man page patch:
-can be any of +can be one of
how is that better (non-native speaker here...)?
Non native speaker either, but I think (feel) "any of" is better applied to very short lists, whereas "one of" is better applied to long ones, and our list has grown long. As the matter above, just a matter of individual perception.
As someone who is a native English speaker I would say that "one of <list>" implies you can select one item from <list> (only one) and "any of <list>" implies you can select one or more option from <list>. I have had a brief look in 'man flashrom' and I would suggest removing "any of" in all places and "one of" in one place, they don't seem needed.
Best explained in a patch, so I have attached one. Signed-off-by: Andrew Morgan ziltro@ziltro.com
I left “one of -h, -R, -L, -z, -E, -r, -w, -v or no operation.” because those options are mutually exclusive.
On Sat, 11 Jun 2011 23:05:46 +0100 Andrew Morgan ziltro@ziltro.com wrote:
On 10/06/11 23:31, Pete Batard wrote:
regarding the man page patch:
-can be any of +can be one of
how is that better (non-native speaker here...)?
Non native speaker either, but I think (feel) "any of" is better applied to very short lists, whereas "one of" is better applied to long ones, and our list has grown long. As the matter above, just a matter of individual perception.
As someone who is a native English speaker I would say that "one of <list>" implies you can select one item from <list> (only one) and "any of <list>" implies you can select one or more option from <list>. I have had a brief look in 'man flashrom' and I would suggest removing "any of" in all places and "one of" in one place, they don't seem needed.
Best explained in a patch, so I have attached one. Signed-off-by: Andrew Morgan ziltro@ziltro.com
I left “one of -h, -R, -L, -z, -E, -r, -w, -v or no operation.” because those options are mutually exclusive.
hello andrew
i have merged your patch with another one and committed it in r1339. please see http://patchwork.coreboot.org/patch/3133/ for details. thanks for your input!
On Thu, 09 Jun 2011 16:38:40 +0100 Pete Batard pbatard@gmail.com wrote:
As promised, here's v2 of the patch.
It adds support for the ARM-USB-OCD, as well as the -H versions (untested). I eventually settled on "arm-usb-###(-h)" for the new designations. I've also edited the mock-up wiki to reflect these changes [1] (you can pick the wiki source at [2]). I'll send a separate patch for the updated man page later.
Also attached the verbose logs for probe/read/write against an Asus P5B Deluxe motherboard, using an ARM-USB-TINY.
Signed-off-by: Pete Batard <pbatard at gmail.com>
Regards,
/Pete
[1] https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_... [2] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_p...
hi again,
i have also updated the wiki as you proposed, but left out the photograph because we don't own the copyright (it's obviously taken from the olimex page). i don't think it's necessary, but if you want a photograph of the hardware to be included please make a shot yourself and send it to us - or ask for a wiki account (i cannot add you myself though).
On Sat, Jun 11, 2011 at 4:17 PM, Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
On Thu, 09 Jun 2011 16:38:40 +0100 Pete Batard pbatard@gmail.com wrote:
As promised, here's v2 of the patch.
It adds support for the ARM-USB-OCD, as well as the -H versions (untested). I eventually settled on "arm-usb-###(-h)" for the new designations. I've also edited the mock-up wiki to reflect these changes [1] (you can pick the wiki source at [2]). I'll send a separate patch for the updated man page later.
Also attached the verbose logs for probe/read/write against an Asus P5B Deluxe motherboard, using an ARM-USB-TINY.
Signed-off-by: Pete Batard <pbatard at gmail.com>
Regards,
/Pete
[1] https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_... [2] http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Flashrom_ftdi_p...
hi again,
i have also updated the wiki as you proposed, but left out the photograph because we don't own the copyright (it's obviously taken from the olimex page). i don't think it's necessary, but if you want a photograph of the hardware to be included please make a shot yourself and send it to us - or ask for a wiki account (i cannot add you myself though).
I own a JTAGkey Tiny, I am interested to test flashing an SPI BIOS chip with it, what should I do?
The webpage says:
"The Amontec JTAGkey2 can be used with flashrom for programming SPI chips. JTAGkey and JTAGkey-Tiny should work, if you add them to ft2232_spi.c (untested)."
Should I power the chip externally in 3.3v?
There are many JTAG boards based on FT2232, that would be great to support them all.
Best,
-- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators."
Hi Benjamin,
On 2011.06.11 18:47, Benjamin Henrion wrote:
I own a JTAGkey Tiny, I am interested to test flashing an SPI BIOS chip with it, what should I do?
The webpage says:
"The Amontec JTAGkey2 can be used with flashrom for programming SPI chips. JTAGkey and JTAGkey-Tiny should work, if you add them to ft2232_spi.c (untested)."
The first thing to do will be to find the USB Vendor ID (VID) and Product ID (PID) of your device. This can usually be accomplished by plugging in your device and checking its properties (eg. by issuing the command 'lsusb' on Linux). The VID used by Amontec is expected to be the same as the one used by FTDI, hence 0x0403, so all you should have to do is find the PID.
Once you have these values, you should be able to duplicate the entries related to the JTAGKey in ft2232_spi.c, and add a new identifier for yours. Then after recompiling (you'll need libftdi installed), you should be good to go.
Should I power the chip externally in 3.3v?
Yes you should. Both the Amontec and the Olimex based products related to ARM JTAG interfacing use a standard ARM JTAG pinout, that does not include provision for providing power.
An example of the full ARM JTAG pinout is provided in the entry for the ARM-USB-TINY [1]. VREF and VTARGET are used as input only (and are usually connected together), to adjust to the voltage being used by the target device, so unless your device has an additional port to provide power, the JTAG port alone will not do as a voltage source.
However, I found that providing power for SPI was really no trouble at all: all you need to do is pick up a couple of AA or AAA batteries, put them in serial, and you have the 3.0V DC you are after (anything close to 3V will do - it doesn't have to be exactly 3.3). If you have any remote lying around, that uses 2 AAs, all you have to do is open the battery compartment and stick 2 cables where the batteries make contact near the middle, since all the remotes I know have the battery serialization at the bottom.
The voltage source then needs to be split between the JTAGKey (JTAG VREF+GND) and your SPI target (SPI VCC+GND), but if the JTAGKey Tiny design is the same as the ARM-USB-TINY from Olimex, even that should be a no brainer, as VREF and VTARGET would be connected together, as well as all the ground lines. Therefore, you just have to connect the voltage source to the key, and you should be able to pull that voltage, from duplicated pins, into your SPI port.
Please let us know how your testing goes.
Regards,
/Pete
[1] http://www.flashrom.org/FT2232SPI_Programmer#Olimex_ARM-USB-TINY_and_related...
-
Andrew Morgan -
Benjamin Henrion -
Carl-Daniel Hailfinger -
Idwer Vollering -
Pete Batard -
Stefan Tauner