Hi,
I'm trying to find out which external programmers should be supported next.
1. There was talk of an AVR-based new programmer using the serprog protocol on IRC by someone with the nick "coldelectrons", but I have no idea if he/she is reading this mail. IMHO more hardware using the serprog protocol is always a good idea.
2. All those Willem/Sivava variants. People regularly request those, but I don't think anyone in here owns the hardware.
3. RayeR's SPIPGM. I have a preliminary patch which could work, but I don't have the hardware. Will send the patch to the list soon.
4. LPC^2, Milksop, CheapLPC and other programmers from the Xbox modding community.
5. Dozens of SPI programmer hardware projects scattered over the net. Too many to count, and I'm not sure which of them has more than one user.
In general, it seems creating a new programmer hardware design is like writing IRC clients: A nice way to get started in the field. I have no problems merging flashrom support for all of them, but I won't implement support for all of them myself.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Hi,
I'm trying to find out which external programmers should be supported next.
- There was talk of an AVR-based new programmer using the serprog
protocol on IRC by someone with the nick "coldelectrons", but I have no idea if he/she is reading this mail. IMHO more hardware using the serprog protocol is always a good idea.
That would be me, and yes, I am.
I had a Willem clone at one time, but the software I received with it is far from current - and then I had to try and figure out which variant/version I had so I could try to download the right version....
I no longer have the Willem in whole form, just as I no longer use Windows, which is why I'm trying to make my own.
I'm using an Arduino Mega to speak the 'serprog' protocol, and to bitbang a parallel bus to a DIP32 socket. The atmega1280 on the Mega has the capability of interfacing to an external SRAM, but I haven't had much luck in making that work in a breadboarding environment. After all the IO used for the parallel bus, there is still enough IO left over (and dedicated functions) for rs232, SPI, and i2c.
My current schematic only works for 5V-only chips.
My problem thus far is that while I can read a chip and dump it to a file, I'm unable to detect or write to a chip. From what I can tell, something doesn't jive between normal AM29F040 probing and the operation of a serprog programmer. For one thing, you need to throw certain address/values at a 29F' and detect a response...while the serprog protocol buffers all writes to an operation buffer. I don't think the probe routine ever 'executes' the buffer. I've only been looking over the code for maybe 2 days, so I'm far from expert on it.
Even as I received this email, I've been dicing up flashrom code into a python script that will hopefully talk to my ad-hoc programmer and flash my darn AM29F040 for me.
On 05.05.2010 02:26, fritz wrote:
Carl-Daniel Hailfinger wrote:
- There was talk of an AVR-based new programmer using the serprog
protocol on IRC by someone with the nick "coldelectrons", but I have no idea if he/she is reading this mail. IMHO more hardware using the serprog protocol is always a good idea.
That would be me, and yes, I am.
I had a Willem clone at one time, but the software I received with it is far from current - and then I had to try and figure out which variant/version I had so I could try to download the right version....
Heh yes, I heard such complaints from various people, and that's why I hope we can support Willem family programmers in flashrom soon.
I'm using an Arduino Mega to speak the 'serprog' protocol, and to bitbang a parallel bus to a DIP32 socket. The atmega1280 on the Mega has the capability of interfacing to an external SRAM, but I haven't had much luck in making that work in a breadboarding environment. After all the IO used for the parallel bus, there is still enough IO left over (and dedicated functions) for rs232, SPI, and i2c.
My current schematic only works for 5V-only chips.
My problem thus far is that while I can read a chip and dump it to a file, I'm unable to detect or write to a chip. From what I can tell, something doesn't jive between normal AM29F040 probing and the operation of a serprog programmer. For one thing, you need to throw certain address/values at a 29F' and detect a response...while the serprog protocol buffers all writes to an operation buffer. I don't think the probe routine ever 'executes' the buffer. I've only been looking over the code for maybe 2 days, so I'm far from expert on it.
serprog_chip_readb() should cause a buffer flush, and every probe sequence calls this function indirectly via chip_readb() to read the chip response.
Even as I received this email, I've been dicing up flashrom code into a python script that will hopefully talk to my ad-hoc programmer and flash my darn AM29F040 for me.
Can you post a verbose flashrom log for your programmer?
By the way, if the timing in your programmer is not accurate, chip detection is guaranteed to fail, especially with such old flash chips. Depending on the chip, it will need one microsecond or up to 20 milliseconds to start sending its ID, and if you're too slow, the chip will have stopped sending its ID before you start reading. Some chips already stop sending the ID before others even start, and that's the reason flashrom has detailed timing info for pretty much every chip stored in flashchips.c. Modern chips are way more forgiving (zero delay to start sending the ID, and they will send the ID forever).
Regards, Carl-Daniel
On 05.05.2010 04:30, Carl-Daniel Hailfinger wrote:
On 05.05.2010 02:26, fritz wrote:
My problem thus far is that while I can read a chip and dump it to a file, I'm unable to detect or write to a chip. From what I can tell, something doesn't jive between normal AM29F040 probing and the operation of a serprog programmer. For one thing, you need to throw certain address/values at a 29F' and detect a response...while the serprog protocol buffers all writes to an operation buffer. I don't think the probe routine ever 'executes' the buffer. I've only been looking over the code for maybe 2 days, so I'm far from expert on it.
serprog_chip_readb() should cause a buffer flush, and every probe sequence calls this function indirectly via chip_readb() to read the chip response.
It is also possible that one of the recent serial core patches may have messed up serprog buffering. Can you retry with the 0.9.1 release (r709/r710) just to be sure this is not a regression in flashrom?
Can you post a verbose flashrom log for your programmer?
By the way, if the timing in your programmer is not accurate, chip detection is guaranteed to fail, especially with such old flash chips.
A non-working write would also cause a failing probe.
If everything else fails, you could ask Urja Rannikko for the AVR source code of his serprog programmer. I think it was posted to the flashrom list some time ago, but I can't find the link right now. I've added Urja to the CC of this mail.
Regards, Carl-Daniel
An update on my microcontroller-based external serial programmer:
It works.
I can program 5V-only chips, in DIP32 form, or PLCC32 with an adapter. The highest baud rate I've been able to make work is 115200, which makes things pretty slow. Further experimentation may show that I could run a higher baudrate and maybe remove most of the `noop` delays in my I/O routines - but that's for another day.
Of some old chips I had extracted from old motherboards, I was able to detect and dump a Winbond W29EE011, and a SST29EE010.
However, the chip I wanted to program - Am29F040B - I could NOT detect.
I'll spare you the in-depth story of the past twelve hours I've spent working on it.
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
Mine is not the only chip flashrom does that with: http://pastebin.org/288436
My schematic, board layout, and firmware can be found at http://www.coldelectrons.com/blog/?page_id=165
I've figured one very small change that makes flashrom properly work to detect my chip:
diff --git a/flashchips.c b/flashchips.c index b1af60a..4feabe8 100644 --- a/flashchips.c +++ b/flashchips.c @@ -178,7 +178,7 @@ struct flashchip flashchips[] = { .model_id = AM_29F040B, .total_size = 512, .page_size = 64 * 1024, - .feature_bits = FEATURE_ADDR_2AA | FEATURE_SHORT_RESET, + .feature_bits = FEATURE_SHORT_RESET, .tested = TEST_UNTESTED, .probe = probe_jedec, .probe_timing = TIMING_IGNORED, /* routine don't use probe_timing (am29f040b.c) */
For some reason, having FEATURE_ADDR_2AA set makes jedec.c screw up the address.
With that changed: $ sudo ./flashrom -p serprog:/dev/ttyUSB0:115200 -VV flashrom v0.9.2-r1015 on Linux 2.6.32-trunk-amd64 (x86_64), built with libpci 3.1.7, GCC 4.4.3 20100108 (prerelease), little endian flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... 936M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1001 us, 10000 myus = 10056 us, OK. Initializing serprog programmer serprog_init serprog:connected - attempting to synchronize . serprog:Synchronized serprog:Interface version ok. serprog:Programmer name "MEGASHIELDSERPRG" serprog:serial buffer size 128 serprog:operation buffer size 4096 serprog:Maximum write-n length 1 serprog:Maximum read-n length 16777216 Probing for AMD Am29F040B, 512 KB: Chip lacks correct probe timing information, using default 10mS/40uS. serprog_chip_writeb serprog:Passing write-n bytes=1 addr=0x5555 serprog_delay serprog_chip_writeb serprog:Passing write-n bytes=1 addr=0x2aaa serprog_delay serprog_chip_writeb serprog:Passing write-n bytes=1 addr=0x5555 serprog_delay serprog:Executed operation buffer of 30 bytes serprog_chip_readb addr=0x0 returning 0x01 serprog_chip_readb addr=0x1 returning 0xA4 serprog_chip_writeb serprog:Passing write-n bytes=1 addr=0x5555 serprog_delay probe_jedec_common: id1 0x01, id2 0xa4serprog:Executed operation buffer of 10 bytes serprog_chip_readb addr=0x0 returning 0xFF serprog_chip_readb addr=0x1 returning 0xFF
Found chip "AMD Am29F040B" (512 KB, Parallel) at physical address 0xfff80000. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom@flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -Vr, -Vw, -VE), and mention which mainboard or programmer you tested. Thanks for your help! === No operations were specified. serprog_shutdown
I now have my chip programmed, and I didn't have to write an application from scratch to do it. If it had gone smoother, I'd profess thanks, but in my sleep-deprived state I think all you are going get out of me is a grunt and a respectful nod :)
Am Freitag, den 28.05.2010, 12:48 -0400 schrieb fritz:
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
You found a bug. If you send your patch with a sign-off http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure the fix will be added with you as primary author.
Mine is not the only chip flashrom does that with: http://pastebin.org/288436
Which is OK. Some flash chip data sheets specifiy to use the addresses 0x555, 0x2AA, 0x555
For some reason, having FEATURE_ADDR_2AA set makes jedec.c screw up the address.
It's the intended effect of that FEATURE. It means that the chip it with this feature needs 0555/02AA/0555 instead of 5555/2AAA/5555. When we unified chip drivers, it seems we didn't read datasheet thouroughly enough, although we worked quite carefully on it, and got this chip wrong. We are very sorry for the time you wasted on that.
I think we were in IRC contact. For some of us, finding this mistake would have been a couple-of-minute jobs (can be seen from flashrom -V output), so having asked about this undetected chip might have saved you hours of debugging.
I now have my chip programmed, and I didn't have to write an application from scratch to do it. If it had gone smoother, I'd profess thanks, but in my sleep-deprived state I think all you are going get out of me is a grunt and a respectful nod :)
But *we* do need to thank you for reporting the wrong flag.
Regards, Michael Karcher
On 05/28/2010 12:48 PM, fritz wrote:
An update on my microcontroller-based external serial programmer:
It works.
That's awesome! Great Work :-)
On Fri, May 28, 2010 at 9:48 AM, fritz fritzlists@gmail.com wrote:
An update on my microcontroller-based external serial programmer:
It works.
I can program 5V-only chips, in DIP32 form, or PLCC32 with an adapter. The highest baud rate I've been able to make work is 115200, which makes things pretty slow. Further experimentation may show that I could run a higher baudrate and maybe remove most of the `noop` delays in my I/O routines - but that's for another day.
I was thinking of programming 2mbit flash chips with shift registers and an regular arduino and it didn't occur to me to use flashrom as software. When I get around to using them I might just have to spring for a megaduino. Sweet!
Hi,
I have some success using flashrom >serprog _> own avr frimware.
it needs some polishing the i will release schematics + source.
i doupt shift regs is the way to go.. i used a 74act574 (8 bit latch) for the low 8 bits and dedicated io for the high bits (the other way around would have been better) if you used one 574/8 address bits you only need 8+<chip ctrl lines>+<(adresslines+7)/8)> io pins. best would be to use a whole port for the datapins..
i will do a arduino posrt shortly.
greetings, Reinder
Kyle Kienapfel wrote:
On Fri, May 28, 2010 at 9:48 AM, fritz fritzlists@gmail.com wrote:
An update on my microcontroller-based external serial programmer:
It works.
I can program 5V-only chips, in DIP32 form, or PLCC32 with an adapter. The highest baud rate I've been able to make work is 115200, which makes things pretty slow. Further experimentation may show that I could run a higher baudrate and maybe remove most of the `noop` delays in my I/O routines - but that's for another day.
I was thinking of programming 2mbit flash chips with shift registers and an regular arduino and it didn't occur to me to use flashrom as software. When I get around to using them I might just have to spring for a megaduino. Sweet!
flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
On 5/28/10 9:48 AM, fritz wrote:
However, the chip I wanted to program - Am29F040B - I could NOT detect.
I'll spare you the in-depth story of the past twelve hours I've spent working on it.
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
The Problem is the Am29F040B uses 0x2AA variant, but the Am29F040 uses 0x2AAA. What AMD/Spansion did was change the command addresses without changing the chip ids. Sadly there's no way to distinguish between the two.
Am Samstag, den 19.06.2010, 14:04 -0700 schrieb Sean Nelson:
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
The Problem is the Am29F040B uses 0x2AA variant, but the Am29F040 uses 0x2AAA. What AMD/Spansion did was change the command addresses without
Do we have a user with a Am29F040B that works with the 2AA variant? In that case have him/her test with the 2AAA variant. It is quite likely that the 2AAA variant works on all chips (the higher bits being ignored) by the 2AA chip.
Regards, Michael Karcher
On Sat, 19 Jun 2010 14:04:21 -0700 audiohacked at gmail.com (Sean Nelson) wrote:
On 5/28/10 9:48 AM, fritz wrote:
However, the chip I wanted to program - Am29F040B - I could NOT detect.
I'll spare you the in-depth story of the past twelve hours I've spent working on it.
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
The Problem is the Am29F040B uses 0x2AA variant, but the Am29F040 uses 0x2AAA. What AMD/Spansion did was change the command addresses without changing the chip ids. Sadly there's no way to distinguish between the two.
Seems like they have done that between Am29F010 and Am29F010A as well (cf. "Not detecting Am29F010 using 3Com PCI nic" by Ignatius Grippa)...
Actually, there is of course a way to distinguish them: probe once with FEATURE_ADDR_2AA and once with FEATURE_ADDR_2AAA :) I'll try to get Ignatius to test this...
On 25.12.2015 03:03, Stefan Tauner wrote:
On Sat, 19 Jun 2010 14:04:21 -0700 audiohacked at gmail.com (Sean Nelson) wrote:
On 5/28/10 9:48 AM, fritz wrote:
However, the chip I wanted to program - Am29F040B - I could NOT detect.
I'll spare you the in-depth story of the past twelve hours I've spent working on it.
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
The Problem is the Am29F040B uses 0x2AA variant, but the Am29F040 uses 0x2AAA. What AMD/Spansion did was change the command addresses without changing the chip ids. Sadly there's no way to distinguish between the two.
Seems like they have done that between Am29F010 and Am29F010A as well (cf. "Not detecting Am29F010 using 3Com PCI nic" by Ignatius Grippa)...
Actually, there is of course a way to distinguish them: probe once with FEATURE_ADDR_2AA and once with FEATURE_ADDR_2AAA :) I'll try to get Ignatius to test this...
The AMD Am29F040B is clearly probable with FEATURE_ADDR_2AAA, too. I am looking at AMD publication 21445, Rev E, issued Novermber 29, 2000. Note 4 on page 14 indicates that: "Address bits A18–A11 are don’t cares for unlock and command cycles, unless SA or PA required." 0x2800 (the additional Bits in 0x2AAA compared to 0x2AA) are bits A11 and A13, so this chip just doesn't care.
Regards, Michael Karcher
On Fri, 25 Dec 2015 10:03:56 +0100 Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de wrote:
On 25.12.2015 03:03, Stefan Tauner wrote:
On Sat, 19 Jun 2010 14:04:21 -0700 audiohacked at gmail.com (Sean Nelson) wrote:
On 5/28/10 9:48 AM, fritz wrote:
However, the chip I wanted to program - Am29F040B - I could NOT detect.
I'll spare you the in-depth story of the past twelve hours I've spent working on it.
The summary: Flashrom (from svn) would detect the other chips using addresses 0x5555, 0x2AAA, 0x5555 Flashrom (from svn) would try to detect the Am29F040 using addresses 0x0555, 0x02AA, 0x0555 - which is not according to the datasheet.
The Problem is the Am29F040B uses 0x2AA variant, but the Am29F040 uses 0x2AAA. What AMD/Spansion did was change the command addresses without changing the chip ids. Sadly there's no way to distinguish between the two.
Seems like they have done that between Am29F010 and Am29F010A as well (cf. "Not detecting Am29F010 using 3Com PCI nic" by Ignatius Grippa)...
Actually, there is of course a way to distinguish them: probe once with FEATURE_ADDR_2AA and once with FEATURE_ADDR_2AAA :) I'll try to get Ignatius to test this...
The AMD Am29F040B is clearly probable with FEATURE_ADDR_2AAA, too. I am looking at AMD publication 21445, Rev E, issued Novermber 29, 2000. Note 4 on page 14 indicates that: "Address bits A18–A11 are don’t cares for unlock and command cycles, unless SA or PA required." 0x2800 (the additional Bits in 0x2AAA compared to 0x2AA) are bits A11 and A13, so this chip just doesn't care.
Oh hai!
Yes, indeed. Also the Am29F080 and Am29F080B feature this misfeature. I have a patch prepared that splits all of them. This will likely result in two definitions matching the chip with the current probing as you explained but will make it possible to distinguish them later with the new probing framework.
-
Carl-Daniel Hailfinger -
fritz -
Joseph Smith -
Kyle Kienapfel -
Michael Karcher -
Reinder de Haan -
Sean Nelson -
Stefan Tauner