[coreboot] Thinkpad X230, Coreboot 4.7 + SeaBIOS 1.11.0 flashing, memtest86+ 5.01, fancontrol and WoL
oxij at oxij.org
Mon Apr 23 17:53:03 CEST 2018
Duncan <dguthrie at posteo.net> writes:
> The wiki page says many things. I've edited the page for clarity about
> that and removed the odd Buspirate-specific instructions (I am not sure
> why BusPirate users can't just look at Flashrom wiki etc).
> In general don't use external power for in-system-programming (ISP) on
> the X230 (or any other recent Intel laptop) - the boards in question
> really weren't designed to have flash powered that way.
> Do NOT power system flash externally as well as with the WoL feature -
> this can only do bad things to the board.
This last paragraph is unclear. You want to say that I should only power
using the WoL feature, not external power, on all the models, right?
>> The only difference with older models is that you have to cut
>> coreboot.rom into 8M and 4M pieces and flash them separately. (You can
>> flash the top 4M only, but then, apparently, you wouldn't be able to
>> reflash the ME region internally).
> There isn't actually a difference to older models, except that they've
> split system flash over two flash chips. The BIOS region (the area we
> may install Coreboot on) on the X230 is actually 7MiB, not 4MiB. It's
> just that the 4MiB can be used on its own for Coreboot, without having
> to touch the 8MiB flash chip. If you look at the flash descriptor,
> you'll see that the BIOS region is described as 7MiB, that is, leading
> from the last 3MiB of the 8MiB flash chip to the end of the 4MiB flash
Yes, I noticed that. I seems that between x220 and x230 ME region got a
few KB too fat for 8M and Lenovo had to add a whole new 4M SIP chip just
for those several KB.
> If you want to make use of the whole 7MiB (without changing the size of
> other regions per se), either:
> 1. Flash internally
> 2. Build a Coreboot image using the flash descriptor and other Intel
> blobs dumped from your system, and then split the image e.g. using dd so
> that you can change flash contents of both the 8MiB and 4MiB flash chips.
But I dump after every reboot and I see ME writing to the flash. It
looks as if it logs something there in some binary format (it
incrementally writes to higher addresses on every dump). To flash
internally with a full ME running seems as a bad idea.
> Alternatively, you could replace the two flash chips with a single 16MiB
> flash chip (as I understand it, this is the largest size supported by
> the SPI controller), which is easier to use, and you'll have more space
> for payloads (some payloads like a Linux payload can be very large, and
> Linux payloads are very flexible and may be fun to play with).
That's nice to know.
>> # Wake on LAN issue/question
>> After flashing coreboot I expected "Wake on Lan on AC connect" to stop
>> working since it was configured in vendor BIOS, but it still works. Why?
>> What code enables it? Can I disable it? How?
>> Also, does WoL need the GBE/ME blobs to work? It is kinda useful that it
>> still works with coreboot since and I can now reflash with impunity
>> using the same WoL method if I brick the ROM. But I want to know if I
>> would be able to clean the ME region and wipe the GBE region (and use
>> USB Ethernet instead) and still use the WoL trick for flashing.
> One thing to note is that the GbE "blob" isn't really a blob as one
> would think. It is configuration data (which is arguably not possible to
> copyright) and thus should be possible to generate. It's not executable
> as far as I understand.
> I'd honestly not recommend using USB ethernet - the onboard NIC performs
> well and is reliable.
> There are no issues with using the WoL feature and "cleaning" the ME
> region. Some users have reported "cleaning" the ME region makes suspend
> cease to work, but I've not experienced this. It may be kernel/OS
> version or they may have installed their dump that is corrupted in some
> way. It seems like something fairly difficult to debug.
> It's possible that they are encountering issues with the ME not working
> with their dumped firmware image. In general, it is best to flash back a
> "factory fresh" firmware image (perhaps, in this case, "cleaned" with
> the ME Cleaner program). It is not clear to me why this is, but this is
> what some users have reported - as far as I understand, the ME itself
> may hold some sort of persistent state. Spooky.
It does hold some state, as I noted above. Spooky indeed.
https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf is for
ME11 and Thinkpad x230 is ME8, but the slide #11 there lists "FLOG"
"Flash Log" ME region. So it does log something in ME11. I couldn't find
much descriptive research on ME < 11. I'd like to read something that
describes what the BUP stage does in ME8, but
what ME11 BUP does, and I'm confused:
>>> Stage 1
>>> During the initial stage, the sfs internal diagnostic file system
>>> (SUSRAM FS, a file system located in non-volatile memory) is
>>> created, the configuration is read, and, most importantly, the PMC
>>> is queried about what caused the startup: power-on of the platform,
>>> restart of the entire platform, ME restart, or waking up from sleep.
>>> This stage is called boot flow determination. Subsequent stages in
>>> the work of the initialization finite automaton depend on it. In
>>> addition, several modes are supported: normal and a set of service
>>> modes in which the main ME functionality is disabled (HAP, HMRFPO,
>>> TEMP_DISABLE, RECOVERY, SAFE_MODE, FW_UPDATE, and FD_OVERRIDE).
>>> Stage 2
>>> At the next stage, the ICC controller is initialized and the ICC
>>> profile (responsible for clock frequencies of the main consumers) is
>>> loaded. Boot Guard is initialized and cyclic polling for processor
>>> startup confirmation is started.
So, ME gets booted on AC power and then it waits for somebody else (EC?
PCH?) to enable CPUs via power button press in stage 2? Or does it boot
only after power button press in parallel with CPUs?
> In any case, I'm not sure if it's a good idea to really change the ME
> region, if you think it's risky.
So the question stands. What code implements WoL? Is it the GBE adapter
itself? Does it read CMOS values? (How else vendor BIOS can disable it?)
More information about the coreboot