Fix a function call in the normal path using the original function
name and arguments in code that was changed in commit 3bfd7cc6
(drivers/pc80: Rework normal / fallback selector code)
This commit reworked most of the fallback / normal code,
however the normal code paths were not fully tested by Jenkins,
so this was missed.
Change-Id: Ied66334977272a13b7a7307ff4d9f34eb22040aa
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12315
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
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>
On x86_64 we need to leave long mode before we can switch to 16bit
mode. Oh joy! When's my 64bit resume pointer coming?
Why didn't this get caught earlier? Seems the Asrock E350M2 didn't
do Suspend/Resume?
Yes, I know it's Intel syntax. Will be converted to AT&T syntax
as soon as the whole thing actually works.. 8)
Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11106
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some registers only allow word-sized or half-word-sized operations and will
cause a data fault when accessed with byte-sized operations.
However, the compiler may or may not break such an operation into smaller
(byte-sized) chunks. Thus, we need to reliably perform word-sized operations for
32 bit read/write and half-word-sized operations for 16 bit read/write.
This is particularly the case on the rk3288 SRAM registers, where the watchdog
tombstone is stored. Moving to GCC 5.2.0 introduced a change of strategy in the
compiler, where a 32 bit read would be broken into byte-sized chunks, which
caused a data fault when accessing the watchdog tombstone register.
The definitions for byte-sized memory operations are also adapted to stay
consistent with the rest.
Change-Id: I1fb3fc139e0a813acf9d70f14386a9603c9f9ede
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11698
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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>
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>
Since we now have more freedom in the bootblock linking step it no
longer makes sense to use a monolithic bootblock.S. Code segments must
still be included as the order in bootblock.S determines code flow.
However, non-code flow related assembly stubs don't need to be directly
included in bootblock.S
Change-Id: I08e86e92d82bd2138194ed42652f268b0764aa54
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11792
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code flow doesn't fall through to walkcbfs, as it does in the rest
of bootblock.S. Instead, walkcbfs is called (albeit via a jmp). The
linker cannot know this when walkcbfs.S is included directly.
When we use a CAR bootblock, we lose several hundred bytes because
walkcbfs is not garbage-collected, yet it isn't used. This problem
is solved by assembling walkcbfs.S separately, and linking it.
Change-Id: Ib3a976db09b9ff270b7677cb4f9db80b0b025e22
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11785
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As part of preparing for systems with non-memory-mapped media, we want
to be able to call into C code. This change allows us to link C code
directly into the bootblock. The steps of going from bootblock main()
to CAR setup to C code will be implemented in subsequent patches.
Note that a few files selected with bootblock-y will now be compiled
for the bootblock as well, but since we enabled garbage collection,
they will not be included in the final binary.
Change-Id: I5ca6dcaf176f5469c6a3bb925859399123493bc6
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11783
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The only difference between the ifeq/else/endif guarded rules is the
linker flags specific to x86. Add those flags to LDFLAGS_bootblock,
and only use one rule for bootblock.debug.
Change-Id: I986a93e0418f05fb273512d7efe0573052493332
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11782
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The x86 bootblock linking is a mess. The bootblock is treated in
a very special manner, and never received the update to link-time
garbage collection.
On newer x86 platforms, the boot media is no longer memory-mapped.
That means we need to do a lot more setup in the bootblock. ROMCC is
unsuitable for this task, and walkcbfs only works on memory-mapped
CBFS. We need to revise the x86 bootflow for this new case.
The approach this patch series takes is to perform CAR setup in the
bootblock, and load the following stage (either romstage or verstage)
from the boot media. This approach is not new, but has been done on
our ARM ports for years.
Since we will be adding .c files to the bootblock, it is prudent to
use link-time garbage collection. This is also consistent to how we
do things on other architectures. Unification FTW!
Change-Id: I16b78456df56e0053984a9aca9367e2542adfdc9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11781
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to do a verification of romstage on x86 one needs to
run verstage which verifies romstage (and the memory init code).
However, x86 doesn't have SRAM like every other modern SoC so
managing the cache-as-ram region is especially critical.
First move all of the "shared" objects to the beginning of
the .car.data section. This change then ensures that each stage
using car.ld to link has the same consistent view of the addresses
of these fixed-sized objects in cache-as-ram. The CAR_GLOBALs can
be unique per stage. However, these variables are expected to have
a value of zero at the start of each stage. In order to allow a
stage to provide those semantics outside of the initial cache-as-arm
setup routine add _car_global_start and _car_global_end symbols.
Those symbols can be used to clear the CAR_GLOBALs for that stage.
Note that the timestamp region can't be moved out similarly to the
pre-ram cbmem console because the object storage of the timestamp
cache is used *after* cache-as-ram is torn down to indicate if the
cache should be used or not. Therefore, that timestamp needs to
migrated to ram. A logic change in src/lib/timestamp.c could
alleviate this requirement, but that task wasn't tackled in this
patch.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I15e9f6b0c632ee5a2369da0709535d6cb0d94f61
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11740
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to support verstage on x86 one needs to link verstage
like romstage since it needs all the cache-as-ram goodies. Therefore,
provide a macro that one can invoke that provides the necessary
recipes for linking that particular stage in such an environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: I12f4872df09fff6715829de68fc374e230350c2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11739
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The output of command below,
# i386-elf-nm build/cbfs/fallback/romstage_null.offenders | \
grep -q "" ; echo $?
has different result on MacOS, OS X Mavericks, which outputs 0.
On linux, it outputs 1.
I assume it is misleading to search an empty string in a empty
string. Change it to testing if the string is empty.
Change-Id: Ie4b8fe1fb26df092e2985937251a49feadc61eb0
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Set XN bit of block upper attribute to device memory in mmu. CPU may
speculatively prefetch instructions from device memory, but the IO
subsystem of some implementation may not support this operation. Set
this attribute to device memory mmu entries can prevent CPU from
prefetching device memory.
BRANCH=none
BUG=none
TEST=build and booted to kernel on oak-rev3 with dcm enabled.
Change-Id: I52ac7d7c84220624aaf6a48d64b9110d7afeb293
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7b01a4157cb046a5e75ea7625060a602e7a63c3c
Original-Change-Id: Id535e990a23b6c89123b5a4e64d7ed21eebed607
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/302301
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Unlike the other stages, the payload requires virtual memory to be set up
and also a privelege level change.
Change-Id: Ibbe2a55f7719d917f121a53a17c6d90e6b2ab3d1
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/11699
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
If we use a linux payload/any payload that wants to manage virtual
memory, and the payload is a supervisor (thus requiring virtual
addressing before being started), we need to make sure that the page
table is mapped into the virtual address space. Move the start address
of the tables so the payload can manage virtual memory.
Change-Id: I1d99e46f38a38a163fb1c7c517b1abca80cde0dc
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11621
Tested-by: build bot (Jenkins)
Existing memlayout code placed sections in overlapping areas, and would
overwrite the payload if it was large enough. Update memlayout.ld in
src/mainboard/emulation/spike-riscv to represent the spike emulator, and
add sbi interface which now has room into src/arch/riscv/bootblock.S.
Add utility code to qemu-riscv, but emulator itself has yet to be
updated to new ISA and as such should not be used.
Update Makefile to include all the files necessary for sbi interface.
Clean up unused include in src/arch/riscv/include/atomic.h and
whitespace in src/mainboard/emulation/spike-riscv/memlayout.ld
Fixed whitespace issues in spike_util.c
Change-Id: Id97fe75e45ac1361005bec6d421756ee3f98a508
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11370
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that cbfstool supports XIP for romstage utilize it.
This removes the double link steps with the cbfstool
locate and add-stage sandwich.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I1ec555f523a94dd4b15fe8186cbe530520c622c0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11670
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Trap handling code was bugged in that it loaded in the wrong stack
pointer, overwriting the space the processor uses to talk to its host
for doing device requests. Fix this issue, as well as add support for
handling misaligned loads the same way we handle misaligned stores.
Change-Id: I68ba3a114b7167b3212bb0bed181a7595f0b97d8
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11620
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
RISCV requires the bios/bootloader to set up an interface by which it
can get information about memory, talk to host devices, etc. Put
implementation for spike in
src/mainboard/emulation/spike-riscv/spike_util.c, and
src/arch/riscv/trap_handler.c
Change-Id: Ie1d5f361595e48fa6cc1fac25485ad623ecdc717
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11368
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Execution in supervisor level code in RISCV requires early setup of
virtual memory. Add initialization calls in
src/arch/riscv/virtual_memory.c to implement the required page table
setup, and helper functions to use when jumping to the payload correctly
in riscv.
Change-Id: I46e080e0ee8dc13277d567dcd4bf0f61a4507b76
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11369
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Previously there were 2 paths in linking ramstage. One was used for
RELOCATABLE_RAMSTAGE while the other was fixed location. Now that
rmodtool can handle multiple secitons for a single proram segment
there's no need for linking ramstage using lib/rmodule.ld. That
also means true rmodules don't have symbols required for ramstage
purposes so fix memlayout.h. Lastly add default rules for creating
rmod files from the known file names and locations.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Inspected ramstage.debug as well as rmodules
created during the build.
Change-Id: I98d249036c27cb4847512ab8bca5ea7b02ce04bd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11524
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
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>
To reduce file clutter merge romstage.ld and ramstage.ld
into a single memlayout.ld. The naming is consistent with
other architectures and chipsets for their linker script
names. The cache-as-ram linking rules are put into a separate
file such that other rules can be applied for future verstage
support.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and dmp/vortex86ex.
Change-Id: I1e8982a6a28027566ddd42a71b7e24e2397e68d2
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking romstage. Use that same method on x86
as well for consistency.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I016666c4b01410df112e588c2949e3fc64540c2e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11510
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All the other architectures are using the memlayout
for linking ramstage. The last piece to align x86 is
to use arch/header.ld and the macros within memlayout.h
to automaticaly generate the necessary linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards. Analyzed readelf output.
Change-Id: I012c9b88c178b43bf6a6dde0bab821e066728139
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11508
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Though coreboot started as x86 only, the current approach to x86
linking is out of the norm with respect to other architectures.
To start alleviating that the way ramstage is linked is partially
unified. A new file, program.ld, was added to provide a common way
to link stages by deferring to per-stage architectural overrides.
The previous ramstage.ld is no longer required.
Note that this change doesn't handle RELOCATABLE_RAMSTAGE
because that is handled by rmodule.ld. Future convergence
can be achieved, but for the time being that's being left out.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built a myriad of boards.
Change-Id: I5d689bfa7e0e9aff3a148178515ef241b5f70661
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The current way the XIP address of romstage is calculated is by
doing a 'cbfstool locate' using a bin file of romstage linked
at address 0. That address is then used for re-linking romstage at
the address spit out by cbfstool. Currently, the linker actually
sets minimum alignment on the text sections as 32 bytes, but it
doesn't actually honor that value. Instead, provide a minimum
alignment for romstage so as not to fight the linker.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built asus/kfsn4-dre. Confirmed ROMSTAGE_BASE == gdtptr.
Change-Id: Id6ec65d257df9ede78c720b0d7d4b56acfbb3f15
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that the only source of ELF sections for romstage are
from directly included .inc files or ROMCC generated inc
files the subsection globs can be removed. i.e. Remove
.rom.data.* and .rom.text.* listings. Lastly, put the
.rom.data section directly after the .rom.text. They
are by definition read-only and they are generated from
the same place.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Spot checked !ROMCC and ROMCC boards. Confirmed
only .rom.text .rom.data sections exist.
Change-Id: Id17cf95c943103de006c5f3f21a625838ab49929
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11505
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system was previously determining the flow
of the romstage code by the order of files added to
the crt0s make variable. Those files were then
concatenated together, and the resulting file was added
to the build dependencies for romstage proper.
Now romstage.S is added that can be built using
the default object file rules. The generated
romstage.inc is pulled in by way of an #include in the
newly added romstage.S.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards. compared
readelf -e output.
Change-Id: Ib1168f9541eaf96651c52d03dc0f60e2489a77bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11504
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, the x86 romstage build process was unconditionally
creating a romstage.inc and adding it to crt0s. This step is
inherently not necessary in the !ROMCC case becaue the romstage.inc
was created by the compiler outputting assembler. That means
MAINBOARDDIR/romstage.c is truly a C environment that requires
some sort of assembler stub to call into (cache_as_ram.inc from
the chipset dirs). Therefore, remove this processing. The result
is that MAINBOARDDIR/romstage.c can use the normal build steps
in creating an object and linking. The layout of romstage.elf
will change but that's only from a symbol perspective.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built multitude of boards. Compared readelf -e output.
Change-Id: I9b8079caaaa55e3ae20d3db4c9b8be04cdc41ab7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11503
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system was previously determining the flow
and linking scripts bootblock code by the order of files
added to the bootblock_inc bootblock-y variables.Those
files were then concatenated together and built by a myriad of
make rules.
Now bootblock.S and bootblock.ld is added so that bootblock
can be built and linked using the default build rules.
CHIPSET_BOOTBLOCK_INCLUDE is introduced in order to allow the
chipset code to place include files in the path of the bootblock
program -- a replacement for the chipset_bootblock_inc
make variable.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built vortex, rambi, and some asus boards.
Change-Id: Ida4571cbe6eed65e77ade98b8d9ad056353c53f9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11495
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
coreboot has no CREDITS file.
Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11514
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to prepare for more unification of the linker
scripts prefix pci_drivers, epci_drivers, cpu_drivers, and
ecpu_drivers with an underscore.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built different boards includes ones w/ and w/o relocatable
ramstage.
Change-Id: I8918b38db3b754332e8d8506b424f3c6b3e06af8
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11506
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When building up which files to include in romstage there
were both 'cpu_incs' and 'cpu_incs-y' which were used to
generate crt0.S. Remove the former to settle on cpu_incs-y
as the way to be included.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. No include file changes.
Change-Id: I8dc0631f8253c21c670f2f02928225ed5b869ce6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
This patch adds support to enable a linker workaround to a hardware
erratum on some early Cortex-A53 revisions. Since the linker option was
added very recently, we use xcompile to test whether the toolchain
supports it first. It is also guarded by a Kconfig since only a few
ARM64 SoCs will need this and it incurs a performance penalty.
BRANCH=none
BUG=none
TEST=Turned it on or off for Smaug and confirmed that it (dis)appeared
in verbose make output accordingly.
Change-Id: I01c9642d3cf489134645f0db6f79f1c788ddb00d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 57128785760c4dfa32d6e6d764756443a9323cb7
Original-Change-Id: Ia5dd124f484e38460d75fb864304e7e8b18d16b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294745
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
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>
do_dcsw_op is coded as a label, it's possible that linker will place
do_dcsw_op on unaligned address. To avoid this situation, we declare
do_dcsw_op as a function. Also explicitly set the 2nd argument of
ENTRY_WITH_ALIGN(name, bits) to 2.
do_dcsw_op:
cbz x3, exit
c103d: b40003e3 cbz x3, c10b9 <exit>
mov x10, xzr
c1041: aa1f03ea mov x10, xzr
adr x14, dcsw_loop_table // compute inner loop address
BRANCH=none
BUG=none
TEST=build and check do_dcsw_op in elf file
Change-Id: Ieb5f4188d6126ac9f6ddb0bfcc67452f79de94ad
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 4ee26b76089fab82cf4fb9b21c9f15b29e57b453
Original-Change-Id: Id331e8ecab7ea8782e97c10b13e8810955747a51
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293660
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/11395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
RISCV requires a trap handler at the machine stage to deal with
misaligned loads/stores, as well as to deal with calls that a linux
payload will make in its setup. Put required assembly for jumping
into and out of a trap here to be set up by the bootblock in a later
commit.
Change-Id: Ibf6b18e477aaa1c415a31dbeffa50a2470a7ab2e
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11367
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
When the check for global symbols in romstage happens, if everything is
good, a warning appears, telling us that the segment is empty. While the
empty segment is good, the warning is distracting:
"BFD: build/cbfs/fallback/romstage_null.debug: warning: Empty loadable
segment detected, is this intentional ?"
This change hides that particular warning, but shouldn't hide any other
output from objcopy.
Change-Id: If22489280712d02a61c3ee5e0cb2a53db87d6082
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11302
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The asl_template previously unconditionally included
dsdt.aml. However, COMPILE_IN_DSDT=y results in the
dsdt.aml being linked directly into ramstage. Thus
the information is duplicated.
The inclusion of this file unconditionally throws
some errors as certain assets need to be included
in CBFS. However, as there isn't fine-grained
ordering control in how files are added fixed
resource requirements for other assets collide
result in failure to build.
To remedy both things, provide a 2nd argument to
asl_template which defaults to 'y' for CBFS
addition. In the COMPILE_IN_DSDT=y case pass
'n' so that dsdt.aml is no longer added.
BUG=chrome-os-partner:43419
BRANCH=None
TEST=For glados:
Built with COMPILE_IN_DSDT=y. dsdt.aml not included.
Built with COMPILE_IN_DSDT=n. dsdt.aml was included.
Original-Change-Id: I4767e5be2915c1732251fe415017f30314c5efc9
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289840
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Id1828627ba0a034eb05b2fe23be76e19f3040444
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11166
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The sysinfo object within the k8 ram init is used
to communicate progess/status from all the nodes in the
system. However, the code was assuming where the sysinfo
object lived in cache-as-ram. The layout of cache-as-ram
is dynamic so one needs to do the lookup of the correct
address at runtime. The way the amd code is compiled
by #include'ing .c files makes the solution a little
more complex in that some cache-as-ram support code
needed to be refactored.
Change-Id: I6500fa7b005dc082c4c0b3382ee2c3a138d9ac31
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10961
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Spike support: QEMU RISCV is broken, and the maintainers at Berkeley
are working on it, but at the moment spike is the only way to test
on riscv. Add support for spike console output for debugging.
Privileged ISA: Update to privileged ISA in RISCV (machine,
supervisor, hypervisor, user modes) broke exisitng RISCV asm, and
bootblock.S was updated to match the new spec. Clean old assembly
[pg: things build with gcc 4.9 now, but don't expect them to work.
Hardcoding register names into the assembler language may not be the smartest
idea of the RISCV folks.]
Change-Id: Ie2c109d3c26712c207512f74f28ce1a925e6e181
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/11078
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The spec states (5.2.10): "The BIOS aligns the FACS on a 64-byte boundary
anywhere within the system's memory address space."
Change-Id: Ie9415e505525dbdd418028d4954018c829921a18
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: fwts 15.08
Reviewed-on: http://review.coreboot.org/11141
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On x86-64 the current way of calculating the base address
of the boot device (SPI flash) gets an unwanted sign extension,
making it live somewhere at the end of 64bit address space.
Enforce rom_base to be at the upper end of the 4G address space.
Change-Id: Ia81e82094d3c51f6c10e02b4b0df2f3e1519d39e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
bootblock.inc requires config.h to be around which may need to be
created. Have make be aware of it.
Change-Id: I79ad003b461d7da7a5afecdae55fdd07ba735821
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11057
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The new toolchain depends on it.
Change-Id: I9070925eeb3f63a6c31e7474ffb9cba15884703d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10976
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)
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>
Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10586
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This allows SoCs/CPUs to have custom stage_entry in order to apply any
fixups that need to run before standard cpu reset procedure.
BUG=chrome-os-partner:41877
BRANCH=None
TEST=Compiles successfully
Change-Id: Iaae7636349140664b19e81b0082017b63b13f45b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 498d04b0e9a3394943f03cad603c30ae8b3805d4
Original-Change-Id: I9a005502d4cfcb76017dcae3a655efc0c8814a93
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/284867
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/10897
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Kconfigs symbols of type bool are always defined, and can be tested with
the IS_ENABLED() macro.
symbol type except string.
Change-Id: Ic4ba79f519ee2a53d39c10859bbfa9c32015b19d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CBFS_BASE_ADDRESS can be compared against values used with cbfstool
to generate warnings. This can help cut down on mistakes and debug
time.
Change-Id: I149007dd637661f799a0f2cdb079d11df726ca86
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10681
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This fixes issues with our clang reference toolchain on ARM.
Change-Id: Ib754941059285f15332bc694814aff6285969545
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10857
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This is not going as far as I would like it to go, but
some of the external payloads have to be fixed up first.
Long term, I would like to directly add payloads/external/*
to subdirs-y and remove one layer of indirection from the
build process.
For now, moving the payload Makefile targets into payloads/
is already a small improvement.
Change-Id: Ie4eb492eb804e0aaaf1a4d90af2f876f27a32a75
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10829
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to accommodate tracking timestamps in all the
__PRE_RAM__ stages (bootblock, verstage, romstage, etc)
of a platform one needs to provide a way to specify
a persistent region of SRAM or cache-as-ram to store
the timestamps until cbmem comes online. Provide that
infrastructure.
Based on original patches from chromium.org:
Original-Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223348
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/224024
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I8779526136e89ae61a6f177ce5c74a6530469ae1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10790
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The top level Makefile runs the $stage-src .ld scripts through
the preprocessor and puts them in $(obj). Use the preprocessed
.ld files and cat them together into x86 romstage_null.ld.
Change-Id: If71240fbf7231df2b1333a1f8e5160cb8694f6ce
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10743
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While extending the SMBIOS code to write a proper maximum structure size,
the call to elog_smbios_write_type15() was botched.
Fix the name and arguments.
Change-Id: I4c93490b09ddf4da240ff8f2bd8f8cc3f2abd96e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10823
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix up all the code that is using / to use >> for divisions instead.
Change-Id: I8a6deb0aa090e0df71d90a5509c911b295833cea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10819
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The option --divide is required by our assembler to ensure that
'/' is not parsed as a comment sign but as a division, because
some of the cache as ram code is using divisions.
The --divide parameter has been part of the GNU as since binutils 2.17.
Hence, compile romstage (which contains cache as ram init) with
-Wa,--divide unconditionally instead of probing for it and adding it to
all compiler invocations (because that is causing random trouble with
clang when compiling the SMM code and calling gcc with --divide instead of
-Wa,--divide)
Change-Id: Ideefb2a243dc1d657ba415a99c1f8ab1d93800e0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SMBIOS Specification 2.3 and up defines Maximum Structure Size
as the "Size of the largest SMBIOS structure, in bytes, and encompasses
the structure’s formatted area and text strings." The hardcoded size
is too small to accurately represent the maximum SMBIOS structure sizes.
While the field is not used by Linux it is used by some RTOS
implementations, eg. VxWorks.
TEST=Booted Linux and ran github.com/bfrisch/dmidecode which verified
the maximum structure size on Minnowboard Max.
Change-Id: I98087975c53a02857742dea283f4e303485b2ffe
Signed-off-by: Ben Frisch <bfrisch@gmail.com>
Reviewed-on: http://review.coreboot.org/10163
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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)
Compilers aren't happy with a declaration of boot_cpu() after defining
boot_cpu to 1.
Change-Id: I22d0db61646f3e226e5996fa94223ffbb6b760e5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10696
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Bring back the ability to link in the DSDT. This is to help Chrome OS to
switch over to a new upstream quickly (because some of the custom built
mechanisms are a pain with tons of files).
This is supposed to be temporary (famous last words), but I'd rather fix the
lack of CBFS awareness in CrOS bit for good in the time I usually spend on
keeping upstream and CrOS branches close.
Change-Id: I7fa5540bbf5c568c4adca56a09c83b6c7e358ad5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10637
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Move IASL up with the other tools.
- Remove OUT= which is no longer used in the
payloads/external/SeaBIOS Makefile.
Change-Id: I211ddcf3496b533151936fa5cbfa7a92986ec28f
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10606
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ife94f5324971f4fa03e9139f458b985f6fed9d87
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10577
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>
Change-Id: I29eaba74185711df055cf56c23ef2bdae0c7b43e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10578
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This does not optimize memcpy for 64bit, it merely makes it compile.
Change-Id: I69ad6bd0c3d5f617d9222643abf7a2ba7c2a0359
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10575
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Allow calls to cpu_phys_address_size and its support functions during
romstage. This enables the proper display of MTRRs during romstage
without duplicating this code.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: I6f6465c150a683ce91f1494ebb5d9ac60b75b795
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6bfd517088b6a2e8a5958a837e6c8c471de19fd0
Original-Change-Id: I429f9beb69298836acdd71d17a7bcb717939dfc2
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/277392
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10561
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This CL is in preparing for tegra mtc that is invoked by dev init.
mtc currently requires floating point instructions support.
BUG=chrome-os-partner:40999
BRANCH=none
TEST=Build and boot smaug
Change-Id: I470dfcd86026812d617f9ff4f4fcdce601195857
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e3f7336fc7cedf96dab4eff204616519856f831
Original-Change-Id: I14c0003ce76ddf4b4ebb0cf171ea3c62cab55ef9
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/275112
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10558
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Change-Id: Ibcfdc08c9aac02fe263afd629fc262f71da80e9a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8695
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Almost all of the code between x86 and x64 can be shared, so select it for
either architecture.
Change-Id: I681149ed7698c08b702bb19f074f369699cef1bf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8693
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I81f6d8a21ea0d8218f5a4aab2feb39be32f88e01
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8692
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It's derived from EEPROM on Lenovo machines and not from user config
which is ignored.
Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7055
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
This change adds cache management after loading stages.
Before jumping to a new stage we should flush the data
caches to memory and invalidate instruction cache.
After all segments are loaded CBFS cache is also
flushed.
With this change all stages of coreboot are now executed
successfully. This was tested on Pistachio bring up board,
also known as Urara.
Change-Id: I86e07432c21a803ef1cfc41b633c5df42b99de90
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10456
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The coreboot table address is passed as an argument when jumping
to payload.
With this change depthcharge is loaded and executed properly on urara.
Change-Id: I230d474a91b8d38aff070aa4aac623b6c8f0809c
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10460
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The type1 family setting from chromium was mis-merged into the
type2 function. Move it to the correct type1 function.
Bad commit: 51bdc47816
Change-Id: I72e6ef80bbf185a39fcf169c8247dc16462e6bc3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10498
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It can be helpful to certain users of the cbmem init hooks
to know if recovery was done or not. Therefore, add this
as a parameter to the hooks.
Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I1ba4bfa0ac36a09a82b108249158c80c50f9f5fd
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9599
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I7fca8c3fa15c1be672e50e4422d7ac8e4aaa1e36
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9598
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I3fc8e0339fa46fe92cc39f7afa896ffd38c26c8d
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9597
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We test for it in xcompile and add it to CFLAGS.
Change-Id: I041a881b542bc55c1725af384f038da3356e3bb1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10426
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfs_get_file_content was replaced with cbfs_boot_map_with_leak but
36f8d27ea9 failed to get it into account.
Change-Id: I0c7840043b2ea6abaf8e70f4bf1a63c96aedebc1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10403
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Makes it cleaner by putting AML into separate file rather than having
an array in C code.
Change-Id: Ia5d6b50ad9dabdb97ed05c837dc3ccc48b8f490f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10385
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BRANCH=none
BUG=none
TEST=Booted on Oak and confirmed the output cacheable/non-cacheable
string is correct.
Change-Id: I062c1cc384b8cb9d07038399b1bc7ef47d992103
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 45552f95b55cd9fc81817e4ff02c78e885377065
Original-Change-Id: Ie52066dbefd2f54d0746792b89f0b57767811adb
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273994
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10390
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have observed issues with enabling CONFIG_SMP and adding prints
before MMU is enabled on Tegra-based SoCs. This seems to be related
to the hardware assisted locks and the restrictions laid down by ARMv8
spec.
BUG=None
BRANCH=None
TEST=Boots to kernel prompt on smaug.
Change-Id: I29a52f5a972baf396c01faba3ae3e5ecd27563e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f52ee4b5b2e9b7f54eee0d105cb7e17f9a7e1613
Original-Change-Id: I432895560f468903c7beef00e78b6d38275a619c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272449
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10311
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current arm64 MMU interface is difficult to use in pre-RAM
environments. It is based on the memranges API which makes use of
malloc(), and early stages usually don't have a heap. It is also built
as a one-shot interface that requires all memory ranges to be laid out
beforehand, which is a problem when existing areas need to change (e.g.
after initializing DRAM).
The long-term goal of this patch is to completely switch to a
configure-as-you-go interface based on the mmu_config_range() function,
similar to what ARM32 does. As a first step this feature is added
side-by-side to the existing interface so that existing SoC
implementations continue to work and can be slowly ported over one by
one. Like the ARM32 version it does not garbage collect page tables that
become unused, so repeated mapping at different granularities will
exhaust the available table space (this is presumed to be a reasonable
limitation for a firmware environment and keeps the code much simpler).
Also do some cleanup, align comments between coreboot and libpayload for
easier diffing, and change all error cases to assert()s. Right now the
code just propagates error codes up the stack until it eventually
reaches a function that doesn't check them anymore. MMU configuration
errors (essentially just misaligned requests and running out of table
space) should always be compile-time programming errors, so failing hard
and fast seems like the best way to deal with them.
BRANCH=None
BUG=None
TEST=Compile-tested rush_ryu. Booted on Oak and hacked MMU init to use
mmu_config_range() insted of memranges. Confirmed that CRCs over all page
tables before and after the change are equal.
Change-Id: I93585b44a277c1d96d31ee9c3dd2522b5e10085b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f10fcba107aba1f3ea239471cb5a4f9239809539
Original-Change-Id: I6a2a11e3b94e6ae9e1553871f0cccd3b556b3e65
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/271991
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10304
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This allows SeaBIOS to fill it as necessary.
This is needed to make BitLocker work.
Change-Id: I35858cd31a90c799ee1a240547c4b4a80fa13dd8
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10274
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use separate CBMEM allocations for stack and heap on S3 resume path.
The allocation of HIGH_SCRATCH_MEMORY is specific to AGESA and is moved
out of globals and ACPI. This region is a replacement for BIOS_HEAP_SIZE
used on non-resume paths.
Change-Id: I6658ce1c06964de5cf13b4e3c84d571f46ce76f3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10316
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function is required to be implemented by SoC only if some
platform specific parameters are to be passed in from the early
bootloader to bl31 component.
BUG=chrome-os-partner:40414
BRANCH=None
TEST=Compiles successfully.
Change-Id: I6e76a0b6735267971e12aa72a987e8d83f5ad102
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6ab8bc12ffc2ee5bf69cef68bae852dcbf7ccb98
Original-Change-Id: If55aaee8d18a8045a5d842145c0e2c97a37a8bca
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272377
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/10308
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
The boot_device is a region_device that represents the
device from which coreboot retrieves and boots its stages.
The existing cbfs implementations use the boot_device as
the intermediary for accessing the CBFS region. Also,
there's currently only support for a read-only view of
the boot_device. i.e. one cannot write to the boot_device
using this view. However, a writable boot_device could
be added in the future.
Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10216
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This avoids the need to supply weak function and avoids associated risks of
forgetting to link in relevant files.
Change-Id: Ie96475babb4aa4ea8db49023af5b31bfa63b21dc
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7373
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
Now that the users of cbmem_set_top() always provide a consistent
cbmem_top() value there's no need to have cbmem_set_top() around.
Therefore, delete it.
Change-Id: I0c96e2b8b829eddbeb1fdf755ed59c51ea689d1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10314
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
On S3 resume, CBMEM_ID_CONSOLE from previous boot is found in ramstage,
even when romstage did not create it. So buffer did not get cleared
on S3 resume path.
Also do not allocate for preram_cbmem_console in CAR when there
are no means to back it up to ram.
Change-Id: I175cebbb938adf2a7414703fefffb8da796e9fa9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Implementation for cbmem_find() did not work for boards without
EARLY_CBMEM_INIT in romstage.
This is required for S3 resume to work on AGESA plaforms.
First broken with commit 0dff57d
cbmem: switch over to imd-based cbmem
Change-Id: I9c1a4f6839f5d90f825787baad2a3824a04b5bdc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10299
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
For x86 systems employing CONFIG_LATE_CBMEM_INIT, set_top_of_ram() is
called in ramstage to note the upper address of the 32-bit address
space. This in turn is consumed by cbmem. However, in this scenario
cbmem_top() cannot always be relied upon because get_top_of_ram()
doesn't return the same value provided to set_top_of_ram().
To fix the inconsistency in ramstage save the value passed in
to set_top_of_ram() and defer to it as the return value for
cbmem_top().
Change-Id: Ida796fb836c59b9776019e7f8b3f2cd71156f0e5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10313
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Export SLIC table from file in CBFS.
Change-Id: Id0e7fe0a49b9cd50b5e43cd15030e1c2098728ec
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7202
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
All boards now use per-device ACPI. This patch finishes migration
by removing transitional kludges.
Change-Id: Ie4577f89bf3bb17b310b7b0a84b2c54e404b1606
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7372
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.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>
SLIT and SRAT are created this way only on amdk8 and amdfam10.
This saves the need of having a lot of dummies.
Change-Id: I76d042702209cd6d11ee78ac22cf9fe9d30d0ca5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7052
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.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>
MAINBOARD_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere
(with no overlap), and never read. Remove it.
Change-Id: Ica1f16182b556dbf4a3b747237af74bcc4c0608c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10254
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
CPU_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere
(with no overlap), and never read. Remove it.
Change-Id: I3f294b0724a87876a7e2f274e6933fe10321a69d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10253
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The configuration of SPSR bits that mask processor exceptions is kinda
oddly hidden as an implict part of the transition() function right now.
It would be odd but not impossible for programs to want to be entered
with enabled exceptions, so let's move these bits to be explicitly set
by the caller like the rest of SPSR instead.
Also clear up some macro names. The SPSR[I] bit is currently defined as
SPSR_IRQ_ENABLE, which is particularly unfortunate since that bit
actually *disables* (masks) interrupts. The fact that there is an
additional SPSR_IRQ_MASK definition with the same value but a different
purpose doesn't really help. There's rarely a point to have all three of
xxx_SHIFT, xxx_MASK and xxx_VALUE macros for single-bit fields, so
simplify this to a single definition per bit. (Other macros in
lib_helpers.h should probably also be overhauled to conform, but I want
to wait and see how many of them really stay relevant after upcoming
changes first.)
BRANCH=None
BUG=None
TEST=None
Change-Id: Id126f70d365467e43b7f493c341542247e5026d2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 715600c83aef9794d1674e8c3b62469bdc57f297
Original-Change-Id: I3edc4ee276feb8610a636ec7b4175706505d58bd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270785
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10250
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
This patch slightly reorganizes arm64/boot.c with the aim of being more
readable:
Make more obvious that there's no code execution here after payload_entry.
[pg: taken from patch linked below]
Change-Id: Ia341e5d290b10ad5ba3edb349b8a7f619022d99f
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/10247
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch slightly reorganizes arm64/boot.c with the aim of being more
readable: we need to sync the i-cache in both code paths, so do it in
a single location.
[pg: taken from patch linked below]
Change-Id: Iab173acfc6d66e4dccb6f6ab916aea2007632bfd
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/10246
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch slightly reorganizes arm64/boot.c with the aim of being more
readable: Make spintable handling optional through a kconfig flag.
[pg: taken from patch linked below]
Change-Id: I64610640835473fcc3d9eff01feb5f861b753eb8
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/10245
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch slightly reorganizes arm64/boot.c with the aim of being more
readable. Improve locality of code.
[pg: taken from patch linked below]
Change-Id: Ie9ea6a10b9d5e5c33bf020369afcae4f10ef068e
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/10244
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch slightly reorganizes arm64/boot.c with the aim of being more
readable: the secure monitor entry is now guarded by an explicit if
statement for its Kconfig rather than hiding than in the corresponding
header file. This makes it clear that there are two (soon three)
separate code paths here.
Change-Id: I44993da7a982b08f485b93ffc522d193bb3fa118
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/10243
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>
The secure monitor entry is now guarded by an explicit if
statement for its Kconfig rather than hiding than in the corresponding
header file. This makes it clear that there are two (soon three)
separate code paths here. Similar change for the optional spintable
feature in the "legacy" payload entry path.
[pg: split out from the patch linked below]
Change-Id: Ia1554959b3268b718a9606e2f79d8f22f336c94d
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/10248
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>
Reorganize Kconfig (split out from the original patch linked below)
Change-Id: I84ec8e453dd7a3980de95a455ad21494c601a98c
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/10240
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Implement the cpu_suspend for the PSCI service in secmon.
BRANCH=none
BUG=chrome-os-partner:39620
TEST=test with CPU idle driver that invoke the cpu_suspend of PSCI
Change-Id: I4cdfab88bf36bf432fb33c56c1ea114b384528f8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 90b3ea3fcb21cb393e30a8359f0328054961f6d5
Original-Change-Id: Ieb76abc017b9c3e074cc018903cef72020306a8f
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/269115
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10171
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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 linker scripts are added to stage objs so remove those
from the object lists. boot.c will be needed to link verstage
properly. Lastly, VERSTAGE_LIB has no value so remove it.
Change-Id: Ie53b42c4995a96006463ec5b358aa43a731cb1b8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10149
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
arch_program_segment_loaded ensures that the program segment loaded is
synced back from the cache to PoC. dcache_flush_all on arm64 does not
guarantee PoC in case of MP systems. Thus, it is important to track
and sync back all the required segments using
arch_program_segment_loaded. Use this function in rmodules as well
instead of cache_sync_instructions which guarantees sync upto PoC.
BUG=chrome-os-partner:37546
BRANCH=None
TEST=Boots into depthcharge on foster
Change-Id: I64c2dd5e40ea59fa31f300174ca0d0aebcf8041d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 35ba0b882b86ff2c29ac766e1d65f403c8346247
Original-Change-Id: I964aa09f0cafdaab170606cd4b8f2e027698aee7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/260908
Original-Reviewed-by: Furquan Shaikh <furquan@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/10173
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Timothy Pearson