Output a few more status bits from HFS/HFS2 and add
some interesting bits from HFS3.
BUG=chrome-os-partner:52662
BRANCH=glados
TEST=boot on chell and verify ME status output
Change-Id: I989b680f203678dbe28559e858faf8b4e0837481
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ea34ab019da3fff965102bcef5158ddcc154728
Original-Change-Id: Iff977c8d85b4d4dfa00b5b19bc29d11813a99b9f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/340390
Original-Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-on: https://review.coreboot.org/14687
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
This adds a nyan libpayload config, that should fit all nyan devices.
Change-Id: I6b86a03054a7625534fd38ee6a21d3b91fb43589
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14473
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It turns out that tegra124 needs the framebuffer's bytes-per-line to be
aligned to 32 for proper display. This behaviour was default before
moving to edid_set_framebuffer_bits_per_pixel.
This fixes display on nyan_big.
Change-Id: Ie81b395fca23f3648ea7cd1df51152faea864c9a
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14564
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It turns out that tegra132 and tegra 210 need the framebuffer's
bytes-per-line to be aligned to 64 for proper display. This behaviour
was default before moving to edid_set_framebuffer_bits_per_pixel.
Change-Id: I46dadcf36e1c50e9649121ee6fa9cdf6134a531e
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14734
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This renames "becasue" occurrences to "because".
Change-Id: I7862ce6a865cb1525ca1cef69c2eb1e90cc76a9d
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14735
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It includes support for rk3399.
Change-Id: I326ef3dc3021313ee852395c302c076b3e3c8c5e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:49249
TEST=None. Initial code not sure if it will even compile
BRANCH=none
Change-Id: Ib0fccfe2d103710c006cb3950c65b11b8d596912
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9be5f58bb89ec43d4eb264c94c3f745dcade35dd
Original-Change-Id: If50efb55d4974dfcab07d3ae6488c2413b505a1f
Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/333301
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14657
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins)
The verb *set up* is written with a space [1]. So correct that in the
function descriptions.
[1] http://www.merriam-webster.com/dictionary/set%20up
Change-Id: Icf5aa7eca2c379fdf7ff1935d71efc347f5ce6fa
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/14701
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Assigning the value `1` to `status` in the default branch of the switch
statement is not needed, as the stored value is overwritten before it
can be used.
Change-Id: I532b0e217ff4ed315cd30b08d339c755c6df7539
Found-by: Coverity, CID 1355008: Code maintainability issues (UNUSED_VALUE))
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/14699
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Before multi-CBFS support was added, x86 platforms cached their
ramstage in TSEG so that it could be re-used on the resume
path. However, more resources/assets are being put in cbfs that are
utilized during ramstage. Just caching ramstage does not mean that
correct cbfs region is used for all the data. Thus, provide an option
to allow platforms to skip caching any component for resume.
Change-Id: I0e957a6b859cc7d700aaff67209a17c6558be5de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14636
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On modern x86 platforms like apollolake, pre-RAM stages verstage and
romstage run within the cache-as-ram region. Thus, we do not need to
pass in the --xip parameter to cbfstool while adding these
stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is
default false for all x86 platforms. Apollolake selects this option
since it supports code execution with CAR.
Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
and re-generate _shipped files
Change-Id: I7a18824d64d3f6212e8566695376bf97e2196ee2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14733
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Mask out the bit that doesn't fit in 32bits, so gcc 6.1 is happy
Change-Id: I13e2b41742206b8d86b90314b80cc324c00ae637
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14639
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Tested-by: build bot (Jenkins)
decode_edid either gets EDID_LENGTH bytes or (in the extended case),
2*EDID_LENGTH.
See that this is reflected in its size argument.
Change-Id: If6c76358db4e9ee01c2bd2dbdd5948c61b7aa5bc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14698
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This converts the argument parsing to allow us to add longopts
using GNU getopt(1).
Shortopts should be reserved for general parameters. Longopts can be
used to tweak specific behaviors. For example, we might wish to add
options to set SSH port, timeout, and authentication parameters
with "--ssh-port", "--ssh-timeout", "--ssh-identity", etc.
Change-Id: Idee5579079dbbb7296ad98f5d6025b01aab55452
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14523
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Otherwise, newer GCCs will insist that they get deleted.
Change-Id: Ida45b7d193366f5e611a32632ba610193451b082
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14619
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
gcc 6.1 complains that SMM_OFFSET << 8 is larger than the register
it is assigned to (rightly so):
src/northbridge/amd/gx2/northbridgeinit.c:196:23: error: result of
'1077936128 << 8' requires 40 bits to represent, but 'int' only
has 32 bits [-Werror=shift-overflow=]
msr.lo = (SMM_OFFSET << 8) & 0xfff00000;
^~
Change-Id: Ib0d669268202d222574abee335a6a65c8a255cc7
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14617
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Due to missing braces (that went undetected because of the
indentation), I584189d9fcf7c9b831d9c020ee7ed59bb5ae08e8
CMOS: add set_option() only takes the last changed byte into regard
when determining whether the checksum needs to be updated.
This bug went undetected for 5 years.
Change-Id: I47cedc801a60959386dfdcda3a13b8e3162a7ecb
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14616
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Chrome EC uses IO ports 0x800 -> 0x9ff to communicate over LPC;
however, those ports were not declared as a resource. This had two
major downsides:
* It allowed the allocator to assign said ports to other devices
* It required manually open up an IO window in the LPC bridge.
The LPC bridge on many chromeec boards had to be painstakingly
adjusted to meet these constraints.
The advantage of declaring the resources upfront is that the lpc
bridge can now scan its child resources and automatically open up
IO windows, as requested by its LPC children devices.
Change-Id: I35c4e48dddb7300674d7a9858b590c1f20e3b0e3
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14585
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Every other SOC uses a CONFIG_* flag to enable or disable SERIRQ
continuous mode. Why they do that is beyond me, but the way we
implement it on apollolake is via devicetree.
Change-Id: I6e05758e5e264c6b0015467dd25add3bffe2b040
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14586
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This allows the chomeec driver to declare its resources so that IO
windows to LPC are opened up during resource allocation.
Change-Id: Ife98ecb4cbf5393493e6c71742de8d37953df548
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14591
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This file use stdint types, but does not include the appropriate
header. This creates a parasitic dependency on including stdint.h
before ec_commands.h. Fix that by including the necesarry header.
Change-Id: I52477028c4ba8f6ffad0356c09e5fad4972649ed
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14589
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Communication with ChromeEC, which is on the LPC bus, is needed early
on for vboot purposes. I'm not sure if Google wants to have the
interface available in bootblock or romstage, so we're confguring it
in the bootblock.
The bridge is automatically reconfigured during ramstage in a way in
which we don't get duplicate windows opened upt to LPC.
Change-Id: I77887e881d23f655495dec2687394409a5bb8cf5
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14588
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Besides a number of fixed memory windows, Apollolake supports
opening a configureable 64 KiB MMIO window, as well as four PMIO
windows to the LPC bus. Open up these windows dynamically, based on
how resources were allocated to the child LPC devices.
Change-Id: I170e861693cb6fd1be38889adc951f197a13460f
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14584
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit e976bd4469.
The LPC resource allocation will be completely reworked in subsequent
patches. The most straightforward approach is to start by reverting
the existing code.
Change-Id: I2475542b79817020d4c956f22ed5856f05046b16
Reviewed-on: https://review.coreboot.org/14583
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Do not use devicetree.cb to manually control hardware registers. This
interface will be removed in a subsequent commit and replaced with
runtime allocation that also does sanity checking.
Change-Id: I55561085ea467f19f52110b1a59f45fe290c7f09
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/14582
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The wrong base address was being used for the region of memory
between BDSM and TOLUD. This resulted in a very large reserved
region starting at TOLUD instead of BDSM.
Change-Id: I41d06267ffa93ea47aa059f4ddb7b9c349e51583
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14628
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The XIP_ROM_SIZE Kconfig variable isn't used for these chipsets.
Therefore, indicate as such so that romstage can be placed in
cbfs less rigidly.
Change-Id: If5cae10b90e05029df56c282e8adf37fa0102955
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14626
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Previously, the XIP_ROM_SIZE Kconfig variable is used globally on
x86 platforms with the assumption that all chipsets utilize this
value. For the chipsets which do not use the variable it can lead
to unnecessary alignment constraints in cbfs for romstage. Therefore,
allow those chipsets a path to not be burdened by not passing
'-P $(XIP_ROM_SIZE)' to cbfstool when adding romstage.
Change-Id: Id8692df5ecec116a72b8e5886d86648ca959c78b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14625
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A previous patch [1] to make top-aligned addresses work within per
fmap regions caused a significant regression in the semantics of
adding programs that need to be execute-in-place (XIP) on x86
systems. Correct the regression by providing new function,
convert_to_from_absolute_top_aligned(), which top aligns against
the entire boot media.
[1] 9731119b cbfstool: make top-aligned address work per-region
Change-Id: I3b685abadcfc76dab8846eec21e9114a23577578
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14608
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There used to be a need for an empty smm_init() function
because initialize_cpus() called it even though nothing
called initialize_cpus(). However, garbage collection at
link time is implemented so there's no reason to provide an
empty function to satisfy a symbol that is completely culled
during link. Remove it.
Change-Id: Ic13c85f1d3d57e38e7132e4289a98a95829f765a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14605
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
With all users converted to using the mp_ops callbacks there's
no need to expose that surface area. Therefore, keep it all
within the mp_init compilation unit.
Change-Id: Ia1cc5326c1fa5ffde86b90d805b8379f4e4f46cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14598
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to reduce duplication of code use the common MP and SMM
initialization flow.
Change-Id: I5c4674ed258922b6616d75f070df976ef9fad209
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14597
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In order to reduce duplication of code use the common MP and SMM
initialization flow.
Change-Id: I80b5b94b62bdd001581eb56513a0d532fffb64e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14596
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In order to reduce duplication of code use the common MP and SMM
initialization flow.
Change-Id: I74c81c5d18dff7a84bfedbe07f01e536c0f641fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14595
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In order to reduce duplication of code use the common MP
initialization flow.
Change-Id: I8cfb5ba6f6a31fecde2ce3bf997f87c4486ab3ab
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14594
Tested-by: build bot (Jenkins)
Reviewed-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to reduce duplication of code use the common MP and SMM
initialization flow.
Change-Id: I65beefec53a29b2861433bc42679f3fa571d5b6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14593
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to reduce duplication of code use the common MP
initialization flow.
Change-Id: I2a7c628cfae7cf6af6e89fa8fc274f59127ff7c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14592
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
1. PCI command reg write should be 16-bit.
2. HPTC reg write should be 8-bit. Also, use macros instead of
hard-coded values. Currently, the macros are defined in romstage.c,
but if more P2SB macros are added, it would be good to move them to a
separate header file.
Change-Id: Iad1eb6a95467a41ecf454092808d357425c4c2fc
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14613
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
This fixes UPDATE_IMAGE builds, assuming that the fmap configuration in
the tree didn't change, at least as far as the CBFS regions are
concerned.
Another option would be to synthesize the fmap related files from the
existing image, but that comes with other issues (eg. what about
updating images old enough that there is no fmap?) and is more complex,
so keep it simple, stupid for now.
Change-Id: I036dab9f81f524f7d70bc0029b1ef835e6180a53
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14601
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
In If0d4d61ed8ef48ec20082b327f358fd1987e3fb9 the code
was changed from one to two lines in the body of an if()
statement, without adding braces.
Change-Id: Ibbbdf240157adae95151fb2ce0135948caa60108
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Add time delay support to the scripts.
TEST=Build and run on Galileo Gen2
Change-Id: I2c87977e2a2547e00769e59e1ee81fbbb5dff33f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14555
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Migrate the temperature sensor support from QuarkFspPkg into coreboot.
TEST=Build and run on Galileo Gen2
Change-Id: I6dc68c735375c9d1777693264674521f67397556
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14565
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add register access support using register scripts.
Initialize the USB PHY using register scripts.
TEST=Build and run on Galileo Gen2
Change-Id: I34a8e78eab3c7314ca34343eccc8aeef0622798a
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14496
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>