This patch adds code to read the board ID from Pinky and put it into the
coreboot table.
(Note: This implementation differs slightly from Tegra since it pinmuxes
the GPIOs inside board_id(). That means the pinmuxing might be set more
than once if called in multiple stages, which is perfectly harmless and
in my opinion cleaner than having to (remember to) do it manually in one
of the per-stage files.)
BUG=chrome-os-partner:30167
TEST=With depthcharge patch, select -rev1 device tree for board ID 0.
Change-Id: I265fafcb176a31a46f7792ecf352f1671be7dd41
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9da10ce8b62ec98243fc7c82544b3004316799a8
Original-Change-Id: I5b5689373e1e47b1e0944b5fe5f2e70a285b931f
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217675
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8870
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
We retroactively decided to use the variant name "pinky" for the Rk3288
board we're currently bringing up, and retcon the unadorned "veyron"
name to refer to the Rockchip evaluation board. Since we currently have
no interest to maintain coreboot support for that board in our tree,
let's rename everything to "veyron_pinky" and forget about "veyron".
CQ-DEPEND=CL:217592
BUG=chrome-os-partner:30167
TEST='emerge-veyron libpayload coreboot' fails but
'emerge-veyron_pinky libpayload coreboot' succeeds.
Change-Id: I88bf5cc2da7c2f969ea184b5f12affaa94045a06
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aa8ec24b63d11798fec1993091b113a0c0938c7a
Original-Change-Id: I366391efc8e0a7c610584b50cea331a0164da6f3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217674
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8869
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some files for the veyron project were checked in with execute
permissions where it doesn't make sense. Fix.
BUG=chrome-os-partner:30167
TEST=None
Change-Id: I2a96816d4fd0af3949b0adaf5208fd2862835b5b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d7a408ff273d848b60aaad4f8b27103318e56111
Original-Change-Id: Ia3788abf3755baf028518efb975701cf6cb37e46
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217673
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8868
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Supports DDR3 and LPDDR3.Supports dual channel.ddr max freq is 533mhz.
ddr timing config file in src\mainboard\google\veyron\sdram_inf
Remove dpll init in rk clk_init(), add rkclk_configure_ddr(unsigned int hz).
BUG=chrome-os-partner:29778
TEST=Build coreboot
Change-Id: I429eb0b8c365c6285fb6cfef008b41776cc9c2d9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 52838c68fe6963285c974af5dc5837e819efc321
Original-Change-Id: I6ddfe30b8585002b45060fe998c9238cbb611c05
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209465
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8865
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
BUG=chrome-os-partner:29778
TEST=Build coreboot
Change-Id: I23af280764eb28d3f6b215ab32553fe42ee73272
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: abf5c14c8b32573107d2a1c73a752e740264db7e
Original-Change-Id: I46257cc71cc3cd1e867edf589ddf09f7990d6784
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209462
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8863
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
BUG=chrome-os-partner:29778
TEST=Build coreboot
Change-Id: I74b30ecfe40c039855b835db0dfd0cd25adf960e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a30378a3152c930029a5b170cc6bf46180b5c7b8
Original-Change-Id: I5105e5277b8072c06bb41b39479373697ef81c67
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209468
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8860
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
In order to display a "update in progress" screen on devices with
a slow EC or PD chip it may be necessary to also load the VGA
Option ROM when doing EC software sync.
This adds config options for VBOOT_EC_SLOW_UPDATE which simply sets
a flag in the input parameters that is already handled by vboot.
It also adds a config option for VBOOT_OPROM_MATTERS which is a bit
more tricky in that it sets a flag in input parameters, but also
needs to keep track of the option rom being loaded and pass that
flag into VbInit as well.
Since VbInit will clear the NV bit for option rom loaded the check
that is done in vboot_wants_oprom() needs to first compare against
the vboot handoff copy of the input flags.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Original-Change-Id: Ic2b34bf9e7c6cc5498413fa1b8dff6e6207c9d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223831
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 7d7aa89238efb5081885f9386c8e872fc96f573f)
Change-Id: Ib7fb24e6e80e1f7e836bc62246ab9b3e056fd73d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
this change makes coreboot initialize kernel space and backup space in the tpm
when no firmware space is found in the tpm.
BUG=chrome-os-partner:32410
TEST=Forced factory initialization and verified it went through without errors.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I777e3cb7004870c769163827543c83665d3732b9
Original-Reviewed-on: https://chromium-review.googlesource.com/220412
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit d8c0c407bf0fed60d76441ada7bedd36f6fc3a38)
Change-Id: Icc3779125262b4499e47781991ebbf584abf074a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change makes prevent execution from falling through to unverified
code when hard_reset is not implemented. it also includes a few touch-ups.
BUG=None
TEST=Booted Veyron Pinky. Verified firmware selection in the log.
BRANCH=None
Original-Change-Id: I9b02ab766172a62c98b434c29f310bc4a44f342d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219625
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit d1f5207d83d2247b55f2bb9d02ac843305fc3ded)
Change-Id: I99dd5a2ca3a5369accb14408ea9d266bf60e7132
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Original-Reviewed-on: https://chromium-review.googlesource.com/212365
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Note: This purposefully is probably broken in vendorcode/google/chromeos
as I'm just trying to set a base for dropping more patches in. The vboot
paths will have to change from how they are currently constructed.
(cherry picked from commit 4fa17395113d86445660091413ecb005485f8014)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9117434ce99695f9b7021a06196d864f180df5c9
Reviewed-on: http://review.coreboot.org/8881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change reduces the code duplication of the bootblock and the romstages for
Nyans.
BUG=none
TEST=Built Nyan, Big, and Blaze. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: dnojiri@chromium.org (Daisuke Nojiri)
Original-Change-Id: Ieb9dac3b061a2cf46c63afb2f31eb67ab391ea1a
Original-Reviewed-on: https://chromium-review.googlesource.com/214050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit f3413d39458f03895fe4963a41285f71d81bcf5f)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I912f63b12321aa26a7add302fc8a6c4e607330ef
Reviewed-on: http://review.coreboot.org/8880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This introduces a new kconfig variable to select the VBNV backing
store explicitly instead of inferring it from CPU/SoC architecture.
x86 platforms have historically relied only on CMOS to store VBNV
variables, while ARM-based platforms have traditionally relied on
the EC. Neither of those solutions are going to scale well into
the future if/when CMOS disappears and we make ARM-based systems
without an EC.
BUG=chrome-os-partner:29546
BRANCH=none
TEST=compiled for nyan_blaze and samus
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I4a8dadfb6bb666baf1ed4bec98b29c145dc4a1e7
Original-Reviewed-on: https://chromium-review.googlesource.com/213877
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit d088fc71b2e2b45e826d3dedb8e536ad58b8d296)
Change-Id: Iea325a8c4d07055143e993d89b827f86b8312330
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
rmodules ccopts contain information about specific arch like armv4,v7. Hence, it
is important to include them in VBOOT_CFLAGS
BUG=None
BRANCH=None
TEST=Compiles correctly for armv4 in rush
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id:
Original-Change-Id: I8f5509f753e28046678c3782d6f0b6210559f798
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209979
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit ca9f2f86ff1bc445abf5f97f61c04b6eccbd3e25)
Change-Id: I6cd7c47f33cf897d8ee96e7154222b3bfbe5221f
Reviewed-on: http://review.coreboot.org/8775
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to more cleanly apply upcoming changes some files
will need to do a dance.
Change-Id: Ib50670743c10221785447490190ecdbff8c764fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8654
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.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>
These boards are supposed to be able to determine the board ID at run
time based on GPIO settings.
BUG=chrome-os-partner:30489
TEST=verified that all boards build. Checked that storm proto0 reports
board ID of 0 on the console
Original-Change-Id: Iadd758a799d69e1e34579d7d495378856b64c45b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210119
(cherry picked from commit f4d41ddf906c1bf0d10da38011998fa0a630c332)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d5f94d3428157a70f0a9d711b57432e3f796733
Reviewed-on: http://review.coreboot.org/8722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
storm uses three GPIOs in tertiary mode, such that proto0 returns
value of 8 when the GPIOs are interpreted as a single tertiary number.
Adjust the calculated value to return board ID of 0 on proto0, and
monotonously incrementing values on newer boards.
BUG=chrome-os-partner:30489
TEST=when enabled, the board ID value of zero is reported on the console.
Original-Change-Id: I2ff8fd5cbc8d568877b6f8bf220e146893f1e4be
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210118
(cherry picked from commit 6ba24f31583933f02be111c8767ae9df56537011)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I35ee218df35a0924d4bb8fcbc6c875450a609f24
Reviewed-on: http://review.coreboot.org/8721
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For the majority of Chrome OS boards there is no need to include board
ID calculation in any stage but ramstage, where the ID should be
available for inclusion into the coreboot table.
BUG=chrome-os-partner:30489
TEST=build only, no other tests yet
Change-Id: I1451d52382bc48cc126d40267e0f61712f4a6d4b
Original-Change-Id: Ib9c06698a399d31e79a9b14143343ba2ad46d0fb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210117
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 27dd40e85bfcd0a38f388bad4d79f5fbb77a7566)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8720
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@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>
Add implementation of the GPIO API defined in src/include/gpiolib.h.
Also, clean up the GPIO driver, make it use pointers instead of
integers for register address.
This requires a touch in the SPI driver, where the CS GPIO is toggled
and in the board function where it enables USB interface.
BUG=chrome-os-partner:30489
TEST=tested with the following patches, observed proto0 properly read
the board ID.
Original-Change-Id: I0962947c6bb32a854ca300752d259a48e9e7b4eb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210115
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit e951f735001509d135cc61530ed0eecb5fc31a85)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8a612dce000931835054086c1b02ebfc43dc57d2
Reviewed-on: http://review.coreboot.org/8718
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Bootblock stack on Danube should be SRAM and defined separately from
the rest of the coreboot stack. The actual coreboot stack will be
defined later.
The top of the stack should be above the bottom, as the stack grows
towards lower addresses.
BUG=chrome-os-partner:31438
TEST=ran bootblock on simulator under codescape, observed stack
properly initialized.
Change-Id: I43d2bae5f85a09a95ca0103b253399bd92555aef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e02724cb4b30990ebaa631dabb45917af29d6437
Original-Change-Id: I3c37c8b5a1c0e7fd19411558a8f6d899fc283191
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218732
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8767
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add basic board support for the ImgTec Danube Virtual Platform, which
emulates a system built around the Danube SoC.
Run this by loading coreboot.bimg into a flash device connected to SPFI1
chip select 0 & then executing the Danube boot ROM.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: Ia62af62804bab261f3cabf7c2e62f5bb08a4a1a4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6cb1017f5e2fec85f7f5c60cd2cfec63cc886b49
Original-Change-Id: I7a2b52f304bcb4b614440ec38975e05f38b0e590
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207976
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8766
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Actual timer support is not yet available for Danube, it will be added
soon. For now, just to make the target build, modify it to use
GENERIC_UDELAY and HAVE_MONOTONIC_TIMER configuration option.
BUG=none
TEST=the target builds again
Change-Id: Iad1ceb966d5dbc8687b966be4d2506c8f92eba5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 261837539fb5a31f96e682edbcbbbc0e588f2750
Original-Change-Id: Ie3289eace9d2baadd01bd641b5dffc635ac80c0f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220395
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8765
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Romstage initialization code does not need to be board specific, keep
it in the SOC directory. Should there be a need for the board specific
code, it can be added later.
BUG=chrome-os-partner:31438
TEST=with upcoming patches, the urara board coreboot builds fine
Change-Id: Ib619fa9313d463ded13e9259e50bb5aeaab4fb05
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c08977aaa5e9b5da29359d1920d7d8b61ce86d3
Original-Change-Id: I27e2d225bd36c42ccd29128d0ea9a970566c02af
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/215992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8764
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Iniitialize I2C bus required for TPM operation. Problem observed was that if
frequency is raised above 20KHz, TPM starts responding with NAKs either for
address or for data. Need to look into that.
BUG=None
BRANCH=None
TEST=Compiles successfully and TPM success messages seen while booting.
Original-Change-Id: I9e1b4958d2ec010e31179df12a099277e6ce09e0
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/210001
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 01e87ae35431147f442e3f3e531537b8f0de1c9d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7dddc39d77f9a726fa51dd58ea9b7712c9a6fae2
Reviewed-on: http://review.coreboot.org/8715
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Enable L1 Sub-State when both root port and endpoint support it.
[pg: keyed the feature to MMCONF_SUPPORT, otherwise boards
without that capability fail to build.]
Change-Id: Id11fc7c73eb865411747eef63f5f901e00a17f84
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6ac04ad7e2261846e40da297f7fa317ccebda092
Original-BUG=chrome-os-partner:31424
Original-TEST=Build a image and run on Samus proto boards to check if the
settings are applied correctly. I just only have proto boards and
need someone having EVT boards to confirm the settings.
Original-Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Original-Change-Id: Id1b5a52ff0b896f4531c4a6e68e70a2cea8c736a
Original-Reviewed-on: https://chromium-review.googlesource.com/221436
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/8832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There was an empty udelay() implementation result in 0 waits.
Provide an actual implementation.
BUG=None
BRANCH=None
TEST=Built and ran through to depthcharge on rush.
Change-Id: Ia7060566a71c36bb7e4543c2fe4ee49d168518c7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c8832e73de238358ea801ccd7c2330de35a7b40e
Original-Change-Id: I201f2fdc4e4f5c88d48e4002839b03e808a5a1bc
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210827
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8830
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of using rela_time use the stopwatch API as the
semantics fit perfectly with the expiration usage.
BUG=None
BRANCH=None
TEST=Built, but similar usage tested on tegra132.
Change-Id: I1147f2bed84b93d1b776205df9ae04d1db9c98a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c38e054dd166d5eb53f692833b5ce88a230816e3
Original-Change-Id: I6d3f3da4e035e872890d8b67947b17a981673dba
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8819
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of open coding the monotonic timers use the stopwatch
abstraction.
BUG=None
BRANCH=None
TEST=Booted and noted timings work as expected. Built with software_i2c
and no compilation failures.
Change-Id: Ie5ecdd5bc764c1ab8ba4a923e65a1666aacd22f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c7bffb5aeb41e9b88cd2c99edd6abc38f1dc90af
Original-Change-Id: I0170fe4b93d9976957a2dcb00a6ea41ddc0320ce
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219495
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8817
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Simplify the SPI timeout by using the stopwatch.
BUG=None
BRANCH=None
TEST=Built nyan. Confirmed stopwatch works independently.
Change-Id: Ida26a0748d4b5a6a28aa8f6e2b92fe2ee4cbe17f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 900d7ac826b76d49290033c87849bf776684f2c1
Original-Change-Id: I84b7949060326b7c6cc1872420b93bd44604c4d3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219493
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8816
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's a lot of places where expiration and running time are
open coded. Allow for those places to be simplified by adding
a stopwatch construct. The stopwatch can have an expiration or
just be used to accumulate time.
BUG=None
TEST=Built and verified API works as expected by using implementation.
Change-Id: Ibd636542b16d8554f1ff4512319a53dce81c97e5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bc623a1b36eb08c5877591c4509cd61131c62617
Original-Change-Id: I53604900fea7d46beeccc17f1dc7900d5f28518b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219492
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8815
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These modules are necessary to resolve external names when building
the board image. These are just skeletons for now which will be filled
later.
BUG=chrome-os-partner:31438
TEST=when config is enabled, emerge-urara coreboot succeeds. more
extensive testing to come later
Change-Id: I0fcb5d33187172ecac77041425402b33e89e8944
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 94ec79b0ab872f5c5fe7db5bef5fdabf77d6b3b6
Original-Change-Id: I69cc178976a910ebf8031ed9ac9ad67b4cc0878a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/215678
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8763
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add build infrastructure and basic support code for the ImgTec Danube
SoC. This support is sufficient to run on a simulator.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I59e36589765bf06b075fd4850215a0ef71246bb1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 881278d7fbb8e6803bc8f6f9e84c64640b097401
Original-Change-Id: Ia7ed7288b13085db7ff37b5ad75d978b6137f958
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8762
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the proper configuration flags enabled, do_printk is available
from src/console, no need to define it elsewhere.
BUG=chrome-os-partner:31438
TEST=with upcoming patches, the urara board coreboot builds fine
Change-Id: I82071b4ca1686639c0bd39c63a06b61cb5bf5571
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 69c655537c50274a61cf123b7fc387ec60dd29c7
Original-Change-Id: Ib1e3e5750cdc1adc509b4580a4f24d3ff3b105ee
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/215862
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8761
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the build infrastructure and basic architectural support required
to build for targets using the MIPS architecture. This is sufficient
to run on a simulator, but will require the addition of some cache
maintenance and timer setup in order to run on real hardware.
BUG=chrome-os-partner:31438, chromium:409082
TEST=none yet
Change-Id: I027902d8408e419b626d0aab7768bc564bd49047
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fcc0d934d7223922c878b1f87021cb5c2d7e6f21
Original-Change-Id: If4f99554463bd3760fc142477440326fd16c67cc
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207972
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8760
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As MIPS toolchain does not provide adequate support for 64 bit
division and shift operations, the missing functions are required to
be provided by the user.
This patch brings in the Linux implementation of the 64 bit arithmetic
shift borrowed from arch/mips/lib/ashldi3.c (eg. Linux v3.14).
BUG=chromium:406038
TEST=With the upcoming patches coreboot successfully builds for MIPS
targets in chroot (coming later).
Change-Id: I2168f69352a9b9e3c5d197489f701a442e65703c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ec616161be8ad3aeb6494e7121615e3329b414d
Original-Change-Id: Ia1ccb29d4c9f3c95e04e06f6af7ce8a00e2e7455
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/214156
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8759
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Certain boards need to speak proto v3 over i2c. Leverage the
transport agnostic API to share the logic with other proto v3
impelementations.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built and ran on ryu. Can talk to the EC successfully.
Change-Id: I1d0cd6907057af4ded3c4460193bbe1d897a1db7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cb9ac965ad04c9491f40fd9aa595176a28a467b3
Original-Change-Id: Ib699120fd232392e8caa0889c2bf40f4587a8a35
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211139
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8828
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Depending on the transport mechanism for proto v3 different bytes
need to be send and/or read before the request and response. Depending
on the software and/or controller interface that requirement leads to
needing to copy data into temporary buffers. Avoid this by allowing
the transport mechanism to provide the request and response
buffers.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=Built for rush and ryu. Ran on ryu with i2c implementation.
Also built for rambi to check x86 systems.
Change-Id: I35d4d69bd1fa900fc0cfe3822496f381405bdcb1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c7224426e1d0bcf06ed010131a2462a6ca201d8b
Original-Change-Id: Iad6cce566a253ca72e6f5009a97235ece0a6c1b5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211138
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8827
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The EC doesn't return any data when one performs a write to
VBNV context. Therefore there is a mismatch of expectations.
Correct this by properly setting the expected response length.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=No longer hanging while writing to VBNV on ryu.
Change-Id: I7077a507c3280358dac1f88ece62cacee9b71bea
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c1735c3377163aeb9e90155cb9f081a1eea919c9
Original-Change-Id: I455724f20f5442bd62a792f09273227417475f07
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211137
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8826
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's helpful to view program size by inspecting the symbols.
_start and _end exist on romstage and ramstage. In order to
be consistent add _end for bootblock too.
BUG=None
BRANCH=None
TEST=Built and noted bootblock has _end symbol.
Change-Id: I06634b317e957e8271bf32530a56b5541c79b9ee
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b4ac926b30749d22e90a6f12ebac52107e241526
Original-Change-Id: I7f0b4dd4078c7d23c70949563b4c3f4df9e66142
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210832
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8824
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
It causes fan top speed due to this bug + our board-specific workaround,
and causes invalid temperature sensor readings.
Therefore, re-configure the register "External Temperature Sensor Host
Control Register" to terminate processes when this issue happens.
BUG=chromium:402204
TEST=ran suspend_stress_test 500 times
Change-Id: I439d5de798fbe999e4eec5497e6969b7b453121b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b82f2922c7fce3ca6b2797a8d9775e9db2817fe9
Original-Change-Id: I6e71b6a46a31b00e541c304f1ed58c1678c1d42e
Original-Signed-off-by: Ryan Lin <ryan.lin@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219445
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/8820
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When adding gargabe collection to x86 the --gc-sections
flags was inadvertently missed when linking romstage_null.debug.
Fix this omission.
Change-Id: I7d2700755afa78459c6f8707303a0e64936a1a9f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8850
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_romstage() to perform
the necessary work to load and run romstage.
Change-Id: Id59f47febf5122cb3ee60f9741cfb58cb60ccab5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8711
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_ramstage() to perform
the necessary work to load and run ramstage.
Change-Id: I37b1e94be36ef7a43efe65b2db110742fa105169
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8710
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Miraculously a console is being compiled in for romstage.
However, as no calls were potentially printing to the preram
console this was being ignored. Instead provide the symbol
required so as not to fail the build.
Change-Id: Id8f0b6e6d15b41fa7fe1b63bf2d91f15baa0edda
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8712
Tested-by: build bot (Jenkins)
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>
GD25LQ64C and GD25LB64C have the same ID and settings.
BUG=chrome-os-partner:25907
BRANCH=baytrail
TEST=Boot with GD25LQ64 and check MRC data save/restore works.
Change-Id: I8a4aa7cabd9a7657c2f0bae255a87341db3f1061
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20b5896adbbbdedcb1b7de435466dcc6bfa703cb
Original-Change-Id: I86d1e69552b6000faa9e0523356e27d7e2a6a6db
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193238
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8770
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This allows us to use the driver before ramstage.
BRANCH=none
BUG=none
TEST=built and booted on Pinky
Change-Id: I0700388b0e4e0562e3c0a52863c8357097bfd8d6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cd57587dab74de509d5c50cfc1ad337d765af6c8
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I0ce901331e401274254b8889484ffb41359119fa
Original-Reviewed-on: https://chromium-review.googlesource.com/235864
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8774
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When the driver is included in bootblock, malloc() is not available.
Come to think of it, it is perfectly fine to use a statically
allocated structure for the SPI device descriptor - coreboot is
unlikely to require concurrent support of multiple SPI devices of the
same kind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=bootblock on the FPGA board recognizes the installed Winbond
device:
coreboot-4.0 bootblock Tue Nov 11 07:27:24 PST 2014 starting...
SF: Detected W25Q16 with page size 1000, total 200000
Change-Id: Iea1936a219d38848580a10f75eb8bbcab17e6507
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0b4082442aa526d387a80cb5872d78670e6b468b
Original-Change-Id: Iaa69d610ef18e69b1ae5ade2d958f9fe1595a723
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228959
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8771
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
S25FL116K family uses the first 3 bytes in response to a legacy identification
command (9f) while previously supported models use the last 4 bytes. This change
defines identify functions to allow both types to be handled correctly.
BUG=none
BRANCH=tot
TEST=verified romstage is loaded on cosmos development board.
Change-Id: I1970a9af17e81299fada5029724d405de4022156
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 65ff436db2355cb68a766a3dedbcd7e2f765e6db
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Icdd2645e356652672c4482e7b805da1bc0f21e71
Original-Reviewed-on: https://chromium-review.googlesource.com/234431
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8773
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a macro to check if a value is aligned.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio.
Change-Id: I0680954eb1b1964a631527f96aa0570a32944fa1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f1717648e0a4b54217d71f8d0a15d496737d156
Original-Change-Id: Ie0bc1374918a7ffaaec5fea62c1193a42edd416c
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246692
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8757
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
mainboards/amd/fam10: Initialize cbmem area after raminit
When GFXUMA is enabled, CBMEM is placed at TOM - UMASIZE
When GFXUMA is disabled, CBMEM is placed at TOM
This matches the behaviour present before conversion to early
CBMEM.
The CBMEM location code implicitly assumes TOM does not change
between romstage and ramstage. TOM is set by romstage raminit,
and is never changed by romstage or ramstage afterward. As
the CBMEM location is positioned at a specific offset from TOM
that is known to both romstage and ramstage early CBMEM is safe
on Fam10h systems.
TEST: Booted ASUS KFSN4-DRE and verified both cbmem timestamp
tables from romstage and cbmem log tables from ramstage.
Change-Id: Idf9e0245fe91185696ff664b06182c26b376c196
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8489
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Our target is to get rid of backup_top_of_ram() and get_top_of_ram()
entirely so only declare these with LATE_CBMEM_INIT=y.
Change-Id: I54f549fe774996f4d803f9ec527e0fac46f6576f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8749
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
The CBMEM memory segment is always placed at TOM - UMASIZE when GFXUMA
is enabled, however when GFXUMA is disabled an attempt was made to locate
the CBMEM memory segment above the I/O hole in certain rare cases.
Removing this special case does not impact functionality, and paves
the way for early CBMEM support.
Change-Id: I98d29ab9d601a4e20f58e2cd0a66abb13b494e74
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
The AMD RS780 early initialization code originally used the
CF8/CFC I/O method for PCI configuration space access. After
the default configuration access method was changed to MMIO
(http://review.coreboot.org/#q,aad07472), booting would hang
at "PCI: pci_scan_bus for bus 01". Fix the problem by changing
function rs780_nb_gfx_dev_table() so that it no longer borrows
the BAR3 address needed for PCIe MMIO config usage.
Change-Id: I8816b94c848e1b50f8c880e5867a96ca2a33a8a7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8394
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
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>
SERIRQ_CONTINUOUS_MODE is specific feature of LPC busses.
This fixes a KCONFIG unmet dependency warning on ARM mainboards with
chromeec.
Change-Id: Iae61986219585dcb1124cf3b24fa32a8596d56c8
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8665
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add license header with copyright of the original authors.
Change-Id: I8c55bb38a2a2a387ad2461e11d402c7392fa2497
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8691
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The decode of UART addresses down to the LPC bus needs
to occur early to allow romstage console messages to
be seen. This enables the decode of most of the I/O
ports typically seen in a system.
Change-Id: I6636946af4ad5320a5a46c2920b4f06345b5f806
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8661
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The current spi_xfer() function sets the count in hardware and then
loops while waiting for the requested number of bytes to be sent or
received. However, the number of bytes to be transferred may exceed
the maximum count that can be programmed into the controller.
This patch re-factors spi_xfer() to split the low-level FIFO handling
portions for transmit/receive into their own functions to be called
by loops in spi_xfer() which will break large transfers into smaller
ones.
BUG=chrome-os-partner:30904
BRANCH=storm
TEST=built and booted with a >64KB payload on Storm
Original-Change-Id: I70743487996cf08cfc602449f2181a7fcd99bfa4
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209838
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Tested-by: Trevor Bourget <tbourget@codeaurora.org>
(cherry picked from commit 5ec28de11f12c2438356f45ce978a17fbb603bf7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0033e0dd96006cfd30a7a4f5e5a052f677e05108
Reviewed-on: http://review.coreboot.org/8676
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since CCLK_BURST_POLICY and SUPER_CCLK_DIVIDER are not accesible
from AVP, the first place that can change CPU clock is after CPU
has been brought up, ie, ramstage in this case.
CPU initial clock source is set to PLLP by MTS.
BUG=None
TEST=Norrin64 and A44
Original-Change-Id: I525bb2fa2be0afba52837bc0178950541535fd22
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209698
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit ba77e26508bb4a50a08d07ad15632ff1ba501bfa)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Icf2458c491b4b3a553d3e01f88c6f25b25639e89
Reviewed-on: http://review.coreboot.org/8677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently, the rmodules inclusion for vboot is dependent on ramstage_arch.
This change adds dependency on romstage_arch, since vboot is associated with
romstage. Inclusion based on ramstage_arch is left as is in case someone needs
it in ramstage.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for link, rush and nyan
Original-Change-Id: Ib62415671c26a4a18c7133d98e8c683414def32b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209568
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 00da67cc02c81d7a6160f7336b33bf53b00e1875)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9df02134af4e396c7257a2db2e2c371cfd1a02bc
Reviewed-on: http://review.coreboot.org/8673
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide functionality to create dynamic classes based on program name and the
architecture for which the program needs to be compiled/linked. define_class
takes program_name and arch as its arguments and adds the program_name to
classes-y to create dynamic class and compiler toolset is created for the
specified arch. All the files for this program can then be added to
program_name-y += .. Ensure that define_class is called before any files are
added to the class. Check subdirs-y for order of directory inclusion.
One such example of dynamic class is rmodules. Multiple rmodules can be used
which need to be compiled for different architectures. With dynamic classes,
this is possible.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for nyan, rush and link.
Original-Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209379
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 242bb90d7476c2ee47d60c50ee18785edeb1a295)
Some of this cherry-pick had already been committed here:
commit 133096b6dc
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9f5868d704c4b3251ca6f54afa634588108a788c
Reviewed-on: http://review.coreboot.org/8672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In some previous attempt to enable monotonic timers on all platforms,
the LAPIC monotonic timer was selected for Haswell devices, despite
the fact that LAPIC timers are not used in coreboot on Haswell
(See haswell Kconfig) and there already was a monotonic timer
implementation enabled that just needed to be added for SMM as well.
Change-Id: I6beb2977864e507956636860ed463e1991cea1ed
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8702
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
When the Intel SPI drivers were refactored, compilation for Chrome OS
devices broke, because ELOG uses the SPI driver in SMM.
Change-Id: If2b2da5d526196ed742e17409b01a381417d0ce8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8701
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
On ChromeOS devices the ELOG section size and offset are
provided by the FMAP, rather than KConfig. Some upstream
refactoring broke compilation in that case.
Change-Id: I8b08daa327726218815855c7c2be45f44fcffeed
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8700
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@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)
From GCC's documentation:
Optimize debugging experience. -Og enables optimizations that do not interfere
with debugging. It should be the optimization level of choice for the standard
edit-compile-debug cycle, offering a reasonable level of optimization while
maintaining fast compilation and a good debugging experience.
Change-Id: I9a3dadbf8e894cb28e29d7b2f4e9add252e7bbb3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8689
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This removes the mainboard agesawrapper.c file from binarypi
based boards and creates a common one.
Change-Id: I900dba914f1c401e4ac732eb93d94b98216e629a
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8671
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This makes the change to the cpu/amd/pi/00730F01 that was
made for the cpu/amd/agesa based boards in:
commit 48518f0d
AGESA: Add amd_initcpuio() and amd_initmmio()
These are not wrappers for AGESA as they do not enter vendorcode at all.
We expect most of the added fixme.c file to be written without use of AMDLIB.h
and parts relocated as northbridge enable_resources().
The equivalent change has already been made for cpu/amd/pi/00630F01.
Change-Id: I591b50ee807436f5a1dee14d2c88a77462024744
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8670
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested on an X60, Native graphics init still works perfectly.
Change-Id: I91be3baa658e0332028c512c5a4cb0aee07d540a
Signed-off-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-on: http://review.coreboot.org/8696
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Most things still needs to be filled in, but this will allow us to build boards which use this SOC.
BUG=chrome-os-partner:29778
TEST=emerge-veyron coreboot
Original-Change-Id: If643d620c5fb8951faaf1ccde400a8e9ed7db3bc
Original-Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/205069
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 2f72473a8c2b3fe21d77b351338e6209035878fb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I53fd0ced42f6ef191d7bf80d8b823bb880344239
Reviewed-on: http://review.coreboot.org/8653
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I thought this wasn't going to work, and observing the timC detection
failure of early tests, I was getting somewhat discouraged; however,
this works. I've tried it with all possible permutations of the
following memory modules:
* 2 GiB single-rank DDR3-1600
* 4 GiB single-rank DDR3-1600
* 4 GiB dual-rank DDR3-1600
I did notice a limited number of memtest errors during one of the
runs, but they were in an address range that is otherwise marked as
reserved. I wrote that off as "maybe something was doing MMIO there
just when memtest was poking the address range". I was not able to
reproduce that error.
Change-Id: Ibd52e1d52fc8d900591d6a488f9a5b4d1e5e4fd3
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8477
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
This brings the KFSN4-DRE in line with other boards in the tree.
Change-Id: I9216130f51ed0576871fd27ca6ae4610c5f5810e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8683
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This was missed in commit bde6d309 as the driver is not enabled
in any configuration by default.
Change-Id: I3d886531f5bcf013fc22ee0a1e8fa250d7c4c1a4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8660
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
There is no point in duplicating boardid.h per board - they are all
the same. Let's keep a single instance in the common include directory
and let the linker report a problem if one tries using this function
on a board where it is not supported.
BUG=chrome-os-partner:30489
TEST=verified that coreboot builds fine for nyan_big and nyan_blaze.
Original-Change-Id: Ifbe9c2287a1d828d4db74c637d1d02047ac4da25
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209699
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 589e6415faf18ca6aaf44da343dd33eadc8a53d3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8eef89cb822611a0050e5a50fc4b970eebd8d962
Reviewed-on: http://review.coreboot.org/8666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is useful when the PCB layout of a mainboard does not allow
stable operation at the increased HyperTransport speeds of newer
processors.
Change-Id: Idc93a1294608178ddf38ca72d40e6bad7deb9004
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8464
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch removes a chunk of romstage code from Tegra and all Nyan
boards that was supposed to enable some LCD power rails early, but never
really worked. The dev_find_slot() function can only find PCI devices,
which the CPU cluster is not. Since we're done with Nyan-RO and the
ramstage display code is fine as it is, there is no point in trying to
fix this... but we should remove it from ToT lest someone uses it as a
blueprint to add more dead code to future boards.
BRANCH=None
BUG=None
TEST=None
Original-Change-Id: I6eee256873299429d4e3934fe7d454120390f34d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207720
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a3df62a3bcefcc20ae59648f5d1f0a01db3c02c6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8deedea5e9787848aae3064509c611bc349313cc
Reviewed-on: http://review.coreboot.org/8638
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This capability means:
FERR messages are sent out on system detected an
unmasked floating point x87 FPU error.
Even though this capability is supported on nehalem it doesn't
make sense to set it in early stage. This MSR
has a core scope which results in an unsync MSR because
it's not set on other cores than the BSP.
Found-by: BITS
Tested-on: lenovo thinkpad x201t
Change-Id: Ief3c04f57ac69e7289fbd37dbc3fd239f9098155
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8659
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BIOS Writer's Guide, rev 1.6.0, June 2012:
This MSR controls whether and FERR message is sent over the system bus
when unmasked x87 exceptions are generated.
This feature is not supported from Sandy Bridge processor onwards.
Change-Id: I19b260ca4b62f57c26989430693b00b9853bc441
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8658
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Stop running AVP at the end of romstage until event conditions are met (JTAG,
GIC_IRQ or LIC_IRQ).
BUG=chrome-os-partner:30831
BRANCH=None
TEST=Compiles successfully and boots till last known good checkpoint.
Original-Change-Id: Ia221f08b27ac0c60a66d588e351677144cc6a322
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209424
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit df4e8b4c8a1002443a936bd0563fbc9e0710f489)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I59f7702bd50a1039b8723e9cb12b8d714e353d37
Reviewed-on: http://review.coreboot.org/8651
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SPI controller operates on packets which can be variable
length up to 32-bit packets. It also has the ability to be
put in packed or unpacked mode w.r.t each packet. i.e. does
a single fifo register hold >= 1 packet. The current programming
uses 8-bit packets in unpacked mode which means 4 fifo slots
are used for a 32-bit DMA transfter. As the AHB can only operate
on a minimum of 32-bit bursts the triggers need to be programmed
correctly so that there is room for a full 32-bit DMA transaction.
Previously faster SPI clocks just made things magically work.
BUG=chrome-os-partner:30779
BRANCH=None
TEST=Built and booted through coreboot with 20MHz SPI clock.
Original-Change-Id: I3f1cd4dddcea9514327b2363ed450a527db7e1fe
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208862
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit d9864228a2479e412d7e0d2221fe536f78329acd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I61c145f35e1f889d4f83f3dfea049bfd347c1196
Reviewed-on: http://review.coreboot.org/8649
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Trust Zone carveout registers are only accessible using
a secure access mode. The AVP runs as non-secure all the time.
In EL3 the CPU is in secure mode, but when the MMU is enabled
the page tables dictate if accesses to certain regions are
secure or not. However, ramstage is currently being loaded
into non-secure memory and the page tables will live in
non-secure memory as well. Therefore, handle all these
cases by providing global state which mirrors the TZ
register.
BUG=chrome-os-partner:30782
BRANCH=None
TEST=Built and ran through ramstage with the MMU enabled
Resources are read and set accordingly.
Original-Change-Id: Ib76b2641497a29ef2adb75934b2df55ecf0b3e78
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209061
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 0bcbdc56978f6ebe3e7d1b74ed2fd861e03bb562)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9c1beed443a48870ba190427e87caf90caf4ff6b
Reviewed-on: http://review.coreboot.org/8648
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add support for mmu initialization and enabling caches. mmu_operations provides
functions to add mmap_regions using memrange library and then calls mmu_init for
armv8.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until depthcharge load. Goes past
all the earlier alignment errors.
Original-Change-Id: I57c2be80427fa77239093c79ece73e31fd319239
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208762
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit a6141d13d40cfa5a493bde44e69c588dda97e8fd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I33bf4b2e28b85a3117b566cb8497f2bd5aabb69b
Reviewed-on: http://review.coreboot.org/8647
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add support for initializing and enabling mmu for armv8. Using 64KiB granule and
33 bits per VA, thus total VA address space is 6GiB. PA Range is 64GiB. Makes
use of memrange library to get a list of all the mmap regions from the SoC to
initialize XLAT table.
Currently, all calculations in mmu.h are based on the assumptions that max 33
bits are used in VA and granule size is 64KiB. Changes in these assumptions will
have to reflect in the dependent calculations as well.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until "payload not found". Goes past
all the earlier alignment errors.
Original-Change-Id: Iac1df15f0b81dcf64484a56b94f51357bcd67cc2
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208761
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 6fe96360c03342115f849074f9e45a2c4e210705)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5360a3be95f198bd0b4f79b62f31228cc7a9c285
Reviewed-on: http://review.coreboot.org/8646
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Other default slams should be added later to the init table
once we know what the kernel touches. But for now, only VDD_CPU
is needed.
Also slipped in a minor name change in mainboard.c
BRANCH=none
BUG=none
TEST=none, no HW here for me to test on yet
Change-Id: Ifbe86192449ed0466085808a0a12a15a7b6a1795
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208385
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 53b332fb12cd685fbec265695333a70c4064524c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With this memory resource, the payload loading code should be
able to create a bounce buffer and load the payload successfully.
Adapted from tegra124 soc.c
BUG=None
BRANCH=None
TEST=Built and booted to ramstage on rush.
Original-Change-Id: I2e336ce93c1b0236104e63d3785f0e3d7d76bb01
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208121
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 20765da0b15ee8c35a5bbfe532331fc6b1cef502)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I267ced473ad0773b52f889dfa83c65562444c01f
Reviewed-on: http://review.coreboot.org/8644
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Once LPDDR3 init is supported in the ryu romstage, this can
be reverted. Note that this 528MHz BCT has been pre-qualed
by NVIDIA AE's, but will be updated as more tuning is done.
BUG=none
BRANCH=none
TEST=Builds, BCT is in binary, but I have no HW here to test on
Original-Change-Id: I315a9a5d56290bb5f51863b15053d2171db7b1e4
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208384
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 660e40cb473d47ce763e79d6061367bf381a1c48)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I29ad31fc83f45ca8f92809a7dc252cf984c8c6fe
Reviewed-on: http://review.coreboot.org/8643
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The CCSIDR_EL1 register has cache attribute information
for a given cache selection in CSSELR_EL1. However, the
cache isn't being selected before reading CCSIDR_EL1.
Instead use CTR_EL0 which better fits with the semantics
of dcache_line_bytes(). CTR_EL0 has the minimum data cache
line size of all caches in the system encoded in 19:16 encoded
as lg(line size in words).
BUG=None
TEST=Built.
Original-Change-Id: I2cbf888a93031736e668918de928c3a99c26bedd
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208720
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 8d5dfba35d74fc4c6ee14365a2e9d9ed9f43115d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I1db47ff5850c276d0246ac67e8b96f7ed19016c0
Reviewed-on: http://review.coreboot.org/8642
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The address map code was originally assuming all carveouts would
be packed together in the upper end of the physical memory
address space. However, the trust zone carveout is always in the
32-bit address space. Therefore, one needs to query memory ranges
by above and below 4GiB with the assumption of carveouts being
packed at the top of *each* resulting range.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot on rush.
Original-Change-Id: Iab134a049f3726f1ec41fc6626b1a6683d9f5362
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208101
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 8d5795fbff36e91906384e10774a32541d358324)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If15ff48d5a4c81731eb364980b30c8086deb1cca
Reviewed-on: http://review.coreboot.org/8641
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The default CBFS size configuration setting is incorrect in case of
Qualcomm SOC targets, as the coreboot blob is much smaller than the
actual bootprom. Note that this size also must match the board fmap
defined in the appropriate depthcharge board directory.
BUG=chromium:394068
TEST=manual
. previously failing to boot coreboot image does not fail to load
depthcharge anymore.
Original-Change-Id: I1b178970b1deee05705490542e4a0c57500379dd
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208146
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 01f3561fdee7b5547534e20d423fbbb1b490532c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If573bbc6254cf6786e75970eae3ad2b327a7ecfe
Reviewed-on: http://review.coreboot.org/8640
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Provide a default Trust Zone region size of 1MiB, and
correctly account for it in the AVP and the arm64 cores.
The different path between the arm64 cores and the AVP
is because the AVP cannot access the Trust Zone region
registers. Therefore the AVP needs to account for the
Trust Zone region.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran. Noted Trust Zone region being accounted for.
Original-Change-Id: Ie0f117ec7a5ff8519c39778d3cdf88c3eee57ea5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/208062
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 22f2fa05c009c58f53b99b9ebe1b6d01fdac5ba7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I28506b4401145d366b56126b2eddc4c3d3db7b44
Reviewed-on: http://review.coreboot.org/8639
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Set correct gpio routing and enable bits for EC SMI gpio and EC WAKE gpio.
Verified with schematics.
Change-Id: Ie3b98c4456a870c881e7663b19eb8ca8e5564c5c
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/8358
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Currently on AMD boards no romstage messages can be saved in CBMEM, so
only messages from ramstage on will be stored in CBMEM. Other than
that nothing changes.
Enabling CBMEM console by default does not noticeably decrease boot
time as the messages are directly written to CAR or RAM.
The board status script under `util/board_status/` reads the coreboot
messages from CBMEM, which are then uploaded to the board status
repository. With CBMEM console disabled by default, currently no
coreboot console messages are uploaded to the board status repository,
although it is important to have those.
Enabling CBMEM console by default improves this situation, so that for
all boards at least ramstage messages are stored in the board status
repository.
Change-Id: I8d5a58c078325c43a0317bcfaafc722d039aab0b
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5350
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
There is nothing platform specific in retrieving S3 resume state from
romstage_handoff structure. Boards without EARLY_CBMEM_INIT update
acpi_slp_type from ACPI power-management block or scratchpad registers.
Change-Id: Ifc3755f891a0810473b3216c1fec8e45908fc1ab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8188
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This was added to handle cases of Intel FSP platforms that had
EARLY_CBMEM_INIT but could not migrate CAR variables to CBMEM.
These boards were recently fixed.
To support combination of EARLY_CBMEM_INIT without CAR migration was
added maintenance effort with little benefits. You had no CBMEM
console for romstage and the few timestamps you could store were
circulated via PCI scratchpads or CMOS nvram.
Change-Id: I5cffb7f2b14c45b67ee70cf48be4d7a4c9e5f761
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8636
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
If it's not supported on a particular board, either the build will fail or
checks within the cbmem console itself should detect the problem. There
shouldn't be random memory corruption any more.
BUG=None
TEST=Built with CONSOLE_CBMEM enabled on nyan and saw that it was actually
enabled.
BRANCH=None
Original-Change-Id: Id6c8c7675daafe07aa4878cfcf13faefe576e520
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193167
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 20b486443bfc2d93d72bbc9e496023a00ab9ab30)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I39fbcdff61f6d8f520f2e9d7612dee78e97898b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7748
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit 2e0cf14 corrected this for pi/00730F01/northbridge.c.
This commit fixes it for pi/00630F01/northbridge.c.
Found-by: Clang
Change-Id: I4eb93a07aacf6ffc5a159222117e7c934d85859e
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8289
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Also fix a typo in a config option for SteppeEagle.
Change-Id: Iad51cc917217aa0eac751dc805c304652d20e066
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/7247
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The CAR macros and the associated functions are only employed
under the following conditions:
- chipsets which have CAR
- compilation during romstage
Therefore clean up the build-time conditionals to use those 2
constructs.
Change-Id: I2b923feeb68f2b964c5ac57e11391313d9c8ffc5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8634
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Starting with version 2.1 qemu provides a full set of smbios tables
for the virtual hardware emulated, except type 0 (bios information).
This patch adds support for loading those tables to coreboot.
The code is used by both i440fx and q35.
Change-Id: Id034f0c214e8890194145a92f06354201dee7963
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/8608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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)
Make compilation fail if this is included in non-romcc compiles.
I am a bit surprised that this ever compiled.
Change-Id: I8dfc1229681819d2381821a0195a89b44dd76b6a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8420
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
All boards in tree use 0. Looks like this is all work that was
never completed and tested.
We also have static setting sysconf.segbit=0 which would conflict
with PCI_BUS_SEGN_BITS>0.
Having PCI_BUS_SEGN_BITS>0 would also require PCI MMCONF support
to cover over 255 buses.
Change-Id: I060efc44d1560541473b01690c2e8192863c1eb5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8554
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Julius Werner