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
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
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
