Coreboot Build Script Failing

So ever since I heard Purism announced that they had officially purged Intel ME from their machines, I’ve been extremely interested in updating my Librem 15v3. That having been said, I’ve run into a few problems when trying to build the new coreboot image on my hardware.

For starters the ME Firmware RAR file has been updated so the script fails to verify the signature for the updated file. Fixing this was relatively easy and I was able to do so without any issue. Long story short: R48 became R49 and the previous R48 links redirect to the new R49 file. The comments in the script file indicate that the link and signature should be updated in the event of a change, so thats what I did.

Okay with that out of the way - I proceeded to move forward with the script and I now run into this error.

Built purism/librem15v3 (Librem 15 v3)
File build/coreboot.rom is 16777216 bytes
  Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
  Flash Region 1 (BIOS): 00200000 - 00ffffff
  Flash Region 2 (Intel ME): 00001000 - 001fffff
  Flash Region 3 (GbE): 07fff000 - 00000fff (unused)
  Flash Region 4 (Platform Data): 07fff000 - 00000fff (unused)
  Flash Region 5 (Reserved): 07fff000 - 00000fff (unused)
  Flash Region 6 (Reserved): 07fff000 - 00000fff (unused)
  Flash Region 7 (Reserved): 07fff000 - 00000fff (unused)
  Flash Region 8 (EC): 07fff000 - 00000fff (unused)
HEAD is now at 9facf98... Change debug line to avoid confusion with new --extra-partitions argument
Full image detected
The ME/TXE region goes from 0x1000 to 0x200000
Found FPT header at 0x1010
Found 11 partition(s)
Found FTPR header: FTPR partition spans from 0x2000 to 0xa9000
Found FTPR manifest at 0x2478
ME/TXE firmware version 11.0.18.1002
Removing unused partitions...
 b'FTPR'         (0x1000   - 0xa8000  (0xa7000  total bytes)): removed
 b'FTUP'         (0x110000 - 0x1bc000 (0xac000  total bytes)): removed
 b'DLMP'         (0x0      - 0x0      (0x0      total bytes)): removed
 b'PSVN'         (0xe00    - 0x1000   (0x200    total bytes)): removed
 b'IVBP'         (0x10c000 - 0x110000 (0x4000   total bytes)): removed
 b'MFS\x00'      (0xa8000  - 0x10c000 (0x64000  total bytes)): removed
 b'NFTP'         (0x110000 - 0x1bc000 (0xac000  total bytes)): removed
 b'ROMB'         (0x0      - 0x0      (0x0      total bytes)): removed
 b'FLOG'         (0x1bc000 - 0x1bd000 (0x1000   total bytes)): removed
 b'UTOK'         (0x1bd000 - 0x1bf000 (0x2000   total bytes)): removed
 b'ISHC'         (0x0      - 0x0      (0x0      total bytes)): removed
Removing unused partition entries in FPT...
Traceback (most recent call last):
  File "./me_cleaner/me_cleaner.py", line 638, in <module>
    mef.write_to(me_start + 0x14, pack("<I", len(new_partitions) / 0x20))
struct.error: required argument is not an integer

So if I’m guessing here my guess is that the parameters passed to the me_cleaner script specifically single out the MFS partition but this image has a partitioned named ‘MFS\x00’ instead. Perhaps thats MFS with a null character at the end of the string? I don’t know.

Anyway I’d reallly appreciate any insight anybody can offer here. I’d love to ascend to the next level of hardware freedom as soon as possible :wink:

Thanks in advance!

I’m seeing this on my Librem 13v2 also running Arch (I figured that was relevant because I saw you mentioned it in the other thread).

I think this is because @kakaroto’s changes to me_cleaner.py expect /usr/bin/python to be Python 2.x, but on Arch it’s Python 3. In Python 3, division of two integers using the / operator always returns a float, which explains why we get “required argument is not an integer”. Standard me_cleaner is supposedly both Python 2 and 3 compatible.

I tried replacing the offending / with the // operator to get integer division instead, but that causes a different error somewhere else:

Traceback (most recent call last):
  File "./me_cleaner/me_cleaner.py", line 640, in <module>
    me_start + min_start, b"\xff")
  File "./me_cleaner/me_cleaner.py", line 68, in fill_range
    raise OutOfRegionException()
__main__.OutOfRegionException

I tried changing the '\0' in line 617 to '\x00' after seeing that the comment above it references ‘MFS\0’ but both of our outputs have “MFS\x00” but it didn’t help.

I don’t have any other clues yet, but I suspect it’s a different Python 2/3 incompatibility. For now, you can just hardcode python2 into me_cleaner.py and it builds and verifies just fine:

diff --git a/me_cleaner.py b/me_cleaner.py
index 39641f1..6d1d10b 100755
--- a/me_cleaner.py
+++ b/me_cleaner.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python2
 
 # me_cleaner - Tool for partial deblobbing of Intel ME/TXE firmware images
 # Copyright (C) 2016, 2017 Nicola Corna <nicola@corna.info>

I just flashed it. If I haven’t posted back in 15 minutes, something has gone horribly wrong.

Update: It boots! I’m not entirely sure how to interpret the ME status since it differs from all of the posted examples:

ME: FW Partition Table      : BAD
ME: Bringup Loader Failure  : YES
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : YES
ME: Update In Progress      : YES
ME: D3 Support              : YES
ME: D0i3 Support            : YES
ME: Low Power State Enabled : YES
ME: Power Gated             : YES
ME: CPU Replaced            : YES
ME: CPU Replacement Valid   : YES
ME: Current Working State   : Unknown (15)
ME: Current Operation State : M0 without UMA but with error
ME: Current Operation Mode  : M0 without UMA
ME: Error Code              : Preboot
ME: Progress Phase          : <NULL>
ME: Power Management Event  : CM0PG->CM0
ME: Progress Phase State    : Unknown phase: 0x0f state: 0xff
ME: Power Down Mitigation   : YES
ME: PD Mitigation State     : Issue Detected but not Recovered
ME: Encryption Key Override : Workaround Applied
ME: Encryption Key Check    : FAIL
ME: PCH Configuration Info  : Changed
ME: Firmware SKU            : Unknown (0x7)
ME: FPF status               : fused

Update 2: 34 minutes later, the ME has not shut down the machine and it is still running:

$ uptime
 03:55:40 up 34 min,  1 user,  load average: 0.61, 0.76, 0.84
1 Like

Yeah that fixed the issue. Thanks. Here is my ME status. It closely resembles yours:

ME: FW Partition Table      : BAD
ME: Bringup Loader Failure  : YES
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : YES
ME: Boot Options Present    : YES
ME: Update In Progress      : YES
ME: D3 Support              : YES
ME: D0i3 Support            : YES
ME: Low Power State Enabled : YES
ME: Power Gated             : YES
ME: CPU Replaced            : YES
ME: CPU Replacement Valid   : YES
ME: Current Working State   : Unknown (15)
ME: Current Operation State : M0 without UMA but with error
ME: Current Operation Mode  : M0 without UMA
ME: Error Code              : Preboot
ME: Progress Phase          : <NULL>
ME: Power Management Event  : CM0PG->CM0
ME: Progress Phase State    : Unknown phase: 0x0f state: 0xff
ME: Power Down Mitigation   : YES
ME: PD Mitigation State     : Issue Detected but not Recovered
ME: Encryption Key Override : Workaround Applied
ME: Encryption Key Check    : FAIL
ME: PCH Configuration Info  : Changed
ME: Firmware SKU            : Unknown (0x7)
ME: FPF status               : fused

Hey, thanks @aarmea for figuring it out! I hadn’t thought of python 3. I’ll have to test against it next time and fix this. Maybe it’s already fixed since my changes got pushed upstream and Nicola Corna already adapted/fixed my patches.
The crash you saw couldn’t be fixed with the changes you attempted probably because the problem was that there were no partitions left at all (You see FTPR and MFS as ‘removed’ even though they are unremovable), so I’m just glad it crashed instead of letting you flash a completely empty ME which would have had unknown consequences.

@jaylittle The ME RAR being updated, I already fixed that, and made some changes so that if it gets updated in the future, the script will figure out the filename to use automatically and ignore the hash (it will still check the hash of the ME image inside of it, so that’s safe).

As for the ME status in cbmem, that’s exactly what we want, it’s because the ME is disabled, so coreboot can’t even access its status registers (it returns 0xfffffffff which coreboot interprets as all that). It’s explained here, where it says “a disabled ME simply doesn’t give us a status at all—so coreboot will even think that the ME partition is corrupted.”

Next week, I’ll look over the ME changes, see if upstream fixed the python 3 issues, then test, and update my me_cleaner branch so others using Arch won’t have this issue!

In the meantime, enjoy your disabled ME!

1 Like

Thanks for the info @kakaroto. It is much appreciated :slight_smile:

Definitely enjoying the disabled ME today. Been using the laptop all day and its been rock solid stable. Great work!

1 Like