Flashrom cannot read EEPROM, no DMI table found

[randall-mcpherson]

I am having the same issue, and exact same terminal output as OP on #173. I am using a Dell Optiplex 5055, the latest version of Flashrom, and Debian 12 Bookworm. Whether I supply the argument flashrom -p internal:laptop=this_is_not_a_laptop, or flashrom -p internal -r backup.bin as outlined here, I am provided with the same splash text as in post 173, which informs that I may supply the argument flashrom -p internal:laptop=this_is_not_a_laptop. I have checked here as well, and see that someone is having the same issue as of last month, and with the same chipset as is in my machine, detailed here. In addition to solving this issue, clarification as to whether I may be likely to succeed in flashing coreboot internally as outlined here in the coreboot documentation, would be appreciated. I do not currently know how to disable read/write protection, and am looking into that, if that is the nature of the issue. Any help is appreciated. Thanks.

[randall-mcpherson]

So I found on [ubuntu.manpages](https://manpages.ubuntu.com/manpages/xenial/man8/flashrom.8.html#programmer-specific information) the following under AMD Chipsets:
`

          Beginning with the SB700 chipset there is an integrated microcontroller (IMC) based
          on  the  8051  embedded  in every AMD southbridge. Its firmware resides in the same
          flash chip as the host's which makes writing to the  flash  risky  if  the  IMC  is
          active.  Flashrom  tries  to temporarily disable the IMC but even then changing the
          contents of the flash can have unwanted effects: when the  IMC  continues  (at  the
          latest  after a reboot) it will continue executing code from the flash. If the code
          was removed or changed in an unfortunate way it is unpredictable what the IMC  will
          do.  Therefore,  if  flashrom  detects  an active IMC it will disable write support
          unless the user forces it with the

            flashrom -p internal:amd_imc_force=yes

          syntax. The user is responsible for supplying a suitable image or leaving  out  the
          IMC  region with the help of a layout file. This limitation might be removed in the
          future when we understand the details better and have received enough feedback from
          users. Please report the outcome if you had to use this option to write a chip.

`

Is this applicable, and if so, is there some plausible workaround?