<div dir="ltr">Hi all,<div><br></div><div>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?</div><div><br></div><div>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).</div><div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><div>(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.</div><div><br></div><div>(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 

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">(not sure if this is necessary for first boot?)</span> </div><div><br></div><div>(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.</div><div><br></div><div>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.</div><div><br></div><div>Best regards,</div><div>Tahnia</div></div>