In order to avoid a 300ms timeout waiting for mbp_cleared flag
to be set there is a new flow for the ME10 1.5MB firwmare that
we can follow which will save significant boot time.
This requires sending new commands that do not generate an ACK
message, and ensuring an HMRFPO LOCK message is sent.
In addition now that the delay is removed clean up the ME path
to do the work in init() step and add a final() step that does
the disabling of the PCI device.
BUG=chrome-os-partner:30637,chrome-os-partner:34134
BRANCH=samus,auron
TEST=build and boot on samus, measure ~300ms speedup in boot time
Original-Change-Id: I753087ecd65f6ebed9f812318a359f893e01da9f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234400
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 25aff4b188dc94a99af30869a162e01e3fa8dee7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia35373548a902a718155a1a57057f55067d2f3ac
Reviewed-on: http://review.coreboot.org/9697
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the blobs from the coreboot tree and get them from
3rdparty.
Change-Id: I0798091530be9654d7e073839b4efeb3f9c0302c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9694
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Remove the blobs from the coreboot tree and get them from
3rdparty.
Change-Id: I4938b5c47e6ae7059eda144b664aeafdd674f0fb
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
decode_edid() parses the whole EDID buffer, regardless of whether there
is an extension buffer, so we pass the size of the EDID actually read to
prevent EDID parser getting the wrong data.
BUG=chrome-os-partner:35053
TEST=Boot from jerry
BRANCH=veyron
Change-Id: I5951b670f129cf4765a5199cb58ac6abff5478a6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4d508647efc0a9d48b2a4b23c12a54b63af2813e
Original-Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240643
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9645
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds RTC functions to the existing RK808 driver.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=with eventlog patches applied to pinky, booted and saw eventlog
entries generated with correct timestamps:
localhost ~ # mosys -k eventlog list
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Change-Id: I1df70a2ca94ff463ffea8d9f02d951d6c62e6b08
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a304f7e6954f585f04feef54c4902dcb25a39fcc
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9
Original-Reviewed-on: https://chromium-review.googlesource.com/238525
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9643
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9642
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch implements support for the CRYPTO module in RK3288 and ties
it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for
now, since the engine doesn't support SHA512 and it's very unlikely that
we'll ever use SHA1 for anything again.
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and
that firmware body hashing time dropped to about 1.5ms (from over 70ms).
Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b
Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236436
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9641
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This switches all the rk3288 platforms to use the common CBFS wrapper
instead of implementing its own CBFS media driver. It also happens
that veyron_* platforms use Gigadevice SPI flash (at least for now).
As we use more SPI-related stuff, for example eventlog and vboot data in
Brain's case, we will need to use more of the SPI API anyway. This
prevents us from having to duplicate pieces of it for rk3288.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Change-Id: Ie462456814646fdc277485d9e2d8c901fd4936e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b
Original-Reviewed-on: https://chromium-review.googlesource.com/235882
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9678
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We use the devicetree to pass the backlight control gpio before,
but if there have different board version, and it uses different
io to control backlight, it will hard to distinguish it. So, we
move the backlight control to mainboard, and use board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: Ifa81eb2455296f4b4285b681208f4393f266fb34
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2ff7f65134dcf97f97757750eab41dcf8c7765d3
Original-Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234711
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9630
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Like Nyan, Veyron boards use a GPIO to reset the system so that we can
make the accompanying TPM reset secure and unforgeable. The normal
kernel reboot driver knows that, but the SoC-internal watchdog doesn't.
This patch implements a check for the global reset status register in
the early bootblock and triggers a hard_reset() when it matches "first
global watchdog reset" or "second global watchdog reset". Seems that
the difference between the two is is a choice controlled by
wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both
cases.
BRANCH=None
BUG=chrome-os-partner:33141
TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end
up in recovery without this patch but can boot normally with it.
Change-Id: Ice79648831e1e97d22325711da9e82bbf6bf3c75
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5d7cb52b2c2dcb2fff0bf83fc168439dade4b1b7
Original-Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231734
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9629
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The only way to reliably reset an SD card in an unknown state is by
power-cycling. Since a kernel may crash and reboot at any point, SD
cards may be left in one of them fancy high-throughput modes that
depthcharge (or, in fact, a newly booting kernel without prior
knowledge) doesn't support, so we need to reset the card on every boot.
This patch adds support to turn off an RK808 regulator completely and
uses that to turn off SD card power rails in early romstage. The time
until configure_sdmmc() in ramstage turns them back on should be more
than enough to drain the power rail for an effective power-cycle.
BRANCH=None
BUG=chrome-os-partner:34289
TEST=Booted a Pinky from SD card, noticed that it works before and
after this patch.
Change-Id: Iaa5f7adaa59da69a964785c5e369ad73c6620224
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 95fba21907f1f3f686cb5a95b993736247db8f96
Original-Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233713
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9626
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This function was added in upstream but was missing in Chromium OS
Change-Id: I35debf65153e5f280343eebfe91438ecf665ba22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9677
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This is not a standard feature so it should be included by the
mainboard if it is actually present in a system.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=build and boot on samus
CQ-DEPEND=CL:226663, CL:226664
Change-Id: Id4d0e5ed243dcb95e64fb8c848667f651b75aa4e
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8909913f5c11c5805c77a3373859634b02a301e2
Original-Change-Id: Ib7c171a5a007a2dddfb3d80341c6dc488e383e99
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226662
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; I2C0 clock is
set up properly.
BRANCH=none
Change-Id: I15ffc5f7d8e8aadfc3cd249284bc492d0d13d9a1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6404ab6ad12ea1579eaf5ae55a9eddd9bd9f96e2
Original-Change-Id: Iafdf492291b47f0088f3b5e621d630b8d21ab106
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/250450
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9673
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The base address used was TOP CLOCK control address instead of
the PERIPH CLOCK CONTROL. That was incorrect and is fixed with
the current patch.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; now the hash accelerator,
fed by this clock, is correctly clocked at 200MHz.
BRANCH=none
Change-Id: I0ead3951dc1dfc872881b8d1ae9b63f8104af50d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 871cb50ca43a6c760f346eb447e8ff102d8ca0b6
Original-Change-Id: I198d64f97a85a6fcf00c3853bf23d2d767e0e631
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245313
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9670
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the asserts were not done properly: the value has
to be shifted before is matched with the mask.
Added condition to exit while loop for USB clock setup.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; after this patch is
applied none of the asserts fail and the code is executed
properly.
BRANCH=none
Change-Id: Ib3aae9f7751a9f077bc95b6e0f9d63e3e16d8e4b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 96999a4322ba98e87bc6746ad05b30cc56704e2e
Original-Change-Id: I8d2d468d618ca1ffcb1421409122482444e6d420
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243214
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9667
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the added code for clock and MFIOs setup, bootblock
now exceeds 16KB. This patch increases the allowed limit
to 18KB.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works as expected
BRANCH=none
Change-Id: I166f882bd3db446bcd6f9e1f828cab22266c6ac7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: da95db5ed348419b7905dc1ab68fd64d7b2eb5e0
Original-Change-Id: I0cacc6163f21ae3673c2716b12dde66bd48290f9
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243213
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9665
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As the payload increases in size, a bigger CBFS cache is required.
Therfore, bootblock, romstage and the cbfs cache were placed in
GRAM (128 K) and the stack and cbmem console were moved to
SRAM (64 K). With the exception of CBFS cache, the sizes of all
the other regions remains the same.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board;
behavior was as expected.
BRANCH=none
Change-Id: I19857f785ca1514f7483d582c7ad6ee470a8fefc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c895660dbdcd113bdc9d832beab30886313c28d6
Original-Change-Id: I004f8f081d04f83e3f5cee969e50803685cfdf67
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/236551
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9664
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When using this mode data is received and transmitted on the same
edge of the SPFI clock, which allows for higher frequencies of
operation. In this mode the maximum supported frequency is 50Mhz.
If this mode is not enabled the maximum supported frequency is
25Mhz.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; the SPFI hardware block is
fed by the system clock (with a fixed freqency of 400 MHz).
To achieve the SPFI frequency of 50MHz the internal divider of
SPFI must be set to 64. To achieve a frequency of 25 Mhz the
internal divider must be set to 32.
A value of 64 = division by 8
A value of 32 = division by 16
BRANCH=none
Change-Id: Ifd5f739b6157b99e4c1f92b5bb72615ee610ae6c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8b6cce616ec7926682d4eff096563acf1dfd6c65
Original-Change-Id: I337b6fcf462bcf6021ca77a8b1133cf49140ba76
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241425
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9663
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Set elements:
- UART1 clock dividers and MFIOs
- SPIM1 clock dividers and MFIOs
- USB clock dividers
- System clock divider
- System PLL
- MIPS CPU PLL
BUG=chrome-os-partner:31438
TEST=tested on Pisachio bring up board; UART, SPI NOR, SPI NAND, and USB
have proper functionality.
BRANCH=none
Change-Id: Ib01186a652fd59295a4cafc3ca99b94aa9564f74
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 65e68d82f34bb40ef3cfb397ecf5df0c83201151
Original-Change-Id: Ia2c31bbbfc020dc4fd71c72b877414adfdfc42a8
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241423
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9662
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The GPU MMU won't function properly until it sees the VPR
is locked down. Therefore, do the appropriate work.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I6011c75c1e6c231f2fa416e0057cb5805a88a2bb
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: ca9cc9917b98a148442468d1d1541a0408ab6c2c
Original-Change-Id: I3601f419b561cee392391577ef8db66b9fbd8c1b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242910
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: http://review.coreboot.org/9660
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add and call display shift clock divider function to set shift clock
divider.
This change is also intended for code sharing on dc settings.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and rush
Change-Id: I9ad1b32de50395720355bb2d00f5800c7f6c4b73
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24a72fa3411652d54ae1f7d69db0a7293aad7877
Original-Change-Id: I01582c6863d31627ac93db9fddda93f4f78249cd
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238943
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9614
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add these parameters so that they can be specified in devicetree.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and rush
Change-Id: I77ee16263e1ce6a8c32b3cd203c1b8a499514a8e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c3b254936e696f81ca7eeeb7f6968a5350352b59
Original-Change-Id: Iba47afe95c3889047a82582730be7a253fae76e7
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9611
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Freeing up memory on rk3288 is like squeezing water out of a stone right
now, but I still managed to get a few drops here and there. Let's hope
this will be enough.
BRANCH=None
BUG=None
TEST=Pinky builds and boots again. memsz is ~15K in bootblock and ~39K
in verstage.
Change-Id: Icf7ff3369bf367426a34f1490e0a041ae9bd6367
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a3737ab535cdef228a1607433860f881db04412
Original-Change-Id: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235870
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9609
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Files necessary for the SOC bringup are added to the CBFS as raw
blobs.
Ipq8064 specific MBN header will allow to determine were the blobs
should be loaded and what start address should be used.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=build storm firmware and verify that the right components are added:
$ emerge-storm coreboot chromeos-bootimage
$ cbfstool /build/storm/firmware/image.bin print
image.bin: 8192 kB, bootblocksize 32488, romsize 2883584, offset 0x7f40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x7f40 raw 376
ddr.mbn 0x8100 raw 25820
rpm.mbn 0xe640 raw 78512
tz.mbn 0x21940 raw 85360
fallback/verstage 0x36700 stage 39500
fallback/romstage 0x401c0 stage 15652
fallback/ramstage 0x43f40 stage 24328
config 0x49e80 raw 2701
fallback/payload 0x4a940 payload 65592
u-boot.dtb 0x5a9c0 (unknown) 2922
(empty) 0x5b580 null 2509336
$
Change-Id: I967cd20364c90a1ef7add959621992c2356f158d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6b5238d47da417b8b1993ad3348f4c32381cd0e4
Original-Change-Id: Id642ae68ef07750624f85b31ad891752d8af99bf
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233672
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The first blob in the Storm bootimage is a concatenation of the
Uber-sbl produced by the qca-firmware ebuild and the coreboot
bootblock.
The new tool is used to add the bootblock to uber-sbl and update the
size values in the combined header.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=no execution tests yet, the build succeeds.
Change-Id: I4f1fe8a97ffab04eee4f82bc43e6f5406dd9bb42
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a126a62f65a568d62fe35bdcf27eaec38fd1a997
Original-Change-Id: Iec3c1e943f1f9ee5ca20320a6365fc4aa5516e38
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232310
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9573
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The first 64 bytes of the framebuffer contain garbage after running
the option rom and after calling the VBE mode set with the flag to
clear the framebuffer.
Work around this issue by clearing the first 64 bytes in the framebuffer
in the broadwell graphics setup code after it executes the VBIOS.
BUG=chrome-os-partner:32771
BRANCH=samus,auron
TEST=build and boot on samus in dev mode, check for graphical corruption
Change-Id: I0381e32a5ea17e13c4ed598835999c12136418cf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f29c1b0b7c100cf290f82de671042823032f71c9
Original-Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222676
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9464
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10
Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234061
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9601
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a
Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224524
Original-Trybot-Ready: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit 257aaee9e3a (arm: Add bootblock_mainboard_early_init() for
pre-console initialization) inadvertently moved the timer initialization
after console initialization for IPQ806x, which is apparently not a good
idea for this platform. This patch solves the issue by moving
init_timer() to bootblock_mainboard_early_init(), which is the new hook
explicitly provided to perform pre-console tasks.
BRANCH=None
BUG=None
TEST=Built and booted Storm with 257aaee9e reverted. Noticed that it was
already broken. Bisected coreboot and tracked down breakage to commit
a126a62f (ipq8064: use the new utility to build bootblock). Built and
booted successfully with this patch and a revert of a126a62f to confirm
that the bug in question here is fixed.
Change-Id: I4a3faa2aec8ff1fbbe6c389f1d048475aa944418
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 752d1f879f9bd841f18bd84842491f747458cf52
Original-Change-Id: Ie4aa2d06cb6fda6d5ff8dd5ea052257fb7b8a24b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233290
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9574
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this is a preparation for porting these drivers to coreboot. the code will be modified by the following patches.
BUG=chrome-os-partner:33647
BRANCH=ToT
TEST=None
Change-Id: I2baeed5b6130ace2515d6e28115f8d1008004976
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7c03a186a599be9d274c6fcdea1906529cc117d7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I9f3428ef02d2ba15ae63c99b10fe0605dd595313
Original-Reviewed-on: https://chromium-review.googlesource.com/231461
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch uses the new bootblock_mainboard_early_init() hook to run the
UART pinmuxing on rk3288-based boards before initializing the console.
This allows us to get rid of the hacky second console_init() call in
bootblock_soc_init(). We can also simplify the pinmux selection a bit
since we know that a given board always uses the same UART (still keep
an assert around to be sure, though).
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky.
Change-Id: I3da8b0e4bd609f33cedd934ce51cb20b1190024b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: caabda8fc1ddb4805d86fd9a0d5d2f3cf738bfaf
Original-Change-Id: Ia56c0599a15f966d087ca39181bfe23abd262e72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231942
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9604
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On most platforms, enabling the console and exception handlers are
amongst the very first things you want to do, as they help you see
what's going on and debug errors in other early init code. However, most
ARM boards require some small amount of board-specific initialization
(pinmuxing, maybe clocks) to get the UART running, which is why
bootblock_mainboard_init() (and with it almost all of the actual
bootblock code) always had to run before console initialization for now.
This patch introduces an explicit bootblock_mainboard_early_init() hook
for only that part of initialization that absolutely needs to run before
console output. The other two hooks for SoC and mainboard are moved
below console_init(). This model has already proven its worth before in
the tegra124 and tegra132 custom bootblocks.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu.
Change-Id: I510c58189faf0c08c740bcc3b5a654f81f892464
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f58e84a2fc1c9951e9c4c65cdec1dbeb6a20d597
Original-Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231941
Reviewed-on: http://review.coreboot.org/9603
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
[pg: this was already partly upstreamed. These are the remains.
Further cleanup is necessary and on the short-term TODO, but beyond
the scope of this commit]
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9602
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Display configuration is board specific. The change here is preparing
for supporting other than dsi interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: Ied39d5d539d2be4983ab70976bffbe51fccba276
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 36be6b2e35c6246d5384d71b9ab9d4ddbf17764a
Original-Change-Id: I494a04f7d6c0dbad2d472f4c2cd0aabfb23b8c97
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234271
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9584
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
dc supporting functions can be used for other than dsi display
interfaces. This change is preparing for supporting sor display
interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: I8a310e188fae70d7726c4360894b392c4546e105
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a7ab7225e3419a0fd93894dbb9a959390f29945b
Original-Change-Id: Id14cbd89457cb91c23526927a432f4eb7cc6291b
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9583
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
After DDR PHY reset de-asserted, DLL automatically starts to
lock, and the lock time is maximum 5.12us. The output clock of
DLL supplies the clocks of DDR controller and PHY digital logic.
So before DLL lock, the clocks of DDR controller and PHY digital
logic are indeterminate. When programming DDR in the period of
DLL unlock, the programming maybe unstable because of the
indeterminate clocks. So we need wait for at least 5.12us after
de-asserting reset, then start to program DDR registers.
10us provide some safety margin.
BUG=chrome-os-partner:33148
TEST=I'm using the following command line test ok(15000 cycles).
"while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off;
do : ; done"
BRANCH=None
Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e
Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232894
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Used for audio on Rush/Ryu. I2S1/DAP2 provides the audio
'stream' for the dev/rec mode 'beeps'.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=With follow-on CLs that make use of this support,
audio beeps (via VbExBeep) can be heard on Rush. Built
both Rush and Ryu OK.
Change-Id: Iea5559db4431e48001adbbce17fa0f3aaaf8387c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2bd701a5f4186e49739b25f4afd5000d5d9b4970
Original-Change-Id: Ia8c32303979f25300e22b5a14609d9d9d5ce3132
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233670
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9576
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI
read and write transactions. Limiting transfer size in the wrapper
allows to provide the API user with unlimited transfer size
transactions.
The tranfer size limitation is added to the spi_slave structure, which
is set up by the controller driver. The value of zero in this field
means 'unlimited transfer size'. It will work with existion drivers,
as they all either keep structures in the bss segment, or initialize
them to all zeros.
This patch addresses the problem for reads only, as coreboot is not
expected to require to write long chunks into SPI devices.
BRANCH=none
BUG=chrome-os-partner:32441, chrome-os-partner:31438
TEST=set transfer size limit to artificially low value (4K) and
observed proper operation on both Pistachio and ipq8086: both
Storm and Urara booted through romstage and ramstage.
Change-Id: Ibb96aa499c3eec458c94bf1193fbbbf5f54e1477
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4f064fdca5b6c214e7a7f2751dc24e33cac2ea45
Original-Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232239
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9571
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
WPT-LP has 4 SATA ports. Current code assumes 6 SATA ports and as a result,
some reserved bits are written with 1. No specific issue has been observed
so far.
BUG=None
BRANCH=None
TEST=Verify SATA PCI configure space dump on Auron
Change-Id: I737719b3d5cd788158cd5b6991405ba098be4078
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2b55587a74ac5d45354dc123937b562290468855
Original-Change-Id: I9c53ac86e2bf72901647bd2cfa48ac0ce31abea0
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233661
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9479
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
