Age | Commit message (Collapse) | Author |
|
Change-Id: Ic1ca6c2e1cd06800d7eb2d00ac0b328987d022ef
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16434
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: Iea3f12a5a7eb37586f5424db2d7a84c4319492f8
Reported-by: Coverity (1361947)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16335
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Normally machine-mode code operates completely within physical address
space. When emulating less privileged memory accesses (e.g. when the
hardware doesn't support unaligned read/write), it is useful to access
memory through the MMU (and with virtual addresses); this patch
implements this functionality using the MPRV bit.
Change-Id: Ic3b3301f348769faf3ee3ef2a78935dfbcbd15fd
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16260
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I273e9d20e02f0333f28e0fc2adcc7940578ea93e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16263
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Not all SBI calls are implemented, but it's enough to see a couple dozen
lines of Linux boot output.
It should also be noted that the SBI is still in flux:
https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/6oNhlW0OFKM
Change-Id: I80e4fe508336d6428ca7136bc388fbc3cda4f1e4
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16119
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ie62f60b2e237fa4921384e3894569ae29639f563
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16262
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I06c6493355f25f3780f75e345c517b434912696f
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16261
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I1c8127412af0f9acc5b5520dc324ac145e59a4bd
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16160
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A new Kconfig option, DEBUG_PRINT_PAGE_TABLES, is added to control this
behaviour. It is currently only available on RISC-V, but other
architectures can use it, too, should the need arise.
Change-Id: I52a863d8bc814ab3ed3a1f141d0a77edc6e4044d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16015
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I57032f958c88ea83a420e93b459df4f620799d84
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16016
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I52fae62bc6cf775179963720fbcfaa9e07f6a717
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16017
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In particular:
- Fix the condition of the loop that fills the mid-level page table
- Adhere to the format of sptbr
Change-Id: I575093445edfdf5a8f54b0f8622ff0e89f77ccec
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I copied it from commit e10d2def7d of spike and made sure the copyright
header is still there.
Change-Id: Ie8b56cd2f4855b97d36a112a195866f4ff0feec5
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ide87c45806c5e58775c77e7f780efb4cf81a70c9
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16014
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
mb() is used in src/arch/riscv/ and src/mainboard/emulation/*-riscv/.
It is currently provided by atomic.h, but I think it fits better into
barrier.h.
The "fence" instruction represents a full memory fence, as opposed to
variants such as "fence r, rw" which represent a partial fence. An
operating system might want to use precisely the right fence, but
coreboot doesn't need this level of performance at the cost of
simplicity.
Change-Id: I8d33ef32ad31e8fda38f6a5183210e7bd6c65815
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15830
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
A few things are currently missing:
- The trap handler doesn't set the stack pointer, which can easily
result in trap loops or memory corruptions.
- The SBI trampolin page (as described in version 1.9 of the RISC-V
Privileged Architecture Specification), has been removed for now.
Change-Id: Id89c859fab354501c94a0e82d349349c29fa4cc6
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15591
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
And do the detection just before the initialization.
Change-Id: I9a52430262f799baa298dc4f4ea459880abe250e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15831
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
These functions are not used anywhere.
Change-Id: Ica1f4650e8774dd796be0aff00054f3698087816
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15829
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: If1c63971335a6e2963e01352acfa4bd0c1d86bc2
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15590
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This function is unused since coreboot starts payloads in machine mode,
and it uses the obsolete eret instruction.
Change-Id: I98d7d0de5a3959821c21a0ba4319efb610fdefde
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Using the opcode directly is necessary for the transition to the GCC
6.1.0 based toolchain, because the old toolchain only supports eret and
the new toolchain only supports mret.
Change-Id: I17e14d4793ae5259f7ce3ce0211cbb27305506cc
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15290
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I98927a70adc45d9aca916bd985932b94287921de
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15285
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Ron Minnich writes: "we'll change cbfstool to put a header on the
payload to jump to supervisor if that is desired. The principal here is
that payloads are always started in machine mode, but we want to set the
page tables up for them."
Change-Id: I5cbfc90afd3febab33835935f08005136a3f47e9
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15510
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ic42d8490cc02a3907e2989435aab786f7c0f39c9
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15287
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ib0535bf25ce25550cc17f64177f804a70aa13fb3
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The different entry points (0x100, 0x140, ...), which were defined in
the RISC-V Privileged Specification 1.7, aren't used anymore. Instead
the Spike bootrom jumps at the start of our image, and traps are handled
through mtvec.
Change-Id: I865adec5e7a752a25bac93a45654ac06e27d5a8e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Implement writeat and eraseat support into the region_device_ops struct.
Change-Id: Iac2cf32e523d2f19ee9e5feefe1fba8c68982f3d
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/15318
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This is where the RAM is (now), on RISC-V.
We need to put coreboot.rom in RAM because Spike (at the moment) only
supports loading code into the RAM, not into the boot ROM.
Change-Id: I6c9b7cffe5fa414825491ee4ac0d2dad59a2d75c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15149
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In the default (medlow) code model, pointers are loaded with a lui, addi
instruction sequence:
lui a0, 0xNNNNN
addi a0, a0, 0xNNN
Since lui sign-extends bits 32-63 from bit 31 on RV64, lui/addi can't
load pointers just above 0x80000000, where RISC-V's RAM now lives.
The medany code model gets around this restriction by loading pointers
trough auipc and addi:
auipc a0, 0xNNNNN
addi a0, a0, 0xNNN
This way, any pointer within the current pc ±2G can be loaded, which is
by far sufficient for coreboot.
Change-Id: I77350d9218a687284c1337d987765553cf915a22
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The uart8250mem driver needs it.
Change-Id: I09e6a17cedf8a4045f008f5a0d225055d745e8db
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: I12de8f82499074f0fbbc1c09210b00c6a9614c1b
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15146
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I9759771fa6fc708d7d97509c5f5e0cefb8ab4c96
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14962
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
It isn't used anymore.
Change-Id: Ie554d1dd87ae3f55547466e484c0864e55c9d102
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14567
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Utilize the architecture dependent coreboot table size value
from <arch/cbconfig.h>
Change-Id: I80d51a5caf7c455b0b47c380e1d79cf522502a4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14455
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Stefan and others have discussed their interest in only
including options in Kconfig that are directly associated
with building a coreboot image. There are variables that
are architecture dependent that are utilized in the
coreboot infrastructure. To meet that goal, introduce
<arch/cbconfig.h> header file which defines variables
for the coreboot infrastructure that are architecture
dependent but utilized in common infrastructure.
Change-Id: Ic4cb9e81bab042797539dce004db0f7ee8526ea6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14454
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
In order to de-duplicate common patterns implement one write_tables()
function. The new write_tables() replaces all the architecture-specific
ones that were largely copied. The callbacks are put in place to
handle any per-architecture requirements.
Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14436
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add a architecture specific function, arch_write_tables(), that
allows an architecture to add its required tables for booting.
This callback helps write_tables() to be de-duplicated.
Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
A architecture-specific function, named bootmem_arch_add_ranges(),
is added so that each architecture can add entries into the bootmem
memory map. This allows for a common write_tables() implementation
to avoid code duplication.
Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14434
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Each arch was calling cbmem_list() in their own write_tables()
function. Consolidate that call and place it in common code
in write_coreboot_table().
Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14430
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Instead of hard coding a #define in each architecture's
tables.c for the coreboot table size in cbmem use a Kconfig
varible. This aids in aligning on a common write_tables()
implementation instead of duplicating the code for each
architecture.
Change-Id: I09c0f56133606ea62e9a9c4c6b9828bc24dcc668
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14429
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Apparently the memo was missed about the write_tables()
signature. Fix the confusion.
Change-Id: I8ef367345dd54584c57e9d5cd8cc3d81ce109fef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14421
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This used to build, but will not with newer toolchains.
Change-Id: I0f397839eb85977ba18328b0e32040b15a6c3b0f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/14296
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
On non-x86 platforms, coreboot uses the memlayout.ld mechanism to
statically allocate the different memory regions it needs and guarantees
at build time that there are no dangerous overlaps between them. At the
end of its (ramstage) execution, however, it usually loads a payload
(and possibly other platform-specific components) that is not integrated
into the coreboot build system and therefore cannot provide the same
overlap guarantees through memlayout.ld. This creates a dangerous memory
hazard where a new component could be loaded over memory areas that are
still in use by the code-loading ramstage and lead to arbitrary memory
corruption bugs.
This patch fills this gap in our build-time correctness guarantees by
adding the necessary checks as a new intermediate Makefile target on
route to assembling the final image. It will parse the memory footprint
information of the payload (and other platform-specific post-ramstage
components) from CBFS and compare it to a list of memory areas known to
be still in use during late ramstage, generating a build failure in case
of a possible hazard.
BUG=chrome-os-partner:48008
TEST=Built Oak while moving critical regions in the way of BL31 or the
payload, observing the desired build-time errors. Built Nyan, Jerry and
Falco without issues for good measure.
Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13949
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Only i386 has code to support bounce buffer. For others coreboot
would silently discard part of binary which doesn't work and is a hell to debug.
Instead just die.
Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13750
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add lb_arch_add_records() to allow the architecture code to
generically hook into the coreboot table generation.
BUG=chrome-os-partner:50214
BRANCH=glados
TEST=With all subsequent patches confirmed lb_arch_add_records() is
called when a strong symbol is provided.
Change-Id: I7c69c0ff0801392bbcf5aef586a48388b624afd4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13669
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
Change-Id: I49292e69a5636c675bb8ed7cfe4462ca8189487e
Signed-off-by: Andrew Waterman <waterman@cs.berkeley.edu>
Reviewed-on: https://review.coreboot.org/13736
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Id547c98e876e9fd64fa4d12239a2608bfd2495d2
Signed-off-by: Andrew Waterman <aswaterman@gmail.com>
Reviewed-on: https://review.coreboot.org/13735
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
It is silly to have a single header to declare the main()
symbol, however some of the arches provided it while
lib/bootblock.c relied on the arch headers to declare it. Just
move the declaration into its own header file and utilize it.
Change-Id: I743b4c286956ae047c17fe46241b699feca73628
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13681
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
jmp_to_elf_entry() is not defined anywhere. Remove it.
Change-Id: I68f996a735f2ef3dd60cf69f9b72c3f1481cbb55
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It's no longer used. Remove it.
Change-Id: Id6f4084ab9d671e94f0eee76bf36fad9a174ef14
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13678
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|