We had lots of casts that caused warnings when compiling on RISCV.
Clean them up.
Change-Id: I46fcb33147ad6bf75e49ebfdfa05990e8c7ae4eb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7066
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This really is not critical but we might as well get it right.
Change-Id: Ifec1e8dc35d7f5bb89d9a7a877d82410c83a3288
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7070
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Change-Id: I9b80b72de96fb28489dcc8547b8f748ea4fcc355
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7074
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
It's specific to butterfly. Doesn't do anything on lenovos.
Change-Id: I7b607196733225eace0f5e70b4cc02651488aa74
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6841
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As currently many systems would be barely functional without ACPI,
always generate ACPI tables if supported.
Change-Id: I372dbd03101030c904dab153552a1291f3b63518
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The offset of the device_nvs in the gnvs struct is expected to be
0x1000. It is actually 0x100 so padding is needed to move device_nvs
to the expected location. ACPI references to device_nvs objects will
be correct with the padding.
This was tested using a Micro Industries customized Baytrail-I board
based on the Intel Bayley Bay CRB. In intel/baytrail/nvs.h, there's
a Google customized structure located at 0x0100-0x0FFF that is
removed from the fsp_baytrail/nvs.h which explains the mismatch here.
Change-Id: I4721a79b53b5b3345ff9b0c053bdd31d2cf9cb61
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7038
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
ACPI globalnvs.asl expects the gnvs memory area size to be 0x2000.
Padding has been added to device_nvs struct to reserve the full
0x2000 bytes for gnvs usage.
No known issues are caused by having the GNVS area shorter than
what ACPI thinks. Since there's nothing defined in this area,
O/S shouldn't try to access it. Only problem might be if O/S
notices the SSDT is located within the GNVS defined area.
I verified that the next table written to memory (SSDT) is 0x2000
past GNVS start using a custom-designed Baytrail-I motherboard
based on the Intel Bayley Bay CRB.
Change-Id: I9792954c7a3403eba6f37d7e53ea4a9ed3a2e4ac
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7039
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Zero out the GNVS area so that uninitialized portions are defined.
Tests using Microsoft Windows (XP/7/8) gave a bluescreen bugcheck: A5
(ACPI_BIOS_ERROR) with the first parameter (0x00001000)
(ACPI_BIOS_USING_OS_MEMORY). Some ACPI enumerated devices use the
GNVS area to define whether they're enabled and their MMIO regions.
On my custom baytrail-based board and build, these devices were
disabled but GNVS had uninitialized data indicating the devices
were enabled with improper MMIO regions.
Should investigate further to see where the GNVS device values are
set if enabled and make sure they're set to valid values even when
the devices are disabled via the mainboard/devicetree.cb.
Change-Id: I2b575c65bfaab58ae6206ac6f457c259c27a7d97
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7040
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Windows chokes if it's not the case.
Change-Id: I3df15228ed00c3124b8d42fc01d7d63ff3fe07ba
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7017
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
With handling of this section removed it confused the linker.
Change-Id: Id096c1642c0bfed1007a4b7d7dfa89f8b4ffcae1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7042
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
According to ACPI spec all SSDTs should have distinct OEM table ID.
We end up with 2 SSDTs named "COREBOOT". Fix this.
Change-Id: I01bccb72758baf51c6b4263778716f4bb9d438c9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7016
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Otherwise "reserved" fields end up with a garbage instead of predictable
value.
Change-Id: I8a036769a8f86f1d6752651601de2800f4f1bd00
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7014
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Fix the error 'implicit declaration of function
"southcluster_smm_save_gpio_route"', when SMM module is added.
Change-Id: Ia050ab7e2b036541537b645d3fe4dc747cd1dff8
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7024
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
With SMM enabled the boot stopped while patching up global NVS in DSDT.
The cause is that both CPUs are assigned the same SMBASE address.
So update the "cpu_smm_do_relocation()" function so that each
CPU gets a different SMBASE address
Based on rmodule work that wasn't propagated to the FSP
version: commit 3eb8eb7eba
Change-Id: I77cd27d3a4f207411a689b5be572b4406a03f16b
Signed-off-by: Kayalvizhi Dhandapani <kayalvizhid@ami.com>
Reviewed-on: http://review.coreboot.org/7026
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
The static library builder for the stub that interfaces to the
AGESA binary does not include config.h and kconfig.h, so any
header file changes that depend on Kconfig variables fail. Force
these two system headers to be included in the build of any AGESA
stub files.
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Change-Id: I2e8d38fa5aa21cc31b995ee3abe68ab3c3c55a68
Reviewed-on: http://review.coreboot.org/6979
Reviewed-by: Martin Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins)
RISCV is a new architecture. This change simply setups up xcompile
to detect and use RISCV compilers if they are found.
Change-Id: Iad1a88ef2e3c8dd1e601549aeca26fb29b2bc7ae
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7023
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's not been needed for years, is definitely not needed now
that cbfstool parses bzImages, and its presence keeps confusing
people.
Also, rewrite history. We never mentioned mkelfimage in the
documentation. Never, ever, ever.
Change-Id: Id96a57906ba6a423b06a8f4140d2efde6f280d55
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7021
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In E-EDID (EDID v1.3), Monitor Name (0xfc) and Monitor Range Limits (0xfd) are
always required. However, some panels do not really have these fields. As a
workaround (and since we don't really use these fields), we only print warning
messages for that case.
Change-Id: I81b1db7d7f6c6f9320a862608dec4c7be298d7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193742
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c633215ef8342664d9a4478e821fc8aad368b7f3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7009
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On non-x86 systems, the location of the preram CBMEM console may not be in a
predictable place relative to other things in the linker script. That makes it
difficult to work with as its own section because the linker will complain if
you try to move backwards as it lays out memory. If the console header is
treated as an actual blob of memory which has to be put in the image, we'd
have to predict where to put it so that it isn't before something with a lower
address or after something with a higher address. Symbols, on the other hand,
can be defined arbitrarily.
Change-Id: I3257b981eee0c15bb997a9f2c55a03494c6ec6f0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/193164
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a492761c27076bcac080013d509ae4aafd6dc3e3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7013
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Typically assert.h should provide assert().
Change-Id: I465f4a616b212f7b00d445c575866b13eecfa6fb
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187410
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 3990584ac8e1ec9b3838bd9dfdf8a9cb2d20fbd0)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6961
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Copied (and unmodified) the minimal bits from ChromeOS libVPD:
https://chromium.googlesource.com/chromiumos/platform/vpd
Old-Change-Id: Id75d1bfd16263ac1b94c22979f9892cf7908d5e6
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187411
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
(cherry picked from commit a10ca23686299f3fd5b639631242cadaa2ca9e8a)
vendorcode: Update ChromeOS VPD Parser.
Merge recent changes in ChromeOS VPD that allows non-memory-mapped firmware
to load VPD easier and faster (ref:
https://chromium-review.googlesource.com/188134 ).
Old-Change-Id: I3ee0b89c703f476f3d77cdde52cc7588724f7686
Reviewed-on: https://chromium-review.googlesource.com/188743
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 03f4d521a7fa711b963b0e1822e92eac16a691b1)
vendorcode: Access to ChromeOS VPD on default CBFS media.
The new function "cros_vpd_gets(key, buf, size)" provides an easy and quick way
to retrieve values in ChromeOS VPD section.
Old-Change-Id: I38e50615e515707ffaecdc4c4fae65043541b687
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187430
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
(cherry picked from commit bcd3832c06e8ed357c50f19396da21a218dc4b39)
Squashed 3 related commits for a ChromeOS VPD parser.
Change-Id: I4ba8fce16ea123c78d7b543c8353ab9bc1e2aa9f
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6959
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
In order to enumerate CPU devices that are non-x86 (read: no lapic)
provide a generic 'cpu' device.
Change-Id: Ifeafdad8076935c3448784e6958117002509acbf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6824
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It is hard to see where things are coming from without correct headers.
Change-Id: I8e2195b101501ffd25464196283fb2bddb5b8f51
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5980
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When preparing an image for source level debugging, it is convenient
to be able to compile some modules with -O0, which makes it much
easier to follow the execution flow.
This patch allows to do it by defining GDB_DEBUG=1 in the environment
before invoking make. Adding this feature as a common config flag is
problematic, because we don't want to compile the entire image with
-O0.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196359
(cherry picked from commit dde4928c045d12e502cb109015a710cd9fdf2a04)
Changed from CFLAGS to CFLAGS_common.
Change-Id: Ie0be653509509eeb64ea3a7229f54c0c812840a9
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7005
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There is a status bit for this event in most intel chipsets that
we can read and report. Start by adding the new event type.
Change-Id: Ib06411e3b87a1d069fb469943dd445bee6c1291f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199370
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 386a06170ec5afb31d0fe93ace3afbaab897a598)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7004
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If a port is connected before and after an xhci controller reset, the
PORTSC CSC bit may not be asserted. Add an additional check in
xhci_rh_port_status_changed for the PRC bit so we can correctly handle
ports in such a state.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I2d623aae647ab13711badd7211ab467afdc69548
Reviewed-on: https://chromium-review.googlesource.com/189394
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ee7c3ea182b35bb6ce3c62f301c4515714f6e654)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7002
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The generic roothub reset port function is overly broad and does some
things which may be undesirable, such as issuing multiple resets to a
port if the reset is deemed to have finished too quickly. Remove the
generic function and replace it with a controller-specific function,
currently only implemented for xhci.
Change-Id: Id46f73ea3341d4d01d2b517c6bf687402022d272
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189495
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 54e1da075b0106b0a1f736641fa52c39401d349d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7001
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It brings in useless dependencies, a weird autotools
configuration, and tons of pain everywhere.
Instead just build things ourselves.
Change-Id: I67f06e711cb9dcd594363bc1a4f99d3273074549
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6986
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Replace it with the existing #define
Change-Id: I6e67ed1a455cd4f9eeed1865b9ef981e7ef0a874
Found-by: Idwer Vollering
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6992
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
These have apparently never been used because they are
incorrect.
Change-Id: I3624cb2548a0ee3da56a2cca62ed50b0dfbf7817
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196266
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit bc0187702061fe326422c070c592a18cd93de723)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6999
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EDID v1.4 has changed some fields (0xfc - Monitor Name, 0xfd - Monitor Range
Limits) to optional so we need to list the requirements explicitly instead of
sharing v1.3 requirements.
Change-Id: I5c7ca06893bd20e178bc35164c4ca639c881e00b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193013
(cherry picked from commit 2ad598b8bd620117e70e13347365d74a7c6b87ef)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6998
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Vladimir Serbinenko