Stefan,
Ahh thank you, that makes sense. The nicintel_spi was working when I pointed it at an actual intel PCI card, but I got pulled away before I could further experiment between the various commands with the various PCI address targets.
*Eric Donaldson*
*DevOps Engineer**Zadara Storage* eric@zadarastorage.com
Skype: eric_zadara Twitter: @ZadaraStorage Website http://www.zadarastorage.com/ | Blog http://www.zadarastorage.com/blog/ | LinkedIn http://www.linkedin.com/company/zadara-storage/ | Facebook http://www.facebook.com/ZadaraStorage.VPSA | Twitter http://twitter.com/zadaraStorage | YouTube http://www.youtube.com/playlist?list=PLZHbMSlUCWob2xFDopFs10UiEwEF8CHg_
On Fri, Mar 11, 2016 at 4:31 PM, Stefan Tauner < stefan.tauner@alumni.tuwien.ac.at> wrote:
On Fri, 11 Mar 2016 08:25:16 -0800 Eric Donaldson eric@zadarastorage.com wrote:
Sorry about that, thought I had included the command I was running. I was just running the probe on it to figure out if I was going to be able to read and write to flash, then it said to run it verbosely and submit it. `flashrom -p internal:pci=01:00.0`
I think you are confusing the internal programmer with nicintel_spi (etc). The internal programmer is actually used to access the flash chip of the mainboard containing the firmware of the board and possibly its on-board peripherals. Thus it *might* contain the PXE firmware as well but there is no easy way to prepare images for that.
However, from what you wrote so far I think you want to use nicintel_spi and friends to access the boot flash of dedicated NICs. For them the pci parameter makes way more sense as well :)
-- Kind regards/Mit freundlichen Grüßen, Stefan Tauner