Hi.
Sorry. I don't speak English.
Please come and discuss such (massive) rewrites on #flashrom or the mailing list. I like most approaches you had handling the parallel port, but we need to coordinate changes to avoid duplicate work with the Willem FWH/LPC programmer device.
First thing is to get rid of direct calls INB () and OUTB (). Because difficult to recognize that OUTB (0x12, 0xDC02) is lpt_write_control (0x12), and INB (0xDB01) is lpt_read_status (). Now appeared in the mailing list patches for Willem and they also use OUTB (), INB (). In Linux INB () and OUTB () call iopl () or ioperm (), and iopl () requires a UID == 0. In Windows INB () and OUTB () are available only after dancing with a tambourine. For Windows, I wrote code to use InpOut32.dll ( http://www.highrez.co.uk/Downloads/InpOut32/default.htm ), but have not tested, because I do not use Windows. See: https://bitbucket.org/mmcx/flashrom/commits/fc684370fba426db678691ab9f5b6486...
Can you confirm "byteblaster" and "wiggler" to work with patches applied upto this: http://patchwork.coreboot.org/patch/3880/
I confirm "byteblaster" and "wiggler" is OK with http://patchwork.coreboot.org/patch/3880/.
Should we use "byteblastermv" and "Altera ByteBlasterMV" ?
Altera has two adapters for LPT: ByteBlaster II and ByteBlasterMV. They differ in polarity signal OE. "ByteBlasterMV" a jumper between pins 7 and 10 of LPT. "ByteBlaster II" has a jumper between pins 6 and 10 LPT. I use a clone ByteBlasterMV. Possible it is necessary to add a method "probe()" to determine whether the adapter connected.
My plan was to have that set of patches merged as the first step. Keeping these simple increases chances of getting a review and merge. Handling parallel port with either direct IO or ppdev must be independent of using SPI, there are FWH/LPC/parallel flash programmers. And parallel port code needs to be portable to different OS too. I did not look thoroughly, maybe these requirements were taken care of already.
In previous patches for each adapter appear almost identical methods init () and shutdown (). The difference is only able to pin "to programming" and "after the programming" for different adapters. I think it is better to use bitmaps to describe the state of pins. I also think that it is more convenient to use the pin numbers LPT, what number of bits in the registers. One more thing: LPT-port has an internal inversion on pines 11, 14, 17 (so-called "bit 7 hack"). I think that this inversion has no place in the description of adapters.
Maksim