This change switches all SOC vendors and southbridges
to be autoincluded by Makefile.inc, rather than having to be
mentioned explicitly in soc/Makefile.inc or in
soc/<vendor>/Makefile.inc.
This means, vendor and SOC directories are now "drop
in", e.g. be placed in the coreboot directory hierarchy
without having to modify any higher level coreboot files.
The long term plan is to enable out of tree components to be
built with a given coreboot version (given that the API did not
change).
Change-Id: Iede26fe184b09c53cec23a545d04953701cbc41d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9799
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Many chipsets were using a stage cache for reference code
or when using a relocatable ramstage. Provide a common
API for the chipsets to use while reducing code duplication.
Change-Id: Ia36efa169fe6bd8a3dbe07bf57a9729c7edbdd46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8625
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
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>
According to BYT platform design guide chap 14.2.2, the NC GPIOs
need to be configured to GPO.
BRANCH=none
BUG=none
TEST=Test on rambi, boot to OS, and make sure NC pins config to GPO
Change-Id: Ida5ea89ee66e39b4fddea242dc918b314756d94f
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 998493566f5cf7abd9375583e12fe631b226e591
Original-Change-Id: Ieaf346d1c7bf3ecb47a71a6ee4afaa805235cc37
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/249060
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this code change provides a way to enable 2x refresh rate
in RW image
In baytrail, it enables 2x refresh rate by default
BUG=chrome-os-partner:35210
BRANCH=none
TEST=check the register is set properly on rambi
Change-Id: I2a935b570c564986898b6c2064fc7ad43506dcba
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c740d403708862514be9fa24f56b2764328979eb
Original-Change-Id: I84f33d75ea7ebfea180b304e8ff683884f0dbe8a
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241754
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9498
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The original code uses L1EXIT_MASK to shift the bit for
PCIe L1 exit latency, the code should use L1EXIT_SHIFT
for bit shifting.
BUG=chrome-os-partner:34037
BRANCH=None
TEST=build and boot on candy, verify B0:D28:F0 + 4Ch [17:15]
set to 010b. Correspond WIFI device performance got improvement.
Signed-off-by: Kevin L Lee <kevin.l.lee@intel.com>
Change-Id: I3ac5b6319b726aa16cdb9678face89022d979517
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 381827e3d92c9e786cd8ebe412586968662fb4be
Original-Change-Id: I8171f80720830cfa76f26778ae31c7590a723b92
Original-Reviewed-on: https://chromium-review.googlesource.com/234673
Original-Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Tested-by: Kenji Chen <kenji.chen@intel.com>
Original-Commit-Queue: Kenji Chen <kenji.chen@intel.com>
Reviewed-on: http://review.coreboot.org/9480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Using REG_PCI_POLL32 to check if the LINK is active with 50ms timeout.
BRANCH=none
BUG=chromium:431169
TEST=Test on Enguarde, compile ok and boot OS
Change-Id: If98ab4e31d17ec4e62d68b93edcec6d9aee87367
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: cf692ae9aebb43ab46cb07d36b62b300b16be1dc
Original-Change-Id: I490e6ffa40979628edf52a7444808b6d25a6e83d
Original-Signed-off-by: Kevin Hsieh <kevin.hsieh@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231777
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9478
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Most Baytrail based devices MMIO registers are reported in ACPI
space and the device's PCI config space is disabled. The PCI config
space is required for many "legacy" OSs that don't have the ACPI
driver loading mechanism. Depthcharge signals the legacy boot
path via the SMI 0xCC and the coreboot SMI handler can switch the
device specific registers to re-enable PCI config space.
BUG=chrome-os-partner:30836
BRANCH=None
TEST=Build and boot Rambi SeaBIOS.
Change-Id: I87248936e2a7e026f38c147bdf0df378e605e370
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: dbb9205ee22ffce44e965be51ae0bc62d4ca5dd4
Original-Change-Id: Ia5e54f4330eda10a01ce3de5aa4d86779d6e1bf9
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219801
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Original-Tested-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/9459
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch aligns baytrail to the new SoC header include scheme.
BUG=None
TEST=Tested with whole series. Compiled Rambi.
Change-Id: I0f0a894f6f33449756582eefa0b50bae545220db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1216a86538517c03a7e5bca547d08ff3dbcaa083
Original-Change-Id: If5d2a609354b3d773aa3d482e682ab97422fd9d5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222026
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9363
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Disable VC setting for HDA so hdmi audio choppy issue will be eliminated.
Change HDA initialize steps to sync with UEFI reference code.
BUG=chrome-os-partner:25651
BRANCH=Baytrail
TEST=Does not have choppy noise during video playing
Original-Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Original-Change-Id: I45d49123d369b7d075776215e709af5801ea696d
Original-Reviewed-on: https://chromium-review.googlesource.com/186024
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Benson Leung <bleung@chromium.org>
Original-Tested-by: Benson Leung <bleung@chromium.org>
Original-Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
(cherry picked from commit 9f725a40f77cd684b2e230bd226d78d87b56e73b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4fc10a161e5996e14d4823491fb62a7beff39bcc
Reviewed-on: http://review.coreboot.org/9297
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On the SMM APM_CNT_FINALIZE step reinitialize the SPI
controller so that it can still log events after the SPI
controller has been locked down.
BUG=chrome-os-partner:24624
BRANCH=baytrail
TEST=Built and booted. Events still logged after SPI controller
has been locked down.
Original-Change-Id: I41a3e12c0398303e74f95eb6df82d5bc4303898b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/185630
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 28ffb1a9e761cdfeb173bd533684db1011260e0a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia82753cba9ae4f049de2e81061739efc21d49a1e
Reviewed-on: http://review.coreboot.org/9296
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The rmod_stage_load structure contained the same fields
as struct prog. In order to more closely integrate with the
rest of program loading use struct prog.
Change-Id: Ib7f45d0b3573e6d518864deacc4002802b11aa9c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9143
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Intel will be making slight changes to USB3 PLL VCO and iCLK PLL current
on C0 stepping of BYT-M/D C0 stepping in order to meet the high demands
for these processors.
Pre-conversion materials are compatible with USB PLL VCO current increase.
Post-conversion materials ARE REQUIRED to be run with increased USB3 PLL
VCO current.
BUG=chrome-os-partner:31199
TEST=Boot Rambi, then read USHPHY_CDN_PLL_CONTROL and verify register
has new value.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: bc01a3df80f5bd7fd86047c8bbf1584d19363e3b
Original-Change-Id: Ie9c3d0afd54ea7ced2c76ebb948de95be0828fa0
Original-Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/211337
Original-Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-(cherry picked from commit df20eca47ca0ff33baf5d554ef11dd2b35706a5d)
Original-Reviewed-on: https://chromium-review.googlesource.com/205970
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217772
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Kenji Chen <kenji.chen@intel.com>
Original-Tested-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I1c825992a2b4dfac86f77cde567d2471ca4c19e6
Reviewed-on: http://review.coreboot.org/9200
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Disable Root Port0 only when there is no PCIe device
present on any root port.
BUG=None
TEST=Boot Rambi with PCIe installed/non-installed on RP0 to
confirm the RP0 is correctly enabled/disabled. However, I still
need someone to help check if RP0(no device) is still enabled
if there is device on other RPs since since I have no devices
having slots from RP1/2/3.
Change-Id: Iae552975250ed6f309c423b847621b8994172891
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c5cef0b7c2c146f0d46ed49b75fd2ec8369210ce
Original-Change-Id: I7147569e78b2d1ecea070bc933773cdcae59f9e7
Original-Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217791
Original-Tested-by: Ted Kuo <tedkuo@ami.com.tw>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9219
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Report PCI routing table of all PCIe root ports for legacy interrupt.
Some PCIe devices using legacy interrupt can't work if PCI routing table
isn't defined. It's necessary and defined in BWG Chapter 28.1.3.
BUG=chrome-os-partner:31943
TEST=compiled and tested
BRANCH=NONE
Signed-off-by: Ted Kuo <tedkuo@ami.com.tw>
Change-Id: I2c684edfd1fc624bed471783584250cd9f5e66f5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: b9040d564a32607327057a84b9aab14e66cd5b45
Original-Change-Id: Ia15ced6c5fdcc6712e5f2831e42c6dee320f166b
Original-Reviewed-on: https://chromium-review.googlesource.com/218422
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Ted Kuo <tedkuo@ami.com.tw>
Original-Commit-Queue: Ted Kuo <tedkuo@ami.com.tw>
Original-Tested-by: Ted Kuo <tedkuo@ami.com.tw>
Reviewed-on: http://review.coreboot.org/9201
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In commit 72a8e5e751 the
Makefile's were updated to use named types for cbfs
file addition. However, the call sites were not checked to
ensure the types matched. Correct all call sites to use the
named types.
Change-Id: Ib9fa693ef517e3196a3f04e9c06db52a9116fee7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9195
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
When building HAVE_REFCODE_BLOB there are a couple of errors. One
is a failure building !CHROME_OS. The other is from a header
change where console_tx_byte() was declared.
Change-Id: Ia912902e8276d13b8e1716aa16c57b111579a03d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9141
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
These binaries were being added to CBFS using hexadecimal values instead
of the CBFS binary type names. The same value was being used in
different places for different things.
For example, the value 0xAB is used for SPDs, MRC & FSP binaries.
This patch uses CBFS type names instead of hex values everywhere a
hex value was previously used.
Change-Id: Id5ac74c3095eb02a2b39d25104a25933304a8389
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8978
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There is nothing platform specific in retrieving S3 resume state from
romstage_handoff structure. Boards without EARLY_CBMEM_INIT update
acpi_slp_type from ACPI power-management block or scratchpad registers.
Change-Id: Ifc3755f891a0810473b3216c1fec8e45908fc1ab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8188
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
At some point the license text for a file was incorrectly
changed. That license was then copied and pasted. I'm sure it
was myself. Anyhow, fix the bustedness.
Change-Id: I276083d40ea03782e11da7b7518eb708a08ff7cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Fix up commit ce7ecf9c (baytrail: enable monotonic timer), which
selected `HAVE_MONOTONIC_TIMER` explicitly, although it is already
selected by `TSC_MONOTONIC_TIMER` (cf. `src/cpu/x86/Kconfig`).
Therefore remove the explicit selection of that Kconfig option.
Change-Id: I8964771947a6f7457dcdefe7a17be623ae0ef900
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8471
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The existing code generated invalid ACPI processor objects
if the core number was greater than 9. The first invalid
object instance was autocorrected by Linux, but subsequent
instances conflicted with each other, leading to a failure
to boot if more than 10 CPU cores were installed.
The modified code will function with up to 99 cores.
Change-Id: I62dc0eb61ae2e2b7f7dcf30e9c7de09cd901a81c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8422
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
On x86, change the type of the address parameter in
read8()/read16/read32()/write8()/write16()/write32() to be a
pointer, instead of unsigned long.
Change-Id: Ic26dd8a72d82828b69be3c04944710681b7bd330
Signed-off-by: Kevin Paul Herbert <kph@meraki.net>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7784
Tested-by: build bot (Jenkins)
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
The name was always obscure and confusing. Instead define cbmem_top()
directly in the chipset code for x86 like on ARMs.
TODO: Check TSEG alignment, it used for MTRR programming.
Change-Id: Ibbe5f05ab9c7d87d09caa673766cd17d192cd045
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7888
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This reverts the revert commit 5780d6f387
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Due to some projects don't have the correct settings in devicetree.cb
so put this change in case those projects without are setting in devicetree.cb
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
even there is no setting in devicetree
Original-Change-Id: Iaf8155497c41f10c81d1faa7bb0e3452a7cedcc6
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209051
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 713f809952a2d8da434d619d48cb7ddce1991925)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I86f9b77e703d2b844fa636678499c47ffaffeede
Reviewed-on: http://review.coreboot.org/8218
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
USBPHY_COMPBG needs to be configured by project
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
Original-Change-Id: I05eee384d94cf5deeec14418bd78816df0b26a92
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/208557
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 20a9c0ab7ab180596821751110f0c0a35d3ff3a1)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8bed3fa4e74e4bb4c93fa522d9df631bac2d9795
Reviewed-on: http://review.coreboot.org/8216
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
No reason to carry timestamps on CAR stack, as implementation
of timestamps internally stashes on CAR_GLOBAL table and migrates
those to CBMEM.
Change-Id: I5b3307df728b18cd7ebf3352f7f7e270ed1e9002
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8022
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Cherry-pick from chromium and adjusted for added boards
and changed directory layout for arch/arm.
Timestamp implementation for ARMv7
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Original-Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Original-Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Original-Reviewed-on: https://gerrit.chromium.org/gerrit/63793
(cherry-picked from commit cc1a75e059020a39146e25b9198b0d58aa03924c)
Change-Id: Ic51fb78ddd05ba81906d9c3b35043fa14fbbed75
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8020
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
GPIO init marcos are not enough to initialize different gpio attributes
BUG=none
TEST=emerge-rambi coreboot works well
Original-Change-Id: I193fa7b3e22632cacb555e726e3dd3991f4f4faa
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/200531
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5e0fcbcd7cefcfccb5b565003336d197bb29e4cc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6bf4db9397733a003dfdedc6eb63b82127917851
Reviewed-on: http://review.coreboot.org/7953
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The GPIO_OUT_LOW #define was missing an internal comma in both
soc/intel/baytrail and soc/intel/fsp_baytrail.
Thanks to Werner Zeh for pointing this out.
Change-Id: I2e5507058739e5fdc2c0e43e0380058458870e46
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7801
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Werner Zeh <werner.zeh@gmx.net>
In order to protect ourselves from the kernel driver not honoring or
placing the correct frequency in the backlight register always set one.
This code path picks 200Hz as the default if nothing is specified in
device tree. It's somewhat arbitrary but that frequency is valid for all
the eDP panel specs we've seen being used on baytrail devices.
BUG=chrome-os-partner:28267
BRANCH=baytrail
TEST=Built and booted in normal mode. Noted register write stuck.
Original-Change-Id: Ifec29f0671e9f14ba57b9643c29d8bb2cd07eef5
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196821
Original-Reviewed-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 2eaa650860ebbc838dbf8c1c1ca2259ac64141ac)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ifec29f0671e9f14ba57b9643c29d8bb2cd07eef5
Reviewed-on: http://review.coreboot.org/7845
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This ensures that SPI is ready when eventlog code is used.
x86 platforms which use eventlog invoke elog_clear() in GSMI and
elog_add_event_raw() when deciding the boot path based on ME status.
For the SMM case spi_init() is called during the finalize stage in
SMM setup. For the boot path case we can call spi_init() at the
beginning of BS_DEV_INIT and it will be ready to use when the boot
path is determined from the ME status.
BUG=none
BRANCH=none
TEST=tested on Link (bd82x6x), Beltino (Lynxpoint), and Rambi
(Baytrail) with follow-up patch
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Id3aef0fc7d4df5aaa3c1c2c2383b339430e7a6a1
Original-Reviewed-on: https://chromium-review.googlesource.com/194525
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 173d8f08e867bab8c97a6c733580917f5892a45d)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ifaed677bbb141377b36bd9910b2b1c3402654aad
Reviewed-on: http://review.coreboot.org/7756
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
They were only used internal to the SPI drivers and, according to the comment
next to their prototypes, were for when the SPI controller doesn't control the
chip select line directly and needs some help.
BUG=None
TEST=Built for link, falco, and rambi. Built and booted on peach_pit and nyan.
BRANCH=None
Original-Change-Id: If4622819a4437490797d305786e2436e2e70c42b
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/192048
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 1e2deecd9d8c6fd690c54f24e902cc7d2bab0521)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ida08cbc2be5ad09b929ca16e483c36c49ac12627
Reviewed-on: http://review.coreboot.org/7708
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
spi_set_speed was never implemented, and spi_cs_is_valid was only implemented
as a stub and never called.
BUG=None
TEST=Built for rambi, falco, and peach_pit.
BRANCH=None
Original-Change-Id: If30c2339f5e0360a5099eb540fab73fb23582905
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/192045
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 98c1f6014c512e75e989df36b48622a7b56d0582)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iebdb2704ee81aee432c83ab182246d31ef52a6b6
Reviewed-on: http://review.coreboot.org/7707
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
According to spec IRQ1 isn't available for PIRQ assignment.
Has gone unnoticed probably because modern OS use MSI or
at least APIC and even with noapic don't use IRQ1 with PCI
IRQs.
Change-Id: Idc7db249007df629b27e8cae41cc80358d5306f6
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7478
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
readelf(1) may not know about the i386 flavor, or not
be present at all under this name.
Change-Id: I285df1f2098200b89918a4c4d3610e6427e86e01
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7448
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
- The hotplug register doesn't work in the way we describe. Just leave
it at default.
- The backlight registers will be configured by the OS driver.
BUG=chrome-os-partner:27304
TEST=Manual on Rambi. Boot system in both dev and normal mode, verify
that display comes up. Also verify that display functions after warm
reboot and suspend / resume.
BRANCH=rambi+squawks
Change-Id: I5559c131f41c4a14e64e5cec66e18d3a4a46092c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193830
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 3f287cc31e41fabef755c37361e2e65ca413c88c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7217
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Provide the option to embed MRC as an ELF file and not just
binary blob. This allows for MRC to be relocated.
BUG=chrome-os-partner:27654
BRANCH=rambi
TEST=Built and booted rambi.
Change-Id: I2e177c155a3074e4e1d450b1a73b7299aebd5286
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192893
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 89c97d5e2023b8c5cc780e1b1d532d0a586512f9)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7214
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Moving the cache-as-ram base address to 0xfe000000 will
provide more breathing room in the physical address space.
It will also allow for larger SPI roms in the future.
BUG=chrome-os-partner:27045
BRANCH=baytrail
CQ-DEPEND=CL:*157278
TEST=Built and booted. Suspended and resumes. Vboot works, MRC
settings are being saved as well.
Change-Id: I618c069e504f545e02de5ac54e057566f0b5d6c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190700
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 73c07a319d678f3e9be2fac64599c94f91c9ad9c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7212
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Implement vboot_get_sw_write_protect, which returns the FW SPI ROM SW WP
status.
BUG=chrome-os-partner:26777
TEST=Manual on Rambi with all patches in sequence:
`crossystem sw_wpsw_boot` prints 0
`flashrom --wp-enable` + reboot
`crossystem sw_wpsw_boot` prints 1
BRANCH=Rambi
Original-Change-Id: I5da35c1b2d25b8679bf0084af65d08de224387f8
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190097
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 5bba447654417c42952c49542ed047b4867d04d1)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I739cbb8fca5f02462cf78c81f9b364aabfd3fe86
Reviewed-on: http://review.coreboot.org/7211
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The reg_script functionality is only used by specific chipsets so have
it selected instead of defaulting to y for ARCH_X86.
Change-Id: I8fb9466e148eed7896ca8ed80755c77ba1190583
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7006
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Most of the code related to the mc146818 is not related to the RTC and is
really for managing the CMOS storage. Since we intend to add a generic API
for RTC drivers it's inconvenient for those functions to have an rtc_ prefix.
This CL renames those functions so they start with cmos_ instead. There are
some places where rtc_init was called with a comment that says something about
starting the RTC. That wasn't correct before (the RTC is always running), but
it looks a little odd now that the function is called cmos_init.
This CL also opportunistically cleans up some style problems in this file.
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197794
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 9a9ad24888b185fb58965457704e326bb508d788)
Removed the addition of stdint.h to mc146818rtc.h since
types.h is now included. Changed rtc_init to cmos_init for
fsp_bd82x6x, fsp_rangeley, fsp_baytrail, ibexpeak, vortex86ex.
Change-Id: Id4b9f6bea93e8bd5eaef2cb17f296adb9697114c
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6977
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is common code for Intel SOC that can be shared.
Change-Id: Ic703f36f56a8238d5cc1248b353d8c3a49827a9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196264
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 3a9057b9616c54a8404eee55511743d2492dbc28)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6968
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This common code can be shared across Intel SOCs.
Change-Id: Id9ec4ccd3fc81cbab19a7d7e13bfa3975d9802d0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit f9919e2551b02056b83918d2e7b515b25541c583)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6967
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
baytrail: Change all GPIO related pull resistors from 10K to 20K
Reviewed-on: https://chromium-review.googlesource.com/187570
(cherry picked from commit 762e99861dd1ae61ddcf1ebdec8e698ede54405e)
baytrail: workaround kernel using serial console on resume
Reviewed-on: https://chromium-review.googlesource.com/188011
(cherry picked from commit b0da3bdb5b6b417ad6cab0084359d4eae1cb4469)
baytrail: allow dirty cache line evictions for SMRAM to stick
Reviewed-on: https://chromium-review.googlesource.com/188015
(cherry picked from commit 50fb1e6a844e1db05574c92625da23777ad7a0ca)
baytrail: Optionally pull up TDO and TMS to avoid power loss in S3.
Reviewed-on: https://chromium-review.googlesource.com/188260
(cherry picked from commit e240856609b4eed5ed44ec4e021ed385965768d6)
rambi: always load option rom
Reviewed-on: https://chromium-review.googlesource.com/188721
(cherry picked from commit d8a1d108548d20755f8683497c215e76d513b7a9)
baytrail: use new chromeos ram oops API
Reviewed-on: https://chromium-review.googlesource.com/186394
(cherry picked from commit f38e6969df9b5453b10d49be60b5d033d38b4594)
rambi: always show dev/rec screens on eDP connected panel
Reviewed-on: https://chromium-review.googlesource.com/188731
(cherry picked from commit 7d8570ac52f68492a2250fa536d55f7cbbd9ef95)
baytrail: stop e820 reserving default SMM region
Reviewed-on: https://chromium-review.googlesource.com/189084
(cherry picked from commit 6fce823512f5db5a09a9c89048334c3524c69a24)
baytrai: update MRC wrapper header
Reviewed-on: https://chromium-review.googlesource.com/189196
(cherry picked from commit 36b33a25b6603b6a74990b00d981226440b68970)
rambi: Put LPE device into ACPI mode
Reviewed-on: https://chromium-review.googlesource.com/189371
(cherry picked from commit 5955350cd57fd1b3732b6db62911d824712a5413)
baytrail: DPTF: Enable mainboard-specific PPCC
Reviewed-on: https://chromium-review.googlesource.com/189576
(cherry picked from commit 27fae3e670244b529b7c0241742fc2b55d52c612)
baytrail: Add config option for PCIe wake
Reviewed-on: https://chromium-review.googlesource.com/189994
(cherry picked from commit 1cc31a7c021ec84311f1d4e89dd3e57ca8801ab5)
rambi: Enable PCIe wake
Reviewed-on: https://chromium-review.googlesource.com/189995
(cherry picked from commit c98ae1fee54cfb2b3d3c21a19cdbbf56a0bfa1e6)
Squashed 13 commits for baytrail/rambi.
Change-Id: I153ef5a43e2bede05cfd624f53e24a0013fd8fb4
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6957
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
ACPI globalnvs.asl expects the gnvs memory area size to be 0x2000.
Padding has been added to device_nvs struct to reserve the full
0x2000 bytes for gnvs usage.
No known issues are caused by having the GNVS area shorter than
what ACPI thinks. Since there's nothing defined in this area,
O/S shouldn't try to access it. Only problem might be if O/S
notices the SSDT is located within the GNVS defined area.
I verified that the next table written to memory (SSDT) is 0x2000
past GNVS start using a custom-designed Baytrail-I motherboard
based on the Intel Bayley Bay CRB.
Change-Id: I9792954c7a3403eba6f37d7e53ea4a9ed3a2e4ac
Signed-off-by: Scott Radcliffe <sradcliffe@microind.com>
Reviewed-on: http://review.coreboot.org/7039
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Stop polluting first screen of all boards.
Change-Id: I1ab88075722f7f0d63550010e7c645281603c9c3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fixed spelling and added empty lines to separate the help
from the text automatically added during make menuconfig.
Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6313
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
SPI controllers in Intel and AMD bridges have a slightly different
restriction on how long transactions they can handle.
Change-Id: I3d149d4b7e7e9633482a153d5e380a86c553d871
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6163
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Whenever spi_xfer is called and whenver it's implemented, the natural unit for
the amount of data being transfered is bytes. The API expected things to be
expressed in bits, however, which led to a lot of multiplying and dividing by
eight, and checkes to make sure things were multiples of eight. All of that
can now be removed.
BUG=None
TEST=Built and booted on link, falco, peach_pit and nyan and looked for SPI
errors in the firmware log. Built for rambi.
BRANCH=None
Change-Id: I02365bdb6960a35def7be7a0cd1aa0a2cc09392f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192049
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6175
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The spi_flash_probe and and spi_setup_slave functions each took a max_hz
parameter and a spi_mode parameter which were never used.
BUG=None
TEST=Built for link, falco, rambi, nyan.
BRANCH=None
Change-Id: I3a2e0a9ab530bcc0f722f81f00e8c7bd1f6d2a22
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192046
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6174
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This existed for ChromeOS but was no longer used with DYNAMIC_CBMEM.
Change-Id: I558a7ae333e5874670206e20a147dd6598a3a5e7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6032
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
There are a couple of places where CPPFLAGS are
pasted into CFLAGS, eliminate them.
Change-Id: Ic7f568cf87a7d9c5c52e2942032a867161036bd7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5765
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Rename INCLUDES to CPPFLAGS since the latter is more
commonly used for preprocessor options.
Change-Id: I522bb01c44856d0eccf221fa43d2d644bdf01d69
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5764
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Though the limited documentation indicates the default is
0 for the gfx_turbo_disable bit, in practice that isn't
true. Knock down the gfs_turbo_disable bit to enable
graphics turbo mode.
BUG=chrome-os-partner:25044
BRANCH=baytrail
TEST=Built and booted. Added debug code to output SB_BIOS_CONFIG.
Noted that bit 7 was set to 0.
Change-Id: I11210c6a0b29765cb709a54d6ebd94211538807b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182640
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5050
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
On baytrail, it appears that the turbo disable setting is
actually building-block scoped. One can see this on quad
core parts where if enable_turbo() is called only on the
BSP then only cpus 0 and 1 have turbo enabled. Fix this
by calling enable_turbo() on all non-bsp cpus.
BUG=chrome-os-partner:25014
BRANCH=baytrail
TEST=Built and booted rambi. All cpus have bit 38 set to 0
in msr 0x1a0.
Change-Id: Id493e070c4a70bb236cdbd540d2321731a99aec2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182406
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5048
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This will allow USB devices to wake the system (if 5V is not turned off)
and the controller to enter D3 at runtime. (if autosuspend is enabled)
BUG=chrome-os-partner:23629
BRANCH=baytrail
TEST=build and boot on baytrail
1) with modified EC to leave 5V on in S3 ensure that waking from suspend
with USB keyboard works.
2) with laptop-mode-tools usb autosuepend config updated see that device
enters D3 at runtime when no external devices attached.
Change-Id: Ia396d42494e30105f06eb3bd65b4ba8b1372cf35
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182536
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5046
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The current byte value was being converted to an int
when checking against literal 0xff. As the type of
the current pointer was char (signed) it was sign
extending the value leading to 0xffffffff != 0xff.
Fix this by using an unsigned type and using a
constant type for expected erase value.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmwareupdate. Noted that MRC
cache doesn't think the erased region isn't erased.
Change-Id: If95425fe26da050acb25f52bea060e288ad3633c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182154
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5044
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
On a firmware update the MRC cache is destroyed. On the
subsequent boot the MRC region was attempted to be erased
even if it was already erased. This led to spi part taking
longer than it should have for an unnecessary erase
operation. Therefore, check that the region is erased
before issuing the erease command.
BUG=chrome-os-partner:24916
BRANCH=baytrail
TEST=Booted after chromeos-firmeareupdate. Noted no
error messages in this path.
Change-Id: I6fadeb6bc5fc178abb0a7e3f0898855e481add2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5043
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This improves boot time in 2 ways for a firmware upgrade:
1. Normally MRC would detect the S0 state without an MRC cache
even though it's told to the S5 path. When it observes this
state a cold reset occurs. The cold reset stays in S5 for
at least 4 seconds which is time observed by the end user.
2. As the EC was running RW code before the reset after firmware
upgrade it will still be running the older RW code. Vboot will
then reboot the EC and the whole system to put the EC into RO
mode so it can handle the RW update.
The issues are mitigated by detecting the system is in S0 with
no MRC cache and the EC isn't in RO mode. Therefore we can do the
reboot without waiting the 4 secs and the EC is running RO so
the 2nd reboot is not necessary.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Booted. Updated firmware while in OS. Rebooted. Noted the
EC reboot before MRC execution.
Change-Id: I1c53d334a5e18c237a74ffbe96f263a7540cd8fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182061
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5040
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Added a method in each temp sensor to disable the aux trip points
and then a wrapper function to call this method for each enabled
temperature sensor.
The event handler function is changed to not use a switch statement
so it does not need to be serialized. This was causing issues
with nested locking between the global lock and the EC PATM mutex.
Some unused code in temp sensors that was added earlier is removed
and instead a critical threshold is specified in _CRT.
The top level DPTF device _OSC method is expanded to check for the
passive policy UUID and initialize thermal devices. This is done
for both enable and disable steps to ensure that the EC thermal
thresholds are reset in both cases.
Additionally the priority based _TRT is specified with TRTR=1.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and start
esif_uf application. Observe that temperature thresholds are set
properly when running 'appstart Dptf' and that they are disabled
after running 'appstop Dptf'
Change-Id: Ia15824ca42164dadae2011d4e364b70905e36f85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182024
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5037
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
- Remove some unused functions from CPU participant that were
confusing the userland component since the CPU does not have
an ACPI managed sensor.
- Guard the charger participant with an ifdef so it can be
left out if not supported.
- Use the EC methods for setting auxiliary trip points and for
handling the event when those trip points are crossed.
- Add _NTT _DTI _SCP methods for thermal sensors. I'm not
clear if these are required or not but they seem to be expected
by the other DPTF framework components.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi and load ESIF framework
Change-Id: I3c9d92d5c52e5a7ec890a377e65ebf118cdd7087
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181662
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5028
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The SMI on TCO timer timeout policy was copied from other
chipsets. However, it's not very advantageous to have
the TCO timer timeout trigger an SMI unless the firmware
was the one responsible for setting up the timer.
BUG=chromium:321832
BRANCH=rambi,squawks
TEST=Manually enabled TCO timer. TCO fires and logged in
eventlog.
Change-Id: I420b14d6aa778335a925784a64160fa885cba20f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181985
Reviewed-on: http://review.coreboot.org/5035
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The PMC in baytrail maintains an additional set
wake status in memory-mapped registers. If these
bits aren't cleared the device won't be able to
go to S5 or S3 without being immediately woken up.
Therefore clear these registers.
BUG=chrome-os-partner:24913
BRANCH=rambi,squawks
TEST=Ensured PRSTS bit 4 is cleared after a reboot and S3 and S5 work
correctly.
Change-Id: I356e00ece851961135b4760cebcdd34e8b9da027
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181984
Reviewed-on: http://review.coreboot.org/5034
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
When CONFIG_ELOG is selected the reset, power, and wake
events are logged in the eventlog.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Various resets and wake sources. Interrogated eventlog
to ensure results are expected.
Change-Id: Ia68548562917be6c2a0d8d405a5b519102b8c563
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181983
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5033
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The memory reference code doesn't maintain some of
the registers which contain valuable information in order
to log correct reset and wake events in the eventlog. Therefore
snapshot the registers which matter in this area so that
they can be consumed by ramstage.
BUG=chrome-os-partner:24907
BRANCH=rambi,squawks
TEST=Did various resets/wakes with logging patch which
consumes this structure. Eventlog can pick up reset
events and power failures.
Change-Id: Id8d2d782dd4e1133113f5308c4ccfe79bc6d3e03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181982
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5032
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The BISOC.EXIT_SELF_REFRESH_LATENCY field should
not be updated from the default.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: I6e701a520513372318258648e998dd8c7ab29ea4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180730
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/5025
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Make sure reg_script is executed before the device is put into
ACPI mode.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi from eMMC in ACPI mode
Change-Id: I4090babbfc7fb0f3be4da869386e998d87a513ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179896
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5017
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Since this file will get added to payloads it is useful if it
exports what offset in NVS it lives.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: I52860980c91dfe2525628e142b34ca192e69b258
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179848
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5014
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
In order to use the same reference code on S3 resume
that was booted the program needs to be cached. Piggy
back on the ramstage cache to save the loaded reference
code program.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed. Noted locations of reference
code caching and load addresses in console.
Change-Id: I90ceaf5697e8c269c3244370519d4d8a8ee2eb4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179777
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5013
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Certain code paths want to know if S3 resume is
happening. However, the current baytrail code doesn't
note S3 resume early enough. Therefore, mark S3
resume just after pattr setup.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=Built and booted. S3 resumed.
Change-Id: I5e5cc285940e4567521afb8483614ce6f813ddde
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179774
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5010
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The inclusion of reg_script_run_on_dev() allows
for removing some of the chained reg_scripts just
to set up the device context. Use the new reg_script
function in those cases.
BUG=None
BRANCH=None
TEST=Built and booted. Didn't see any bizarre dmesg or coreboot
console output.
Change-Id: I3207449424c1efe92186125004d5aea1bb5ba438
Signed-off-by: Aaron Durbin <adurbin@chromium.og>
Reviewed-on: https://chromium-review.googlesource.com/179541
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5009
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
According to the reference code all these registers
need to be set to their best known values.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. Suspend and wake. No idea about
observable impact yet.
Change-Id: I0e31505a165eee1d177e5d726edcfa6947430476
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179749
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5008
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
There's a slew of ports required to initialize baytrail's
perf and power values. Therefore, add the necessary
functionality in the iosf module as well as the reg_script
library.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted.
Change-Id: Id45def82f9b173abeba0e67e4055f21853e62772
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5007
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The iosf access functions already use some common code,
however there is a duplication for setting up the proper
control register for port and opcode. Introduce macros
to remove this verbosity.
BUG=chrome-os-partner:24345
BRANCH=None
TEST=Built and booted. Suspend and wake.
Change-Id: I5bad7e2a11fa8e8bd4a3d7fa53d917b2565644f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179747
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5006
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This adds the option to put LPSS and SCC devices into ACPI mode
by saving their BAR0 and BAR1 base addresses in a new device
NVS structure that is placed at offset 0x1000 within the global
NVS table.
The Chrome NVS strcture is padded out to 0xf00 bytes so there
is a clean offset to work with as it will need to be used by
depthcharge to know what addresses devices live at.
A few ACPI Mode IRQs are fixed up, DMA1 and DMA2 are swapped and
the EMMC 4.5 IRQ is changed to 44.
New ACPI code is provided to instantiate the LPSS and SCC devices
with the magic HID values from Intel so the kernel drivers can
locate and use them.
The default is still for devices to be in PCI mode so this does
not have any real effect without it being enabled in the mainboard
devicetree.
Note: this needs the updated IASL compiler which is in the CQ now
because it uses the FixedDMA() ACPI operator.
BUG=chrome-os-partner:23505,chrome-os-partner:24380
CQ-DEPEND=CL:179459,CL:179364
BRANCH=none
TEST=manual tests on rambi device:
1) build and boot with devices still in PCI mode and ensure that
nothing is changed
2) enable lpss_acpi_mode and see I2C devices detected by the kernel
in ACPI mode. Note that by itself this breaks trackpad probing so
that will need to be implemented before it is enabled.
3) enable scc_acpi_mode and see EMMC and SDCard devices detected by
the kernel in ACPI mode. Note that this breaks depthcharge use of
the EMMC because it is not longer discoverable as a PCI device.
Change-Id: I2a007f3c4e0b06ace5172a15c696a8eaad41ed73
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179481
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5004
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is not complete yet but it compiles and doesn't cause
any issues by itself. It is tied into the EC pretty closely
so that is part of the same commit.
Once we have more of the EC support done it will need some
more work to make use of those new interfaces properly.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, dump DSDT and look over \_SB.DPTF
Change-Id: I4b27e38baae18627a275488d77944208950b98bd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179459
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5002
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
These need to be set before the kernel will work without
running the VBIOS option rom.
Also necessary is setting the PP_CONTROL register with
the EDP_FORCE_VDD bit.
BUG=chrome-os-partner:24367
BRANCH=none
TEST=boot on rambi in normal mode and see the panel come up
Change-Id: I495f818d581d08b80db11785fe28b601ec956b3b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179364
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5000
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The SD card controller can have the capabilities it supports
to be overridden. Add two optional fields to the chip structure
to allow the mainboard to override the SD card controller
capabilities.
BUG=chrome-os-partner:24423
BRANCH=None
TEST=Built and booted. Noted capabilities override console output.
Change-Id: Ibfef8f765b35eeec6da969dd05f5484f8672a7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179414
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4997
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The VDAT data was off by 2 bytes when reading it from the
kernel. The reason is that the header did not line up
correctly with actual ACPI code.
BUG=chrome-os-partner:24440
BRANCH=None
TEST=crossystem devsw_cur now returns either 0 or 1 depending
on state.
Change-Id: Ie78599f29cd5daf7da98db5e37fa276d24339f6a
Signed-off-by: Aaron durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179372
Reviewed-on: http://review.coreboot.org/4996
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The LPE audio device needs 1MiB of memory for its firmware.
It also has a requirement that the memory needs to be on a
512MiB boundary. Just take 1MiB @ 512MiB for the LPE device.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and analyzed console logs for resources. Also interrogated
registres within the kernel.
Change-Id: I4d9ad5c7b5a2f3eb627b30528d738289278b3a7b
Reviewed-on: https://chromium-review.googlesource.com/179192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4994
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The Linux kernel driver cannot handle Baytrail legacy GPIOs, so make the
default input GPIO type MMIO.
BUG=chrome-os-partner:24408
TEST=Manual on Rambi. Run "echo 169 > /sys/class/gpio/export; cat
/sys/class/gpio/gpio169/value", verify GPIO value changes based upon mic
jack status.
BRANCH=None
Change-Id: I27870ce8b7ecae9228e06e48c8759409c824c2eb
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179169
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4992
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The new IASL is complaining about the PCI memory region not
having consistent base/end/length values because they are
placeholder that are fixed up in the method before returning.
Put in some more valid placeholder values to make it happy.
BUG=chromium:311294
BRANCH=none
TEST=build and boot with IASL 20130117 on rambi
Change-Id: I0e21adcce43deb14d3c2c45787ff8c9efc357c2f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178864
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4988
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Add device tree option to determine if the LPE
audio codec has a platform clock signal connected
to it from the SoC. If a frequency is selected the
platform clock number is used to enable the
clock.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted rambi with 25MHz option. Probed pin
to audio codec. Noted 25MHz clock.
Change-Id: I67d0d034f30ae1c7ee8269c0aea43e8c92ff868c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178780
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4986
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
There are 3 banks of GPIOs that need to be described
with specific _UID and memory/interrupt values.
BUG=chrome-os-partner:24314
BRANCH=none
TEST=build and boot on rambi, check for probed driver:
gpiochip_find_base: found new base at 154
gpiochip_add: registered GPIOs 154 to 255 on device: INT33FC:00
gpiochip_find_base: found new base at 126
gpiochip_add: registered GPIOs 126 to 153 on device: INT33FC:01
gpiochip_find_base: found new base at 82
gpiochip_add: registered GPIOs 82 to 125 on device: INT33FC:02
fed0c000-fed0cfff : INT33FC:00
fed0c000-fed0cfff : INT33FC:00
fed0d000-fed0dfff : INT33FC:01
fed0d000-fed0dfff : INT33FC:01
fed0e000-fed0efff : INT33FC:02
fed0e000-fed0efff : INT33FC:02
Change-Id: I9619e2af4e1ccdf3d7b2e4ae280aadf22e278aeb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178601
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4985
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
With microcode 31E MWAIT 0x51 is now C6NS and 0x52 is now C6FS.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi, check that C1/C2/C3 are all used now
Change-Id: I8528d808f4082c85d90e2b57747d9f2e2d982b85
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178461
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4984
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
NCORE pad addresses were wildly wrong due to documentation bugs.
BUG=chrome-os-partner:24179
TEST=Manual on Rambi. Verify display isn't always on. Verify brightness
control now works in Chrome OS.
BRANCH=None.
Change-Id: I464436a58baa4957329c11231c5a866dafd97ce8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177597
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4980
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The default mode of the SPI controller has prefetching disabled.
That obviously has a performance impact. Enable both caching
and prefetching to make booting faster. This has a significant
impact on streaming data out of SPI.
BUG=chrome-os-partner:24085
BRANCH=None
TEST=Built and booted rambi. Payload loading step went from ~285ms
to ~54ms.
Change-Id: I065cf44e1de7dcefc49aa9ea9ad0204929ab26f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177220
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4976
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When a pad is configured for direct IRQ it needs to be in
non-legacy. Additionally, the signal is passed directly to
the APIC by setting the LEVEL and TPE bits in the pad config
register. The APIC can then be configured for level, edge,
and rising/falling.
BUG=chrome-os-partner:24037
BUG=chrome-os-partner:22863
BRANCH=None
TEST=Built and booted with this config. Trackpad is firing interrupts
more than it should, but it appears to be a trackpad firmware
and/or configuration issue.
Change-Id: I00042b2ddba67d6bf23f0e7468d0719196e6f865
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176793
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4975
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The TPM needs to have the TPM_Startup command sent to it
on all boot paths. The call init_chromeos() in romstage_common()
fulfills this requirement.
BUG=chrome-os-partner:24057
BRANCH=None
TEST=Built and booted. Was able to suspend to ram multiple times
in a row.
Change-Id: Id0339a9d82897249d20ff5f62d2dcb8b535310fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176803
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4974
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The PCIe subsystem was constantly waking up boards from
S3 and S5. Completely disable PCIe wake ups. It can be made
mainboard-configurable later if needed.
BUG=chrome-os-partner:24004
BRANCH=None
TEST=Both S3 and EC RW->RW update (trip through S5) don't
cause wakeups.
Change-Id: I922e2947c4b6e29277d913f06192601a2954f8fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176791
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4972
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Previously pads were being configured as both input and output
simultaneously due to the config bits being active low. Create new
defines that only enable either input or output, and use them in our
GPIO configs.
BUG=chrome-os-partner:22863
TEST=Manual on Rambi. Verify system boots and peripherals still
function.
BRANCH=None.
Change-Id: If386682a3d810864b7b9f5d2aecdb2e6cfceea86
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176725
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4971
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This commit does the common parts for all LPSS devices
that are enabled: enable snoop in IOSF and enable power
management. Additionally, the i2c devices are taken out of
reset.
BUG=chrome-os-partner:23790
BRANCH=None
TEST=Built and booted with modified kernel-next. I2C bus devices
show up and I see 0x10 on one of the buses.
Change-Id: I540caea6a8666f5684dc5cee683a6b085dfac6de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176424
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4969
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The eMMC device is initialized as version 4.5 with HS200 speeds.
BUG=chrome-os-partner:23966
BRANCH=None
TEST=Built and booted rambi to login screen off of eMMC device.
Change-Id: I686c6136005fcb2587b939ddea293f4398df9868
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176536
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4967
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The SSC (storage control cluster) houses the SD, SDIO, and eMMC
interfaces. The scc cofniguration function, baytrail_init_scc(),
is ran in the pre device stage to initialize the SCC. The eMMC
is expected to be configured for version 4.5.
BUG=chrome-os-partner:23966
BRANCH=None
TEST=Built and booted with some other eMMC changes into login screen off
of eMMC device.
Change-Id: I81cc755a790b7e43ad234a8201dae480277202c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176535
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4966
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The SCORE allows controlling the pad configuration while
the SSC handles the configuration for the storage control
cluster.
BUG=chrome-os-partner:23966
BRANCH=None
TEST=Built.
Change-Id: Ifd9f67a4e88d5bb99faec6ceeb3e263001a87c41
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176533
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4964
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Add support for DirectIRQ / dedicated IRQs. This consists of up to 16
IRQs for both SCORE and SSUS banks.
BUG=chrome-os-partner:22863
TEST=Manual on Rambi. Set some pins to GPIO_DIRQ, and then verify DIRQ
regwrites w/ GPIO_DEBUG look correct.
Change-Id: I4b0dc6e7ae86c9f554b6e78792239234f702764c
Reviewed-on: https://chromium-review.googlesource.com/176165
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4962
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
GPIOs which trigger SMIs only set the status bits in the ALT_GPIO_SMI
regier. No bits in the SMI_STS register are set. Therefore, the
ALT_GPIO_SMI register needs to be read and cleared on every SMI.
Additionally, the mainboard_gpi_smi() handler needs to be called as
well on every SMI because of this property.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted to recovery screen. Typed 'lidclose' on EC
console. SMI occurred which caused the board to be shutdown.
Change-Id: Ic204d8b928a0cb4f51f108a649f374d9f94e4f47
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176391
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4958
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
In order for gpio pins to trigger an smi/sci the GPIO_ROUT
register needs to be set accordingly. For SMI, the ALT_GPIO_SMI
register needs to be enabled for each gpio as well.
The first 8 gpios from the suspend and core well are the only gpios
that can trigger an SMI or SCI. The settings for the GPIO_ROUT
and ALT_GPIO_SMI register are not commited until the SMM settings
are enabled in the southcluster.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted. Manually triggered SCI by changing GPE0a_EN
and toggling PCH_WAKE_L on the EC console.
Change-Id: Id79b70084edc39fc047475e984494c224bd75d6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176390
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4957
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The gpe0 block's size was being misreported. Correct
the gpe0 size and use make the FADT fields be more
robust instead instead of hand calculating fields that
are the based on the same size.
This change correctly enables GPE events in the kernel.
Confirmed this by using iotools read the gpe_cnt register.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted. Confirmed EC's GPE event is enabled (but
still not working).
Change-Id: I415710f7fec2e95cecee3bf679ee673dacc27480
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176271
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4956
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
- C-state table based on static config
MWAIT values are from ref code for non-S0ix config
C6 substate 8 is ignored by the kernel as it violates the CPUID
but it is left in as the other substate may not work.
- P-state table generated with proper ratio and VID values
relies on having the package power msr set to magic value
as the power-on default is wrong
- T-state table uses static table
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: I7c997e58cb3a71d0ec413b17f0c5467bef4bf62c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175742
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4954
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The bus clock speed is needed when building ACPI P-state tables
so extract that function and have the value be saved in pattrs.
The various IACORE values are also needed, but rather than have
the ACPI code to the bit manipulation have the pattrs store an
array of the possible values for it to use directly.
BUG=chrome-os-partner:23505
BRANCH=none
TEST=build and boot on rambi
Change-Id: I5ac06ccf66e9109186dd01342dbb6ccdd334ca69
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176140
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4953
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As far as I can tell turbo enabling behaves like
it did on haswell so use the standard code.
There are also some magic values to set in some magic
MSRs related to turbo and package power so they report
correctly.
The L2 cache shrink is enabled and a threshold is set
that makes both dual and quad core happy.
C1E is disabled to match the reference code.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: Ic6d4283d480a44d85a9b96571baf83928615665c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175743
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4952
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The mainboard needs an opportunity to hang devices off of
the LPC device. Therefore, provide this opportunity for the
mainboard.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Buit and booted with keyboard. Keys work.
Change-Id: Ie2b660ad43e86d9237b0b0bb0720b069670bc537
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176133
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4949
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The IRQs used for devices that are in acpi mode are added as well
as the IRQ defitions for the dedicated GPIO IRQ routing.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built.
Change-Id: I2eed5a4584e2d908c32617c9289a2abeaa30bd44
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176120
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4947
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Baytrail has a configurable SCI irq. Add support for
properly configuring SCI irq. Note that it is currently
fixed to IRQ9, but the code supports setting it to the
other supported values. The current mainboards using
baytrail defer the madt IRQ override information to the
chipset.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted. Noted 'SCI is IRQ9' message.
Change-Id: I7b307bd58f9de944f0cb4c116107a15345499f2e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176075
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4946
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Previously the only path through memory init and coreboot was
hardcoding S5. Therefore all S3 paths would not be taken. Allow
for S3 resume to work by enabling the proper control paths in
romstage.
BUG=chrome-os-partner:22867
BRANCH=None
TEST=While in kernel 'echo mem > /sys/power/state'. Board went
into S3. Power button press resumed back into kernel.
Change-Id: I3cbae73223f0d71c74eb3d6b7c25d1b32318ab3e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175940
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4943
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The FADT for baytrail had incorrect offsets leading to
the kernel spewing a huge mess of ACPI errors. Fix these offsets
to be initialized in the chipset code.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted into kernel on rambi. Login screen comes up.
Change-Id: I89fc2a4fd800ff01cedf89b51cfb1369aceb9f03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175663
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4941
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This provides the initial support for interrupt routing
in bay trail. It includes both acpi changes and board changes
to ensure the interdependencies are met with the current ASL
code. The PIRQ routing is handled by the mainboard exporting
an irqroute.h header that describes the per device and PIRQ
PCI settings.
There are still a lot of ACPI errors in the kernel with this
change, though.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted rambi into kernel.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Id8a865a24fc8d49743c0b54efdb64aaef52fcd8e
Reviewed-on: https://chromium-review.googlesource.com/175700
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4940
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5570
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is needed to let the kernel know it can control everything
and not to disable features.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: I40ff15bb931a9be7c31509ec84489083b5af0a82
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175629
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4939
Tested-by: build bot (Jenkins)
There is a lot of NVS allocated to things that are not really
used. Most of these are removed and some are moved around.
Thermals are expected to be handled with DPTF so I've removed
that bit of code but have not yet cleaned up the thermal zone.
I left in the SIO BARs since I think we will need those still
even though they may need work still.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: Id16ee67e6b3709a303c001afd72947147f938127
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4936
Tested-by: build bot (Jenkins)
The top of low memory is also the start of the region where
PCIe resources are allocated. This needs to be passed in
ACPI but is only readable from IOSF.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: Iad95335f72dc3e35b837bedb8d52d388c861a330
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175625
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4935
Tested-by: build bot (Jenkins)
Add a length define for all the reserved MMIO regions and
use them in the ACPI code to reserve the regions there.
Add a region for the "abort page" documented in the EDS.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: I2060dca0636a2fdc0533ddd0826f94add2c272c3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175624
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4934
Tested-by: build bot (Jenkins)
- a few clock gating bits were set improperly and were preventing
the system from transitioning out of S0 state.
- the XHCC registers were not getting the top byte set properly
which includes things like DMA write request size and request
boundary crossing control. This was causing memory corruption.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=build and boot kernel from USB on rambi with XHCI driver
Change-Id: I8e8135a793dfbaa1f163766702e3a8f19bba9703
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175558
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4933
Tested-by: build bot (Jenkins)
This gives us completely transparent low-level function to transmit
data.
Change-Id: I706791ff43d80a36a7252a4da0e6f3af92520db7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5336
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Low system tables are in this region, and it is probably safer
to keep ASEG reserved.
Also keep the region used by ramoops from being used by the OS
and from being cleared by developer mode boots.
Lots more work needed to make the ACPI tables fully functional.
BUG=chrome-os-partner:23505
BRANCH=rambi
TEST=boot on rambi and see that the kernel finds RSDP and uses ACPI
Change-Id: I4f7064d3cff14a3ecf15b194a1f20c1fa9d5e134
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175554
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4932
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This adds required steps to initialize the EHCI controller
on the baytrail platform.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=build and boot from USB on rambi
Change-Id: I3a5487791e2305616036d4550e260a178c0e1c4d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175512
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4930
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This adds required steps to initialize the XHCI controller
on the baytrail platform.
Actually using XHCI is causing lots of bad behavior including
apparent memory corruption.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: Ic43e04f4b47e107ec3bb0c387a9fc72c3cae0271
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175511
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4929
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Apparently the LPE device needs a 25MHz clock. Provide
the work around to enable this clock.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built and booted. Confirmed setting being applied.
Change-Id: Ibff5563436b3025eb8b61ffee3302bd2da872b39
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175493
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4928
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The clock control unit needs to be accessed to configure
some of the devices properly. Therefore. provide a way
to access the CCU.
BUG=chrome-os-partner:23791
BRANCH=None
TEST=Built.
Change-Id: I30ed06e6aef81ee99c6d7ab3cbe8f83818b8dee5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175492
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4927
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Parts of the audio path are common between the HDA and LPE.
However, those parts are power-controlled by the D-state of
the HDA device. Therefore, one cannot put the HDA into D3Hot
because those audio paths will be shutdown.
BUG=chrome-os-partner:22871
BRANCH=None
TEST=Built and booted through depthcharge. Disabling HDA still
causes a shutdown when performing warm reset, however I
was able to verify the magic sequence was being performed.
Change-Id: I3b01356d85a4b7b902bd896b8eb9e7bc509fcc42
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175491
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4926
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Previously it was not known how to put the TXE pci device
into D3Hot. It's been disseminated that this is not a requirement
for disabling the TXE pci device in the function disable register.
Therefore, allow this by returning 0 from place_device_in_d3hot().
BUG=chrome-os-partner:22871
BRANCH=None
TEST=Temporarily set TXE to be disabled. Noted FUNC_DIS was being
set accordingly.
Change-Id: Ibf537bf8ba718859591dc89bdf41e57c1ea9d836
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175490
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4925
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The same sequence is used regardless of the port
being read or written. Therefore, use the same
implementation for reading or writing to a port.
BUG=None
BRANCH=None
TEST=Built and booted through depthcharge. Dev and recovery
screens still work. Nothing bizarre in console output.
Change-Id: I1a64b54b50472fa7d601e199653eb4a76accf910
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175441
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4922
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The low power subsystem devices have a lot of their
configuration done in the IOSF sideband message space.
Add support for these access methods.
BUG=chrome-os-partner:23790
BRANCH=None
TEST=Built and booted through depthcharge.
Change-Id: I0dd52b952a16ef1280c29301164db041ee87f636
Signed-off-by: Aaron Durbin <adurbin@chromum.org>
Reviewed-on: https://chromium-review.googlesource.com/175440
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4921
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The elog boot counter in cmos was not being initialized
nor incremented. Start doing that in romstage. Since S3
resume is not detected yet the increment is unconditional.
BUG=None
BRANCH=None
TEST=Built and booted through depthcharge multiple times. Noted
output such as 'Boot Count incremented to 4'.
Change-Id: Ic585d4ad4b3af086e0067e28fe0f35c02979bbd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174717
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4919
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The ACPI code was previously complaining about not being able
to find the GNVS area: 'ACPI: Could not find CBMEM GNVS'. Fix
this by adding GNVS area early in start up. This is also the
appropriate place to set the acpi_slp_type variable to indicate
an S3 resume or not.
BUG=chrome-os-partner:22867
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted through depthcharge. Noted cbmem has 'ACPI GNVS'
entry.
Change-Id: Ifbca3dd390ebe573730ee204ca4c2f19626dd6b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174647
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4918
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The callers of the following functions assume the storage
area provided by the pointers is initialized. That's not the
case as these were just place holders.
- void acpi_create_intel_hpet(acpi_hpet_t * hpet);
- void acpi_create_serialio_ssdt(acpi_header_t *ssdt);
To fix this properly initialize the hpet entry, and just remove
the serialio_ssdt function entirely.
BUG=chrome-os-partner:23505
BRANCH=None
TEST=Built and booted through depthcharge on rambi. Noted no more
ACPI errors relating to invalid length.
Change-Id: If56ab033562ef2d755e9c9de42f507c95d291aba
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174716
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4917
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The EC LPC init function needs to run to enable the internal keyboard.
I needed this to confirm that it is just USB keyboards that are causing
all sorts of issues.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=boot to recovery screen and hit tab
Change-Id: Iea0fc66ba62ea7da71ef83c26e25ae32bef102bd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175207
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4915
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Add SATA driver for baytrail platform.
BUG=chrome-os-partner:23643
TEST=Manual, in dev mode. Verify on rambi that SATA disk is detected, and
kernel is found + booted.
Change-Id: I5c13e03203c8f26d233c7d10af8ff6812c460578
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174914
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4913
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
When the southcluster pci devices are listed in the devicetree add
the ability to perform the proper disabling sequence for turning
off devices. This only turns off the pci device interface as well
as put the device into D3Hot. It is not yet known how to put the TXE
device into D3Hot so it's currently not possible to disable that
device.
Also, expose the southcluster_enable_dev() function so that other
devices can call this if they require doing specific things before
disabling the device. The southcluster_enable_dev() is only called
on devices found in the devicetree and if they currently have no
ops associated with them.
BUG=chrome-os-partner:22871
BRANCH=None
TEST=Built and booted through depthcharge. Interrogated
output to ensure devices were being properly disabled.
Change-Id: I537ddcb9379907af2fe012948542b6150a8bf7c5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174644
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4911
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
While most registers accesses don't need the use of the MCRX
register (upper 24 bits of address) the MCRX register should
be protected. The reference code could be doing accesses to
registers that initialized the MCRX register. Thus, any access
after that should ensure the MCRX register is initialized
appropriately.
BUG=None
BRANCH=None
TEST=Verified assembly output. Also, built and booted through
depthcharge.
Change-Id: I4d6cfbe6bb1666790c69778b8f2c8baeaf015264
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174643
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4909
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
With the recent improvement 3d6ffe76f8,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
- Ungate display in PUNIT
- Set GSM to 64MB since 32MB is not supported in <C0 stepping
- Initialize power management registers in GTT
- Execute VBIOS if found
BUG=chrome-os-partner:23507
BRANCH=rambi
TEST=build and boot to dev screen via HDMI on rambi
Change-Id: Idb032c7ea7f16b651b4c921e3429a652fe663a5d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174922
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4907
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The data needs to be available in the register before the control
bits are set to make the write happen.
BUG=chrome-os-partner:23507
BRANCH=rambi
TEST=successfully ungate power on PUNIT on rambi
Change-Id: I8fae60d5385ce9a401c1dec9cbb39b70d157a6c2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174898
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4906
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC needs to be initialized early in romstage. Therefore
perform the call after console has been initialized in order to
view any messages that the code may spit out.
BUG=chrome-os-partner:23387
BRANCH=None
TEST=Built and booted with recovery mode and EC in RW. Noted that
system reboots the EC.
Change-Id: I35aa3ea4aa3dbd9bd806b6498e227f45ceebd7a1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174713
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4904
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Version 2 of the efi wrapper wants the speed of the TSC
timer initialized in the parameter structure.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted through depthcharge. No errors spit out by
wrapper.
CQ-DEPEND=CL:*147256
Change-Id: I9cd265ea6bde93be85fc6fbc905d83af57fc2773
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174712
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4903
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Before the special PUNIT settings the GFX pci device
had the same device id as the transaction router. This
required a special case in the transaction router's
driver to do the proper thing for read_resources().
However, that requirement is no longer needed as the
PUNIT special message is now being done. Therefore,
remove the work around.
BUG=None
BRANCH=None
TEST=Built and looked at resource allocation logs to confirm
work around is no longer needed.
Change-Id: I90b155cb5560ca3291f146c2f586456e5529f6b2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174652
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4902
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A global microcode_ptr was added when doing the MP
development work. However, this is unnecessary as the
pattrs structure already contains the pointer. Use
that instead.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted. Microcode still being loaded correctly.
Change-Id: I0abba66fc7741699411d14bd3e1bb28cf1618028
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174552
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4901
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The reference code blob is needed to bootstrap
certain pieces of hardware in bay trail. Provide
the ability to run reference code by loading
the reference code as an rmodule.
Note that support for vboot verification and S3
resume is omitted from this commit.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Built and booted with refcode loading.
Change-Id: I30334db441a57f4d87b4de6fca0a9a48e1c05c05
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4898
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The PCU (platform controller unit) contains the
resources and IP blocks that used to reside in the
south bridge. Bay Trail has since renamed it south
cluster. There are quite a few fixed MMIO and I/O
resources. If these aren't added the resource allocator
will freely assign these addresses which causes conflicts
and other subtle bugs.
BUG=chrome-os-partner:23544
BUG=chrome-os-partner:23545
BRANCH=None
TEST=Built and booted through depthcharge. Verified
resource allocation not weird. And no more depthcharge
crashes.
Change-Id: I697fbda4538c03fded293bcb63a5823b1ed150ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174421
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4893
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Enabling the monotonic timer allows for collecting
boot stage times as well as each device initialization
time.
BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted. Noted timings in console output.
Change-Id: I5fdc703ea21710fd26de352f367c6fc0c767ab6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174422
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4894
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Initialize SMM on all CPUs by relocating the SMM region
and setting SMRR on all the cores. Additionally SMI
is enabled in the south cluster.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi. Tested with DEBUG_SMI and noted
power button turns off board while in firmware.
Change-Id: I92e3460572feeb67d4a3d4d26af5f0ecaf7d3dd5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173983
Reviewed-on: http://review.coreboot.org/4892
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Bring up the APs using x86 MP infrastructure.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi. Noted all cores are brought up.
Change-Id: I9231eff5494444e8eb17ecdc5a0af72a2e5208b5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173704
Reviewed-on: http://review.coreboot.org/4889
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Minor style changes to the way GPIO pull-ups are specified in
board-specific GPIO maps. Intent is to allow calls to GPIO_FUNC macro
from such maps.
BUG=chrome-os-partner:22863
TEST=Manual. Build + boot on bayleybay.
Change-Id: I80134b65d22d3ad8a049837dccc0985e321645da
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173748
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4886
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The original documentation was incorrect. Fix the pci
device for the MMC port to reflect reality.
MMC is at 00:17.0 with a device id of 0x0f50.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: Ic18665b7dda5f386e72d1a5255e4e57d5b631eb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172772
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4884
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Despite some references to a fixed bclk in some of the
docs the bclk is variable per sku. Therefore, perform
the calculation according to the BSEL_CR_OVERCLOCK_CONTROL
msr which provides the bclk for the cpu cores in Bay Trail.
BUG=chrome-os-partner:23166
BRANCH=None
TEST=Built and booted B3. correctly says: clocks_per_usec: 2133
Change-Id: I55da45d42e7672fdb3b821c8aed7340a6f73dd08
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172771
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4883
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are 2 methods currently available in coreboot to load
ramstage from romstage: cbfs and vboot. The vboot path had
to be explicitly enabled and code needed to be added to
each chipset to support both. Additionally, many of the paths
were duplicated between the two. An additional complication
is the presence of having a relocatable ramstage which creates
another path with duplication.
To rectify this situation provide a common API through the
use of a callback to load the ramstage. The rest of the
existing logic to handle all the various cases is put in
a common place.
Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5087
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
After running the MRC blob print out some information
on the training: MRC version, number channels, DDR3
type, and DRAM frequency.
Example output:
MRC v0.90
2 channels of DDR3 @ 1066MHz
Apparently there are two dunit IOSF ports -- 1 for each
channel. However, certain registers really on live in
channel 0. Thus, there was some changes to dunit support
in the iosf area.
BUG=chrome-os-partner:22875
BRANCH=None
TEST=Built and booted bayleybay in different configs.
Change-Id: Ib306432b55f9222b4eb3d14b2467bc0e7617e24f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172770
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4882
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
If a payload is compiled to use SSE instructions it will
fault with an undefined opcode because SSE instructions weren't
enabled. Therefore enable SSE instructions at runtime.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted with SSE enabled payload. No exceptions seen.
Change-Id: I919c1ad319c6ce8befec5b4b1fd8c6343d51ccc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172642
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4881
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add suport for verifying the ramstage with vboot
during romstage execution. Along with this support
select CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM to
cache the relocated ramstage 1MiB below the
top end of the TSEG region.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with CONFIG_VBOOT_VERIFY_FIRMWARE=y
selected.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I355f62469bdcca62b0a4468100effab0342dc8fc
Reviewed-on: https://chromium-review.googlesource.com/172712
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4880
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Pull-ups and pull-downs can be active on functional pins. Add configs
for these options so they can be specified on board GPIO maps.
TEST=Manual on bayleybay. Verify that platform boots to payload load.
BUG=chrome-os-partner:22863
Change-Id: Ie4f77d8ce812f086cc8fe5a6bfcac59669f56f92
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172766
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5209
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Bay Trail has the following types of resets it supports:
- Soft reset (INIT# to cpu) - write 0x1 to I/O 0x92
- Soft reset (INIT# to cpu)- write 0x4 to I/0 0xcf9
- Cold reset (S0->S5->S0) - write 0xe to I/0 0xcf9
- Warm reset (PMC_PLTRST# assertion) - write 0x6 to I/O 0xcf9
- Global reset (S0->S5->S0 with TXE reset) - write 0x6 or 0xe to
0xcf9 but with ETR[20] set.
While these are documented this support currently provides support
for 2nd soft reset as well as cold and warm reset.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted.
Change-Id: I9746e7c8aed0ffc29e7afa137798e38c5da9c888
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172710
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4878
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's helpful to have a lot of the early init happen
before the handoff to mainboard. One example of this
need is having the BARs programmed so that the mainboard
can read board-specific gpios.
BUG=chrome-os-partner:22865
BRANCH=None
TEST=Built. Booted and saw console outout in bayleybay
mainboard.
Signed-off-by; Aaron Durbin <adurbin@chromium.org>
Change-Id: I030d7b4f9061ad7501049e8e204ea12255061fbe
Reviewed-on: https://chromium-review.googlesource.com/172290
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4871
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
- Add functions to peek at GPIO input pad values (need to be used from
romstage for board ram_id GPIOs)
- Modify UART GPIOs to use existing fn-assignment function
TEST=Manual. Add debug print and verify that GPIO functions return input
values. Also, verify UART still functions in romstage.
BUG=chrome-os-partner:22865
Change-Id: Ib2e57631c127a592cfa20ab6e2184822424e9d77
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172189
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4870
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Set the BSP to operate at max frequency early in romstage.
The call to punit_init() is when the frequency actually ramps as
that makes the punit actually start working.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted. Noted operating frequency status is max.
Change-Id: Icfd9e5c7682aa21fc740bd687607ca6a66597d5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172131
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4869
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The caching policy for romstage was previously using a 32KiB
of cache-as-ram for both the MRC wrapper and the romstage stack/data.
It also used a 32KiB code cache region. The BWG's limitations for
the code and data region before memory is up was wrong. It consists
of a 16-way set associative 1MiB cache. As long as enough addresses
are not read there isn't a risk of evicting the data/stack.
Now create a 64KiB cache-as-ram region split evenly between romstage
and the MRC wrapper. Additionally cache the memory just below
4GiB in CBFS size. This will cover any code and read-only data needed.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted quickly with corresponding changes to MRC warpper.
CQ-DEPEND=CL:*146175
Change-Id: I021cecb886a9c0622005edc389136d22905d4520
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172150
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4868
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Like the bunit and dunit, add the punit accessor functions.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built.
Change-Id: Ifd7184dfca8c0491c107bc1c562ea1ded444e372
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171931
Reviewed-on: http://review.coreboot.org/4867
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- Set config0 defaults for hysteresis disable, pad bypass, etc.
- Set config1 power-on defaults.
- Set pad_val for input as default.
BUG=chrome-os-partner:22863
TEST=Manual. Enable GPIO_DEBUG and verify pad registers are set
according to expectation. Also verify bayleybay still boots to payload
loading.
Change-Id: I0f1c9e4d4f39c5c56d7e14a82eb4825612e19420
Reviewed-on: https://chromium-review.googlesource.com/171903
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4866
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The punit is responsible for a number of things. Without
performing the sequence included it won't change processor
frequency when requested and apparently there are some bizarre
hangs introduced if this sequence isn't included either. Lastly,
this needs to come after microcode has been loaded. As that is
done in bootblock the ordering is correct.
One other side effect is that this fixes the graphics devices'
device id. Before it was showing up as the same device id of the
SoC transaction router.
BUG=chrome-os-partner:22880
BUG=chrome-os-partner:23085
BUG=chrome-os-partner:22876
BRANCH=None
TEST=Built and booted.
Change-Id: Ib7be1d4b365e9a45647c778ee5f91de497c55bf1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171862
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4864
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Start loading microcode in the bootblock. This way
no caching has been set up and cache-as-ram mode
will be running in a validated configruation (with ucode
patch).
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted. Confirmed microcode is loaded.
Change-Id: I6fd1d8e55bcc9d799b11d9faed771ac50dc120a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171861
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4863
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The TCO timer always starts ticking out of reset.
However, depending on microcode loading and punit
initialization the TCO timing out has a different
impact on the sytem. Without loading microcode
or initializing the punit the tco times out and
nothing happens. However, when microcode is loaded
a timeout will reset the system. Lastly, if the
punit is initialized but the microcode isn't loaded
the TCO timeout will shut down the system.
To fix all the weird symptoms disable the TCO.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and booted with microcode loading. Reset doesn't
occur.
Change-Id: I49cd62f510726a96bf734ae728a352c671d1561e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171860
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4862
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Apparently there was another BAR living at 0x5c in the LPC
bridge that mapped the PUNIT registers. EDS 2.0 released
and this register is now documented.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and booted.
Change-Id: I5892c2a14923b57826060e92b4335cb1952ea057
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171612
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4861
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The 316 microcode is the newest version. Include that in the build.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built and partially booted with microcode loading. Noted 316
loaded.
Change-Id: Iba01dd58688737ae38bc58a84014ee9526540db1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171611
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4860
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow for one to write an individual byte of a 32-bit register
when sending a read/write through the IOSF messaging system.
Add PUNIT registers and fields for early sequencing.
BUG=chrome-os-partner:23085
BRANCH=None
TEST=Built and partially booted with changes that use PUNIT
registers and individual byte en fields.
Change-Id: I929fb5c51d805c55c478cab884e3572254987fc7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171710
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4859
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The mrc_wrapper.h was changed to protect against ABI differences
between the two sets of compilers and flags used. This requires
a prope shim for the console output funciton.
BUG=chrome-os-partner:23048
BRANCH=None
TEST=Built and booted successfully.
Change-Id: I976e692e66dcfc0eacadae6173abfd9b81e31137
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171580
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4858
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This commit always selects COLLECT_TIMESTAMPS and starts
tracking TSC values from the early stages of bootblock.
The initial timestamp value is saved in mm0 and mm1 while
in bootlbock. This approach works because romcc is not configured
to use mmx registers for its compilation.
Additionally, the romstage api with the mainboard was changed to
always pass around a pointer to a romstage_params structure as the
timestamps are saved in there until ram is up.
BUG=chrome-os-partner:22873
BRANCH=None
TEST=Built and booted with added code to print out timestamps at
end of ramstage. Everything looks legit.
Change-Id: Iba8d5fff1654afa6471088c46a357474ba533236
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170950
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4856
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
During ramstage, call mainboard_get_gpios to get initial GPIO configuration
from the mainboard code, then initialize GPIOs as requested.
BUG=chrome-os-partner:22863
TEST=Manual. Using bayleybay GPIO table, set UART GPIOs to 'function 1',
and verify UART still works after GPIO configuration. Also, verify
legacy GPIO config is functional by toggling test pin.
Change-Id: Ic58d8ddd15c4dc48a751a83f6d26c7809c1efc42
Reviewed-on: https://chromium-review.googlesource.com/170306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4855
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This completes the improvements to the ELF file parsing code. We can
now parse section headers too, across all 4 combinations of word size
and endianness. I had hoped to completely remove the use of htonl
until I found it in cbfs_image.c. That's a battle for another day.
There's now a handy macro to create magic numbers in host byte order.
I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe
we can use it for the others too, but this is sensitive code and
I'd rather change one thing at a time.
To maximize the ease of use for users, elf parsing is accomplished with
just one function:
int
elf_headers(const struct buffer *pinput,
Elf64_Ehdr *ehdr,
Elf64_Phdr **pphdr,
Elf64_Shdr **pshdr)
which requires the ehdr and pphdr pointers to be non-NULL, but allows
the pshdr to be NULL. If pshdr is NULL, the code will not try to read
in section headers.
To satisfy our powerful scripts, I had to remove the ^M from an unrelated
microcode file.
BUG=None
TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same. This was also fully tested across all chromebooks for building and booting and running chromeos.
BRANCH=None
Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181272
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5098
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The pattrs structure is intended for the supporting coreboot
code to reference instead of going back to the source of
the values (msrs, cpuid, etc). It essentially serves as a global
structure for collecting attributes about the platform/processor.
Additionally, the implementation provides a point during boot to
hoook work before device enumeration/initialization by providing
a init() function to soc_intel_baytrail_ops that is called before
device work in the boot state machine.
BUG=chrome-os-partner:22862
BUG=chrome-os-partner:22863
BRANCH=None
TEST=Built and booted. Noted pattrs output.
Change-Id: I073da8aca29635146fb0d4a2625b2b7564fd8414
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170403
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4854
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The dunit on baytrail is the dram unit. Provide a means
to access the configuration registers there using the
proper IOSF mechanisms.
BUG=chrome-os-partner:22875
BRANCH=none
TEST=Built and booted. Able to read dram registers.
Change-Id: I4d5c019720a7883fe93f3e1860bcd57ce2ea6542
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170490
Reviewed-on: http://review.coreboot.org/4853
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Prior to this commit the coreboot resource allocator
was not using proper addresses. That's not surprising there
wasn't any code to initialize the resources properly. This
commit initializes the memory map accoring to the BUNIT
registers.
BUG=chrome-os-partner:22860
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted. Noted output for resource assignments
is sane.
Change-Id: Ice8d067d8b993736de5c5b273a0f642fa034a024
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170429
Reviewed-on: http://review.coreboot.org/4852
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The coreboot device modeling for pci devices wants
a pci_operations structure for all devices. This structure
just sets the subsystem vendor and device id. Add a common
one that all the other pci drivers can use for Bay Trail.
BUG=chrome-os-partner:22860
BRANCH=None
TEST=Built and booted while utilizing this new structure.
Change-Id: I39949cbdb83b3acb93fe4034eb4278d45369e321
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170428
Reviewed-on: http://review.coreboot.org/4851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The graphics device needs to have its resource contraints
initialized before running the reference code. Right now just
use a 256MiB aperture, 32MiB of stolen memory data, and 2MiB
GTT memory.
BUG=chrome-os-partner:22869
BRANCH=None
TEST=Built and booted. Noted amount of stolen memory matches
configuration as well as BAR size within the graphics
device.
Change-Id: I328bf858f288363187cf705d6340947393b5ff10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170427
Reviewed-on: http://review.coreboot.org/4850
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Take advantage of the cache early in bootblock. The
intent is to speed up cbfs walking when trying to locate
romstage.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted.
Change-Id: If03210103c9782390230915db3b4a9759d172dce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial Bay Trail code is intended to support
the mobile and desktop version of Bay Trail. This support
can train memory and execute through ramstage. However,
the resource allocation is not curently handled correctly.
The MRC cache parameters are successfully saved and reused
after the initial cold boot.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted on a reference board through ramstage.
Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4847
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
