The VDDIO to GEN2 I2C SCL/SDA pins is 1.8V and the external
pull-up voltage is 3.3V (the external 3.3V > I/O 1.8V) thus
the pinmux E_OD bit of these two pins needs to be set to
ensure GEN2 I2C pads work fine on 3.3V.
BRANCH=nyan
BUG=none
TEST=observed voltage drop from 3.3V to 2.36V on gen2 i2c
on blaze w/o this change. the waveform looks good on both
scl/sda pins w/ this change.
Original-Change-Id: I1b97f0c9c7580d1e532c3bdf7ac8690241ee7ee3
Original-Signed-off-by: Ken Chang <kenc@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/200996
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 2db39166ec525e56a19746f38a867305a2687365)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0c84eade89311baf0a6f180cb5cc9e2145f6b7ea
Reviewed-on: http://review.coreboot.org/7952
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The kernel will not track wakeup events for devices unless they have
a defined _PRW. There is no EC output of the lid signal coming to
a GPIO and instead it pulses PCH_WAKE#.
BUG=chrome-os-partner:27631
TEST=Manual on Rambi.
- Run lidclose + lidopen on EC console, verify that wakeup_count
increments.
- Run lidclose + lidopen in rapid succession, verify that suspend
request is aborted.
BRANCH=Rambi.
Original-Change-Id: I8d4c58a7bb37d7e474ec094fe96e46e1bfd980de
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200289
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 08c6b42f1ed1af7fff6217e6b71469edd7ff4b2e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iee813ed6f39cd3d5e0a2bdd395c740f82a1cf01a
Reviewed-on: http://review.coreboot.org/7945
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
xHCI Spec says TD Size (5 bits) field shall be forced to 31,
if the number of packets to be scheduled is greater than 31.
BUG=chrome-os-partner:27837
BRANCH=rambi,nyan
TEST=Manual: Ensure recovery boot with USB 2.0 media on Squawks
works fine without any babble errors.
Original-Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd
Original-Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Original-Originally-Reviewed-on: https://chromium-review.googlesource.com/202297
Original-Reviewed-on: https://chromium-review.googlesource.com/202330
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ae58b99370df3a86bf15d84b97db858a968b1dbd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9668b947f676c109fad9297e5efde91bf7f796fd
Reviewed-on: http://review.coreboot.org/7913
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add the empty weak function clear_recovery_mode_switch().
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set, turning the
device off and on again with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Original-Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Original-Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197780
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Sheng-liang Song <ssl@google.com>
Original-Tested-by: Sheng-liang Song <ssl@google.com>
(cherry picked from commit 18908bb64cef34ca41812814817ef887961bed34)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I71ca9f3ea8d816c865375ec66a0603ca211f23ae
Reviewed-on: http://review.coreboot.org/7895
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Length arguments for VbExTpmSendReceive have type uint32_t but it calls function
which expects size_t. This change converts uint32_t to size_t on call and
size_t to uint32_t on return.
BUG=None
BRANCH=None
TEST=Booted Nyan Big to Linux
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I1971488baae2d060c0cddec7749461c91602a4f9
Original-Reviewed-on: https://chromium-review.googlesource.com/198016
(cherry picked from commit 6830747eb47568f2a2b494624522d37d8945c030)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I20741759e7bbd60dd7044c532287d6b55047e19a
Reviewed-on: http://review.coreboot.org/7894
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
To avoid LCD_VCC glitch on cold reset, set SOC_DISP_ON as GPIO output high.
After gfx initialize is done, set it to native function 2.
BUG=chrome-os-partner:25159
BRANCH=firmware-rambi-5216.B
TEST=Tested on Rambi and squawks, no LCD_VCC glitch anymore.
Original-Change-Id: If16af498e910a8da1d77a9a66456eb767286a61a
Original-Change-Id: Icf62588fa0338f89fafb3fe9246c26f16bcdaa60
Original-Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197985
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 6f7d621678f22133c9825565fedc77d19198b08c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ibaf547b8d1c27811a1bec9fa3254d559c505a361
Reviewed-on: http://review.coreboot.org/7893
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
If the kernel does not properly handle the TPM and send it a
TPM_SaveState command before suspend then it will not be in
the correct state on resume. In order to easily detect this
case add a new post code for TPM failure and use it in the
vboot resume path.
BUG=chromium:371105
TEST=Build and boot on wtm2.
Original-Change-Id: I412520b521387a8e18ad1c6f5a64b39cdd5c88ec
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199371
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit ff2f0dc56c1a783295710f81567af02729fe1da2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5baf894fd72922acd79d191e5485ae8ef7e0d559
Reviewed-on: http://review.coreboot.org/7936
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Use the RTC driver interface to find the timestamp for events instead of
reading the CMOS based RTC directly on x86 or punting on ARM. This makes
timestamps available on both architectures, assuming an RTC driver is
available.
BUG=None
TEST=Built and booted on nyan_big and link and verified that the timestamps
in the event log were accurate.
BRANCH=nyan
Original-Change-Id: Id45da53bc7ddfac8dd0978e7f2a3b8bc2c7ea753
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197798
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 493b05e06dd461532c9366fb09025efb3568a975)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4fad296ecfeff8987e4a18054661190239245f32
Reviewed-on: http://review.coreboot.org/7891
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The AS3722 PMIC, like many PMICs, has an RTC built into it. This change adds a
driver for it which implements the new RTC API.
BUG=None
TEST=Built and booted with the event log code modified to use this interface.
Verified that events had accurate timestamps.
BRANCH=nyan
Original-Change-Id: I400adccbf84221dcba8d520276bb91b389f72268
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197796
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 011e49beba3a99abbd122866891e3c20bf1188d2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ibc1d342062c7853a30d195496c077e37a02b35b0
Reviewed-on: http://review.coreboot.org/7890
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch has a rather twisted history. It was originally split off
from a chromium patch, which moved ALTCENTURY to Kconfig. However,
since we have no user without ALTCENTURY, we've agreed that the best
way to proceed is to eliminate the non-ALTCENTURY case entirely.
The old commit message and identifiers are kept below for reference:
The availability of "ALTCENTURY" is now set through a kconfig
variable so it can be available to the RTC driver without having to have a
specialized interface.
BUG=None
TEST=Built and booted on Link with the event log code modified to use the RTC
interface. Verified that the event times were accurate.
BRANCH=nyan
Original-Change-Id: Ifa807898e583254e57167fd44932ea86627a02ee
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197795
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
This is the second half the following patch.
(cherry picked from commit 9e0fd75142d29afe34f6c6b9ce0099f478ca5a93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8e871f31c3d4be7676abf9454ca90808d1ddca03
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7987
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
This brings in the banana_cs version of the SPI driver.
BUG=chrome-os-partner:27784
TEST=none
Original-Change-Id: Ie93ec8c962c26fff1f0a235516cd8a4062cab40b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/194225
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3cada6e4ed51a6d4f637aa31a1a836352a99d13d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0a58a4ddaf9375c22c9b2b249a2baa2c5538ba6c
Reviewed-on: http://review.coreboot.org/7982
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
There is a hub in USB port2 downstream.
BUG=chrome-os-partner:28964
BRANCH=None
TEST=emerge-nyan_blaze coreboot depthcharge chromeos-bootimage and verify usb
port2 is workable
Original-Change-Id: I0e698970729911f401f89594232f9d49e4da93cc
Original-Signed-off-by: Neil Chen <neilc@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/200417
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 9316acfe8791585f778eecead95943e6422ca419)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I76e4331ea6e803bfbbddefab449310421c0c1d9c
Reviewed-on: http://review.coreboot.org/7949
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Our tests with the I2C bit clear mechanism (recovering from "lost
arbitration" errors) show that the bit clear hardware does not work
correctly in some situations. When a wedged slave device tries to send
more than one 0-to-1-to-0 transition to the host (e.g. leftover bits
from an aborted read), the controller never transitions the BC_ENABLE
bit back to zero.
This patch adds a long timeout to the bit clear code that waits for
register transitions as a safeguard. This way, We will still eventually
exit the function (probably followed by a reboot). Our tests show that
this will recover from all conditions after at most a few reboots.
BRANCH=nyan
BUG=chrome-os-partner:28323
TEST=Ran wedge_ack and wedge_read tests with software_i2c patch, system
recovered as expected in all cases.
Original-Change-Id: I6c37119130e1240e1ef3a5944582abbcd2e39ff0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200265
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4c8d0af25cf107a38c856b38067b8f2f74384f22)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I600d5c9a8e68719cf8795c083c5fac63f626f5bf
Reviewed-on: http://review.coreboot.org/7948
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Original-Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198791
Original-Reviewed-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 8f71503dbbd74c5298e90e2163b67d4efe3e89db)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id6c5f75bb5baaabd62b6b1fc26c2c71d9f1ce682
Reviewed-on: http://review.coreboot.org/7947
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When doing DP attach, we need to make sure the register change to
take effect immediately, otherwise it may fail to catch the attach
timing.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Original-Change-Id: I569dc435a1aa4aac0d5ecd0655d2ad87a791246d
Original-Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/200414
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 47b86e2893fa667bebada6a0e0b443886dd5ee02)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Icf809b46e675bbdb8633d9a4f31d005d6644bd2a
Reviewed-on: http://review.coreboot.org/7951
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We initialized the dc before the plld's initialization. So some
of the dc init settings did not took effect. This patch moves
the clock_display() before the dc init call.
BRANCH=None
BUG=chrome-os-partner:28128
TEST=Display works and system boots up on Nyan and Big
Original-Change-Id: If2c40e2526fdf7a6aa33a2684ba324bd0ec40e90
Original-Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/200413
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit dc3cc253c319c21772c30962d963ec9dfc4944a7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I021290f4293c740666d460f73fecbe79146896a4
Reviewed-on: http://review.coreboot.org/7950
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=nyan
TEST=built and booted on Big under various modes, verified that
expected boot mode showed up using "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I8d98487a2cb910874c8d741008ae59a6c89102e7
Original-Reviewed-on: https://chromium-review.googlesource.com/199691
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 9f4b2574c1af23dcdc01706e9a118441f46a0f97)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ibbf264a1e05323dfddb7cdb270ee6f2d49e83eff
Reviewed-on: http://review.coreboot.org/7946
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Provide elog stub functions so eventlog support can be omitted
without littering code with "#if CONFIG_ELOG".
This makes it so coreboot can be built without eventlog support for
these platforms for debugging purposes.
BUG=none
BRANCH=none
TEST=compiled for Nyan and Rambi with CONFIG_ELOG unset
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Ibf56d29a09234068773378f99ad9bffd5480dc9c
Original-Reviewed-on: https://chromium-review.googlesource.com/198647
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 8e83dd460647972c4f46c19f8dc3d3ad7baeb550)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3c0803ceb7a1c06da717416c42b6b7730c029ed0
Reviewed-on: http://review.coreboot.org/7901
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The IO accessor wrappers are used to allow integer register addresses.
A structure defining UART interface configuration is declared and
defined. A few long lines are wrapped. Interface functions are renamed
to match the wrapper API.
cdp.c is edited to fit into coreboot compilation environment, and the
only function required by the UART driver if exposed, the rest are
compiled out for now.
BUG=chrome-os-partner:27784
TEST=after all patches are applied the serial console on AP148 becomes
operational.
Original-Change-Id: I80c824d085036c0f90c52aad77843e87976dbe49
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196662
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 5e9af53a069cd048334a3a28f0a4ce9df7c96992)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I80c824d085036c0f90c52aad77843e87976dbe49
Reviewed-on: http://review.coreboot.org/7874
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
These patch modifies .h files to match the coreboot API. A few more
significant changes are:
- UART specific fields removed from common board structure in cdp.h.
These fields are set at compile time in u-boot (where this
structure comes from), they will be set in a different structure in
the UART driver in an upcoming patch.
- an inline wrapper is added in gpio.h to provide GPIO API the UART
driver expects.
- the ipq_configure_gpio() is passed the descriptor placed in ro data.
BUG=chrome-os-partner:27784
TEST=none
Original-Change-Id: Id49507fb0c72ef993a89b538cd417b6c86ae3786
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196661
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit ea400f1b720eb671fa411c5fd1df7efd14fdacd6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2c7be09675b225de99be3c94b22e9ee2ebb2cb9a
Reviewed-on: http://review.coreboot.org/7873
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Make sure it is initialized at different stages.
BUG=chrome-os-partner:27784
TEST=manual
. not much at this point, just verified that it compiles
Original-Change-Id: I343e7a6648e2ca935606cd76befd204aabd93726
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on:
https://chromium-review.googlesource.com/196592
(cherry picked from commit aedc41924313e5c21aef97b036f5a0643d59082d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4a90ae5ba6c9a561b7d5c938d18b6ea2b855855f
Reviewed-on: http://review.coreboot.org/7981
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The following patches had to be squashed
to properly build all the different ARM boards.
ipq8064: storm: re-arrange bootblock initialization
The recent addition of the storm bootblock initialization broke
compilation of Exynos platforms. The SOC specific code needs to be
kept in the respective source files, not in the common CPU code.
As of now coreboot does not provide a separate SOC initialization API.
In general it makes sense to invoke SOC initialization from the board
initialization code, as the board knows what SOC it is running on.
Presently all what's need initialization on 8064 is the timer. This
patch adds the SOC initialization framework for 8064 and moves there
the related code.
BUG=chrome-os-partner:27784
TEST=manual
. nyan_big, peach_pit, and storm targets build fine now.
Original-Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197835
(cherry picked from commit 3ea7307b531b1a78c692e4f71a0d81b32108ebf0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
arm: Redesign mainboard and SoC hooks for bootblock
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.
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().
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>
(cherry picked from commit 257aaee9e3aeeffe50ed54de7342dd2bc9baae76)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id055fe60a8caf63a9787138811dc69ac04dfba57
Reviewed-on: http://review.coreboot.org/7879
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
When emerging libpayload a warning is generated about selfboot() being
defined without a prior prototype.
Add cbfs.h when CBFS use if compiled fixes the warning.
BUG=none
TEST=build rambi storm nyan_big
verify that there is no compilation warnings thrown any more
Original-Change-Id: Ic9cb5571f708bb006a0d477e451fd1f3b3eb833f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200099
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 7e4aa17936b70dd08f58b3a55c6db55ea03709d7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie3baaaca82fb6ec432860c638acb2a3ef9451469
Reviewed-on: http://review.coreboot.org/7909
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
The calling convention of payload entry function is different by architecture.
For example, X86 takes no arguments and ARM needs first param to be a
cb_header_ptr*.
To help payloads load and execute other payloads easily and correctly, we should
provide the selfboot() function in libpayload, using same prototype as defined
in coreboot environment.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Original-Change-Id: I8f1cb2c0df788794b2f6f7f5500a3910328a4f84
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199503
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 1e916cf021ce68886eb9668982c392eadedc7b7e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7279ef27f49ef581d25a455dd8f1f2f7f1ba58cb
Reviewed-on: http://review.coreboot.org/7907
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
BUG=chrome-os-partner:25907
BRANCH=baytrail(rambi)
TEST=Read and write MRC and ELOG on Glimmer with Eon device.
Original-Change-Id: If883ff6eb14dd49a06f57a01ca61661854ded78d
Original-Reviewed-on: https://chromium-review.googlesource.com/198324
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Marc Jones <marc.jones@se-eng.com>
Original-Tested-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 536c34c2d92178f4e62b8ca7cfffceaf80a305f6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I199451ed2b29c55bfb5e1487afa8cf3b9978e63e
Reviewed-on: http://review.coreboot.org/7935
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The Eon SPI25 code had a number of issues:
- fix page write calculation
- fix erase segment
- fix id check
- fix sector size
- make commands EN25 generic
This makes the code similar to other SPI25 devices used in coreboot.
BUG=chrome-os-partner:25907
BRANCH=baytrail(rambi)
TEST=Read and write MRC and ELOG on Glimmer with Eon device.
Original-Change-Id: I7667eab28b850790d92a591c869788d51c26a56c
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/198323
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Marc Jones <marc.jones@se-eng.com>
Original-Tested-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 2ee0da695bf6a6c6aedc0dd2b3a3b7c9c3165bca)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8917e778cd62f3745189336d23c0c6118887d893
Reviewed-on: http://review.coreboot.org/7934
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Since the same driver is going to be used at all coreboot stages, it
can not use malloc() anymore. Replace it with static allocation of the
driver container structure.
The read interface is changed to spi_flash_cmd_read_slow(), because of
the problems with spi_flash_cmd_read_fast() implementation. In fact
there is no performance difference in the way the two interface
functions are implemented.
BUG=chrome-os-partner:27784
TEST=manual
. with all patches applied coreboot proceeds to attempting to load
the payload.
Original-Change-Id: I1c7beedce7747bc89ab865fd844b568ad50d2dae
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197931
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 57ee2fd875c689706c70338e073acefb806787e7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9d9e7e343148519580ed4986800dc6c6b9a5f5d2
Reviewed-on: http://review.coreboot.org/7933
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197800
Original-Tested-by: Vadim Bendebury <vbendeb@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41
Reviewed-on: http://review.coreboot.org/7932
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Add the device ID definitions and properties for the SPI chip used on
the AP148 board (Google Storm).
BUG=chrome-os-partner:27784
TEST=manual
. with the rest of the patches applied AP148 boots all the way to
trying to read the payload.
Original-Change-Id: I5a0e5c9d3cc9ea81bc5227c0fbc1d0a5fc7bec27
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197895
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a7c69981b18ac6b1158273596b94df0def65963d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I14e2f4f8f691a7db6ed596a3440914e08680867b
Reviewed-on: http://review.coreboot.org/7931
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This CL adds an API for RTC drivers, and implements its two functions,
rtc_get and rtc_set, for x86's RTC. The function which resets the clock when the
CMOS as lost state now uses the RTC driver instead of accessing the those
registers directly.
BUG=None
TEST=Built and booted on Link with the event log code modified to use
the RTC interface. Verified that the event times were accurate.
BRANCH=nyan
Original-Change-Id: Ifa807898e583254e57167fd44932ea86627a02ee
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197795
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
This is the first half of the patch.
(cherry picked from commit 9e0fd75142d29afe34f6c6b9ce0099f478ca5a93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I159f9b4872a0bb932961b4168b180c087dfb1883
Reviewed-on: http://review.coreboot.org/7889
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Original-Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199791
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5217446a536bb1ba874e162c6e2e16643caa592a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d839316e9697bd3afa0b60490a840d39902dfb3
Reviewed-on: http://review.coreboot.org/7938
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The -z "${V}" sure must have meant to be -n "${V}", but come to think
of it, this check is not necessary, as the following check will
succeed if and only if V is set to 1.
BUG=none
TEST=verified that adding V=1 to the environment causes the lpgcc
debug statements to show up in the output.
Original-Change-Id: I1eb43ef49aeb4f16aef4fbee3a1037e853f9b40f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200501
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 7d69a292b1dc90e68e539e329f019098f8af5007)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I63785fd9fc88b95d50ecced1f4f74a76ca68089c
Reviewed-on: http://review.coreboot.org/7912
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in chromium.org 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Original-Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200688
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3f01d1dc0974774f0b3ba5fc4e069978f266f2fc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I98c1d8360539b457e6df07cbcf799acaf6c4631b
Reviewed-on: http://review.coreboot.org/7910
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
The keyboard.c uses IO cycles to access the legacy PC keyboard device.
ARM can't do IO cycles, so remove the option for ARM configs.
Change-Id: Ifc6c2368563f27867f4babad5afdde0e78f4cf78
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7922
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There were a few build warnings in the USB driver to clean
up before -Werror may be enabled.
Change-Id: I220cfcf0ee926912a184a91d3ced3ba61259130e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7921
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Original-Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196323
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 1f880bca06ed0a3f2c75abab399d32a2e51ed10e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6c67a9efb00d96fcd67f7bc1ab55a23e78fc479e
Reviewed-on: http://review.coreboot.org/7908
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Some EABI conformant toolchains like GCC need additional functions like raise.
To prevent payloads adding arch-specific implementations everywhere, we should
provide the default version in libpayload.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Original-Change-Id: Id1e3c29590aa5881aefd944a7551949ce9a47b8f
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199686
(cherry picked from commit 395810c4b744dbb720050f79a2c1a30e81464554)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2e1d8c8cb519f8e788c22d081132d23b49b8f822
Reviewed-on: http://review.coreboot.org/7906
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
I always thought the support for multiple logical SCSI units in the USB
mass storage class was a dead feature. Turns out that it's actually used
by SD card readers that provide multiple slots (e.g. one regular sized
and one micro-SD). Implementing perfect support for that would require a
major redesign of the whole MSC stack, since the one device -> one disk
assumption is deeply embedded in our data structures.
Instead, this patch implements a poor man's LUN support that will just
cycle through all available LUNs (in multiple calls to usb_msc_poll())
until it finds a connected device. This should be reasonable enough to
allow these card readers to be usable while only requiring superficial
changes.
Also removes the unused 'protocol' attribute of usb_msc_inst_t.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=Alternatively plug an SD or micro-SD card (or both) into my card
reader, confirm that one of them is correctly detected at all times.
Original-Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198101
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 960534a20e4334772c29355bb0d310b3f41b31ee)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I39909fc96e32c9a5d76651d91c2b5c16c89ace9e
Reviewed-on: http://review.coreboot.org/7904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
So I was debugging this faulty USB SD card reader that would just fail
it's REQUEST SENSE response for some reason (sending the CSW immediately
without the data), cursing those damn device vendors for building
non-compliant crap like I always do... when I noticed that we do not
actually set the Allocation Length field in our REQUEST SENSE command
block at all! We set a length in the CBW, but the SCSI command still has
its own length field and the SCSI spec specifically says that the device
has to return the exact amount of bytes listed there (even if it's 0). I
don't know what's more suprising: that we had such a blatant bug in this
stack for so long, or that this card reader is really the first device
to actually be spec compliant in that regard.
This patch fixes the bug and changes the command block structures to be
a little easier to read (why that field was called 'lun' before is
beyond me... LUN is a transport level thing and should never appear in
the command block at all, for any command). It also fixes a memcpy() in
wrap_cbw() to avoid a read buffer overflow that might expose stack frame
data to the device.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=The card reader works now (for it's first LUN at least).
Original-Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198100
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 88943d9715994a14c50e74170f2453cceca0983b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3097c223248c07c866a33d4ab8f3db1a7082a815
Reviewed-on: http://review.coreboot.org/7903
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Always build CBMEM for romstage, even for boards that will not use it.
We further restrict car_migrate_variables() runs to non-ROMCC boards without
BROKEN_CAR_MIGRATE.
This fixes regression of commit 71b21455 that broke CBMEM console support
for boards with a combination of !EARLY_CBMEM_INIT && !HAVE_ACPI_RESUME.
Change-Id: Ife91d7baebdc9bd1e086896400059a165d3aa90f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7877
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
When using fixed MTRRs for CAR setup, CONFIG_DCACHE_RAM_BASE is ignored
and was not correctly set on affected sockets and boards. It was still
referenced in romstage linker script. This was discovered by clang builds
failing for cases where DCACHE_RAM_BASE = 0, while gcc builds passed.
The actual DCACHE_RAM_BASE programming is base = 0xd0000 - size, as taken
from intel/cpu/cache_as_ram.inc.
Change-Id: Ied5ab2e9683f12990f1aad48ee15eaf91133121c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7887
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Ken Chang