Commit a1d6dc3f authored by Simon Glass's avatar Simon Glass Committed by Bin Meng

x86: Add chromebook_coral

Add support for coral which is a range of Apollo Lake-based Chromebook
released in 2017. This also includes reef released in 2016, since it is
based on the same SoC.
Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng's avatarBin Meng <bmeng.cn@gmail.com>
parent 2153e8fb
Pipeline #1647 passed with stages
in 136 minutes and 52 seconds
......@@ -2,6 +2,7 @@
dtb-y += bayleybay.dtb \
cherryhill.dtb \
chromebook_coral.dtb \
chromebook_link.dtb \
chromebox_panther.dtb \
chromebook_samus.dtb \
......
This diff is collapsed.
......@@ -8,6 +8,20 @@ choice
prompt "Mainboard model"
optional
config TARGET_CHROMEBOOK_CORAL
bool "Chromebook coral"
help
This is a range of Intel-based laptops released in 2018. They use an
Intel Apollo Lake SoC. The design supports WiFi, 4GB to 16GB of
LPDDR4 1600MHz SDRAM, PCIe WiFi and Bluetooth, eMMC (typically 32GB),
up two cameras (front-facing 720p and another 5MP option), USB SD
reader, microphone and speakers. It also includes two USB 3 Type A and
two Type C ports. The latter are used as power input and can also
charge external devices as well as a 4K external display. There is a
Chrome OS EC connected on LPC, a Cr50 secure chip from Google and
various display options. OEMs products include Acer Chromebook 11
(e.g. C732, CB11, CP311) and Lenovo Chromebook (100e, 300e, 500e).
config TARGET_CHROMEBOOK_LINK
bool "Chromebook link"
help
......@@ -62,6 +76,7 @@ config TARGET_CHROMEBOOK_SAMUS_TPL
endchoice
source "board/google/chromebook_coral/Kconfig"
source "board/google/chromebook_link/Kconfig"
source "board/google/chromebox_panther/Kconfig"
source "board/google/chromebook_samus/Kconfig"
......
if TARGET_CHROMEBOOK_CORAL
config SYS_BOARD
default "chromebook_coral"
config SYS_VENDOR
default "google"
config SYS_SOC
default "apollolake"
config SYS_CONFIG_NAME
default "chromebook_coral"
config SYS_TEXT_BASE
default 0xffe00000
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select X86_RESET_VECTOR
select INTEL_APOLLOLAKE
select BOARD_ROMSIZE_KB_16384
config PCIE_ECAM_BASE
default 0xf0000000
config EARLY_POST_CROS_EC
bool "Enable early post to Chrome OS EC"
help
Allow post codes to be sent to the Chroem OS EC early during boot,
to enable monitoring of the boot and debugging when things go wrong.
With this option enabled, the EC console can be used to watch post
codes the first part of boot.
config SYS_CAR_ADDR
hex
default 0xfef00000
config SYS_CAR_SIZE
hex
default 0xc0000
endif
CHROMEBOOK_CORAL_BOARD
M: Simon Glass <sjg@chromium.org>
S: Maintained
F: board/google/chromebook_coral/
F: include/configs/chromebook_coral.h
F: configs/chromebook_coral_defconfig
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright 2019 Google LLC
obj-y += coral.o
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2019 Google LLC
*/
#include <common.h>
int arch_misc_init(void)
{
return 0;
}
/* This function is needed if CONFIG_CMDLINE is not enabled */
int board_run_command(const char *cmdline)
{
printf("No command line\n");
return 0;
}
CONFIG_X86=y
CONFIG_SYS_TEXT_BASE=0x1110000
CONFIG_SYS_MALLOC_F_LEN=0x3d00
CONFIG_SPL_SYS_MALLOC_F_LEN=0xf000
CONFIG_NR_DRAM_BANKS=8
CONFIG_BOOTSTAGE_STASH_ADDR=0xfef00000
CONFIG_DEBUG_UART_BOARD_INIT=y
CONFIG_DEBUG_UART_BASE=0xde000000
CONFIG_DEBUG_UART_CLOCK=1843200
CONFIG_VENDOR_GOOGLE=y
CONFIG_TARGET_CHROMEBOOK_CORAL=y
CONFIG_DEBUG_UART=y
CONFIG_FSP_VERSION2=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_INTEL_CAR_CQOS=y
CONFIG_X86_OFFSET_U_BOOT=0xffe00000
CONFIG_X86_OFFSET_SPL=0xffe80000
CONFIG_SPL_TEXT_BASE=0xfef10000
CONFIG_BOOTSTAGE=y
CONFIG_SPL_BOOTSTAGE=y
CONFIG_TPL_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=10
CONFIG_BOOTSTAGE_STASH=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro earlyprintk console=tty0 console=ttyS0,115200"
CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_SPL_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=7
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_LAST_STAGE_INIT=y
CONFIG_BLOBLIST=y
# CONFIG_TPL_BLOBLIST is not set
CONFIG_BLOBLIST_ADDR=0x100000
CONFIG_HANDOFF=y
CONFIG_TPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_CPU_SUPPORT=y
CONFIG_SPL_PCI=y
# CONFIG_SPL_SPI_FLASH_TINY is not set
CONFIG_HUSH_PARSER=y
CONFIG_CMD_CPU=y
CONFIG_CMD_PMC=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_GPIO=y
CONFIG_CMD_I2C=y
CONFIG_CMD_PART=y
CONFIG_CMD_READ=y
CONFIG_CMD_SATA=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_TIME=y
CONFIG_CMD_SOUND=y
CONFIG_CMD_BOOTSTAGE=y
CONFIG_CMD_TPM=y
CONFIG_CMD_TPM_TEST=y
CONFIG_CMD_EXT2=y
CONFIG_CMD_EXT4=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_MAC_PARTITION=y
# CONFIG_SPL_MAC_PARTITION is not set
# CONFIG_SPL_DOS_PARTITION is not set
CONFIG_ISO_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SPL_EFI_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="chromebook_coral"
# CONFIG_NET is not set
CONFIG_REGMAP=y
CONFIG_SYSCON=y
CONFIG_SPL_OF_TRANSLATE=y
CONFIG_CPU=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_DW=y
CONFIG_TPL_MISC=y
CONFIG_CROS_EC=y
CONFIG_CROS_EC_LPC=y
CONFIG_SPI_FLASH_WINBOND=y
# CONFIG_X86_PCH7 is not set
# CONFIG_X86_PCH9 is not set
CONFIG_PINCTRL=y
# CONFIG_SPL_PINCTRL_FULL is not set
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550=y
CONFIG_SOUND=y
CONFIG_SOUND_I8254=y
CONFIG_SOUND_RT5677=y
CONFIG_SPI=y
CONFIG_ICH_SPI=y
CONFIG_TPL_SYSRESET=y
CONFIG_TPM_TIS_LPC=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_STORAGE=y
CONFIG_USB_KEYBOARD=y
CONFIG_SPL_FS_CBFS=y
# CONFIG_SPL_USE_TINY_PRINTF is not set
CONFIG_TPL_USE_TINY_PRINTF=y
CONFIG_CMD_DHRYSTONE=y
CONFIG_TPM=y
# CONFIG_EFI_LOADER is not set
.. SPDX-License-Identifier: GPL-2.0+
.. sectionauthor:: Simon Glass <sjg@chromium.org>
Chromebook Coral
================
Coral is a Chromebook (or really about 20 different Chromebooks) which use the
Intel Apollo Lake platform (APL). The 'reef' Chromebooks use the same APL SoC so
should also work. Some later ones based on Glacier Lake (GLK) need various
changes in GPIOs, etc. but are very similar.
It is hoped that this port can enable ports to embedded APL boards which are
starting to appear.
Note that booting U-Boot on APL is already supported by coreboot and
Slim Bootloader. This documentation refers to a 'bare metal' port.
Boot flow - TPL
---------------
Apollo Lake boots via an IFWI (Integrated Firmware Image). TPL is placed in
this, in the IBBL entry.
On boot, an on-chip microcontroller called the CSE (Converged Security Engine)
sets up some SDRAM at ffff8000 and loads the TPL image to that address. The
SRAM extends up to the top of 32-bit address space, but the last 2KB is the
start16 region, so the TPL image must be 30KB at most, and CONFIG_TPL_TEXT_BASE
must be ffff8000. Actually the start16 region is small and it could probably
move from f800 to fe00, providing another 1.5KB, but TPL is only about 19KB so
there is no need to change it at present. The size limit is enforced by
CONFIG_TPL_SIZE_LIMIT to avoid producing images that won't boot.
TPL (running from start.S) first sets up CAR (Cache-as-RAM) which provides
larger area of RAM for use while booting. CAR is mapped at CONFIG_SYS_CAR_ADDR
(fef00000) and is 768KB in size. It then sets up the stack in the botttom 64KB
of this space (i.e. below fef10000). This means that the stack and early
malloc() region in TPL can be 64KB at most.
TPL operates without CONFIG_TPL_PCI enabled so PCI config access must use the
x86-specific functions pci_x86_write_config(), etc. SPL creates a simple-bus
device so that PCI devices are bound by driver model. Then arch_cpu_init_tpl()
is called to early init on various devices. This includes placing PCI devices
at hard-coded addresses in the memory map. PCI auto-config is not used.
Most of the 16KB ROM is mapped into the very top of memory, except for the
Intel descriptor (first 4KB) and the space for SRAM as above.
TPL does not set up a bloblist since at present it does not have anything to
pass to SPL.
Once TPL is done it loads SPL from ROM using either the memory-mapped SPI or by
using the Intel fast SPI driver. SPL is loaded into CAR, at the address given
by CONFIG_SPL_TEXT_BASE, which is normally fef10000.
Note that booting using the SPI driver results in an TPL image that is about
26KB in size instead of 19KB. Also boot speed is worse by about 340ms. If you
really want to use the driver, enable CONFIG_APL_SPI_FLASH_BOOT and set
BOOT_FROM_FAST_SPI_FLASH to true[2].
Boot flow - SPL
---------------
SPL (running from start_from_tpl.S) continues to use the same stack as TPL.
It calls arch_cpu_init_spl() to set up a few devices, then init_dram() loads
the FSP-M binary into CAR and runs to, to set up SDRAM. The address of the
output 'HOB' list (Hand-off-block) is stored into gd->arch.hob_list for parsing.
There is a 2GB chunk of SDRAM starting at 0 and the rest is at 4GB.
PCI auto-config is not used in SPL either, but CONFIG_SPL_PCI is defined, so
proper PCI access is available and normal dm_pci_read_config() calls can be
used. However PCI auto-config is not used so the same static memory mapping set
up by TPL is still active.
SPL on x86 always runs with CONFIG_SPL_SEPARATE_BSS=y and BSS is at 120000
(see u-boot-spl.lds). This works because SPL doesn't access BSS until after
board_init_r(), as per the rules, and DRAM is available then.
SPL sets up a bloblist and passes the SPL hand-off information to U-Boot proper.
This includes a pointer to the HOB list as well as DRAM information. See
struct arch_spl_handoff. The bloblist address is set by CONFIG_BLOBLIST_ADDR,
normally 100000.
SPL uses SPI flash to update the MRC caches in ROM. This speeds up subsequent
boots. Be warned that SPL can take 30 seconds without this cache! This is a
known issue with Intel SoCs with modern DRAM and apparently cannot be improved.
The MRC caches are used to work around this.
Once SPL is finished it loads U-Boot into SDRAM at CONFIG_SYS_TEXT_BASE, which
is normally 1110000. Note that CAR is still active.
Boot flow - U-Boot pre-relocation
---------------------------------
U-Boot (running from start_from_spl.S) starts running in RAM and uses the same
stack as SPL. It does various init activities before relocation. Notably
arch_cpu_init_dm() sets up the pin muxing for the chip using a very large table
in the device tree.
PCI auto-config is not used before relocation, but CONFIG_PCI of course is
defined, so proper PCI access is available. The same static memory mapping set
up by TPL is still active until relocation.
As per usual, U-Boot allocates memory at the top of available RAM (a bit below
2GB in this case) and copies things there ready to relocate itself. Notably
reserve_arch() does not reserve space for the HOB list returned by FSP-M since
this is already located in RAM.
U-Boot then shuts down CAR and jumps to its relocated version.
Boot flow - U-Boot post-relocation
---------------------------------
U-Boot starts up normally, running near the top of RAM. After driver model is
running, arch_fsp_init_r() is called which loads and runs the FSP-S binary.
This updates the HOB list to include graphics information, used by the fsp_video
driver.
PCI autoconfig is done and a few devices are probed to complete init. Most
others are started only when they are used.
Note that FSP-S is supposed to run after CAR has been shut down, which happens
immediately before U-Boot starts up in its relocated position. Therefore we
cannot run FSP-S before relocation. On the other hand we must run it before
PCI auto-config is done, since FSP-S may show or hide devices. The first device
that probes PCI after relocation is the serial port, in initr_serial(), so FSP-S
must run before that. A corollary is that loading FSP-S must be done without
using the SPI driver, to avoid probing PCI and causing an autoconfig, so
memory-mapped reading is always used for FSP-S.
It would be possible to tear down CAR in SPL instead of U-Boot. The SPL handoff
information could make sure it does not include any pointers into CAR (in fact
it doesn't). But tearing down CAR in U-Boot allows the initial state used by TPL
and SPL to be read by U-Boot, which seems useful. It also matches how older
platforms start up (those that don't use SPL).
Performance
-----------
Bootstage is used through all phases of U-Boot to keep accurate timimgs for
boot. Use 'bootstage report' in U-Boot to see the report, e.g.:
Timer summary in microseconds (16 records):
Mark Elapsed Stage
0 0 reset
155,325 155,325 TPL
204,014 48,689 end TPL
204,385 371 SPL
738,633 534,248 end SPL
739,161 528 board_init_f
842,764 103,603 board_init_r
1,166,233 323,469 main_loop
1,166,283 50 id=175
Accumulated time:
62 fast_spi
202 dm_r
7,779 dm_spl
15,555 dm_f
208,357 fsp-m
239,847 fsp-s
292,143 mmap_spi
CPU performance is about 3500 DMIPS:
=> dhry
1000000 iterations in 161 ms: 6211180/s, 3535 DMIPS
Partial memory map
------------------
ffffffff Top of ROM (and last byte of 32-bit address space)
ffff8000 TPL loaded here (from IFWI)
ff000000 Bottom of ROM
fefc000 Top of CAR region
fef96000 Stack for FSP-M
fef40000 59000 FSP-M
fef11000 SPL loaded here
fef10000 CONFIG_BLOBLIST_ADDR
fef10000 Stack top in TPL, SPL and U-Boot before relocation
fef00000 1000 CONFIG_BOOTSTAGE_STASH_ADDR
fef00000 Base of CAR region
f0000 CONFIG_ROM_TABLE_ADDR
120000 BSS (defined in u-boot-spl.lds)
200000 FSP-S (which is run after U-Boot is relocated)
1110000 CONFIG_SYS_TEXT_BASE
Supported peripherals
---------------------
- UART
- SPI flash
- Video
- MMC (dev 0) and micro-SD (dev 1)
- Chrome OS EC
- Keyboard
- USB
To do
-----
- Finish peripherals
- left-side USB
- USB-C
- Cr50 (security chip: a basic driver is running but not included here)
- I2C (driver exists but not enabled in device tree)
- Sound (Intel I2S support exists, but need da7219 driver)
- RTC (driver exists but not enabled in device tree)
- Various minor features supported by LPC, etc.
- Booting Chrome OS, e.g. with verified boot
- Integrate with Chrome OS vboot
- Improvements to booting from coreboot (i.e. as a coreboot target)
- Use FSP-T binary instead of our own CAR implementation
- Use the official FSP package instead of the coreboot one
- Enable all CPU cores
- Suspend / resume
- ACPI
Credits
-------
This is a spare-time project conducted slowly over a long period of time.
Much of the code for this port came from Coreboot, an open-source firmware
project similar to U-Boot's SPL in terms of features.
Also see [2] for information about the boot flow used by coreboot. It is
similar, but has an extra postcar stage. U-Boot doesn't need this since it
supports relocating itself in memory.
[2] Intel PDF https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf
......@@ -6,5 +6,6 @@ Google
.. toctree::
:maxdepth: 2
chromebook_coral
chromebook_link
chromebook_samus
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Copyright 2019 Google LLC
*/
/*
* board/config.h - configuration options, board-specific
*/
#ifndef __CONFIG_H
#define __CONFIG_H
#define CONFIG_BOOTCOMMAND \
"fatload mmc 1:c 1000000 syslinux/vmlinuz.A; zboot 1000000"
#include <configs/x86-common.h>
#include <configs/x86-chromebook.h>
#undef CONFIG_STD_DEVICES_SETTINGS
#define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,i8042-kbd,serial\0" \
"stdout=vidconsole,serial\0" \
"stderr=vidconsole,serial\0"
#define CONFIG_ENV_SECT_SIZE 0x1000
#define CONFIG_ENV_OFFSET 0x003f8000
#define CONFIG_TPL_TEXT_BASE 0xffff8000
#define CONFIG_SYS_NS16550_MEM32
#undef CONFIG_SYS_NS16550_PORT_MAPPED
#endif /* __CONFIG_H */
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment