Patch Set 1:

Hi Carl-Daniel,
> Just to make sure I understand you correctly: You want to select which onboard flash chip is accessed by flashrom, and there may be multiple flash chips hanging off different masters.

Correct.

Do the following scenarios look complete to you?
1. Flash chip attached directly to the southbridge (Parallel, LPC, FWH, SPI) and we handle all hardware access inside flashrom.
2. Like 1, but the master accesses are abstracted by using Linux spidev.
3. Like 2, but the chip accesses are abstracted as well by using Linux MTD.
4. Like 1, but sometimes a dual chip setup is used and we may have to set which chip is active (e.g. in Dual BIOS setups), and sometimes a dual chip setup is only accessible as some opaque combined chip.
5. Flash chip attached to some master (Super I/O, EC, whatever) which performs implicit translation for all read accesses from the chipset, but writing and other commands have to be done by talking to the master directly and we handle all hardware access inside flashrom.
6. Like 5, but the implicit translation only covers part of the flash chip and all accesses from flashrom have to be done by talking to the master EC directly.
7. Like 6, but there is no implicit translation.

Scenario 1 is the classic internal case for flashrom.
Scenario 2 is covered by linux_spi.
Scenario 3 is covered by linux_mtd.

Right, but the idea here is to make it so the user says `-p host` instead of having to know which of the three options listed here would usually require (`-p internal:bus=<spi|i2c|lpc>`, '-p linux_spi`, `-p linux_mtd`). As you pointed out this makes it so that the hardware knowledge is inside flashrom, meaning that syntax sugar necessary to target the intended device is nicely abstracted from users, documentation, scripts, tests, daemons, etc.

Using Chromebooks as an example, there are now over 150 devices with hardware from all major vendors listed on their "developer information for Chrome OS devices" website. Flashrom is used on all of them, so keeping flashrom's syntax simple and consistent across all devices is very important.

> The scenarios above are made more complicated by the fact that some ECs require chipset setup to be accessible, and some ECs may really dislike the probe sequence for another EC.

Yes, and it's better to avoid changing the hardware at all if it's not absolutely needed, for example setting the boot BIOS straps register. If something goes wrong in scenarios 5, 6, and 7 and a probe sequence leaves the master in a changed state, then the system might not boot until the power is cycled. And on a laptop that often means taking apart the whole thing and removing the battery.

So overall, AFAICS the desire is to be able to specify "probe just the masters which may have access to the X" where X is "firmware for the main CPU", "VPD", or something else. You also do not want to have detailed hardware knowledge in the scripts calling flashrom, but rather inside flashrom.

Exactly.

Please help me correct any misunderstandings above. Maybe we can come up with a clean design which satisfies all of your needs.

Great!

I wasn't too such that the next step is here and are there any specific actions I should be taking to keep this moving forwards in a direction?

View Change

To view, visit change 38671. To unsubscribe, or for help writing mail filters, visit settings.