| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Ib3e09644c0ee71aacb067adaa85653d151b52078
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6840
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This is needed to successfully build fox_wtm2 from external repo.
BUG=chrome-os-partner:18638
BRANCH=none
TEST=manual: successfully compile coreboot for fox_wtm2 and
create an image with chromeos-bootimage/cros_bundle_firmware
Change-Id: Iaa4e9983faa1d86c2b29d8fd4f577be035497e38
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4132
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Current build configuration always wants to include an Intel Management Engine
(ME) firmware (`me.bin`) on Intel Lynx Point systems. However, we can have a
working coreboot without it, as long as the factory delivered ME firmware is
kept untouched in the flash ROM. So let the user decide if a ME firmware will
be included in the build by introducing the Kconfig option `HAVE_ME_BIN`.
The same was done in commit 99fd30e4 (sandybridge: Make inclusion of me.bin
optional) [1] for Intel Sandy Bridge (BD82x6x).
[1] http://review.coreboot.org/3522
Change-Id: I7c6048fd0f56288769ad90acbfb67b908ac8d824
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6047
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
On newer Intel systems, like Intel Lynx Point, the flash ROM is shared
between the host processor (BIOS), its Management Engine (ME) and an
integrated Ethernet controller (GbE). The layout of the flash ROM (and
other information) is kept in the so called Intel Firmware Descriptor
(IFD). If we only want to build coreboot to update the BIOS section,
all we need is the flash layout.
So add the option to specify the flash layout in the mainboard’s
Kconfig, and thus, to build without the real IFD. However, with such a
build, one has to make sure that the IFD section on the flash ROM will
not be written over (nor any other section that has not been included
by coreboot). A patch to write selected sections of a flash ROM with
IFD has been sent to the flashrom mailing list [2].
The same was done in commit a15cd66b [1] (sandybridge: Make build
possible without descriptor.bin) for Intel Sandy Bridge (BD82x6x).
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html
[PATCH] Add option to read ROM layout from IFD
[2] http://review.coreboot.org/3524
Change-Id: I26a604446cdf37a6bbcee2b14a107b7ccf417d5c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6046
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
SPI registers didnt change since ICH8. No need to have separate
files for them. Unify.
Change-Id: I4e2ac3221b419c007e135c9ee615fc3b84424cbc
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5254
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
With generic load using 32-bit accesses this is no longer has a
huge impact it previously did. It's also unnecessarily
component-speficific.
Change-Id: I7e8a74ea1ceaa225e1024f9eb43e7280773e2b5a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5131
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Move this to the existing USB source files so they can share some
helper functions and keep the main smihandler code cleaner.
The XHCI sleep prepare code now implements the actual sleep
preparation steps from the ref code instead of the docs.
Change-Id: Ic90adbdaba947a6b53824e548c785b4fb3990ab5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4406
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This reverts commit ff81f50f0e4c068b64c4a5c7f5244196ecd24965.
Deferring this step until the finalize stage will allow us
to defer waiting for the MBP clear indicator and speeding
up the boot.
Change-Id: Ib8edffd06689e72875830cd68b5aedb7ac3b0559
Reviewed-on: https://gerrit.chromium.org/gerrit/62631
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The SystemAgent contains a mini-hd audio controller at PCI 0:3.0
which uses the same verb table init sequence as the southbridge.
In order to avoid two copies of the verb table loading code I
separated out the HDA verb table functions into a file that can
be re-used and then added a minihd driver to the haswell northbridge.
The minihd verb table is the same across devices so it can live
within the minihd driver rather than needing to be specified in
each separate mainboard.
I also fixed up the driver for lynxpoint HDA by following the
reference code.
Without HDMI cable plugged in driver does not find any codec,
and it does not seem to re-probe when HDMI is connected. We may
be missing kernel patches for this.
hda-intel 0000:00:03.0: no codecs found!
With a basic kernel patch to add 0x0a0c device ID to HDA driver
and with HDMI cable connected it is much happier:
snd_hda_intel 0000:00:03.0: irq 60 for MSI/MSI-X
input: HDA Intel MID HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input9
snd_hda_intel 0000:00:1b.0: irq 61 for MSI/MSI-X
input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
Change-Id: Ifa587984be4fc2801704a0368b9cdf8379c2450e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4318
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
To save power, disable audio codec in S3 + S5.
Also, refactor Lynxpoint GPIO code slightly to allow usage in SMM
binary.
Change-Id: I55c4248c89a258b5e4cecf8579eb58f1c15430c0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60950
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4339
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Both EHCI and XHCI controllers have additional setup steps
that are not part of the PEI reference code so they need to
be done later.
Both controllers also have specific clock gating setup
requirements that are now implemented.
Additionally they both have specific requirements when entering
sleep states. XHCI needs something in S3/S4/S5 and EHCI only
has steps for S4/S5 entry.
Change-Id: Ic62cbc8b6255455e56b72dd5d52e27a311999330
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4217
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Now that we have RW ramstage we don't need to have the
management engine lock down step done in a final SMM.
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
PCI: 00:16.0: Disabling device
Change-Id: I9db4e72e38be58cc875c1622a966d8fcacc83280
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49757
Reviewed-on: http://review.coreboot.org/4153
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
EHCI controller enable is identical on the affected chipsets.
Change-Id: I91830b6f5144a70b158ec1ee40e9cba5fab3fbc9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3424
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
They were hard-coded to be copied from 3rdparty/ which isn't always
the right choice.
Since the defaults stay the same, this should be compatible.
Change-Id: If2173bef86ad1fcf2335e13472ea8ca41eb41f3d
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3453
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This adds configuration of SerialIO devices in the Lynxpoint-LP
chipset. This includes DMA, I2C, SPI, UART, and SDIO controllers.
There is assorted magic setup necessary for the devices and
while it is similar for each device there are subtle differences
in some register settings.
These devices must be put into "ACPI Mode" in order to take
advantage of S0ix. When in ACPI mode the allocated PCI BARs
must be passed to ACPI so it can be relayed to the OS. When
the devices are in ACPI mode BAR0+BAR1 is saved into ACPI NVS
and then updated and returned when the OS calls _CRS.
Note that is is not entirely complete yet. We need to update
the IASL compiler in our build environment to support ACPI 5.0
in order to be able to pass the FixedDMA entries to the kernel.
There are also no ACPI methods defined yet to do D0->D3->D0
transitions for actually entering/exiting S0ix states.
This is hard to test right now because our kernel does not support
any of these devices in ACPI mode. I was able to build and test
the upstream bleeding-edge branch of the linux-pm git tree. With
that tree I was able to enumerate and load the driver for the
DesignWare I2C driver and attempt to probe the I2C bus -- although
there are no devices attatched.
I am also able to see the resources from ACPI in /proc/iomem get
reserved properly in the kernel.
Change-Id: Ie311addd6a25f3b7edf3388fe68c1cd691a0a500
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2971
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There are subtle yet significant differences in some of the
registers in the power management region between LynxPoint-H
and LynxPoint-LP.
In order to reduce code that is accessing these registers and
would need special cases this adds a number of helper functions
that can be used in both ramstage and SMM.
This commit just adds the new functions, subsequent commits will
start to use them.
Change-Id: I411da75da519f5b3198a408078cbf3114e426992
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2813
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Add a helper function pch_is_lp() that will return 1 if
the current chipset is of the new "low power" variant used
with Haswell ULT.
Additionally these functions are added to SMM so it can
be used there.
Change-Id: I9acdea2c56076cd8d9627aba66cf0844c56a38fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2811
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
So it can get used in both romstage and ramstage.
Change-Id: Ief9eaafdd91df2a7b668de1a9b83aea3af3ff894
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2802
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
SPI accesses can be slow depending on the setup and the access pattern.
The current SPI hardware setup to cache and prefetch. The alternative
cbfs_load_payload() function takes advantage of the caching in the CPU
because the ROM is cached as write protected as well as the SPI's
hardware's caching/prefetching implementation. The CPU will fetch
consecutive aligned cachelines which will hit the ROM as
cacheline-aligned addresses. Once the payload is mirrored into RAM the
segment loading can take place by reading RAM instead of ROM.
With the alternative cbfs_load_payload() the boot time on a baskingridge
board saves ~100ms. This savings is observed using cbmem.py after
performing warm reboots and looking at TS_SELFBOOT_JUMP (99) entries.
This is booting with a depthcharge payload whose payload file fits
within the SMM_DEFAULT_SIZE (0x10000 bytes).
Datapoints with TS_LOAD_PAYLOAD (90) & TS_SELFBOOT_JUMP (99) cbmem entries:
Baseline Alt
-------- --------
90:3,859,310 (473) 90:3,863,647 (454)
99:3,989,578 (130,268) 99:3,888,709 (25,062)
90:3,899,450 (477) 90:3,860,926 (463)
99:4,029,459 (130,008) 99:3,890,583 (29,657)
90:3,834,600 (466) 90:3,890,564 (465)
99:3,964,535 (129,934) 99:3,920,213 (29,649)
Booted baskingridge many times and observed 100ms reduction in
TS_SELFBOOT_JUMP times (time to load payload).
Change-Id: I27b2dec59ecd469a4906b4179b39928e9201db81
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2783
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.
The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.
Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.
Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The low power variant of the chipset introduces a completely
new interface to the GPIOs.
This is a 1KB region and so needs to be moved as well so it does
not conflict with other IO regions.
Also expose the gpio_get functions to ramstage and move the
prototypes to pch.h so they can be used for both GPIO interfaces.
Change-Id: I20bc18669525af16de8cdf99f0ccfa9612be63ad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2648
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore,
the southbridge support is included as well. The basis for this code is
the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires
more attention, but this is a good starting point.
This code partially gets up through the romstage just before training
memory on a Haswell reference board.
Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2616
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
