My main payload is GRUB and I load SeaBIOS as secondary payload when for some
reason I want to boot windows. In this scenario SeaBIOS runs VGA oprom
(SeaVGABIOS is not good enough with intel gfx). VGA oprom expects either
completely uninited gfx or some special state in gmbus and software scratch
registers. Provide this state.
The only alternative without this patch for such usecase is to use oprom and
I'd like to avoid doing so when going my main boot path to GNU/Linux.
Change-Id: Ic157a6a580d7a5048ac28155e0d6b3433bbd1f2c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10239
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
My main payload is GRUB and I load SeaBIOS as secondary payload when for some
reason I want to boot windows. In this scenario SeaBIOS runs VGA oprom
(SeaVGABIOS is not good enough with intel gfx). VGA oprom expects either
completely uninited gfx or some special state in gmbus and software scratch
registers. Provide this state.
The only alternative without this patch for such usecase is to use oprom and
I'd like to avoid doing so when going my main boot path to GNU/Linux.
Change-Id: I38e78fb845e43b81df084cd4d65f4618bfb2506d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10205
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
0x20 was incorrectly represented as 4 * 5 while in fact it's 4 * 8
Change-Id: I6053a3baa6de0da9f1d648009353bc1fe542f81f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10237
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Sample code belongs to documentation, not copied 100x over prodcution code.
Change-Id: I6bb318d76057d02bd6ac5641d12d56ab6d60b745
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10229
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The vboot_context.h file hasn't been used since commit
6d65f796db. Remove it.
Change-Id: I57a6c619c6e1f57be6963da2954329bc9c007dd8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10223
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use cf9 to reboot at the end.
Change-Id: I642a5ec89c864fb03bbcdf6e4fcbb1e28f3fc34c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4693
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These are alternative customer options connected to J19 header.
We need to avoid modifying devicetree.cb, so we fix devicetree
for the super-io device-enables at runtime instead.
Change-Id: I04a79974b9bdf52b09ffc1b1362e201eab1ee011
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10178
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The non-module SMM programs were not being garbage collected
during linking. Do this so that one doesn't have to add dependencies
for unused functions in SMM.
TEST=Interrogated readelf -e smm.elf on both builds as well as diffed
the symbol table. Runtime testing was not done.
Change-Id: I31991496d92191e540df6340c587eec09c7022b3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10219
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fill out functions to get the offset and size for both
regions and region_devices. Additionally add a helper for
memory mapping an entire region_device.
Change-Id: I8896eaf5b29e4a67470f4adc6f5b541566cb93b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10215
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ifb19cf97d4db6c7394521e549968a0cfb6ed1c75
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0137652ca07e290bb3cb1cc82a00b44ac7bcc7bf
Original-Change-Id: Ica649927d3533c847b24e520e8fe73d75fb9e786
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/257375
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10170
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
disabled by GIC CPU interface. This is done by adding a bypass override
capability when the interrupts are disabled at the CPU interface. To
support this, there are four bits about IRQ/FIQ BypassDisable in CPU
interface Control Register. So the CPU can exit from WFI when an
asserted IRQ is coming. This is critical for power gating a CPU.
BRANCH=none
BUG=chrome-os-partner:39620
TEST=testing with CPU idle with power down state support and CPU can
wake up normally
Change-Id: I71ac642e28024a562db898665b74a5791fce325a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3a3f098cbf3fbfdab8150ebd4fd688fdb472b529
Original-Change-Id: I20569a18f34a4b11b8c8c67ea255b3d0f021839f
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/269116
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10172
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
This patch is based on commit f2b3cd63
(lenovo/x60: Support digitizer on X60t and X201t)
Tested on Thinkpad X200 Tablet (7450): all pen functionallity
works (i.e. movements, presure sensitivity and buttons)
Change-Id: I9bd18642a6ea4211dc3be065456a507fc0b72561
Signed-off-by: Alex David <opdecirkel@gmail.com>
Reviewed-on: http://review.coreboot.org/10208
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The check is wrong. On Acer Aspire One it returns 0 despite 2 DIMMs working
fine on the same channel if this check is disabled (tested by memtest).
On boards that have only 1 DIMM per channel, the code will simply find no
SPD and skip empty slot.
Change-Id: I5f2fdcd1d948ebf3eabebaea4441af4c19e47f8f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7568
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We already have APM_CNT_FINALIZE defined to the same value. Just use it
thoughout.
Change-Id: Ife94ec7a34da27d3a720bda7337c02e41f18ac72
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10226
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
add handling of PCI IDs for Broadwell-U/Wildcat Point LP,
using same functions as Haswell-U/Lynx Point LP
Change-Id: I1094cbdace3c73f0f85c2e27c676b877b1a04bfe
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10209
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The struct rockchip_spi_media type is no longer used;
nor is initialize_rockchip_spi_cbfs_media(). Remove them.
Change-Id: I2c24be249e0cd89e2dd328e05cdd24a178fe37e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10214
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These boards are not ThinkPads. Furthermore, autogenerated build.h
might not be generated yet to be included.
Change-Id: I084f632d45477abf5e3cb1b734e8048f554423ec
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10213
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Inclusion of ricoh driver was lost in 1d7b9de350.
So the relevant code wasn't even compiled.
Fix copy-paste mistakes without significance while on it as well.
Change-Id: Ie548cb43f986f147658fc9c67963f8a055250598
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10211
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The spi_flash API did not have any of its callbacks
documented. Do that so that people don't have to go
into the guts of an implementation to figure out the
proper expectations.
Change-Id: I55a0515445cab3697813d88373ee413f30b557b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10206
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently only RO-lock is supported. Make full lock available as an option.
Change-Id: Ib68a1e82733a51053a9adc80ac501b6205c6b8a7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10191
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
In order to facilitate platforms which need a buffer cache
for performing boot device operations provide infrastructure
to share the logic in managing the buffer and operations.
Change-Id: I45dd9f213029706ff92a3e5a2c9edd5e8b541e27
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9132
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide common code for using memory-backed region devices.
This allows in-memory buffers to act as a region device.
Change-Id: I266cd07bbfa16a427c2b31c512e7c87b77f47718
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9131
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The memory pool infrastructure provides an allocator with
very simple free()ing semantics: only the most recent allocation
can be freed from the pool. However, it can be reset and when
not used any longer providing the entire region for future
allocations.
Change-Id: I5ae9ab35bb769d78bbc2866c5ae3b5ce2cdce5fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9129
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The region infrastructure provides a means of abstracting
access to different types of storage such as SPI flash, MMC,
or just plain memory. The regions are represented by
region devices which can be chained together forming subregions
of the larger region. This allows the call sites to be agnostic
about the implementations behind the regions. Additionally, this
prepares for a cleaner API for CBFS accesses.
Change-Id: I803f97567ef0505691a69975c282fde1215ea6da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Routing is decided based on enabled logical/virtual devices.
For a valid devicetree, one should have only one of SP3 and GPIO0,
and only one of SP4 and GPIO1, enabled at a time in configuration.
Change-Id: I02017786aba9dd22d12403aaa71d7641f5bbf997
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10177
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
That function was getting too long.
Change-Id: Ic50f210391c2467b65215aa556269b0ba601c2ec
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10176
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Without this some radios may remain operational. They may consume power but
the immediate demonstrable effect is wireless LED still being on.
Coreboot will reenable radios on resume or poweron.
Change-Id: I9fcb08880964b1594f779a246840bc3013a44afe
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10190
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Move the 3rdparty/blobs marker to include the following:
a710941 amd/pi: Move AGESA cbfs access function to coreboot
63f1db5 AMD avalon: add PSP firmwares
Change-Id: Ie12b273ab9d22ab440b477919e70419b21cb833b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10202
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
When we are taking the recovery path there is no slot or
components to fill out.
Change-Id: Ic97a247629365ef54a340c4398cb7491935edc11
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10198
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The AGESA.c file in 3rdparty has cbfs access functions
for locating the AGESA binaries. coreboot access functions
need to be within coreboot where they can be updated with
cbfs changes. Move the offending function to coreboot.
Change-Id: Ibf6136d04dfbdb0198e90cc3ce719dc286c5610e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10058
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Our style discourages unnecessary typedefs, and this one doesn't gain
us anything, nor is it consistent with the surrounding code: there's
a function pointer typedef'd nearby, but non-opaque structs aren't.
BUG=chromium:482652
TEST=None
BRANCH=None
Change-Id: Ie7565240639e5b1aeebb08ea005099aaa3557a27
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Change-Id: I4285e6b56f99b85b9684f2b98b35e9b35a6c4cb7
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10146
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The cbfstool handling of new-style FMAP-driven "partitioned" images
originally disallowed the use of x86-style top-aligned addresses with
the add.* and layout actions because it wasn't obvious how they should
work, especially since the normal addressing is done relative to each
individual region for these types of images. Not surprisingly,
however, the x86 portions of the build system make copious use of
top-aligned addresses, so this allows their use with new images and
specifies their behavior as being relative to the *image* end---not
the region end---just as it is for legacy images.
Change-Id: Icecc843f4f8b6bb52aa0ea16df771faa278228d2
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10136
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These new-style firmware images use the FMAP of the root of knowledge
about their layout, which allows them to have sections containing raw
data whose offset and size can easily be determined at runtime or when
modifying or flashing the image. Furthermore, they can even have
multiple CBFSes, each of which occupies a different FMAP region. It is
assumed that the first entry of each CBFS, including the primary one,
will be located right at the start of its region. This means that the
bootblock needs to be moved into its own FMAP region, but makes the
CBFS master header obsolete because, with the exception of the version
and alignment, all its fields are redundant once its CBFS has an entry
in the FMAP. The version code will be addressed in a future commit
before the new format comes into use, while the alignment will just be
defined to 64 bytes in both cbfstool and coreboot itself, since
there's almost no reason to ever change it in practice. The version
code field and all necessary coreboot changes will come separately.
BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom and image.bin images with
and without this patch, diff their hexdumps, and note that no
locations differ except for those that do between subsequent builds of
the same codebase. Try working with new-style images: use fmaptool to
produce an FMAP section from an fmd file having raw sections and
multiple CBFSes, pass the resulting file to cbfstool create -M -F,
then try printing its layout and CBFSes' contents, add and remove CBFS
files, and read and write raw sections.
BRANCH=None
Change-Id: I7dd2578d2143d0cedd652fdba5b22221fcc2184a
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 8a670322297f83135b929a5b20ff2bd0e7d2abd3
Original-Change-Id: Ib86fb50edc66632f4e6f717909bbe4efb6c874e5
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265863
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10135
Tested-by: build bot (Jenkins)
verstage previously lacked serial console support.
Add the necessary objects and macro checks to allow
verstage to include the serial console.
Change-Id: Ibe911ad347cac0b089f5bc0d4263956f44f3d116
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10196
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
There was no indication of verstage being loaded. Provide this
output so that one can follow the flow from console messages.
Change-Id: I67ae6bb334608fe10a4a12fe690498afaf6b8366
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10195
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are more stages than currently handled in the
initial message from console_init(). Add support for those
including an UNKNOWN catchall.
Change-Id: I2374db590072bdca8ff35116e2ecb2ad6459b697
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10194
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In ee89435798 microcode for 306ax
was forgotten in migration.
Without microcode update my machine experiences random hangs and various
misbehaviour.
Change-Id: I61c704d88a8a0ed74a16fb3f80cce08e8515e6e2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10180
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add support to allocate a region just below CBMEM root. This region is
reserved for FSP 1.1 to use for its stack and variables.
BRANCH=none
BUG=None
TEST=Build and run on Braswell
Change-Id: I1d4b36ab366e6f8e036335c56c1756f2dfaab3f5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10148
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vladimir Serbinenko