GP0e does not fit into the naming scheme of the field units surrounding
this field unit definition. Also the keys for e and 3 are close to each
other supporting the theory that this is indeed a typo.
Change-Id: I43cf288fe1e0240b33971073c1aa8a1db5762e31
Reported-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5483
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The SerialIO DwordIo() definition is fixed up before returning
it in the serialio device _CRS method, so the values that are set
in the raw ASL are not actually used.
However modern versions of IASL do not like that the RangeLength is
set to zero and will fail to compile. Set this value to 1 to make
IASL stop complaining, but the real value is still fixed up in _CRS
so this has no real effect on the end result.
Change-Id: Iceb888e54dd4d627c12d078915108a11f45b1a2d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Without this memory decoding isn't activated which, in turn,
makes SeaBIOS crash.
Change-Id: I3dcc721b500ab7468e1082157eeeed38044462d0
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5326
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
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>
Properly determine temperature target and set it in early
init rather than hardcoding it in late init.
Change-Id: Ie763f205890674a9dd1d9c5974caaccdd67cea14
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5264
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Chrome OS environment sends an SMI to finalize the chipset/board
at the end of the "depthcharge" payload, but there is no facility to
send this command if not using the full ChromeOS firmware stack.
This commit adds a callback before booting the payload that will
issue this SMI which will lock down the chipset and route USB devices
to the XHCI controller.
Change-Id: I2db9c44d61ebf8fa28a8a2b260a63d4aa4d75842
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5181
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This sequence was derived from BD82X6X and on ibexpeak it inadvertently
disables interrupts. In older kernels it wasn't a problem but in new kernel
it makes codec probe fail.
Change-Id: I40184ae8c4cfe758869af1a1565b88f0a238150e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5074
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Remove the bit of code that was putting the SerialIO devices into
D3Hot state when they are switched from PCI to ACPI mode. Instead,
add the appropriate ACPI Methods to allow the kernel to control the
power state of the device.
The problem seems to be that if the device is put in D3Hot state
before it is switched from PCI to ACPI mode then it does not properly
export its PCI configuration space and cannot be woken back up.
Adding the ACPI Methods for _PS0/_PS3 allows the kernel to transition
the device into D0 state only when it is necessary to communicate with
the device, then put it back into D3Hot state.
Change-Id: I2384ba10bf47750d1c1a35216169ddeee26881df
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5193
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This claim is useless when done before EHCI controller reset. Code in
usbdebug_init_() already sets this properly after reset, see use of
DBGP_OWNER.
Change-Id: Ic17493fe4edbbbed6ebcbef35a264fbf188f1fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4709
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.
Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
When 2 chips are present to get to the second one you have to use hardware
sequencing. Also use it as the fallback if chip is unknown.
Based on code in flashrom by Stefan Tauner and Carl-Daniel Hailfinger
distributed under compatible license.
Tested on Lenovo X230 which has EN25QH64 (8M) + N25Q032..3E (4M)
Change-Id: I56f3cf0406b5f09fa327ed052c8e8b1df1d8a11f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4613
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Without it ME doesn't always start correctly and no temperature is reported,
no fan management and so on.
Change-Id: Iff71f3afbc35a1453a20d182890ae2d196c556bd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4636
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
probably a problem in MRC:
- EHCI output failure after sysagent
- no S3
- no MRC cache
- MRC needs watchdog
- less MTRR could be used by some memory map optimisations
Not tested:
- dock (probably doesn't work)
- msata (probably works)
- wwan (probably works)
- mini displayport (probably works)
Blobs:
MRC
VGA Oprom
Change-Id: I5bdb9372971f48e048848d57b6c924b79782dbde
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4679
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Ability to choose compatibility mode is interesting for testing payloads and
OS for compatibility with older systems.
As per comments
"ide_legacy_combined # TODO: Does nothing since
generations, remove from sb code?"
The "combined" mode was removed. It wasn't used by any mobo and the code for
it is almost identical to IDE one other than few bits relating to interrupt
handling and ISA mode.
Change-Id: I407a8fac753b513812a86bef5abcf39c6d81472e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Number one reason to use cbfs_get_file was to get file length.
With previous patch no more need for this.
Change-Id: I330dda914d800c991757c5967b11963276ba9e00
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4674
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
THis reduces risks of bufer overflows.
Change-Id: I77f80e76efec16ac0a0af83d76430a8126a7602d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
DRAM reset gate GPIO is different on different mobos move it to hidden config
with 60 (current value) as default.
Set it to 10 for Lenovo X201.
Change-Id: I4f3b6876d7c33d4966315091b63a76a9a0064c16
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4622
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The end of the _PS0 method that is supposed to transition the
XHCI device to D0 state is instead putting it in D3 state.
This triggers a PME_B0 GPE which causes a Notify to the XHCI
ACPI Device in the kernel and that increments the wakeup counter
and causes aborted suspends.
Instead if we just leave the device in D0 where it should be
after executing this function then the PME_B0 is not generated
and the kernel does not see a wakeup on XHCI.
Similarly I changed the _PS3 method to always put the device in
D3 at the end of the method, rather than depending on the state
to be D3 at the start.
Before this change the kernel would see the following sequence
when trying to suspend when the XHCI controller is in D3cold:
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff88017802bf28)
kernel: evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [XHCI] (Device) Value 0x02 (Device Wake) Node ffff88017802bc30
kernel: evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [EHCI] (Device) Value 0x02 (Device Wake) Node ffff88017802b8e8
kernel: evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [HDEF] (Device) Value 0x02 (Device Wake) Node ffff88017802b1b8
kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
kernel: xhci_hcd 0000:00:14.0: PME# disabled
kernel: xhci_hcd 0000:00:14.0: enabling bus mastering
kernel: xhci_hcd 0000:00:14.0: setting latency timer to 64
kernel: PM: Wakeup pending, aborting suspend
kernel: last active wakeup source: 0000:00:14.0
Now it does not get a notification (due to PME_B0) when going to D0
on the way into suspend. XHCI goes from D3cold to D0 (in order to
be able to read mmio) and then back to D3hot before suspend.
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff88017802bf28)
kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
kernel: xhci_hcd 0000:00:14.0: PME# disabled
kernel: xhci_hcd 0000:00:14.0: enabling bus mastering
kernel: xhci_hcd 0000:00:14.0: setting latency timer to 64
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._S3D] (Node ffff88017802c000)
kernel: xhci_hcd 0000:00:14.0: PME# enabled
kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS3] (Node ffff88017802bf50)
kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D3hot
Change-Id: Id5cd28eede2b27d97640047feb17349ae4ab79b7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65236
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4448
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The coreboot and ACPI code that clears USB3 PORTSC change status
bits was not properly preserving the state of the PED (port enabled
or disabled) status bit, and it could write 0 back to this field
which would disable the port.
Additionally add back the code that resets disconnected USB3 ports
on the way into suspend (as stated in the BWG) but take care to
clear the PME status bit so we don't immediately wake.
suspend/resume with USB3 devices
1) suspend with no devices, plug in while suspended, then resume
and verify that the devices are detected
2) suspend with USB3 devices inserted, then suspend and resume
and verify that the devices are detected
3) suspend with USB3 devices inserted, then remove the devices
while suspended, resume and ensure they can be detected again
when inserted after resume
Change-Id: Ic7e8d375dfe645cf0dc1f041c3a3d09d0ead1a51
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65733
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4473
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The recommended value in docs is D2, but lynxpoint XHCI does not even
support D2 state which causes the kernel to think this device cannot
be used as a wake source:
kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
kernel: ACPI: Device does not support D2
kernel: xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
Additionally this means the kernel will never put the device into D3
state by itself. There is SMI code that will put the device into D3
before suspend so advertising D3 here should be correct.
With this change the kernel will put the controller into D3 on suspend
and back to D0 on resume, including executing the ACPI methods
for _PS0/_PS3 that contain chipset specific workarounds.
In addition add a _PSC method to directly return the D state from the
device registers. With ALL USB devices removed the XHCI controller
goes into D3 state and the kernel can have a hard time determining
the state of the device at boot.
A kernel compiled with CONFIG_ACPI_DEBUG=y and module parameters
acpi.debug_layer=0x7f acpi.debug_level=0x2f can be used to see
what ACPI methods are executed:
kernel: xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS3] (Node ffff8801000a7f50)
kernel: ACPI: Preparing to enter system sleep state S3
...
kernel: ACPI: Waking up from system sleep state S3
kernel: ACPI: Execute Method [\_SB_.PCI0.XHCI._PS0] (Node ffff8801000a7f28)
kernel: xhci_hcd 0000:00:14.0: power state changed by ACPI to D0
Change-Id: Ic64040eb4dd1947a1e2f0ee253a64be683e0ec70
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
meld with s3d
Change-Id: Ic6789720c4efe661dcb03a4afce8d88115854472
Reviewed-on: https://gerrit.chromium.org/gerrit/63916
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/4409
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- Put the device into D0 and not D3 so memory bar is available
and the subsequent commands actually do something useful
- Remove set of 818Ch[7:0]=FFh (gone in ref code)
- Fix reg 0x40/0x44 mixup
Verify that expected bits are set:
localhost ~ # pci_read32 0 0x14 0 0x10
0xe0500004
localhost ~ # mmio_read32 0xe0508144
0x000003ff
localhost ~ # mmio_read32 0xe050816c
0x000f0038
Change-Id: I388398e8c7d11e538ca18dab55d8bbd9b88f17df
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63801
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4408
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This commit adds a new Kconfig option for the LynxPoint
southbridge that will have coreboot route all of the USB
ports to the XHCI controller in the finalize step (i.e.
after the bootloader) and disable the EHCI controller(s).
Additionally when doing this the XHCI USB3 ports need
to be put into an expected state on resume in order to make
the kernel state machine happy.
Part of this could also be done in depthcharge but there
are also some resume-time steps required so it makes sense
to keep it all together in coreboot.
This can theoretically save ~100mW at runtime.
Verify that the EHCI controller is not found in Linux and
that booting from USB still works.
Change-Id: I3ddfecc0ab12a4302e6034ea8d13ccd8ea2a655d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63802
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4407
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
Allow DTLE DATA / EDGE registers to be configured in board-specific
devicetree.
Change-Id: I82307d08c9cf73461db3ac7fb875a4fe70d6f9ea
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65716
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4475
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The PCIe root port has ASPM settings/workarounds that are only applied
based on the value of an undocumented bit in PCI config register 0x32C.
If that bit is not set for some reason then the settings are not applied.
This devicetree config option will force the ASPM settings for each port
based on the bit map.
Change-Id: I40b08ca9a0ef52742609bac72fb821454a373799
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65314
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4453
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The default ME output is quite verbose and not all that useful
unless you are actively debugging the ME and then you can enable
the CONFIG_DEBUG_INTEL_ME option.
This commit silences the firmware capabilities and the MBP output.
Change-Id: I2b8abcb34ae0d00d9a38d029979e84ee0d0ca287
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65252
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4452
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This message allows unused clocks to be disabled based on a
devicetree setting in each mainboard.
Change-Id: Ib1988cab3748490cf24028752562c64ccbce2054
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65250
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4450
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The original ME code was assuming that the only type of messages
it would send were MKHI type and so it had some embedded checks
for that header and that type of message.
In order to support ICC messages this needs to change to handle
different header types, so now the header will be sent first
and then the data will follow, rather than the two both being
sent in the same low-level function.
This change has no real affect on the system, subsequent commit
will add new ICC messages.
Change-Id: I52848581e49b88c0a79e8bb6bda2a179419808a3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65249
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4449
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The management engine is occasionally hanging the system on resume
when it is accessed. Since we actually don't need to do anything
with it on resume it can be disabled early in the resume path and
avoid assigning resources just to remove them later.
suspend/resume on falco and check /sys/firmware/log
to ensure that device 00:16.0 is disabled early and that no
resources are probed or assigned and that the device init path
does not execute.
Change-Id: I35573681e3a1d43d816d24954842cbe9c61f3484
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4376
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The management engine is slow, requiring at least 500ms between
when the Dram Init Done message is sent (right after memory training)
to when the MBP will report that it is successfully cleared and
that the ME can finally be sent the EOP message.
Currently this is adding 100-150ms to the boot time. If we defer
waiting for the MBP Clear indicator until the finalize step we
can gain back that lost time.
boot on falco with SMI debugging enabled to
ensure that the ME is locked down in the finalize step:
Finalizing Coreboot
SMI# #0
SMI_STS: PM1 APM
ME: MBP cleared
ME: mkhi_end_of_post
ME: END OF POST message successful (0)
Change-Id: Icab4c8c8e00eea67bed5e8154d91a1eb48a492d1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62633
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4375
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are specific programming requirements for the usb3 ports
on all LynxPoint chipsets when transitioning to D0 or D3.
LynxPoint-LP has additional workaround steps needed involving
resetting the disconnected ports when transitioning to D0.
The workarounds are implemented in ACPI code so the controller
can transition properly into D3 at runtime.
Change-Id: I3b428562f48c9cb250b97779a3b2753ed4f81509
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62632
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4374
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>
This is needed for SMBUS drivers to write to devices.
It was copied from existing intel southbridge driver.
Change-Id: Id0ce2393b2946a9c741413bca563a1a4dc0a4f5e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61893
Reviewed-on: http://review.coreboot.org/4364
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The LynxPoint-LP chipset only has one EHCI controller so we should
not attempt to write into the second one that only exists on LynxPoint-H.
Change-Id: I1eae060c7f0a5873c9684e5abfeea5cb5895ab62
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4405
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
- updates from 1.6.0 ref code
- remove the step comments as they are no longer even close
- add constants for LPT revisions
build and boot on Falco
Check that RCBA+2300[1] is set:
> mmio_read32 0xfed1e300
0x00000002
Change-Id: I8b3c5fda3f3170455699a7834239cb991603e7a8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59821
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4326
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There's a need to determine if a specific gpio pin is
is set up to be a native function or not. Implement this.
Change-Id: I91d57a549e0f4fddc0b1849e5f74320fc839642c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59589
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4324
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The BIOS spec for LynxPoint calls out additional
programming steps for the PCIe Root Ports. Implement those
steps from the BIOS spec. These steps are completed before
deeper PCIe probing. The "late" programming was removed as
that was applicable to Cougar/Panther point where this
code was originally copied, though there was some overlap.
Change-Id: I64f25e4451e035d98ca6b66b0335bd280b70b074
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59558
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4323
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
PCIe Root Ports should be disabled based on pin ownership
and the strapping configuration. Implement this logic
for LynxPoint. The chip_ops->enable_dev() path is no
longer used. Instead the PCIe driver handles the enabling
and disabling of devices. This allows for having an empty
or incomplete device tree since those "allocated" devices
do not travel through the chip_ops->enable_dev() path.
The coalescing was tested to be working properly, however
not all configurations were tested.
Change-Id: I1e8bfe5e447b72ff8a4b04b650982d8c1ae0823c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59424
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4322
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
mainboard_smi_gpi has recently been updated to take a u32 argument from a
u16, but the patch introducing the fsp_bd82x6x support has been verified
on a master before this change, thus resulting in a 'cast from incompatible
type' error. Update the pointer to the correct size argument.
Change-Id: I9d62ee43f7c8ed774898f54d29a87cf463b76e91
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4479
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Add support for the bd82x6x using the Intel FSP.
The FSP is different enough to warrant its own source files
for now. The mrc/system agent chromebook solution does much more
southbridge initialization and configuration than the FSP version.
It may be combined in the future.
Change-Id: Ie493945f3d321d854728d231979a0c172d2b36de
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/4017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Ibexpeak shares few files with bd82x6x. In order for it to work correctly
their config structures from chip.h must match, so include bd82x6x/chip.h
in ibexpeak/chip.h
Change-Id: Ib56b311b8af04f4e4803d1834724680f604901cd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4277
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
LynxPoint-LP has a lot of GPEs and the "default" set has been
moved to register 4 starting at bit offset 96. This means
that PME_B0 bit in GPE0_EN/GPE0_STS is now bit 109 in LPT-LP
but still bit 13 in LPT-H.
suspend on falco and wake from usb
4 | 2013-06-19 10:49:17 | ACPI Enter | S3
5 | 2013-06-19 10:49:22 | ACPI Wake | S3
6 | 2013-06-19 10:49:22 | Wake Source | Internal PME | 0
Change-Id: I443cd4d17796888debed70c0bda27ae09accd09b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4253
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Do not directly check the return value of get_option, but instead compare
the returned value against a CB_CMOS_ error code, or against CB_SUCCESS.
Change-Id: I2fa7761d13ebb5e9b4606076991a43f18ae370ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4266
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some of the pcie logic was located in pch.c as well
as pcie.c. Move all pcie logic to the same pcie.c
file. This is a straight cut-and-paste (no logic changes)
except for a rename from pch_pcie_enable() ->
pch_pcie_enable_dev().
Change-Id: I338c53039b95f255ab9ced313c51193a9d34b404
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59277
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4251
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The function to disable devices was formerly named
pch_hide_devfn(). This routine was doing more than hiding
devices. It was disabling them, i.e. turning them off.
Therefore, rename it to pch_disable_devfn(). Also, allow
external callers to this function.
Change-Id: Id5bb319d4e67892c02a39dff49e45b2811a2f016
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59276
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4250
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The iobp functions are useful to may of the southbridge
devices as certain values need to be updated to properly
initialize the devices. Therefore expose read, write, and
updated iobp functions.
Change-Id: Id7fdd8d0d9f022f92d6285ecd8f85a52024ec2bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4249
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There are useful values in NVS that are set at boot
and runtime and they should not be cleared on resume.
suspend/resume twice on slippy and ensure
that the USB ports are still powered on the second suspend.
Change-Id: I4bce60b02b6637f6683120ae9c4a5c64563aacf7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56941
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4210
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Previously, I've set this config in mobo config, yet according to
Kyösti Mälkki this parameter is southbridge-specific and not
mobo-specific.
Change-Id: I92428aed5a69d88a371f5d7267bc54ba7530766c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4276
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The wake device input pins are active low and the
GPIOs need to be set as inverted when they are marked
as an input so they are not spuriously logged.
suspend/resume on slippy with trackpad wake:
8 | 2013-05-29 07:43:14 | ACPI Enter | S3
9 | 2013-05-29 07:43:18 | ACPI Wake | S3
10 | 2013-05-29 07:43:18 | Wake Source | GPIO | 12
and with power button wake:
11 | 2013-05-29 07:43:35 | ACPI Enter | S3
12 | 2013-05-29 07:43:40 | EC Event | Power Button
13 | 2013-05-29 07:43:40 | ACPI Wake | S3
14 | 2013-05-29 07:43:40 | Wake Source | Power Button | 0
Change-Id: I15d38dcc9b2fb4b2b0eb27da358fa3c343e22323
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56940
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4209
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
This is an LPT-LP specific method that will enable a specific
GPIO as an ACPI SCI wake source.
It can be used by a device _DSW method to enable a pin that is
otherwise not configured to generate SCI at runtime.
It will set:
- GPIO owner to ACPI
- GPIO route to SCI
- GPIO config to GPIO, Input, Inverted
Also clean up and remove ACPI field definitions that are unused
and/or incorrect.
Change-Id: I14acc2de50e6200f61c2898a7bd1252400e0f0be
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4189
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
LynxPoint-LP has an additional 16 entries in the IOAPIC that
can be assigned to specific GPIOs when they are configured
as PIRQ.
The maximum redirection entries field in the IOAPIC needs to
be set to 0x27 when this is enabled.
Additionally specific GPIOs need to be routed to PIRQ so they
interrupt via the IOAPIC instead of the GPIO IRQ 14/15.
Change-Id: Ie587e1d203422ff6fb7fc5056d20a5ae66720991
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56620
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4203
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ssdt2 generation code was calling acpigen_patch_len().
However, none of the entries had AML object lengths that
needed patching. That resulted in the following message:
ASSERTION FAILED: file 'src/arch/x86/boot/acpigen.c', line 52
Additionally, this caused an errant write to a memory address
whose value was in the variable ltop. This was the 0 address.
Change-Id: I44abf5a4e4225220575aee6b5c9bb6b0be093a28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56299
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ACPI code was defining two EHCI controllers and ignoring
the XHCI controller. This changes the second EHCI controller
to be XHCI instead and changes the wake resource to indicate
S3 and not S4.
cat /proc/acpi/wakeup
Device S-state Status Sysfs node
HDEF S4 *disabled pci:0000:00:1b.0
EHCI S3 *enabled pci:0000:00:1d.0
XHCI S3 *enabled pci:0000:00:14.0
Change-Id: If28775e6ef8608c22c85ca91d91d1f598ec7755d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56263
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4181
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable GPIO SMI for GPIO34 and set it as inverted so it
is only generated when it is raised by the EC.
1) ec console command: lidopen
2) wait until booted to developer screen
3) ec console command: lidclose
4) ensure system turns off
Change-Id: I7d50f171f3f4539c7c264103d1ffc7c5d0f1c7ba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56052
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4177
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The vendor ids were never updated to reflect LynxPoint's device
ids. Therefore, none of the initialization was being ran. Fix
this.
Change-Id: Ic6ec00c9fb1cbcb6087fd89b0acff3d83294ac6a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55821
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4173
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to report whether coreboot enabled a SerialIO device
in ACPI mode we had been relying on reading NVS in the _STA
method for the SerialIO device.
The ACPI _STA method has restrictions on what it can access
and is unable to access OperationRegions outside its scope
which means it should not be trying to read NVS.
This change adds a new SSDT to the ACPI tables and fills it
with constants that indicate whether or not a device is enabled
in ACPI mode.
The ACPI code is changed to read these variables from the
SSDT and use that instead of trying to query a variable in NVS.
Attempt to use lpt-clk driver to probe the
device clocks for SerialIO devices and see that the kernel
does not complain about accessing the GNVS region.
Change-Id: I8538bee4390daed4ecca679496ab0cb313f174ce
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Disable EC software sync for now
- Report correct EC active firmware mode
- Force enable developer mode by default
- Set up PCH generic decode regions in romstage
- Pass the oprom_is_loaded flag into vboot handoff data
Change-Id: Ib7ab35e6897c19455cbeecba88160ae830ea7984
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4169
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to probe the gpio-lynxpoint kernel driver the
LP GPIO controller needs to be exposed as a specific
ACPI device.
This also allows the resources to be exposed to the OS via
this device instead of the catch-all LPC device.
Ensure the driver loads at boot:
gpiochip_find_base: found new base at 162
gpiochip_add: registered GPIOs 162 to 255 on device: INT33C7:00
Also ensure the driver is visible in sysfs:
$ cat /sys/devices/platform/INT33C7:00/gpio/gpiochip162/label
INT33C7:00
Change-Id: I9f79c008f88da9b67ed1cdfdb9d3a581ce8f05ff
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50215
Reviewed-on: http://review.coreboot.org/4158
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>
There were two undefined MBP types that are now defined.
These include NFC status and some interesting timing data.
ME: Wake Event to ME Reset: 6 ms
ME: ME Reset to Platform Reset: 7 ms
ME: Platform Reset to CPU Reset: 51 ms
Change-Id: I67bf1f303f3c32497041e64c40eb9ccb6a63d88a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49756
Reviewed-on: http://review.coreboot.org/4152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of having an OS re-parse cbmem book-keeping records
for the cbmem allocator just to get the console buffer export
the pointer to the memory console directly in a field named 'CBMC'.
This field lives in the GNVS table.
Change-Id: Ief0c4da7b18df66feb9c816c9f4abdf5a72bd3a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49764
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4149
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Slight tweaks found when looking at latest ref code when
investigating package C-state issues.
A few bits in the clock gating register don't match the
documentation and are also cleaned up.
Change-Id: I36ced7280c160b114c70b2eeafc8b24813ff2f6a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49330
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4142
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Part of X201 port.
Change-Id: If17d707004aba9f08459dbd8f3a146fa3c076aa9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4052
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This reads PCH power levels via PCODE mailbox and writes the
values into the PMSYNC registers as indicated in the BWG.
Change-Id: Iddcdef9b7deb6365f874f629599d1f7376c9a190
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4143
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This will be used in a later commit to do some specific
power sequencing.
Change-Id: Id7f033bb80aed915c2498ea910cb3ac7290da37f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4137
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This adds some macros for the common GPIO defines and drops
the gpio number definition from each entry. The end result
is much easier to read. The wtm2 mainboard gpio list is modified
to use this.
Also fix a bug in the LP version of get_gpio() that was always
returning zero due to a miscompare.
Change-Id: I143e5aee412af1eda84e35f8026f31cf13df508e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48946
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4138
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
With the LynxPoint chipset there are more than 16
possible GPIOs that can trigger an SMI so we need
a mainboard handler that can support this.
There are only a handful of users of this function
so just change them all to use the new prototype.
Change-Id: I3d96da0397d6584f713fcf6003054b25c1c92939
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49530
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4145
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Removing `-Wno-unused-but-set-variable` from `CFLAGS` the build for
QEMU Q35 and Roda RK9, both using the Intel 82801Ix southbridge, fail
with the following error.
src/southbridge/intel/i82801ix/lpc.c: In function 'i82801ix_enable_apic':
src/southbridge/intel/i82801ix/lpc.c:45:5: error: variable 'dummy' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
Removing `dummy` should be safe as GCC probably optimizes it away before
anyway. That no dummy variable is used for an RCBA [1] access in Intel
Lynx Point supports that this can be dropped safely.
[1] root complex base address
[2] src/southbridge/intel/lynxpoint/early_pch.c
Change-Id: I1c138a3498228dbd025f68d5e6af0acc29ed3460
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3982
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The main usbdebug file lib/usbdebug.c was removed from romstage
build with commit f8bf5a10 but the chipset-specific parts were not,
leading to unresolved symbol errors for AMD platforms.
Add a silent Kconfig variable USBDEBUG_IN_ROMSTAGE for convenient
use of this feature.
Change-Id: I0cd3fccf2612cf08497aa5c3750c89bf43ff69be
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3983
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This is needed to apply a rule that get_top_of_ram() in romstage is
required to select HAVE_ACPI_RESUME, otherwise chipset/board has no
means to backup low memory to CBMEM on s3 resume.
Only board affected is asus/p2b.
Change-Id: Ia5cbf4e5e40af25f52a19de584d8bc5370487154
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3971
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Qemu has the fw_cfg interface at 0x510, which conflicts with
power management base address in coreboot. Move the pmbase to a
non-conflicting address. No need to worry about speedstep, it
is not supported by qemu and isn't enabled in the qemu config.
Change-Id: I3e87d8301988028ca0ea7d96c08b4e26ac15a7c2
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3938
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This retrieves back the value stored with store_initial_timestamp()
in the bootblock for southbridge.
Change-Id: I377c823706c33ed65af023d20d2e4323edd31199
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3908
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I46e69154cf576ddb642c34b6dd2bc0d27cc19b7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3811
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: Ie6776b04ca0ddb89a0843c947f358db267ac4a70
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3809
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Add option to choose one of the EHCI controllers in recent
intel chipsets for usbdebug use.
Since EHCI controller function changes from 0:1d.7 to 0:1d.0 in
rcba_config() for some mainboards, check the PCI class code
for match.
Change-Id: I18a78bf875427c163c857c6f0888935c1d2a58d4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3440
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Nowadays, chipsets or boards do not only have one USB port with the
capabilities of a debug port but several ones. Some of these ports are
easier accessible than others, so making them configurable is also necessary.
This change adds infrastructure to switch between EHCI controllers,
but does not implement it for any chipset.
Change-Id: I079643870104fbc64091a54e1bfd56ad24422c9f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3438
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
On AMD platforms, setting of USBDEBUG_DEFAULT_PORT=0 tries to scan
all physical ports one after other in incrementing order. To avoid
possible problems with other USB devices, one can select the port
number here and bypass the scan.
Intel platforms can communicate with usbdebug dongle on one
physical port only, and this option makes no difference there.
Change-Id: I45be6cc3aa91b74650eda2d444c9fcad39d58897
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3872
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Declare the functions that may be used in both romstage and ramstage
with simple device model. This will later allow to define PCI access
functions for ramstage using the inlined functions from romstage.
Change-Id: I32ff622883ceee4628e6b1b01023b970e379113f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Letting SMI handler touch EHCI controller is an excellent source
of USB problems. Remove usbdebug entirely from SMM.
It may be possible to make usbdebug console work from SMM
after hard work and coordination with payloads and even
OS drivers. But we are not there.
Change-Id: Id50586758ee06e8d76e682dc6f64f756ab5b79f5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3858
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I58c4b021ac87a035ac2ec2b6b110b75e6d263ab4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3810
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I71923790aa03e51db01ae3a4745e1c44556d281f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3812
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The tests for __PRE_RAM__ or __SMM__ were repeatedly used
for detection if dev->ops in the devicetree are not available
and simple device model functions need be used.
If a source file build for ramstage had __PRE_RAM__ inserted
at the beginning, the struct device would no longer match the
allocation the object had taken. This problem is fixed by
replacing such cases with explicit __SIMPLE_DEVICE__.
Change-Id: Ib74c9b2d8753e6e37e1a23fcfaa2f3657790d4c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3555
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Directory intel/common must be conditionally added in the list
of source directories, as the parent directory southbridge/intel
is unconditionally added even for boards without such device.
Change-Id: I7088bc6db9f56909ffa996aa7eff76cd72e177eb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3827
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
These are not specific to Intel. Further work needs to be done to
combine these with MMCONF_SUPPORT in arch/io.h.
Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Without that fix, and with CONFIG_SMM_TSEG, we have:
src/southbridge/intel/i82801gx/smihandler.c: In function 'southbridge_smi_sleep':
src/southbridge/intel/i82801gx/smihandler.c:340:3: error: implicit declaration of function 'smi_release_lock' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
make: *** [build/southbridge/intel/i82801gx/smihandler.smm.o] Error 1
The fix is modelled after src/cpu/x86/smm/smihandler.c which
ifdefs smi_release_lock().
Change-Id: Icdc6d039b34a1d95d0e607419bba2484d21abc5e
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3281
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This mistake was spoted by comparison with the
src/southbridge/intel/bd82x6x/smihandler.c file.
Change-Id: I1516f0131d524bd7d001e6780e9a45402d1814d1
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add an option to mark all SPI regions write protected on each S3 resume.
We were used to lock the SPI interface in the payload which isn't run on
the resume path. So we have to do it here.
For the write protection to be effective, all write opcodes in the
opmenu have to be marked correctly (as write operations) and the whole
SPI interface has to be locked. Both is already done.
Change-Id: I5c268ae8850642f5e82f18c28c71cf1ae248dbff
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3594
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All the additional work that needs to be done in EHCI BAR relocation
is independent of the hardware platform and was functionally identical
in all the copies removed.
When USBDEBUG is not selected, PCI EHCI controllers use standard
pci_dev_read_resources() call.
With USBDEBUG selected, PCI EHCI controller's device_operations
.read_resources is replaced with pci_ehci_read_resources() call,
which in turn will replace the device_operations .set_resources call.
The replacement for .set_resources reconfigures usbdebug driver side,
and calls the original .set_resources to configure hardware side.
Change-Id: I8e136a5da4efedf60b6dd7068c0488153efaaf8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3412
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The xHCI controller's MMIO space has a length of 64KiB not 4KiB.
Therefore, setting the xHCI BAR to 0xe8001000 worked the same like
setting it to 0xe8000000, as bit12 is reserved and ignored. This again
interfered with the MMIO space of the first EHCI controller and broke
S3 resume on Ivy Bridge.
AFAIK, the MRC ignores the setting of the xHCI BAR, anyway. So just drop
these lines.
Change-Id: I8af9c2ba34133f15636a9056fc8880b3b6ab95e0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3521
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Current build configuration always wants to include an Intel Management
Engine firmware (me.bin) on Sandy Bridge 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.
Change-Id: I9a1cc29d4940ba22355eb9e653606e436f07e04c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3522
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
On newer Intel systems, the flash ROM is shared between the host
processor (BIOS), it's 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.
This patch adds 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 won't be written over (nor any other section that hasn't been
included by coreboot). A patch to write selected sections of a flash ROM
with IFD has been sent to the flashrom mailing list [1].
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html
Change-Id: Ia23e439a00a197fb54852263f8e206f16c3e8851
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3524
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
LynxPoint LP has only EHCI controller #1.
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: I95c59fb9d5f09afd152872e9bc0418dc67e4aeb2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3472
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Change EHCI #2 to different BAR from EHCI #1.
Even if the ECHI controllers are not to be addressed, it is bad idea
to set two different devices to claim the same PCI memory cycles.
Change-Id: Ib6f7cfac5acf3f8170508547d1584af90273e8c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3471
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Upgrade the ICH7 bootblock to store an initial timestamp like we do it
since Sandy Brigde. I've checked the datasheets for the used scratchpad
registers and grepped for their usage. I'm pretty sure that they aren't
used on any ICH7 based board (for anything before the usual S3-resume
indication).
Change-Id: I28a9b90d3e6f6401a8114ecd240554a5dddc0eb5
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.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>
In case with EARLY_CONSOLE, this printk is called before any other
console is configured to transmit data. This outputs garbage on
CONSOLE_SERIAL as baudrate is not yet programmed.
For case without EARLY_CONSOLE, the order in which different console
drivers initialize is obscure. Might sometimes work properly.
Change-Id: I3792161e0a6dc17e17262048cc9136044dd69dc5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3384
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Setting IRQ delivery to FSB got lost in the rebase process
for commit e6143531.
I captured following error on dmesg and this patch fixes it for
i82801dx.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 2) ...
....... failed.
...trying to set up timer as Virtual Wire IRQ...
..... works.
Change-Id: I0768976cc6b0deab213ad9bd4771e0f278de634c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3371
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Mapping is as follows: bit 15 corresponds to GPIO15 ... bit 0 corresponds to
GPIO0.
Change-Id: I661ce56d9373887270ba3c0518892fbbe6d9de7c
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/3436
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently in Intel BD82x6x southbridge’s `Makefile.inc` the
file `usb_debug.c` is added twice to the build.
This was introduced in
commit 4063ede3fb
Author: Ronald G. Minnich <rminnich@google.com>
Date: Mon Feb 4 20:31:51 2013 -0800
bd82x6x: Fix compiling with USB debug port support
Reviewed-on: http://review.coreboot.org/2784
but was unneeded because it had been already added in
the following commit.
commit 4141993536
Author: Sven Schnelle <svens@stackframe.org>
Date: Sat Jul 28 08:52:44 2012 +0200
bd82x6x: Fix CONFIG_USBDEBUG
Reviewed-on: http://review.coreboot.org/1376
Therefore basically revert that hunk.
There is no policy on how to order these additions, so leave
it to a possible separate commit, unifying this.
Kyösti Mälkki suspects that these additions were meant for
the Intel Lynx Point [1].
[1] http://review.coreboot.org/#/c/3424/
Change-Id: Iaa8de6fcc0d6f3a0a92a28fcb603d7777aa8b24c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3425
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix obvious mistake in cycle that displays GPI status
I hope i found all duplicates of it.
Change-Id: Ic21ff3ecab85953463e5c23daf808dd5edc82ff8
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/3435
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ica3afbf8277cb025251da7af181f8de0d0036b45
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3389
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove local copies of reading and writing I/O APIC registers by
using already available functions.
This change is similar to
commit db4f875a41
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Jan 31 17:24:12 2012 +0200
IOAPIC: Divide setup_ioapic() in two parts.
Reviewed-on: http://review.coreboot.org/300
and
commit e614353194
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Feb 26 17:24:41 2013 +0200
Unify setting 82801a/b/c/d IOAPIC ID
Reviewed-on: http://review.coreboot.org/2532
and uses `io_apic_read()` and `io_apic_write()` too. Define
`ACPI_EN` in the header file `pch.h`.
As commented by Aaron Durbin, a separate `pch_enable_acpi()` is
not needed: “The existing code path *in this file* is about enabling
the io apic.” [1].
[1] http://review.coreboot.org/#/c/3182/4/src/southbridge/intel/lynxpoint/lpc.c
Change-Id: I6f2559f1d134590f781bd2cb325a9560512285dc
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3182
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Remove local copies of reading and writing I/O APIC registers by
using already available functions.
This change is similar to
commit db4f875a41
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Jan 31 17:24:12 2012 +0200
IOAPIC: Divide setup_ioapic() in two parts.
Reviewed-on: http://review.coreboot.org/300
and
commit e614353194
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Feb 26 17:24:41 2013 +0200
Unify setting 82801a/b/c/d IOAPIC ID
Reviewed-on: http://review.coreboot.org/2532
and uses `io_apic_read()` and `io_apic_write()` too. Define
`ACPI_EN` in the header file `pch.h`.
As commented by Aaron Durbin, a separate `pch_enable_acpi()` is
not needed: “The existing code path *in this file* is about enabling
the io apic.” [1].
[1] http://review.coreboot.org/#/c/3182/4/src/southbridge/intel/lynxpoint/lpc.c
Change-Id: I4478b1902d09061ca1db8eab6b71fef388c7a74c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3183
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Remove local copies of reading and writing I/O APIC registers by
using already available functions.
This change is similar to
commit db4f875a41
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Jan 31 17:24:12 2012 +0200
IOAPIC: Divide setup_ioapic() in two parts.
Reviewed-on: http://review.coreboot.org/300
and
commit e614353194
Author: Kyösti Mälkki <kyosti.malkki@gmail.com>
Date: Tue Feb 26 17:24:41 2013 +0200
Unify setting 82801a/b/c/d IOAPIC ID
Reviewed-on: http://review.coreboot.org/2532
and uses `io_apic_read()` and `io_apic_write()` too.
As commented by Aaron Durbin, a separate `i82801gx_enable_acpi()` is
not needed: “The existing code path *in this file* is about enabling
the io apic.” [1].
[1] http://review.coreboot.org/#/c/3182/4/src/southbridge/intel/lynxpoint/lpc.c
Change-Id: I104a2d9c2898da14d26f8f2992d5a065ad640356
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3181
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit »haswell: Add initial support for Haswell platforms« (76c3700f)
[1] used `1 << 25` to set the I/O APIC ID of 2. Instead using
`2 << 24`, which is the same value, makes it clear, that the
I/O APIC ID is 2.
Commit »Intel Panther Point PCH: Use 2 << 24 to clarify that APIC ID
is 2« (8c937c7e) [2] is used as a template.
[1] http://review.coreboot.org/2616
[2] http://review.coreboot.org/3100
Change-Id: I28f9e90856157b4fdd9a1e781472cc4f51d25ece
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3123
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Commit »Add support for Intel Panther Point PCH« (8e073829) [1] used
`1 << 25` to set the APIC ID of 2. Using `2 << 24`, which is the same
value, instead makes it clear, that the APIC ID is 2.
[1] http://review.coreboot.org/853
Change-Id: I5044dc470120cde2d2cdfc6e9ead17ddb47b6453
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3100
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
src/southbridge/intel/lynxpoint/pmutil.c was committed with two
things that needed fixing.
Change-Id: Ib83343a75840aa29847b607b0275971eb8140f12
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3003
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The ACPI NVS region was setup in place and there was a CBMEM
table that pointed to it. In order to be able to use NVS
earlier the CBMEM region is allocated for NVS itself during
the LPC device init and the ACPI tables point to it in CBMEM.
The current cbmem region is renamed to ACPI_GNVS_PTR to
indicate that it is really a pointer to the GNVS and does
not actually contain the GNVS.
Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.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>
This bit offset is incorrect and should only be set based
on another bit in a different register.
Change-Id: I6037534236e3a4a5d15e15011ed9b5040b435eaf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2973
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The new enable_pm1() function was doing 2 things wrong:
1. It was doing a RMW of the pm1 register. This means we were
keeping around the enables from the OS during S3 resume. This
is bad in the face of the RTC alarm waking us up because it would
cause an infinite stream of SMIs.
2. The register size of PM1_EN is 16-bits. However, the previous
implementation was accessing it as a 32-bit register.
The PM1 enables should only be set to what we expect to handle in the
firmware before the OS changes to ACPI mode.
Change-Id: Ib1d3caf6c84a1670d9456ed159420c6cb64f555e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2978
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Previously southbridge_smm_init() was provided that did both
the clearing of the SMM state and enabling SMIs. This is
troublesome in how haswell machines bring up the APs. The BSP
enters SMM once to determine if parallel SMM relocation is possible.
If it is possible the BSP releases the APs to do SMM relocation.
Normally, after the APs complete the SMM relocation, the BSP would then
re-enter the relocation handler to relocate its own SMM space.
However, because SMIs were previously enabled it is possible for an SMI
event to occur before the APs are complete or have entered the
relocation handler. This is bad because the BSP will turn off parallel
SMM save state. Additionally, this is a problem because the relocation
handler is not written to handle regular SMIs which can cause an
SMI storm which effectively looks like a hung machine. Correct these
issues by turning on SMIs after all the SMM relocation has occurred.
Change-Id: Id4f07553b110b9664d51d2e670a14e6617591500
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2977
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reclaims space in ACPI NVS by removing unused fields and
adds new fields for SerialIO BARs which will be used to communicate
the allocated resources to ACPI.
Change-Id: I002bf396cf7b495bc5b7e54b741527e507aff716
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2969
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Make it more similar to i82801d LPC init.
Change-Id: I7b32747ee8012c220c8628994d749999c144b716
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/2545
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The haswell patches that verified correctly were not yet submitted,
but verified correctly. However they still used romcc_io.h which was
dropped in another patch earlier today.
With a lot of development happening in parallel, this is
unfortunately nothing that the gerrit 2.6 Rebase If Necessary submit
type could have fixed.
Change-Id: Ifef9ae05b22c408e78d6cff37defd68e4ed91ed9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2876
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch implements support for vboot firmware selection. The vboot
support is comprised of the following pieces:
1. vboot_loader.c - this file contains the entry point,
vboot_verify_firmware(), for romstage to call in order to perform
vboot selection. The loader sets up all the data for the wrapper
to use.
2. vboot_wrapper.c - this file contains the implementation calling the vboot
API. It calls VbInit() and VbSelectFirmware() with the data supplied
by the loader.
The vboot wrapper is compiled and linked as an rmodule and placed in
cbfs as 'fallback/vboot'. It's loaded into memory and relocated just
like the way ramstage would be. After being loaded the loader calls into
wrapper. When the wrapper sees that a given piece of firmware has been
selected it parses firmware component information for a predetermined
number of components.
Vboot result information is passed to downstream users by way of the
vboot_handoff structure. This structure lives in cbmem and contains
the shared data, selected firmware, VbInitParams, and parsed firwmare
components.
During ramstage there are only 2 changes:
1. Copy the shared vboot data from vboot_handoff to the chromeos acpi
table.
2. If a firmware selection was made in romstage the boot loader
component is used for the payload.
Noteable Information:
- no vboot path for S3.
- assumes that all RW firmware contains a book keeping header for the
components that comprise the signed firmware area.
- As sanity check there is a limit to the number of firmware components
contained in a signed firmware area. That's so that an errant value
doesn't cause the size calculation to erroneously read memory it
shouldn't.
- RO normal path isn't supported. It's assumed that firmware will always
load the verified RW on all boots but recovery.
- If vboot requests memory to be cleared it is assumed that the boot
loader will take care of that by looking at the out flags in
VbInitParams.
Built and booted. Noted firmware select worked on an image with
RW firmware support. Also checked that recovery mode worked as well
by choosing the RO path.
Change-Id: I45de725c44ee5b766f866692a20881c42ee11fa8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Paul Menzel