| Age | Commit message (Collapse) | Author |
|---|
|
This patch changes the way coreboot builds ARM TF to pass the new
COREBOOT flag introduced with the following pull request:
https://github.com/ARM-software/arm-trusted-firmware/pull/1193
Since the new coreboot support code supports the CBMEM console, we need
to always enable LOG_LEVEL INFO. Supporting platforms will parse the
coreboot table to conditionally enable the serial console only if it was
enabled in coreboot as well.
Also remove explicit cache flushes of some BL31 parameters. Turns out we
never really needed these because we already flush the whole cache when
disabling the MMU, and we were already not doing it for most parameters.
Change-Id: I3c52a536dc6067da1378b3f15c4a4d6cf0be7ce7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/23558
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Submodule 3rdparty/arm-trusted-firmware 236c27d21f..3944adca59
This brings in 241 new commits from the upstream arm-trusted-firmware
repository, merged to the upstream tree between December 30, 2016 and
March 18, 2017.
3944adca Merge pull request #861 from soby-mathew/sm/aarch32_fixes
..
e0f083a0 fiptool: Prepare ground for expanding the set of images at
runtime
Also setup ATF builds so that unused functions don't break the build.
They're harmless and they don't filter for these like we do.
Change-Id: Ibf5bede79126bcbb62243808a2624d9517015920
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Due to an unfortunate race between adding verstage support and reverting
an earlier hack that disabled the optimized assembly versions of
memcpy(), memmove() and memset() on ARM64, it seems that we never
enabled the optimized code for the verstage. This should be fixed so
that all stages use the same architecture support code.
Change-Id: I0bf3245e346105492030f4b133729c4d11bdb3ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18976
Tested-by: build bot (Jenkins)
|
|
- Remove warnings about code using deprecated declarations such as:
plat/mediatek/mt8173/bl31_plat_setup.c: In function 'bl31_platform_setup':
plat/mediatek/mt8173/bl31_plat_setup.c:175:2: warning:
'arm_gic_setup' is deprecated [-Wdeprecated-declarations]
include/drivers/arm/arm_gic.h:44:6: note: declared here:
void arm_gic_setup(void) __deprecated;
- Disable pedantic warnings to get rid of these warnings:
In file included from plat/mediatek/mt8173/bl31_plat_setup.c:36:0:
plat/mediatek/mt8173/include/mcucfg.h:134:21: error:
enumerator value for 'MP1_CPUCFG_64BIT' is not an integer constant
expression [-Werror=pedantic]
MP1_CPUCFG_64BIT = 0xf << MP1_CPUCFG_64BIT_SHIFT
Change-Id: Ibf2c4972232b2ad743ba689825cfe8440d63e828
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17995
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
We rely on gnu make, so we can expect the jobserver to be around in
parallel builds, too. Avoids some make warnings and slightly speeds up
the build if those sub-makes are executed (eg for arm-trusted-firmware
and vboot).
Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/18263
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
coreboot's build system picks up the BL31 image as an ELF from the ARM
Trusted Firmware submodule and inserts it into CBFS. However, the
generic 'bl31' build target we run in the ARM Trusted Firmware build
system also generates a raw bl31.bin binary file.
We don't need that binary, and with the recently added support for
multiple non-contiguous program segments in BL31 it can grow close to
4GB in size (by having one section mapped near the start and one near
the end of the address space). To avoid clogging up people's hard drives
with 4GB of zeroes, let's only build the target we actually need.
BRANCH=gru
BUG=chrome-os-partner:56314,chromium:661124
TEST=FEATURES=noclean emerge-kevin coreboot, confirm that there's no
giant build/3rdparty/arm-trusted-firmware/bl31.bin file left in the
build artifacts, and that we still generate .d prerequisite files.
Change-Id: I8e7bd50632f7831cc7b8bec69025822aec5bad27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 31699820f4c36fd441a3e7271871af4e1474129f
Original-Change-Id: Iaa073ec11dabed7265620d370fcd01ea8c0c2056
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/407110
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17380
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e
Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376849
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It isn't used anymore.
Change-Id: Ie554d1dd87ae3f55547466e484c0864e55c9d102
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14567
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
On non-x86 platforms, coreboot uses the memlayout.ld mechanism to
statically allocate the different memory regions it needs and guarantees
at build time that there are no dangerous overlaps between them. At the
end of its (ramstage) execution, however, it usually loads a payload
(and possibly other platform-specific components) that is not integrated
into the coreboot build system and therefore cannot provide the same
overlap guarantees through memlayout.ld. This creates a dangerous memory
hazard where a new component could be loaded over memory areas that are
still in use by the code-loading ramstage and lead to arbitrary memory
corruption bugs.
This patch fills this gap in our build-time correctness guarantees by
adding the necessary checks as a new intermediate Makefile target on
route to assembling the final image. It will parse the memory footprint
information of the payload (and other platform-specific post-ramstage
components) from CBFS and compare it to a list of memory areas known to
be still in use during late ramstage, generating a build failure in case
of a possible hazard.
BUG=chrome-os-partner:48008
TEST=Built Oak while moving critical regions in the way of BL31 or the
payload, observing the desired build-time errors. Built Nyan, Jerry and
Falco without issues for good measure.
Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13949
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Update ATF codebase to a version that supports passing a timestamp and
fix the format to what it accepts now (including quotes).
This provides reproducible builds.
Change-Id: I12a0a2ba1ee7921ad93a3a877ea50309136ab1ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13726
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If coreboot's build process is reproducible (eg. using the latest git
timestamp as source), bl31 is, too.
This requires an arm-trusted-firmware side merge first (in progress) and
an update of our reference commit for the submodule, but it also doesn't
hurt anything because it merely sets a variable that currently goes
unused.
Change-Id: If139538a2fab5b3a70c67f4625aa2596532308f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13497
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
There were several spots in the tree where the path to a per class
object file was hardcoded. To make use of the src-to-obj macro for
this, it had to be moved before the inclusion of subdirs. Which is
fine, as it doesn't have dependencies beside $(obj).
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add more code to verstage
[pg: split downstream commit into multiple commits]
Change-Id: I578a69a1e43aad8c90c3914efd09d556920f728e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2827aa08ff8712c0245a22378f3ddb0ca054255d
Original-Change-Id: I94a9ee2c00e25a37a92133f813d0cd11a3503656
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292662
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12612
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of having to remember to strip the quotes everywhere so that
string comparisons (of which there are a few) match up, do it right at
the beginning.
Fixes building the image with a .config where CONFIG_CBFS_PREFIX
contains quotes.
Change-Id: I4d63341cd9f0bc5e313883ef7b5ca6486190c124
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12578
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
This patch removes the old arm64/stage_entry.S code that was too
specific to the Tegra SoC boot flow, and replaces it with code that
hides the peculiarities of switching to a different CPU/arch in ramstage
in the Tegra SoC directories.
BRANCH=None
BUG=None
TEST=Built Ryu and Smaug. !!!UNTESTED!!!
Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12078
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The existing arm64 architecture code has been developed for the Tegra132
and Tegra210 SoCs, which only start their ARM64 cores in ramstage. It
interweaves the stage entry point with code that initializes a CPU (and
should not be run again if that CPU already ran a previous stage). It
also still contains some vestiges of SMP/secmon support (such as setting
up stacks in the BSS instead of using the stage-peristent one from
memlayout).
This patch splits those functions apart and makes the code layout
similar to how things work on ARM32. The default stage_entry() symbol is
a no-op wrapper that just calls main() for the current stage, for the
normal case where a stage ran on the same core as the last one. It can
be overridden by SoC code to support special cases like Tegra.
The CPU initialization code is split out into armv8/cpu.S (similar to
what arm_init_caches() does for ARM32) and called by the default
bootblock entry code. SoCs where a CPU starts up in a later stage can
call the same code from a stage_entry() override instead.
The Tegra132 and Tegra210 code is not touched by this patch to make it
easier to review and validate. A follow-up patch will bring those SoCs
in line with the model.
BRANCH=None
BUG=None
TEST=Booted Oak with a single mmu_init()/mmu_enable(). Built Ryu and
Smaug.
Change-Id: I28302a6ace47e8ab7a736e089f64922cef1a2f93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12077
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Since, SMP support is removed for ARM64, there is no need for CPU
initialization to be performed via device-tree.
Change-Id: I0534e6a93c7dc8659859eac926d17432d10243aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/11913
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
As ARM Trusted Firmware is the only first class citizen for
booting arm64 multi-processor in coreboot remove SMP
support. If SoCs want to bring up MP then ATF needs to be
ported and integrated.
Change-Id: Ife24d53eed9b7a5a5d8c69a64d7a20a55a4163db
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/11909
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
As ARM Trusted Firmware is the only first class citizen for
booting arm64 multi-processor in coreboot remove spintable
support. If SoCs want to bring up MP then ATF needs to be
ported and integrated.
Change-Id: I1f38b8d8b0952eee50cc64440bfd010b1dd0bff4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11908
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
It's been decided to only support ARM Trusted Firmware for
any EL3 monitor. That means any SoC that requires PSCI
needs to add its support for ATF otherwise multi-processor
bring up won't work.
Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11897
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
For vboot1 there was an rmodule that was loaded and ran to
do the firmware verification. That's no longer used so remove
the last vestiges of VBOOT_STUB.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I6b41544874bef4d84d0f548640114285cad3474e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add an LDFLAGS_common variable and use that for each stage
during linking within all the architectures. All the architectures
support gc-sections, and as such they should be linking in the
same way.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage.
Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11522
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
The src/lib/timestamp.c already has an implementation using
timer_monotonic_get() for timestamp_get(). Use that instead
of duplicating the logic.
BUG=chrome-os-partner:44669
BRANCH=None
TEST=None
Change-Id: If17be86143f217445bd64d67ceee4355fa482d39
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11468
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Fix following compilation error.
LINK cbfs/fallback/verstage.debug
/bin/sh: verstage-objs: command not found
/usr/x86_64-pc-linux-gnu/aarch64-cros-linux-gnu/binutils-bin/2.24/ld.bfd.real: warning: cannot find entry symbol stage_entry; defaulting to 00000000000d7000
BRANCH=chromeos-2015.07
BUG=none
TEST=emerge-oak coreboot
Change-Id: I30e4c43625b2d1d076f24e8c2639ce951839661b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 2a8936cdf34d315f580819df682335b2998f044f
Original-Change-Id: I9afd57a5a868a348dff2c66cad0a8a09cdb2e911
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292557
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11402
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Even if DEBUG=0, BL31 puts NOTICE(..) messages on serial console. Set
LOG_LEVEL=0 if coreboot does not use serial.
BUG=None
BRANCH=None
TEST=Compiles successfully and no console output from bl31 for
production images.
Change-Id: Ie77bcac3e2a0d314545b6811327c413536c77fb9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e8e3bcbf6249c80850a87dd66f34d3ff36158641
Original-Change-Id: I1415a3816cd2fa9dd05bcbd36ac0abc3f2759960
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/286150
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/11014
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
The arm-trusted-firmware build system may not create the final bl31.elf file
atomically, confusing our make to try to use it before it's ready.
Hence insert a (hopefully, but not guaranteed to be atomic) file move.
Change-Id: Iffc80467e0f4bbc96fc62414d4abfaa7b42634f4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10700
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Add support for loading secure os and pass its entrypoint as bl32 params
to bl31 stage.
BUG=chrome-os-partner:40713
BRANCH=None
TEST=Compiles successfully and loads secure os
Change-Id: I1409ccb7344c1d1b1ddc2b321fdae1beea2f823d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d3dc19025ff11c1e0590306230df7654ef9ad086
Original-Change-Id: Iafd540bf2906d10b5ee009e96179121fecbf5e11
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10693
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit 00263d0d8ee23bbe60ea359ea9cb33d551688980
to reintroduce optimized string handling functions.
BUG=chrome-os-partner:41185
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt on Smaug
Change-Id: I47f8d8afa5c9ff3fca67d4d0f393336fef03402b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eeb38afea828a2727d815e4fb5762cfdd09a2b3a
Original-Change-Id: Id053cbcea8b5e7ae29bdd6bb8b6f5e5011c42b00
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/275865
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10564
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The EARLY_CONSOLE Kconfig symbol was removed in
commit 48713a1b - console: Drop EARLY_CONSOLE option
The arm64 and mips directories don't even have early_console.c
to include.
Change-Id: Idc60ffb2bac2b180f4fdd0adf5c411e1f692a846
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10615
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Each SoC should have a BL31_MAKEARGS += ... defining all the make
arguments required for bl31 component compilation.
BUG=chrome-os-partner:40414
BRANCH=None
TEST=Compiles successfully and boots into bl31.
Change-Id: I20383ab61d012f7294d969f196044a5f1c07dfc1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 72bd297994248a9d96acc6f21d06bb6ff0d5292c
Original-Change-Id: I1ddd5c38e9214021d857d9d586310e23fa4114e0
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272430
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10309
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
BUG=chrome-os-partner:40414
BRANCH=None
TEST=ATF compilation successful
Change-Id: Ib4eeced911181f756bd47c19eeb2d196ab5a0a2f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3061a219c24294a9fec4f26fc60b02f67bb55d66
Original-Change-Id: I39849d4048d7333eeab9bd698b4fd496181081a2
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272374
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10307
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Intermediate linking may distort linker behavior (in particular related to
weak symbols). The idea is that archives are closer to 'just a list of
object files', and ideally makes the linker more predictable.
Using --whole-archive, the linker doesn't optimize out object files just
because their symbols were already provided by weak versions. However it
shouldn't be used for libgcc, because that one has some unexpected side-effects.
Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10139
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
This patch adds support for integrating the runtime-resident component
of ARM Trusted Firmware (github.com/ARM-software/arm-trusted-firmware)
called BL31. It expects the ARM TF source tree to be checked out under
$(top)/3rdparty/arm-trusted-firmware, which will be set up in a later
patch.
Also include optional support for VBOOT2 verification (pretty hacky for
now, since CBFSv1 is just around the corner and will make all this so
much better).
BRANCH=None
BUG=None
TEST=Booted Oak with ARM TF and working PSCI (with additional platform
patches).
Change-Id: I8c923226135bdf88a9a30a7f5ff163510c35608d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a1b3b2d56b25bfc1f3b2d19bf7876205075a987a
Original-Change-Id: I0714cc10b5b10779af53ecbe711ceeb89fb30da2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270784
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10249
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Rename Kconfig options for secmon and spintable to be prefixed with
ARM64_ instead of ARCH_, which seems to be the standard throughout the
rest of coreboot (e.g. ARM_LPAE or X86_BOOTBLOCK_SIMPLE). I think this
provides a clearer separation between generic options that are selected
by the architecture (e.g. a hypothetical ARCH_HAS_FEATURE_X similar to
some of the MAINBOARD_HAS_... we have) and options that only make sense
in the context of a single architecture.
Change-Id: I38c2efab833f252adbb7b61ef0af60ab25b768b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e
Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10242
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Remove the secmon Kconfig guard from Makefiles that add to the secmon
class since they are redundant (the class is simply not used when
compiling without secmon) to improve readability/ease-of-use.
[pg: taken out of the patch linked below]
Change-Id: I2f0ad8a923ca32fcade748ac8ee50c23cf9bafb9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e
Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10241
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The linker scripts are added to stage objs so remove those
from the object lists. boot.c will be needed to link verstage
properly.
Change-Id: Ib8427fe015b72e2282219f116a39949739a0af48
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10150
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This slightly streamlines integrating the vboot2 library and
prepares for merging verstage and bootblock on selected devices.
Change-Id: I2163d1411d0c0c6bf80bce64796e1b6a5a02b802
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10004
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Call arm64_cpu_early_setup to allow cpu-specific initialization to be
performed. Also, add support for setting SMPEN bit for cortex a57
within arm64_cpu_early_setup.
BUG=chrome-os-partner:38222
BRANCH=None
TEST=Compiles successfully and SMP works for foster
Change-Id: Ifa4e6134dbce3ad63046b3dd9b947c3d9134d5e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fe0eac5f416efcf9f7b05388a17444205a8352c0
Original-Change-Id: I28a05a20e6adf084cd0bf94bdd0c3b492632107c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/262993
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9977
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Change-Id: Ia4ca0e7d35c0738dbbaa926cce4268143c6f9de3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9f5e78469313ddd144ad7cf5abc3e07cb712183a
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Original-Reviewed-on: https://chromium-review.googlesource.com/231561
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9540
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to dynamically allocate structures based on
affinity levels add malloc() support.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted to kernel.
Change-Id: I40cbd8497a1599db12b9e87eeb379f7dcd21c9b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9cd2b23c2ea045b5832b3d838e29f4b6a1b6cdfb
Original-Change-Id: Ie1412a3a9eb07689059a2cd69bd111274bcb88fa
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226482
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9389
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
BUG=chrome-os-partner:32973
BRANCH=None
TEST=Compiles successfully
Change-Id: Ia4715fd7a852b82c66d436eb12988f8e3290b9b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0d88dd324a8ee0ace51e9ad2343d81cc828a4f34
Original-Change-Id: I662163848a772018f1e8eb003aa3d3bc06e80e98
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223347
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9359
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This stage is not tested on any hardware.
BUG=None
BRANCH=None
TEST=Compiles successfully for rush_ryu and veyron_pinky
Original-Change-Id: I6dd266471c815895bb3dd53d34aacc8fe825eeb6
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/221911
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 907ea2d1f8c9f01d815e8673695dd5271322c7a8)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I617a742d4a387be947086dae33e9a913f742a8d1
Reviewed-on: http://review.coreboot.org/9255
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This allows combining and simplifying linker scripts.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The prog_run() function abstracts away what is required
for running a given program. Within it, there are 2
calls: 1. platform_prog_run() and 2. arch_prog_run().
The platform_prog_run() allows for a chipset to intercept
a program that will be run. This allows for CPU switching
as currently needed in t124 and t132.
Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8846
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The cpu.c contains some helpful construts as well as ramstage
devicetree handling. Split the 2 pieces so that cpu.c can be
reused in secmon.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted.
Change-Id: Iec0f8462411897a255f7aa289191ce6761e08bb0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f30f1186950424b65df6858965a09ca51637e4f
Original-Change-Id: Ie87bd35bf1ccd777331250dcdaae07dab82d3d18
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218842
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9089
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There was a hacky and one-off spin table support in tegra132.
Make this support generic for all arm64 chips.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Ran with and without secure monitor booting smp into the kernel.
Change-Id: I3425ab0c30983d4c74d0aa465dda38bb2c91c83b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 024dc3f3e5262433a56ed14934db837b5feb1748
Original-Change-Id: If12083a9afc3b2be663d36cfeed10f9b74bae3c8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218654
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9084
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34
Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214371
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9080
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Transition library provides the following functionalities:
1) Setup the environment for switching to any particular EL and jump to the
loaded program at that EL. In short "Execute program X at exception level Y
using the state Z"
2) Provides routines for exception entry and exception exit that can be used by
any program to implement exception handling. The only routine required by the
program would be exc_dispatch which handles the exception in its own required
way and returns by making a call to exc_exit. On exc_exit, the transition
library unwinds the whole stack by popping out the saved state of xregs
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and exceptions are tested for ramstage on ryu
Change-Id: I8116556109665e61a53e4b3987d649e3cfed64a1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ab888e8cae0c5f1e79b0e16ca292869f16f1cca
Original-Change-Id: I90f664ac657258724dc0c79bd9f6ceef70064f90
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216375
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9070
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Currently, the rmodules inclusion for vboot is dependent on ramstage_arch.
This change adds dependency on romstage_arch, since vboot is associated with
romstage. Inclusion based on ramstage_arch is left as is in case someone needs
it in ramstage.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for link, rush and nyan
Original-Change-Id: Ib62415671c26a4a18c7133d98e8c683414def32b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209568
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 00da67cc02c81d7a6160f7336b33bf53b00e1875)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9df02134af4e396c7257a2db2e2c371cfd1a02bc
Reviewed-on: http://review.coreboot.org/8673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Original-Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209379
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 242bb90d7476c2ee47d60c50ee18785edeb1a295)
Some of this cherry-pick had already been committed here:
commit 133096b6dc31163f59f658e15f2eb342a0de2ac6
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9f5868d704c4b3251ca6f54afa634588108a788c
Reviewed-on: http://review.coreboot.org/8672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some of the SoC's need an early hook to configure
certain registers. One example of this is on t132
where ramstage is the first thing being ran on the
arm64 core and it is the only entity that can configure
certain registers required for the rest of ramstage.
Therefore, provide the opportunity for the SoC to
implement such requirements.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot.
Original-Change-Id: Ib352f3788872f888581b398c9b394b7c4e54b02a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208061
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 2c50e2b39e75d1383e8e573c576630a5b7313349)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I38df63e46c5c21b2d319fc9eb42053c3a0d61bc8
Reviewed-on: http://review.coreboot.org/8595
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Inconsistent progress was observed running ramstage.
It was determined that the hand-coded assembly functions
were causing issues. Some of the comments seems suspect about
the hardware taking care of alignment. The prudent thing to do
is to use the C ones. Optimization can come later after maturity.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and booted to attempting to payload
Original-Change-Id: I4137adf9b36b638ed207e4efd57adaac64c6a6c1
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207431
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 2762e478c6b59dd30c59aa87a922d0f78c00c0c4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id3196b0c2bf41a21db31f999ba437d118875a236
Reviewed-on: http://review.coreboot.org/8587
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Ramstage needs an assembly entry point for setting up
the initial state of the CPU. Therefore, a function is
provided, arm64_el3_startup(), that bootstraps the state
of the processor, initializes the stack pointer, and
branches to a defined entry symbol. To make this work
without adding too much preprocessor macro conditions
provide _stack and _estack for all the stages.
Currently the entry point after initialization is 'main',
however it can be changed/extended to do more work such
as seeding the stack contents with tombstones, etc.
It should be noted that romstage and bootblock weren't
tested. Only ramstage is known to work.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Brought up 64-bit ramstage on rush.
Original-Change-Id: I1f07d5b6656e13e6667b038cdc1f4be8843d1960
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207262
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 7850ee3a7bf48c05f2e64147edb92161f8308f19)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia87697f49638c8c249215d441d95f1ec621e0949
Reviewed-on: http://review.coreboot.org/8585
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
There were a number of issues with the ARM64 build files. This
patch ports the following changes from ARMV4/V7 to ARMV8:
- make armv8 Kconfig options consistent with armv4/v7
- fix build include issues in boot.c, tables.c,
and early_variables.h by matching armv4/v7.
Change-Id: I57359a96821d88c50f48dc0bb6ad226cacb0c2ec
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iacd95d336559c45458784d1da67bde62a0956620
Reviewed-on: http://review.coreboot.org/8236
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
No need to pass calls through gcc in one case and
directly to binutils in another. Just always call
binutils.
Change-Id: Icf9660ce40d3c23f96dfab6a73c169ff07d3e42b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7610
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934)
This patch is essentially a squash of aarch64 changes made by
these patches:
d955885 coreboot: Rename coreboot_ram stage to ramstage
a492761 cbmem console: Locate the preram console with a symbol instead of a sect
96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3
3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry
ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage
25fd2e9 aarch64: Remove CAR definitions from early_variables.h
65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM
9484873 aarch64: Change default exception level to EL2
7a152c3 aarch64: Fix formatting of exception registers dump
6946464 aarch64: Implement basic exception handling
c732a9d aarch64/foundation-armv8: Basic bootblock implementation
3bc412c aarch64: Comment out some parts of code to allow build
ab5be71 Add initial aarch64 support
The ramstage support is the only portion that has been tested
on actual hardware. Bootblock and romstage support may require
modifications to run on hardware.
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6915
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
