Hello Elly,
Thank you for your reply, and sorry my response has taken a while!
>
Most (non-server) Intel SoCs are supported by coreboot, from ~Core 2 Duo up to
PantherLake (which *should* be released at CES 2026 in two days, but can't say
more than that).
BayTrail and ApolloLake that you mentioned are fully supported, but don't have
great documentation. They were used by Google in Chromebooks, so that should
give you some ideas as to where to start.
This sounds encouraging!
One thing you should keep in mind is that APL/GLK SoCs are a bit "cursed".
They can boot from SPI... as well as eMMC (presumably they've been developed
for automotive sector) and mFIT will nag you to fuse them with BootGuard
(similar to BootROM verifying PBL with vendor's keys).
All of these boards boot from SPI Flash, although some do have eMMC, but
that is only used for bulk storage (these are embedded modules, so we
only use eMMC or NVMe for filesystems).
I will initially be concentrating on 2 modules, one with a baytrail soc
and the other with elkhartlake, and both of these only have SPI Flash
and eMMC - the Apollo Lake module I mentioned in my first email has
lower priority at this time.
All APL systems I've seen in the wild were fused (with the exception of
Chromebooks), but it will not be a problem if you have signing keys.
Could you tell me how would I detect if the devices have been fused?
As for unbricking/developing: Currently the cheapest/best SPI flashers you can
get your hands on is either a Raspberry Pi Pico, or CH347.
They do however have a limitation of being 3.3V, so you will likely need to buy
a 1.8V logic shifter as all APL systems I've seen in the wild used 1.8V SPI.
All of our boards are using 3v3 SPI flash devices.
As for recommendations, DediProg EM100 is the current "industry standard", but
it's... not cheap.
Last time I've checked it cost close to 1000EUR/piece. It has a Spartan Xilinx
6 FPGA inside (newer models likely have a Spartan 7) and supports both 1.8 and
3.3V SPI chips.
I have just ordered an EM100. On all of these modules, the flash devices
are located on the bottom of the board and there is only about 5mm
clearance between the module and the carrier board (which has to be
present at run-time), so it is tricky to connect to the flash devices
themselves, however, there is a debug board available from the
manufacturer which connects to a 40-pin connector on the module which
exposes 7-segment displays for port-80/81, as well as a 14-pin SPI
programmer interface designed for the Dediprog SF100 flash programmer,
but I am sure I could make an adapter for this to connect to am EM100.
I watched a presentation of yours at 38c3 and started trying to poke
around with the intelmetool.
On the baytrail module, I see the following output:
MEI found: [8086:f18] Atom Processor Z36xxx/Z37xxx Series Trusted
Execution Engine
ME Status : 0x1f0000d5
ME Status 2 : 0x60000000
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : YES
ME: Update In Progress : NO
ME: Current Working State : Normal
ME: Current Operation State : (null)
ME: Current Operation Mode : Normal
ME: Error Code : No Error
ME: Progress Phase : Host Communication
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : Host communication established
ME: Extend Feature not present
ME: circular buffer full, resetting...
ME: message (4) too large for buffer (255)
ME: GET FW VERSION message failed
I am guessing that because this board is in manufacturing mode, it is
probably not locked down at all?
On the elkhartlake module, I see something completely different...
Initially intelmetool was saying that it could not find the management
engine, but then I looked in the source, and noticed that elkhartlake is
not even supported, so I found the ME device using lspci:
00:16.0 Communication controller: Intel Corporation Elkhart Lake
Management Engine Interface (rev 11)
And then using the -n option of lspci I discovered 00:16.0 0780:
8086:4b70 (rev 11), so I added this deviceid to the source of
intelmetool and with intelmetool -m -d, I see:
ME PCI device is hidden
RCBA addr: 0x00000000
Can't find ME PCI device
I have not dug much deeper, but at this stage I assume this will be a
bit more of a challenge!
I now have all of the coreboot tools built under Yocto and installed on
my devices, so I will continue probing to see what else I can gather
from these boards.
- Hamish
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
