Age | Commit message (Collapse) | Author |
|
This header is only used for the bootblock compiled with ROMCC. As the
follow-on patches introduce a bootblock which does not make use of
ROMCC, rename this header to prevent confusion.
Change-Id: Id29c5bc6928c11cc7cb922fcfac71e5a3dcd113c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/12867
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
These were mostly written as part of the coreboot project, so get
the standard coreboot license header.
memmove.c came from the linux kernel, so also gets the standard
coreboot v2 license header, but gets the added attribution that it
was derived from the linux kernel. Unlike many coreboot files,
this file may not be re-licensed as GPL V3.
Change-Id: I1fdc26b543e059f7a42d4b886f7222f4c74b959d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12916
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
When we first added ARM support to coreboot, it was clear that the
bootblock would need to do vastly different tasks than on x86, so we
moved its main logic under arch/. Now that we have several more
architectures, it turns out (as with so many things lately) that x86 is
really the odd one out, and all the others are trying to do pretty much
the same thing. This has already caused maintenance issues as the ARM32
bootblock developed and less-mature architectures were left behind with
old cruft.
This patch tries to address that problem by centralizing that logic
under lib/ for use by all architectures/SoCs that don't explicitly
opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option).
This works great out of the box for ARM32 and ARM64. It could probably
be easily applied to MIPS and RISCV as well, but I don't have any of
those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and
leave that for later cleanup.
BRANCH=None
BUG=None
TEST=Built Jerry and Falco, booted Oak.
Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12076
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It never made sense to have bootblock_* in init, but
pirq_routing.c in boot, and some ld scripts on the main
level while others live in subdirectories.
This patch flattens the directory hierarchy and makes
x86 more similar to the other architectures.
Change-Id: I4056038fe7813e4d3d3042c441e7ab6076a36384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10901
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|