[coreboot] Apollo Lake new hardware bring-up

Tahnia Lichtenstein unlich at gmail.com
Wed Apr 18 00:56:46 CEST 2018

Hi all,

I am wondering if anyone here has experience in bringing up newly assembled
hardware based on Apollo Lake SoC, and if so, if they can share how to boot
the hardware for the first time? Is there a special binary (other than
normal bootloader) that I need to load into the TXE ROM, or do I need to
strap special resistors (needed only for first boot in order to load
something into TXE ROM) or anything else that differs from normal boot flow?

I am trying to boot brand new hardware (i.e. it has not gone through any
firmware programming yet), using a coreboot+SeaBIOS combination (adapted
for the hardware), and stitched as per Intel specifications for hardware
that has already undergone the manufacturing process (loading development
keys as per Intel instructions, adding CSE image, PMC image, microcode,
etc.), and disabling verified boot. (Flash map of generated binary

I tried to load the SPI flash-based bootloader binary on the Leaf Hill CRB
and also on the Apollo Island CRB, and both attempts run successfully up to
the RAM initialization phase, where execution stops (because the binary is
intended for a different RAM type as required by my platform).

However, when I try to run my bootloader binary on my brand new platform
straight from assembly, the SPI flash device is only read up until the end
of the flash descriptor, at address 0x14B (i.e. including SoC straps
region, but excluding padding). Then all SPI transactions stop. In other
words, the SPI flash device is not read far enough for boot partition 1 to
be loaded into the SoC, and therefore I conclude the problem is not
strictly related to my coreboot implementation, but related either to (1)
hardware, (2) SoC soft-strapping contained in flash descriptor 4KB region,
or (3) new hardware bring-up procedure.

(1) While I am not discounting a hardware flaw (e.g. incompatible SPI flash
muxing method, or incompatible flash device type, or wrong resister
straps), it seems unlikely at this point. The hardware has proved to work
to some extent, as witnessed on an oscilloscope/logic analyzer - the flash
descriptor region is read correctly (verified byte-by-byte compared to the
hex values in the binary), changes frequency when required to do so by SoC
softstrapping options, and has undergone some limited XJTAG boundary
scanning, and multiple reviews to ascertain designs, layouts and

(2) As for SoC softstraps, I have picked all the values applicable to my
platform, but have not been successful to enable "Firmware ROM bypass"
option in the FIT tool as this option is grayed out and disabled in the
tool (not sure if this is necessary for first boot?)

(3) As for bring-up procedure (before or during first boot), it is unclear
to me what this procedure is. My understanding is there is a special
TXE-related binary I need to load into the TXE ROM before first "normal"
boot, but am not sure how to do this, and not sure if this is necessary (or
possible). Therefore this is my most likely candidate culprit. To solve
this, I tried to load the CSE image (stand-alone, not stitched together
with coreboot outputs or anything else) on the flash and then run the
binary, hoping it would load whatever firmware needs to be loaded into TXE
before first boot. This attempt failed miserably, as this binary's flash
descriptor signature is "24 46 50 54", which differs from the normal
descriptor mode signature of "5A A5 F0 0F" (little endian for 0FF0A55A).
Thus when observing the run-time behaviour, the SPI flash is now only read
up till the signature (at address 0x10 - 0x13), thereafter all SPI
transactions stop. We tried asserting different combinations of resistors
while programming and/or booting (specifically the flash descriptor
override pin and ROM bypass pin) - with normal bootloader binary and CSE
image, makes no difference to initial problem.

I am very sorry if this is the wrong forum to ask, but I have been
struggling with this problem for many weeks, and have not been able to find
answers through the correct channels. I am just hoping someone here might
be able to help point me in the right direction for the procedures of
bringing up new Apollo Lake platforms.

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180418/9f549d4d/attachment.html>
-------------- next part --------------
Start (hex)    End (hex)    Length (hex)    Area Name
-----------    ---------    ------------    ---------

00000000       007FFFFF     00800000        Full Flash Image
00000014       00000017     00000004            FLMAP0 - Flash Map 0 Register
00000018       0000001B     00000004            FLMAP1 - Flash Map 1 Register
0000001C       0000001F     00000004            FLMAP2 - Flash Map 2 Register
00000030       0000003B     0000000C            FCBA - Flash Component Registers
00000040       00000043     00000004            FLREG0 - Flash Region 0 (Flash Descriptor) Register
00000044       00000047     00000004            FLREG1 - Flash Region 1 (IFWI) Register
00000048       0000004B     00000004            FLREG2 - Flash Region 2 (Intel(R) TXE) Register
00000050       00000053     00000004            FLREG4 - Flash Region 4 (Platform Data) Register
00000054       00000057     00000004            FLREG5 - Flash Region 5 (Device Expansion) Register
00000060       00000063     00000004            FLREG8 - Flash Region 8 (Embedded Controller) Register
00000080       00000083     00000004            FLMSTR1 - Flash Master 1 (Host CPU/BIOS)
00000084       00000087     00000004            FLMSTR2 - Flash Master 2 (Intel(R) TXE)
00000100       000002FF     00000200            FPSBA - SoC Straps (Including Padding)
00000DF0       00000EFF     00000110            VSCC Table
00000DF0       00000DF7     00000008                N25Q128A
00001000       0037FFFF     0037F000        Boot Partition 1
00001000       000F9FFF     000F9000            Primary Boot Partition
00001200       0000120F     00000010                IFP Overrides Partition
00001210       00001317     00000108                Unified Emulation Partition (UEP)
00002000       00004FFF     00003000                OEM SMIP Partition
00005000       0000EFFF     0000A000                CSE RBE Partition
0000F000       0001EFFF     00010000                PMCP
0001F000       0007AFFF     0005C000                CSE BUP Partition
0007B000       0007EFFF     00004000                uCode Partition
0007B040       0007EC3F     00003C00                    uCode Patch 1
0007F000       000F7FFF     00079000                IBB Partition
000F8000       000F9FFF     00002000                Debug Token Partition
000FA000       00200FFF     00107000            Secondary Boot Partition
000FA200       00200FFF     00106E00                CSE Main Partition
00380000       006FEFFF     0037F000        Boot Partition 2
00380000       003801FF     00000200            Primary Boot Partition
00380200       00481FFF     00101E00            Secondary Boot Partition
00381000       00481FFF     00101000                OBB Partition
006FF000       007FEFFF     00100000        TXE Data Region

More information about the coreboot mailing list