The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
This page contains some (developer) documentation about the Samsung Exynos5250 CPU.
The Exynos5250 public datasheet revision 1.00 is here.
The Exynos5 family system on chip (SoC) uses the Cortex-A15 implementation of the ARMv7 architecture.
The first mainboard target in coreboot with an Exynos processor is the Samsung XE303C12, also known as Snow. Specifically, it uses the Exynos5250. Since this is currently the only Exynos chip used in Coreboot, this wiki entry will focus on the Exynos5250.
The Exynos5250 currently uses a proprietary first-stage bootloader, called BL1, which does some very basic initialization and loads the next-stage bootloader (BL2) into SRAM. BL2 is coreboot.
BL1's primary purpose is to load BL2 into SRAM. It reads the state of the OM (operating mode) pins and can load BL2 from a variety of devices including MMC, USB, SPI, etc. In the process of doing so it also configures pin muxes.
There has been interest in the community for creating a FOSS version of BL1. Some effort has already gone into this and resulted in the util/runfw tool which is used for running the code in userspace Linux for deeper analysis.
The follow describes the boot flow for Snow along with corresponding sources to read (when applicable).
0. Masked ROM and BL1
The masked ROM (onboard the CPU itself) sets the boot media based on the OM pin strappings. BL1 occupies 8KB of physical ROM space beginning at offset 0 and contains some CPU-specific code for loading a full bootloader image (BL2, which is coreboot).
The masked ROM copies BL1 into SRAM (aka iRAM). Although BL1 is only 8KB in physical size, it is given 13KB to operate in memory. BL1 reads the OM pins again and loads BL2 into SRAM at offset 0x02023400.
For Snow, we use SPI ROM as the boot media / ROM for BL1 and BL2.
Assembly code which sets ARM chip in service mode, puts non-bootstrap CPU cores to sleep, initializes stack.
2. src/arch/armv7/bootblock_simple.c and src/mainboard/google/snow/bootblock.c
C code which does generic ARM cache setup, calls Exynos-specific and mainboard-specific bootblock routines, and jumps to romstage if necessary.
Currently, the exynos5250 bootblock code is a noop. The Snow bootblock code checks GPIOs to see what boot mode we are in. If we are resuming from idle (no DRAM init necessary), we simply jump to the resume vector which is stored in the inform0 register.
Set up PMIC, clocks, and RAM, jump to ramstage. x86 platforms will also copy ramstage code into DRAM at this point for the next stage, but the Exynos5250 CPU on the Snow mainboard has a large enough embedded SRAM which we continue to use for ramstage on this platform.
Set up MMU, framebuffer, exception handler, etc, and execute payload.