The x86 development process for coreboot is broken into the following components:
The development process has two main phases:
The combined steps below describe how to bring up a minimal coreboot for a system-on-a-chip (SoC) and a development board:
The initial coreboot steps are single threaded! The initial minimal FSP development is also single threaded. Progress can speed up by adding more developers after the minimal coreboot/FSP implementation reaches the payload. |
sudo apt-get install m4 bison flex libncurses5-dev
make crossgcc-i386
To use multiple processors for the toolchain build (which takes a long time), use:
make crossgcc-i386 CPUS=N
where N is the number of cores to use for the build.
Most of the coreboot development gets done in this phase. Implementation tasks in this phase are easily done in parallel.
Features |
||
---|---|---|
SoC | Where | Testing |
Cache-as-RAM |
Find
FSP binary:
cache_as_ram.inc Enable: FSP 1.1 TempRamInit called from cache_as_ram.inc Disable: FSP 1.1 TempRamExit called from after_raminit.S |
FindFSP: POST code 0x90
(POST_FSP_TEMP_RAM_INIT)
is displayed Enable: POST code 0x2A is displayed Disable: CONFIG_DISPLAY_MTRRS=y, MTRRs displayed after call to TempRamExit |
Memory Map | Implement a device driver for the north cluster | coreboot displays the memory map correctly during the BS_WRITE_TABLES state |
PCI Device Support | Implement a PCI device driver | The device is detected by coreboot and usable by the payload |
Ramstage state machine | Implement the chip and domain operations to start the device tree processing | During the BS_DEV_ENUMERATE state, ramstage now display the device IDs for the PCI devices on the bus. |
Board | Where | Testing |
Device Tree |
List PCI vendor and device IDs by starting
the device tree processing Disable PCI devices Enable: Implement a PCI device driver |
List: BS_DEV_ENUMERATE state displays PCI vendor and device IDs Disable: BS_DEV_ENUMERATE state shows the devices as disabled Enable: BS_DEV_ENUMERATE state shows the device as on and the device works for the payload |
DRAM |
Load SPD data: src/soc/mainboard/<Vendor>/<Board>/spd/spd.c UPD Setup:
|
Select the following Kconfig values
|
Serial Port |
SoC Support Enable: src/soc/mainboard/<Board>/com_init.c/car_mainboard_pre_console_init |
Debug serial output works |
Payload | Where | Testing |
ACPI Tables |
SoC Support |
Verified by payload or OS |
FSP | Where | Testing |
TempRamInit | FSP TempRamInit | FSP binary found: POST code 0x90
(POST_FSP_TEMP_RAM_INIT)
is displayed TempRamInit successful: POST code 0x2A is displayed |
MemoryInit | SoC support Board support |
Select the following Kconfig values
|
TempRamExit | src/drivers/intel/fsp1_1/after_raminit.S | Post code 0x91
(POST_FSP_TEMP_RAM_EXIT)
is displayed before calling TempRamExit by
after_raminit.S,
CONFIG_DISPLAY_MTRRS=y displays the correct memory regions and
Post code 0x39 is displayed by
after_raminit.S |
SiliconInit | Implement the .init routine for the chip operations structure | During BS_DEV_INIT_CHIPS state, SiliconInit gets called and returns 0x00000000 |
FspNotify | The code which calls FspNotify is located in src/drivers/intel/fsp1_1/fsp_util.c. The fsp_notify_boot_state_callback routine is called three times as specified by the BOOT_STATE_INIT_ENTRY macros below the routine. |
The FspNotify routines are called during:
|
Modified: 20 February 2016