[coreboot] Porting Qotom Q355G4 SBC (similar to Librem 13)

Nico Huber nico.huber at secunet.com
Fri Aug 31 12:07:41 CEST 2018


Hi John,

Am 29.08.18 um 04:02 schrieb John Keates:
> Thank you for your reply! Sadly, Boot Guard is enabled in Verified Boot
> mode. I’ll ask if Qotom can spin up a batch without any public key
> burned into the CPU, or perhaps share the private key. (which is
> obviously unlikely — but one can try)

there are other alternatives; BootGuard has not a single key but a
key hierarchy (probably for more profitable licensing schemes). So
you could try to get your own certificate signed by Qotom. But...
I can only advice against using BootGuard at all. If you don't have
one, you'd be looking forward to an NDA with Intel*. Also, you'd have
to integrate Intel's BootGuard ACM (piece of software that runs be-
fore host firmware) into your coreboot image and might also have to
adapt the early boot process of coreboot itself.

About the port itself. There is another pitfall: Intel FSP for Broad-
well is not integrated into upstream coreboot. What is integrated are
Google's blobs that do about the same as FSP but seem to be only licen-
sable as part of Chromebooks. IANAL, but I assume you could get into
trouble if you'd sell these blobs as part of your own product (not sure
if you want to sell anything). If you just want to use it in-house, that
might be possible, but again IANAL. (Welcome to the blob mess, btw.)

The alternative (with a much better license situation now) would be to
use Intel FSP. It does exist for Broadwell, it's "just" not integrated
upstream.

And some comments to your original mail:

> - gpio.h is probably depending on the PCH used? Seems to be generic for
> this PCH as well

No, GPIO configuration is not generic. Never use the GPIO configuration
of another board! You might provoke short-circuits (I guess the PCH is
protected, but you never know what you break on the other side).

If you have another already working (reference) firmware for your board
(it seems so) you can dump the GPIO settings using `inteltool`.

> - romstage.c initialises the GPIOs does some PEI data copy/memset and
> then romstage_common (which probably is around or before the CAR stage?)

This code runs with CAR enabled (most C code before ramstage does). The
PEI data is passed to the Google blob. The GPIO config and what happens
in `romstage.c` are the most crucial parts to get your board booting.
Alas, I can't tell you much about PEI data for Broadwell. Some settings
are board specific, e.g. memory configuration. You have to figure the
correct settings for your board (some questions may be answered by its
schematics).

Nico

* Well, I have to admit, an NDA has become useful anyway when porting
  coreboot. Mostly because Intel doesn't document what they are doing
  to coreboot.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xBD56B4A4138B3CE3.asc
Type: application/pgp-keys
Size: 5227 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180831/2499bc58/attachment.skr>


More information about the coreboot mailing list