[coreboot] Adding new Intel SoC Apollo Lake

Petrov, Andrey andrey.petrov at intel.com
Sun Jan 24 08:15:16 CET 2016


Hello,

We have just pushed patches that add support for successor of Braswell, new SoC
Apollo Lake.

This is a minimal, barebones implementation that can run several payload and 
boot into Linux. Since new FSP 2.0 spec is not yet final we anticipate changes
in the FSP harness.

Notable changes compared to Braswell:

Booting
-------

Boot mechanism has changed. The hardware natively supports eMMC (SPI flash is
supported as well) as boot media. This is done with assistance of a minuteIA 
block called CSE. Early after powering on this block accesses boot media and
fetches 32KiB code block and puts it SRAM that is shared (read-only) with CPU.
This block is mapped at the bottom of 4 GiB address space. The bootblock code 
is supposed to set up CAR and utilize CSE services to copy media into CAR and
then continue execution in CAR. 

FSP 2.0
-------

Since eMMC can not be memory mapped it makes it impractical to implement 1.x
spec and new FSP 2.0 is introducted.

Notable differences from previous specifications:
- TempRamInit and TempRamExit are now optional
- Instead of big monster blob file, there are a several little bloblings called 
  FSP-T (CAR setup, BARs, early GPIOs), FSP-M (MemoryInit) and FSP-S 
  (SiliconInit)
- Blobs are expected to be run in CAR although xip is still possible 

Implementation notes
--------------------

This implementation uses memory-mapped SPI flash as boot media through media
driver abstraction. FSP blobs and romstage are executed entirely in CAR. There
is no execution-in-place. This makes it possible to add eMMC and other boot 
options either with CSE service or by adding driver into bootblock. We believe
it also reduces complexity associated with image creation.

In order to be able to run romstage in CAR and fit FSP 2.0 bootflow we had to
pay extra attention in our romstage-to-ramstage transition. In essence we had
to have memory caching enabled, run in the CAR and be able to teardown CAR at
the same time. We did our best to find an elegant solution that would also fit
nicely into coreboot boot flow model.

We found it somewhat difficult to use code from older FSP 1.x driver, so we 
wrote new one largely from scratch.

Since TempRamInit/TempRamExit are optional we build new shiny bootblock. It
setups CAR, uses minimal assembly, can run C code, does not depend on blobs,
comes with serial console and is pretty compact.

We look forward to work on integrating these changes.

Andrey Petrov on behalf on Intel CSS coreboot team.



More information about the coreboot mailing list