There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
Patch 'coreboot_tables: reduce redundant data structures' (1f5487a)
added a new lb_range structure to coreboot and libpayload but the
original chromium patch added cb_range to libpayload instead. A followup
patch 'arm: libpayload: Add cache coherent DMA memory definition
and management' (b8fad3d) used the incorrect cb_range structure but
this wasn't caught since the current verification build doesn't
build libpayload for arm.
Change-Id: I7cedc66a4794bf4daa214f54be6e917f96418ff6
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6665
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow and Pit
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
(cherry picked from commit d142ccdcd902a9d6ab4d495fbe6cbe85c61a5f01)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are three coreboot table tags that all define some kind of memory
region, and each has their own homologous struct. I'm about to add a
fourth so I'll just clean this up and turn it into a generic struct
lb_range instead.
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
(cherry picked from commit 22d82ffa3f5500fbc1b785e343add25e61f4f194)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6456
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The address range to scan for the coreboot tables varies from machine to
machine based on the range memory occupies on the SOC being booted and on the
amount of memory installed on the machine. To make libpayload work on
different ARM systems with different needs, this change makes the region to
scan configurable. In the future, we might want to come up with a more
automatic mechanism like on x86, although there's less consistency on ARM as
far as what ranges are even memory in the first place.
Change-Id: Ib50efe25a6152171b0fbd0e324dbc5e89c527d6e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59242
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Otherwise the code would try to parse GPIOs when encountering
a mainboard entry in the coreboot table. This never caused any
problems because the mainboard entry is parsed before the GPIO
entry.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1443bda8585a990a39115743d48304ec4b54bccb
Reviewed-on: https://gerrit.chromium.org/gerrit/59292
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Change-Id: I3235f42c7faaf28a63455162ea55dc1a6bebd1f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Hung-Te Lin <hungte@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48290
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
After another incident related to virtual pointers in lib_sysinfo (and
resulting confusion), I decided to put some comments on the matter into
the code.
Remember, we decided to always use virtual pointers in lib_sysinfo, but
it's not always obvious from the code, that they are.
See also:
425973c libpayload: Always use virtual pointers in struct sysinfo_t
593f577 libpayload: Fix use of virtual pointers in sysinfo
Change-Id: I886c3b1d182cba07f1aab1667e702e2868ad4b68
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/2878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These live at the bottom of memory on x86, but that's IO mapped on the exynos.
The particular range used will likely need to be configurable, but this will
make it work in one more case than it used to.
Change-Id: I4d4963b9732cf538d00f8effb4398f30cbbde6aa
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2410
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This compiles, but it's not tested yet.
Change-Id: I2f73a814649aa36c39af3e77cefd8a968671f5c0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2035
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Gabe Black