[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
attached).
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
manufacturing.
(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,
Tahnia
-------------- 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