On 28 Dec 2018, at 00:36, Piotr Król <piotr.krol(a)3mdeb.com> wrote:
On 8/19/18 4:06 PM, John Keates wrote:
I’m new at the board porting game but I’m interested in making a port
for a single board computer that is running very similar hardware to the
Librem 13 laptop and the Google Pixel 2015.
It seems this board is also rather close to Intel’s own Eval Kit
hardware setup, both in hardware and software regard (almost bare
defaults AMI Aptio firmware).
Looking at the coreboot archives, this board might have been mentioned
that was HTML formatted in an attachment for some reason.
Qotom are definitely interesting platforms :) And there are some OEM
that build on top of their designs.
I can't analyze whole your post, as probably most of people making
coreboot professionally, but I have some pointers to you and would be
glad to get some feedback from you if possible.
It has a running ME, but there is an unpopulated
header (ME1) which when
shorted seems to kill it or put it in manufacturing mode (soldered in a
pin header and plugged in a jumper):
MEI found: [8086:9cba] Wildcat Point-LP MEI Controller #1
ME Status : 0x1e040185
ME Status 2 : 0x10522106
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : NO
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode : Security Override via Jumper
ME: Error Code : No Error
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : 0x52
I'm not sure if killing ME at porting time is good idea it can cause
more problems then gain at this point. I would leave it as it is to keep
Yeah, I figured I’d better start off with a working firmware first anyway, but BootGuard
still prevents that AFAIK.
When not using the jumper, flashrom can’t read anything using the
internal programmer mode, but when plugging the jumper in, it can read
it. Output is not the same as reading the SPI flash chip offline
externally, so some of the flash it probably still hidden by the PCH as
it always does.
This is normal situation, flash descriptor, ME and maybe some SMI
protect access to some regions. You should have external programmer and
read firmware when platform is off - that can be tricky depending on
platform schematics around SPI.
What you should make sure:
1. You have stock firmware version that can boot platform - this can be
just offline read that I described above, online read for sure will
cause platform brick.
2. You should care about flashing only BIOS region of flash and leave ME
as it is.
3. Reading offline (let's call it golden stock version) and writing
offline is good first test - it is risky and may end up in brick, but
that's porting work so risk have to be calculated. If platform boot
after that it is very good indicator, more to that you can think about
writing random binary to bios region and verify that it is not booting
and finally recover with your golden stock firmware version. If platform
boot after that your are good to go with development.
I did have a go at reading and writing the SPI flash offline (I’m used to embedded ARM and
It’s located reasonably accessible, just take the case off and find it next to the CPU
(often the RTC battery is taped on top of it).
It has multiple footprint options it seems (or perhaps a socketed option), but the default
SOIC-8 is easy enough to read, even with the cheap (and ever so fragile) pomona clip.
So at this point, I do have a few verified offline reads (so SMM, MMU, ME etc. don’t mess
with it) which write back fine as well.
My next steps were: cp -R the Purism directory to Qotom, remove all the
Librem15 stuff, rename the Librem13 to Q3XXG4 and remove the EC
references as this board doesn’t have an EC.
At this point, I’m not sure what to do next, besides the text in
board_info.txt (both the vendor directory and the variant directories)
I’ll probably have to make sure:
- acpi_tables.c has the correct tables, unless I can use the (generic
looking) contents the Librem 13 uses, which doe acpi_init_gnvs,
and acpi_create_madt_lapics + acpi_create_madt_ioapic
- there is fadt.c which seems rather generic as well.
- gpio.h is probably depending on the PCH used? Seems to be generic for
this PCH as well
- hda_verb.c seems to relate to the audio system, but I don’t care about
it all that much at this time. The Librem 13 uses the ALC269 which has
some differences to the ALC662, configuring it wrong probably just makes
the chip sad and audio pin routing not work
- mainboard.c contains mainboard_enable and some calls for the GMA chip
(install_intel_vga_int15_handler and some constants), probably the same
accross this broadwell series
- romstage.c initialises the GPIOs does some PEI data copy/memset and
then romstage_common (which probably is around or before the CAR stage?)
- acpi/mainboard.asl is empty, not sure what part of the existing ACPI I
should dump in there
Probably hard to figure out without reverse engineering, schematics or
experiments. The most scary thing is initial GPIO configuration which
can cause hardware damage if set incorrectly. If you don't have
schematics you should risk anyway - at least we do.
Yeah, for this work it is reasonable (as far as risks go). The platform doesn’t have a lot
of peripherals, it seems only the SuperIO and the HDA chip have some sidecar components
with attached GPIOs.
The old wiki and it’s porting guide isn’t up to date as far as I know,
but I haven’t found a new guide or set of docs that shows how to
read/source information from a running system and write it into a new
I’ll probably need to get the GbE region from the old firmware, ME too,
but what other parts of data (ACPI tables? PEI data?)I need to get and
how to fill out that data into the mainboard definition isn’t very clear
PEI is not important. ACPI defintely should be dumped, but if you can
get back to golden stock firmware then it doesn't matter.
I got everything dumped, and I can go back, so that’s good.
has a GPIO header, and two serial ports (one external DB9,
one internal header), so getting debug data out should be possible, but
just randomly building an image and flashing it in to the SPI chip
probably gets me nothing until I have at least configured the serial
port for coreboot to spit out debug data. I’m not sure if I need to get
the FSP from Intel or if I should extract the one from the current firmware.
Here are couple problems with that hardware:
1. It doesn't seem that Intel provide FSP for Broadwell-U, there is
something for Broadewll-DE:
2. Always use Intel most recent FSP
3. 90% chance that your stock BIOS doesn't use FSP, this is BIOS built
from Intel Reference Code that AMI gets directly
4. There is cool debug option that can wear SPI, but if you have
external programmer you can dump logs to SPI and read it from there:
Ah, the SPI logging is pretty cool, didn’t know about that. I did look in to the CCA tool,
which apparently is just an USB3 cable with the USB2 Data pins and VCC pin removed. This
does seem to require cooperation from the ME, so probably not worth a try at this time.
Hope this will help.
The extra pointers are helpful indeed. I have started searches for ULV and mobile series
single board computers that don’t have BootGuard enforcement enabled, but no luck so far.
But if I find one, I can definitely continue.
Couple questions from me:
1. What is the motivation behind this port?
Multiple; on one hand, I’m interested in the booting of more complex systems like x86
systems and large ARM SoCs, only scratched the surface on those, but it looks like fun.
On the other hand, I find the concept of hardware that you cannot boot with software of
your own choice ridiculous, including low level boot roms and firmware.
I do understand that if a large corporation has a business model based on secrets, it’s a
hard problem to solve to give less than 1% of customers something they are happy with
while exposing some of those secrets.
Perhaps an option to get Intel to sign a FOSS ME engine with a key that is recognised by
the on-die SoC/CPU boot ROM would be nice, but that is not likely to happen. Having only
the on-die boot rom as a black box would be much more acceptable to me.
2. Are you active in pfSense, OPNSense or any other
I’m active in OPNSense these days. I used to be rather active in pfSense, but the
environment has gotten too toxic for me over the past years. I do have some side projects
using Linux-based SDN setups on this type of hardware.
3. Is this commercial activity or learning experience?
For me it is learning, but I imagine if I were to succeed, someone would be happy to make
commercial use of it. Perhaps an integrator that takes Qotom whitelabel boxes and preloads
them with an OS and firmware of choice.
Plenty of people would like a local cache of hardware so they don’t have to wait for a
china shipment (that said, Qotom usually arrives within 48hrs here in western europe), and
have local people to talk to.
So on one hand, if some vendor would use it to make things better for everyone, that’d be
cool. On the other hand, if a company like Sophos were to start blindly reselling Qotom
boxes, slap a Sophos logo on it, preinstall the free UTM and sell it at 1000% the worth of
the product, I’d probably have an opinion about that, but then again, so would most people
building stuff in their spare time ;-)
As 3mdeb we are official maintainers of PC Engines and looking to
support whole network appliance environment. Recently we working also on
some support for Qotom based platforms.
I suspect you then have to get around the BootGuard issue, right? Because as far as I
know, you cannot boot coreboot with BootGard fuses blown in enforcement mode.
PC Engines is a pretty cool company, used a lot of ALIX boards in the past (the ones with
the tinyBIOS) which had a few issues between versions but always turned out great in the
I did switch to ARM based systems (often i.MX) and Intel based systems before the APU
platforms became available locally because at that point, white label import became a real
Nice to see you guys on the list!
Embedded Systems Consultant