| Age | Commit message (Collapse) | Author |
|---|
|
Splitting the version prompt satisfies some requirements ROMCC
sets for the order in which we include source files. Also GDB
stub will need console hardware before entering main().
Change-Id: Ibb445a2f8cfb440d9dd69cade5f0ea41fb606f50
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5331
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This patch implements the basic infrastructure required to use the USB
A-A firmware upload feature on Exynos5 processors with Coreboot. It will
require a corresponding host-side script that activates the feature and
uploads the correct image parts in the correct order to harcoded target
addresses, as described in the comments of alternate_cbfs.c.
Also fixes a bug in the Google Snow mainboard where it would not
correctly initialize the pinmux configuration for the SPI flash bus.
During a normal SPI boot the IROM would already do that for you, but
when booting from USB you have to do it yourself.
Change-Id: I40a39f8f5d1d70b58dbf258015c1653a27097d67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64875
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4456
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This adds new MMU setup code. Most notably, this version uses
cbmem_add() to determine the translation table base address, which
in turn is necessary to ensure payloads which wipe memory can tell
which regions to wipe out.
TODOs:
- Finish cleaning up references to old cache/MMU stuff
- Add L2 setup (from exynos_cache.c)
- Set up ranges dynamically rather than in ramstage's main().
Change-Id: Iba5295a801e8058a3694e4ec5b94bbe9a69d3ee6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2877
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This just moves cache maintenance stuff from the armv7 bootblock
code to cache.c
Change-Id: I0b3ab58a1d8a3fe3d9568e02e156a36b6f33ca0b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2867
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This adds a new API for cache maintenance operations. The idea is
to be more explicit about operations that are going on so it's easier
to manage branch predictor, cache, and TLB cleans and invalidations.
Also, this adds some operations that were missing but required early
on, such as branch predictor invalidation. Instruction and sync
barriers were wrong earlier as well since the imported API assumed
we compield with -march=armv5 (which we don't) and was missing
wrappers for the native ARMv7 ISB/DSB/DMB instructions.
For now, this is a start and it gives us something we can easily use
in libpayload for doing things like cleaning and invalidating dcache
when doing DMA transfers.
TODO:
- Set cache policy explicitly before re-enabling. Right now it's left
at default.
- Finish deprecating old cache maintenance API.
- We do an extra icache/dcache flush when going from bootblock to
romstage.
Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Use same console initialization procedure for all ARM stages (bootblock,
romstage, and ramstage):
#include <console/console.h>
...
console_init()
...
printk(level, format, ...)
Verified to boot on armv7/snow with console messages in all stages.
Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
For ARM platform, the bootblock may need more C source files to initialize
UART / SPI for loading romstage. To preventing making complex and implicit
dependency by using #include inside bootblock.c, we should add a new build class
"bootblock".
Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled
for boot block.
For x86, the bootblock is limited to fewer assembly files so it's not using this
class. (Some files shared by x86 and arm in top level or lib are also changed
but nothing should be changed in x86 build process.)
Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
This replaces the current stage-specific exit/entry functions with
generic versions. Now all stages compile with stage_entry(), which
is placed at .text.stage_entry.armv7, and stage_exit().
Snow's ramstage files are also updated to avoid build breakage.
Change-Id: I953a2c4b8121bd4b66c3362557997a9ca3aa53b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This replaces the call() function with a stub which is compiled
separately using -marm. See http://review.coreboot.org/#/c/2175/
for details.
Change-Id: I7f8c45b5e63ec97b0a82294488129d1c97ec0cbf
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2180
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This patch does a few things to get us into romstage:
- Add romstage as a stage (a later patch adds it as a binary, which
is probably wrong). The Makefile magic is complex enough that we
let it build the XIP file for now, but we no longer use it.
- Replace findstage with loadstage. Loadstage will find a stage,
load the code to memory, and zero the remaining part of memory.
Now we can link the romstage to go anywhere!
- Eliminate magic offsets from code/ldscripts and centralize Kconfig
variables in src/cpu/samsung/exynos5250/Kconfig.
- Tidy up code and serial output
Change-Id: Iae4d2f9e7f429cb1df15d49daf9a08b88d75d79d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2174
Tested-by: build bot (Jenkins)
|
|
This is the bloated Snow bootblock which includes:
- SPI driver
- UART, including requisite I2C, Maxim PMIC, and clock config code.
- Adjustments for magic offsets (id section, stack pointer address)
This is just a temporary solution until we have romstage loading.
Once that happens, we'll rip out all but the code necessary for
copying SPI ROM content into SRAM.
Change-Id: I2a11e272eb9b6f626b5d9783eabb4a720a1d06be
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This lays out the groundwork for using a proper bootblock on ARM.
Currently we bypass the bootblock entirely and go straight to
romstage. However we want to utilize CBFS to maximize flexibility
of placing code without relying on a lot of magic numbers which
will break depending on the SoC in use.
Change-Id: I9cc2a8191d2db38b27b6363ba673e5a360de9684
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The first ARMv7 CPU we're going to support is the Exynos 5250
used in the Google Snow ChromeBook.
Change-Id: I4de8433bbc6202eb8fef2556a11186a3376d411b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2004
Tested-by: build bot (Jenkins)
|
