This allows combining and simplifying linker scripts.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Drop the inner underscore for consistency. Follows the
commit stated below.
Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-on: http://review.coreboot.org/9290
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Extend lib/reg_script.c to use a platform table to declare
additional platform specific register access routine functions.
REG_SCRIPT_TYPE_PLATFORM_BASE is the starting value for platform
specific register types. Additional register access types may be
defined above this value. The type and access routines are placed
into reg_script_type_table.
The Baytrail type value for IOSF was left the enumeration since it
was already defined and is being used for Braswell.
BRANCH=none
BUG=None
TEST=Use the following steps to test:
1. Build for a Baytrail platform
2. Build for the Samus platform
3. Add a platform_bus_table routine to a platform which returns the
address of an array of reg_script_bus_entry structures and the
number of entries in the array.
Change-Id: Ic99d345c4b067c52b4e9c47e59ed4472a05bc1a5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2d9fecf4287dff6311a81d818603212248f1a248
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/215645
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: I7cd37abc5a08cadb3166d4048f65b919b86ab5db
Original-Reviewed-on: https://chromium-review.googlesource.com/229612
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9279
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The rmod_stage_load structure contained the same fields
as struct prog. In order to more closely integrate with the
rest of program loading use struct prog.
Change-Id: Ib7f45d0b3573e6d518864deacc4002802b11aa9c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9143
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Instead of having different structures for loading
ramstage and payload align to using struct prog.
This also removes arch_payload_run() in favor of
the prog_run() interface.
Change-Id: I31483096094eacc713a7433811cd69cc5621c43e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8849
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The prog_run() function abstracts away what is required
for running a given program. Within it, there are 2
calls: 1. platform_prog_run() and 2. arch_prog_run().
The platform_prog_run() allows for a chipset to intercept
a program that will be run. This allows for CPU switching
as currently needed in t124 and t132.
Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8846
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The struct prog serves as way to consolidate program
loading. This abstraction can be used to perform more
complicated execution paths such as running a program
on a separate CPU after it has been loaded. Currently
t124 and t132 need to do that in the boot path. Follow
on patches will allow the platform to decide how to
execute a particular program.
Note: the vboot path is largely untouched because it's
already broken in the coreboot.org tree. After getting
all the necessary patches pushed then vboot will be
fixed.
Change-Id: Ic6e6fe28c5660fb41edee5fd8661eaf58222f883
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8839
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Chrome OS devices firmware usually includes an area called VPD (Vital
Product Data). VPD is a blob of a certain structure, in particular
containing freely defined variable size fields. A field is a tuple of
the field name and field contents.
MAC addresses of the interfaces are stored in VPD as well. Field names
are in the form of 'ethernet_macN', where N is the zero based
interface number.
This patch retrieves the MAC address(es) from the VPD and populates
them in the coreboot table so that they become available to the
bootloader.
BUG=chrome-os-partner:32152, chromium:417117
TEST=with this and other patches in place the storm device tree shows
up with MAC addresses properly initialized.
Change-Id: I955207b3a644cde100cc4b48e51a2ab9a3cb1ba0
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 1972b9e97b57cc8503c5e4dc496706970ed2ffbe
Original-Change-Id: I12c0d15ca84f60e4824e1056c9be2e81a7ad8e73
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219443
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9207
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds plumbing necessary to ensure that the CBMEM WiFi
calibration blobs entry, if present, is referenced if the coreboot
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=none - the entry is not yet in the CBMEM
Change-Id: I072f2368b628440b6fe84f310eebc1ab945f809e
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d0330280369753a6520196425e6dfc7d7bd226a3
Original-Change-Id: I04d52934ad1c5466d0d124b32df5ab17c0f59686
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
currently, if the cache size is, for example, 4096 byte, mapping 4096 byte data
fails due to the overly strict check. this change allows cbfs_simple_buffer_map
to use all the cache space to the last byte.
BUG=None
TEST=Booted Nyan Blaze.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I0797b5010afd7316fdec605784e8f48e2d62c37f
Original-Reviewed-on: https://chromium-review.googlesource.com/218883
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit b0b31da336fa2f87fe73f063782d6243f8262d10)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I15e11e574cd14484fe83c9c3674bb5c2d14422f6
Reviewed-on: http://review.coreboot.org/9178
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the files which include cbfs_core.h don't even need
the header definition while others just need the cbfs API
which can be obtained from cbfs.h.
Change-Id: I34f3b7c67f64380dcf957e662ffca2baefc31a90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9126
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Instead of having 2 different functions to call when a program
is loaded provide a single callback with flags parameter. The
previous callbacks for cache management routines did this:
for_each_program_segment:
arch_program_segment_loaded(start, size);
arch_program_loaded();
Now, use one callback instead:
for_each_program_segment:
arch_segment_loaded(start, size, SEG_FINAL?);
Change-Id: I3811cba92e3355d172f605e4444f053321b07a2a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's no need to keep track of struct payload within
the boot state machine. It is completely contained within
the payload loader module.
Change-Id: I16fcecf43d7fb41fc311955fdb82eabbd5c96b11
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8836
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The functions related to caching ramstage were in cbfs.h.
Now that the loading code is separate move those declarations
to the common program_loading.h.
Change-Id: Ib22ef8a9c66e1d2b53388bceb8386baa6302d28b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The run_address() function is not used. Remove it.
Change-Id: I96de4cf0a529b08943ff8281cedead642eb415de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9124
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34
Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214371
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9080
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Two weak functions were added so that architecture specific operations
on each segment of payload or stage can be performed.
Each architecture must define its own operations, otherwise the
behavior will default to do-nothing functions.
This patch has been updated by to fit more in line with
how program loading is currently being done. The API is the
same as the original, but all call sites to stages/payloads
have been updated. This is known to break any archs that use
rmodule loading that needs cache maintenance. That will be fixed
in a forthcoming patch. Also, the vboot paths are left as is
for easier upstreaming of the rest of the vboot patches.
Original-Change-Id: Ie29e7f9027dd430c8b4dde9848fa3413c5dbfbfa
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/239881
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit c82c21ce87a4c02bd9219548a4226a58e77beef0)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ifcee5cd9ac5dbca991556296eb5e170b47b77af7
Reviewed-on: http://review.coreboot.org/8837
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Coreboot generic CBFS media API does not support
multiple media access instances, but it should.
With this fix the CBFS context (memory cache for
SPI accesses) is shared among all open media access
streams. A better memory management scheme might be
required, but for now this fix allows to support
booting deptcharge and accessing VPD through two
independent CBFS media streams.
BUG=chrome-os-partner:32152
TEST=no exception is thrown when the second stream
is opened
Change-Id: I62889089b4832c9e9760ef24ecc517220d8f3ec4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 691f9794805d04beff349f1bc60ac9d7530d7cbf
Original-Change-Id: Ib9d9d1f5209c2e515a95d7acbf4a8ac1255d3f8a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219441
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8897
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
nyan blaze fails to boot because tristates of the board id are interpreted in
the reverse order. this change fixes it.
BUG=none
TEST=Booted Blaze to Linux. Built firmware for Storm.
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I4ff8a15cf62869cea22931b5255c3a408a778ed2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3f59b13d615a8985edf2029d89af05e95aefad33
Original-Change-Id: I6d81092becb60d12e1cd2a92fc2c261da42c60f5
Original-Reviewed-on: https://chromium-review.googlesource.com/211700
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/8980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The name was changed due to review comments misunderstanding, it
should be restored to properly convey what the function does.
BUG=chrome-os-partner:30489
TEST=verified that Storm still properly reports board ID
Change-Id: Iba33cf837e137424bfac970b0c9764d26786be9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c0fff28c6ebf255cb9cf9dfe4c961d7a25bb13ff
Original-Change-Id: I4bd63f29afbfaf9f3e3e78602564eb52f63cc487
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211413
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8979
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I broke cbfs loading with commit 358901. As multiple
functions are being reused one needs to ensure there is
always a cbfs media object allocated on the stack and
initialized. Ya for no common writable globals.
TEST=Ran qemu-armv7. CBFS loading works again.
Change-Id: Ibd047af7dcd8575e6203651471079fc2042da282
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8973
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Board ID value is usually of interest to bootloaders. Instead of
duplicating the board ID discovery code in different bootloaders let's
determine it in coreboot and publish it through coreboot table, when
configured.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: Ia1e36b907ac15b0aafce0711f827cb83622e27bb
Original-Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210116
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit b2057a02db9391e2085b138eea843e6bb09d3ea2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8719
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In some cases, we need to use 1 common VGA device ID to share
among different VGA devices.
But it will show error when it can't find a specific pci rom
by PCI DID.
in fact, it will find the pci rom with common vga ID.
Without this commit, you may need to skip error check during
suspend_stress_test
BUG=none
BRANCH=none
TEST=build OK, and check no error on Auron and Samus
Change-Id: I2b18347e46c831038f048cfd0b065430c72c6f30
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c32ee21b4c942182e5ffb21b58b93fa7c082223
Original-Change-Id: Ib743e960f772b7e2e73a1feb80790a13bd8c06c7
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217415
Original-Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-on: http://review.coreboot.org/8821
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide a common run_romstage() function to be used by
bootblocks to load and run romstage. This is similar to
run_ramstage() in that it provides a single entry point
for doing the necessary work of loading and running romstage.
Change-Id: Ia9643cc091f97a836cf5caefdff8df4a3443df4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Vboot2 targets so far did not have COMMON_CBFS_SPI_WRAPPER
configuration option enabled, so the verstage is missing the relevant
files in some Makefiles. This patch fixes the problem.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied cosmos target builds fine
with COMMON_CBFS_SPI_WRAPPER enabled
Change-Id: I3ce78c8afc5f7d8ce822bbf8dd789c0c2ba4b99c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b72693c96f7d8ce94ce6fe12b316d5b88fded579
Original-Change-Id: Iab813b9f5b0156c45b007fe175500ef0de50e65c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223751
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8772
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Under certain conditions, e.g. automated testing, it is useful
to have the payload (e.g. Linux) reset the reboot_bits CMOS
value. This allows automated recovery in the case of coreboot
starting properly but the payload failing to start due to bad
configuration data provided by the coreboot image under test.
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Change-Id: Ifc8f565f8292941d90b2e520cc9c5993b41e9cdd
Reviewed-on: http://review.coreboot.org/8698
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203033
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I44dacc10214351992b775aca52d6b776a74ee922
Reviewed-on: http://review.coreboot.org/8055
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
They don't contain any useful information and
also block us from having reproducible builds.
Change-Id: Ib03887f6a548230de9f75fb308c73a800e180c48
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8616
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
At some point the license text for a file was incorrectly
changed. That license was then copied and pasted. I'm sure it
was myself. Anyhow, fix the bustedness.
Change-Id: I276083d40ea03782e11da7b7518eb708a08ff7cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As a convenience, print the actual stage name when entering a stage.
Also unify the banner between bootblock / romstage and ramstage. No
reason for two different occurences.
Instead of this:
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 booting...
you will see this:
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 bootblock starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 romstage starting...
[..]
coreboot-4.0 Tue May 13 14:13:37 PDT 2014 ramstage starting...
Roughly based on: https://chromium-review.googlesource.com/199671
Change-Id: Id5894535e0551d113c80e4ff0514287391be1bef
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8578
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
On x86, change the type of the address parameter in
read8()/read16/read32()/write8()/write16()/write32() to be a
pointer, instead of unsigned long.
Change-Id: Ic26dd8a72d82828b69be3c04944710681b7bd330
Signed-off-by: Kevin Paul Herbert <kph@meraki.net>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7784
Tested-by: build bot (Jenkins)
Add native XGI Z9s framebuffer support to coreboot
XGI initialization code largely taken from Linux 3.18.5
TEST: Booted KFSN4-DRE with XGI Volari Z9s into SeaBIOS
with SeaVGABIOS enabled. Text appeared correctly on screen
and interaction with graphical comboot menu was successful.
However, Linux cleared the framebuffer on boot, rendering the
screen useless until Linux loaded its native xgifb driver.
Change-Id: I606a3892849fc578b0c4d74536aec0a0adef3be3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8331
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
We can now create CBMEM with dynamic allocation even if CBMEM
location is resolved late in ramstage.
Change-Id: I8529ccbcd4a0e567ebe0a46232ac5d16476e81a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7861
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Move the CAR migration call to arch -specific part of CBMEM init,
it is truly a x86 specific thing.
Change-Id: I715417e54f197b8745e0670d6b900a5660178141
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7860
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Use the value of CONSOLE_PRERAM_BUFFER_SIZE to determine if we can
do CBMEM console in bootblock and romstage. Kconfig forces it to zero
if _BASE is unset or we cannot do CAR migration on x86.
Add CBMEM console to bootblock, except for x86. Only one of bootblock
and romstage clears the pre-RAM buffer.
To start with empty console log on S3 wakeup, ramstage now clears
previous contents of CBMEM buffer if there was no pre-RAM buffer.
Unify Kconfig variable naming.
TODO: ARM configurations do not define PRERAM_BUFFER_BASE values.
Change-Id: I70d82da629529dbfd7bc9491223abd703cbc0115
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7862
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This avoids the need for separate timestamp_reinit() calls made
via CAR_MIGRATE() that is not implemented for ARM.
Change-Id: Ia683162f3cb5d3cb3d4b7983a4b7e13306b0cfc8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8033
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This replaces need for separate cbmemc_reinit() calls made
via CAR_MIGRATE() and in ramstage.
Change-Id: If7b4d855c75df58b173f26ef3c90a4a7563166d3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7859
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
With the change it becomes irrelevant if memcpy() car.global_data or
cbmemc_reinit() is done first.
Change-Id: Ie479eef346c959e97dcc55861ccb0db1321fb7b2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8032
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Patrick Georgi