Difference between revisions of "Exynos5"

From coreboot
Jump to: navigation, search
Line 5: Line 5:
== Documentation ==
== Documentation ==
The Exynos5250 public datasheet revision 1.00-0 is [http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV1.00-0.pdf here].
The Exynos5250 public datasheet revision 1.00 is [http://www.samsung.com/global/business/semiconductor/file/product/Exynos_5_Dual_User_Manaul_Public_REV1.00-0.pdf here].
== Basics ==
== Basics ==

Revision as of 23:44, 2 May 2013

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.

Boot flow

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.

1. src/arch/armv7/bootblock.inc

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.

3. src/mainboard/google/snow/romstage.c

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.

4. src/mainboard/google/snow/ramstage.c

Set up MMU, framebuffer, exception handler, etc, and execute payload.