According to the commit message for the board Cougar Canyon 2 (48a749a8)
resuming from S3 is currently unsupported.
The FSP does not support S3 at this time. S3 may be added
when it is available in the FSP.
Mirror that in the configuration by not selecting the Kconfig option
`HAVE_ACPI_RESUME`.
Change-Id: I894f103ffa7d8db6342f99fff0867b02bc750752
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4519
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
AT controller needs an ACPI node, otherwise FreeBSD doesn't detect keyboard
and mouse. Currently each SuperIO adds its own description. This one should
be used in the future instead.
Change-Id: Iaad5ed3846c6d9f467a02a286a1e6f60a3607af5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4518
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Microcode update file contains patches for various processor
revisions, it is not an error to have those.
Change-Id: Ifbca26276b66f17092afe249a2cfc229713a9fec
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4520
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
CPU_MICROCODE_IN_CBFS was designed to mean that loading microcode updates
from a CBFS file is supported, however, the name implies that microcode is
present in CBFS. This has recently caused confusion both with contributions
from Google, as well as SAGE. Rename this option to
SUPPORT_CPU_UCODE_IN_CBFS in order to make it clearer that what is meant is
"hey, the code we have for this CPU supports loading microcode updates from
CBFS", and prevent further confusion.
Change-Id: I394555f690b5ab4cac6fbd3ddbcb740ab1138339
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4482
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
Change-Id: I4588fbe320c29051566cef277bf4d20a83abf853
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56642
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4194
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4336
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>
The drivers are designed to work with an edge triggered interrupt.
Change-Id: I35a121ecfb6409bb9049f4d1e034185bb3bb7557
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61664
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4360
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The 5250 DRAM code is *really* chatty. That's not a great
idea in time critical code, and DRAM init is generally
very sensitive about such things.
Finally, for those things that are errors, print them
at an error level, not a debug level.
Change-Id: Ifa86b019dfd5f8ae6c8a1da2a35b5d0808dc3623
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60100
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4359
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When the board is in S3 and S5 the WLAN_DISABLE_L signal
can leak power into the WLAN power well since the GPIO
controlling WLAN_DISABLE_L is in the suspend well. Therefore,
drive WLAN_DISABLE_L low to avoid the power leak.
Change-Id: I1a0df80dd47fdbd535aca7a9d49253794c480606
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61421
Reviewed-on: http://review.coreboot.org/4358
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The name "LPDDR3PHY_CTRL_PHY_RESET_OFF" is not appropriate because the real
phy-reset is a low-active pin, so "off(0)" will trigger "start to reset".
To prevent confusion, we should rename the constants to "RESET_ENABLE" and
"RESET_DISABLE".
Change-Id: Iccba5ef3a2e992f877dea90741f0308c161758c9
Reviewed-on: https://gerrit.chromium.org/gerrit/61081
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/4357
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are needed to enable workarounds/features on specific
CPU types and stepping. The older northbridge function and
defines from sandybridge/ivybridge are removed.
Change-Id: I80370f53590a5caa914ec8cf0095c3177a8b5c89
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61333
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4355
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To configure source clocks on Exynos 5420 for MMC drivers.
Some registers are different from the 5250. FSYS now has two parts
and MMC uses FSYS2. The MMC block uses MPLL as the clock source.
The "high-speed" MMC interface runs as 52MHz, so divider is set
accordingly.
Also, the MMC driver has changed from MSHCI (Mobile Storage Host Controller
Interface) to DWMCI (DesignWare MMC Controller Interface).
Change-Id: I9ba9cf43e2f2dcd9da747888c0c7676bd545177b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60858
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4354
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Make use of google_chromeec_get_board_version to determine board
version, and apply proper RAM_ID table to load correct SPD.
Change-Id: I6a2d54759cf2ce98bf53df0db396c6e09368c714
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61192
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: http://review.coreboot.org/4353
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Update peppy's verb tables for the Realtek ALC283 Audio Codec.
ALC283 Configuration:
Digital Mic - NID 12h: Disabled
Speakers - NID 14h: Enabled
Mono out - NID 17h: Disabled
Mic 1 - NID 18h: Disabled
Mic 2 - NID 19h: Headphone Jack
Line1 - NID 1Ah: Internal Mic
Line2 - NID 1Bh: Disabled
PCBEEP - NID 1Dh: Enabled
SPDIF - NID 1Eh: Disabled
HP-OUT - NID 21h: Headphone Jack
Mic 1 doesn't seem to really be available, but the documentation
refers to NID 18h as MIC1, so it's being disabled as it's not
being used. The onboard microphone has been moved to line 1.
I had my peppy modified to attach the mic to line1 and mic1 now
works with this patch. Mic2 looks harder to rework, so I think
that will have to wait for the DVT boards.
Change-Id: I7d6ce6b428806b6aed1d36e7e25302fa5ae14b21
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58880
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4352
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We will soon need to call google_chromeec_get_board_version to determine
correct DDR SPD. We must do so before DDR is initialized, so allow this
function to be called from romstage.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I882d84e38d11bf66067193a6f408f941f2cf8a81
Reviewed-on: https://gerrit.chromium.org/gerrit/61191
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
USB2 Port A set to 6.4" and Back Panel
USB2 Port B set to 5.2" and Back Panel
USB2 Port C set to 12.3" and Internal
Other devices all set to Internal.
build and boot on falco and check settings.
Based on the config settings all ports end up with
tuning param 1 == 5 and param 2 == 2
U2ECR[0] = 0x00059501
U2ECR[1] = 0x00059501
U2ECR[2] = 0x00059501
U2ECR[3] = 0x00059501
U2ECR[4] = 0x00059501
U2ECR[5] = 0x00059501
U2ECR[6] = 0x00059501
U2ECR[7] = 0x00059e01
Change-Id: I6b9e6df2679036a501355e6b389a486a6f178f99
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61297
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4350
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Systems are hanging in dev_configure() without a log to
indicate which device is being processed. Add some logging
points to save the device path before talking to the device
so we can narrow in on which device is the problem.
Change-Id: I3751c19a1ea68cdccbc33e4f6b2eeddd1bd9f2e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61296
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4349
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This CPU does not support Configurable TDP and so far does
not need to use Controllable TDP.
Change-Id: I15599cd4e6890dd5c9d9f99bc4e95307a8dcc827
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60657
Reviewed-on: http://review.coreboot.org/4347
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I7252925ef5c4efb69cad6b6fa179031162cf8e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61058
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When dealing with DMA, we need a function to invalidate cache without corrupting
contents on main memory (clean).
Change-Id: I28e632ae57a7b7ed1accee74e76045b92f92a699
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The OP assigned by dcache_clean_by_mva must be handled in
dcache_op_mva.
Change-Id: Ib32262f0419453b2690d7c1a1c6602380b46a37f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61077
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The OP assigned by dcache_clean_by_mva must be handled in dcache_op_mva.
Change-Id: Ia7631a08be6afacb13dfff406ac4db20efc98926
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61076
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4343
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The is_resume comment is wrong for this board. It only applies
to the older 5250 cpu. In fact, the is_resume parameter
is not needed for ddr init and will likely be removed soon.
Change-Id: I4e3c92fcaaa75d3c9223d90acccf053f61406307
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60103
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4342
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some new fields were added to the edid data structure, and the edid code was
changed to put estimated values into those fields which were ultimately passed
into depthcharge or other payloads. On snow we do things different and just
declare an edid structure statically which didn't have those members. The rows
and columns of the graphics console were 0, and that confused the framebuffer
driver and made it loop forever.
Change-Id: I6ca3bd948482b347a6a981e83b82b10dca995e5e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61057
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Update RAM_ID table.
- Add DEVSLP0 signal to NGFF SATA port.
Note: After this change, old Micron 2GB boards will no longer boot.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id68a1d6ace2702cca9c37305726cd55a0bde5005
Reviewed-on: https://gerrit.chromium.org/gerrit/60167
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
Reviewed-on: http://review.coreboot.org/4340
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I9791beff44535a0a130292414fcd9875b497b1ca
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4492
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
No ROMCC involved, no need to include .c files in romstage.c.
Change-Id: I8a2aaf84276f2931d0a0557ba29e359fa06e2fba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4501
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
walkcbfs() is used only with ROMCC. Besides finding stages during the
bootblock, it's also used when applying microcode updates during the
bootblock phase. The function used to return only a pointer to the data of
the CBFS file, while making the header completely inaccessible. Since the
header contains the length of the CBFS file, the caller did not have a way
to know how long the data was. Then, other conventions had to be used to
determine the EOF, which might present problems if the user replaces the
CBFS file. This is not an issue when jumping to a stage (romstage), but can
present problems when accessing a microcode file which has not been
NULL-terminated.
Refactor walkcbfs_asm to return a pointer to the CBFS file header rather
than the data. Rename walkcbfs() to walkcbfs_head(), and reimplement a new
walkcbfs() based on walkcbfs_head(). Thus current usage of walkcbfs()
remains unaffected.
The code has been verified to run successfully under qemu.
Subsequent patches will change usage of walkcbfs() to walkcbfs_head where
knowing the length of the data is needed.
Change-Id: I21cbf19e130e1480e2749754e5d5130d36036f8e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
During the update_fit step, 'file_length' is used to determine how many
bytes are left in the CBFS file. It was decremented in a loop from an
array 'mcus[num_mcus].size', but 'num_mcus' was incremented right before.
Since 'mcus' is memset(0) externally, 'file_length' was never decremented.
The loop exited when it reached a dummy terminator, usually 48 bytes of 0
which are internationally added to microcode blobs in coreboot. However,
if that terminator is removed, the loop doesn't stop and continues until
it segfaults.
Change-Id: I840727add69379ffef75b694d90402ed89769e3b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
If the unpacking was interrupt by Ctrl-C, probably part of
an archive is unpacked. If we run buildgcc again, the
incomplete folder would be and skipped.
We can create a file to tell the script the unpacking is done.
Change-Id: Id9eb74d119e22b62c70dca9b38a92c3dbdf0f64c
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The architecture information has been added to the folders to
build archives for crossgcc. We need to change the .gitignore
to keep ignoring them.
Change-Id: Ic18685e507f1b09088120eee6047d49141e29906
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4513
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
I am planning to write a document for new man, helping them to build a
working image from knowing nothing about Coreboot. The previous
LinuxBIOS-AMD64.tex was a good script.
LinuxBIOS was a out-of-date name. It needs to be changed it to Coreboot.
And the new document is not specific to AMD, so we get rid of the AMD64 from
the file name.
This is a separate patch for the renaming.
LinuxBIOS-AMD64.tex was still about SVN and buildtarget. Later patch
will come up for updating those old thing. And this new document,
CorebootBuildingGuide.tex, is planning to be only about building.
Navigating the source code is moved to later advanced document.
Change-Id: Ia8a2fd9db51e9870c1d645067bcfdc91ae1bf90a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4487
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Make boards take less vertical space, and link to board pages
Change-Id: Ifdd062a15191809b75422416c874161d9114363d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4493
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Instead of having global variables put them on the stack.
Change-Id: I462e3b245612ff2dfb077da1cbcc5ac88f8b8e48
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4288
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It was suggested to eliminate the lock for sprintf. One way to do it is
to make the fake tx_byte into a closure. This patch allows it.
It's a bit tricky since we need to preserve compatibility with romcc.
Change-Id: I877ef0cef54dcbb0589fe858c485f76f3dd27ece
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4287
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These were terribly under-documented
Change-Id: I285ea083110d87076281e81065f5f38d0c688358
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4491
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Newer mainboards that use haswell -- and, presumably, chipsets to come -- need
some support functions. Add them in the drivers/intel/gma directory.
Currently, this is one file: intel_ddi.c, but more may come.
Compilation of this file is controlled by INTEL_DDI, defined
in the Kconfig as default n and used in the Makefile.inc
Change-Id: I501ee291c0d4589925ed3e478f67106337fcad31
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60612
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4337
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We use junit style output these days.
Change-Id: I4110ec10bf0e9f4354ee08e7e1c5a81ae605fee0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4484
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add ACPI Methods to enable and disable power limiting with PL1.
This can be used in ACPI Thermal Zone or in EC ACPI _QXX events.
This commit adds new unused methods and is fully tested with the
subsequent commit that makes use of these methods.
Change-Id: I9d8d23bfe9cf7c756ff8ab0412e5a010826b12db
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60546
Reviewed-on: http://review.coreboot.org/4334
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
1) fix enable of power aware interrupt routing
2) set BIOS_RESET_CPL to 3 instead of 1
3) mirror PKG power limit values from MSR to MMIO on all SKUs
4) mirror DDR power limit values from MMIO to MSR
5) remove DMI settings that were from snb/ivb as they do
not apply to haswell
1) verify power aware interrupt routing is working by looking
in /proc/interrupts to see interrupts routed to both cores
instead of always to core0
BEFORE: 58: 4943 0 PCI-MSI-edge ahci
AFTER: 58: 4766 334 PCI-MSI-edge ahci
2) read back BIOS_RESET_CPL to verify it is == 3
localhost ~ # iotools mmio_read32 0xfed15da8
0x00000003
3) read PKG power limit from MMIO and verify it is the same
as the MSR value
localhost ~ # rdmsr 0 0x610
0x0000809600dc8078
localhost ~ # iotools mmio_read32 0xfed159a0
0x00dc8078
localhost ~ # iotools mmio_read32 0xfed159a4
0x00008096
4) read DDR power limit from MSR and verify it is the same
as the MMIO value (note this is zero based on current MRC input)
localhost ~ # rdmsr 0 0x618
0x0000000000000000
localhost ~ # iotools mmio_read32 0xfed158e0
0x00000000
localhost ~ # iotools mmio_read32 0xfed158e4
0x00000000
Change-Id: I6cc4c5b2a81304e9deaad8cffcaf604ebad60b29
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60544
Reviewed-on: http://review.coreboot.org/4333
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Limit power to 12W at 73C and remove limit at 68C.
To have the CPU consume maximum power it is necessary to stress
both the CPU and the GPU. Bastion (chrome.supergiantgames.com)
and/or webglsamples.googlecode.com can be useful for this.
Testing this properly requires a script to report the running
average power readings. The watch_power.sh script is attached
to this issue in the partner tracker.
1) Run watch_power.sh continuously:
localhost ~ # watch -n 0 bash -e /tmp/watch_power.sh
2) Start Bastion (or other stress apps). The power draw should
be close to 15W if under enough load.
3) Watch until temperature climbs above 73C and is caught by
the thermal zone 10 second poll, this can be sped up by blocking
or removing the fan.
4) The ACPI thermal zone states should change to reflect that
active[2] is now enabled and power consumption should drop to 12W.
5) Stop the stress apps and wait until the CPU cools off again,
enable the fan again if it was removed.
6) The ACPI thermal zone state should switch back to active[3].
Change-Id: Ie6714a8543d4f06edf8513086fc9c968273bdb23
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60545
Reviewed-on: http://review.coreboot.org/4335
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The elog code calculates flash offsets and their equivalent
addresses in the memory address space. However, it assumes
the detected flash size is entirely mapped into the address
space. This can lead to incorrect calculations. Add code
to allow ROM_SIZE to be less than detected flash size. The
underlying assumption is that the first ROM_SIZE bytes are
programmed into the larger device.
Change-Id: Id848f136515289b40594b7d3762e26e3e55da62f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4332
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>