<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 11, 2018 at 7:52 AM, Elmar Stellnberger <span dir="ltr"><<a href="mailto:estellnb@elstel.org" target="_blank">estellnb@elstel.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 2018-05-11 00:08, Nico Huber wrote:<br>
> actually, I don't see a BIOS in there at all. ...<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-508228365178877632gmail-">
If you want to hunt more clues nevertheless, you can send us the output<br>
of `flashrom -p internal:laptop=force_I_want_a<wbr>_brick -V`. IIRC, it<br>
also tells from which bus the BIOS was loaded.<br>
<br></span><span class="m_-508228365178877632gmail-">
I think the ME has some logging enabled and simply writes to the flash.<br>
<br>
Nico<br>
<br>
</span></blockquote><span class="m_-508228365178877632gmail-">
<br>
On 2018-05-10 23:24, David Hendricks wrote:<br>
> If this is the case, then you will need to figure out how to prevent<br>
> the EC  from reading/writing the ROM at the same time as flashrom.<br>
> This could be as simple as disabling your OS's power management daemon<br></span>
> to avoid stimulating it, or ...<br>
<br>
Here comes the verbose output of flashrom as attachement.<br>
This time the output was taken after shutting down the backlight daemons:<br>
systemctl stop systemd-backlight@backlight:ac<wbr>pi_video0.service<br>
systemctl stop systemd-backlight@backlight:nv<wbr>_backlight.service<br>
<br>
- and see the newly loaded rom images do not differ any more (though the time between taking both images has been less this time).<br></blockquote><div><br></div><div>Glad that seems to have worked for reading. However as Nico said we really can't recommend attempting to write using flashrom. At least not unless you can get a full understanding of how this works and how to safely disable the EC for updates, and have a method for recovery (e.g. an external programmer). Anything that interacts with the EC (power, thermal, input events, maybe other things) can wake it up and put your system in a bad (possibly bricked) state.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">wget <a href="https://www.elstel.org/uploads/celsius3.rom" rel="noreferrer" target="_blank">https://www.elstel.org/uploads<wbr>/celsius3.rom</a><br>
wget <a href="https://www.elstel.org/uploads/celsius4.rom" rel="noreferrer" target="_blank">https://www.elstel.org/uploads<wbr>/celsius4.rom</a><br>
<br>
  Is it true that these flash images do not contain a BIOS?<br></blockquote><div><br></div><div>It appears true. As Nico said it appears this chip is only for ME firmware and configuration data. There is almost certainly another SPI flash on the motherboard for the BIOS. You may need to (de-)assert some GPIO or send a special command to the EC to select it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If it still contains all ME regions that should be enough for disabling ME? How to do that - I have heard that me_cleaner only works on gen2 and gen3 MEs but that my ME would be gen1?<br></blockquote><div><br></div><div>I'm not an expert on me_cleaner, but the long story short is that ME is a complicated beast that changes frequently and is very intertwined with how the system works. me_cleaner can remove some (many?) modules but can't disable it completely since ME controls some functions needed to bring-up the CPU. I'm sure they'd appreciate your help demystifying your ME's generation!</div></div><br></div></div>