This page contains some (developer) documentation about the Samsung Exynos5250 CPU.
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.
The follow describes the boot flow for Snow along with corresponding files to read.
BL1 reads the OM state to know where to load BL2 from. For Snow, it it strapped to load BL2 (coreboot) from SPI. BL2 is placed at offset 0x4000 in SRAM.
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.