Building cbmem with ASan
$ CC=gcc-5 CFLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-fsanitize=address" make
it sometimes finds a heap-buffer-overflow, while dumping the CBMEM
console.
$ sudo ./cbmem -c
=================================================================
==11208==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5d5782b at pc 0x0804a4d7 bp 0xbfe23bc8 sp 0xbfe23bbc
WRITE of size 1 at 0xb5d5782b thread T0
#0 0x804a4d6 in dump_console /home/joey/src/coreboot/util/cbmem/cbmem.c:553
#1 0x804a4d6 in main /home/joey/src/coreboot/util/cbmem/cbmem.c:1134
#2 0xb70a3a62 in __libc_start_main (/lib/i386-linux-gnu/i686/cmov/libc.so.6+0x19a62)
#3 0x8048cf0 (/home/joey/src/coreboot/util/cbmem/cbmem+0x8048cf0)
0xb5d5782b is located 50 bytes to the right of 131065-byte region [0xb5d37800,0xb5d577f9)
allocated by thread T0 here:
#0 0xb72c64ce in __interceptor_malloc (/usr/lib/i386-linux-gnu/libasan.so.2+0x924ce)
#1 0x804a407 in dump_console /home/joey/src/coreboot/util/cbmem/cbmem.c:542
#2 0x804a407 in main /home/joey/src/coreboot/util/cbmem/cbmem.c:1134
#3 0xb70a3a62 in __libc_start_main (/lib/i386-linux-gnu/i686/cmov/libc.so.6+0x19a62)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/joey/src/coreboot/util/cbmem/cbmem.c:553 dump_console
Shadow bytes around the buggy address:
0x36baaeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
=>0x36baaf00: fa fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa
0x36baaf10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
==11208==ABORTING
Fix up commit 06b13a37 (cbmem: Terminate the cbmem console at the cursor
position.) by reverting setting the cursor to 0.
Change-Id: Id614a8e0f1a202671dd091f825d826a17176bfcc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10572
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
These are no longer needed.
Test: Booted minnowmax.
Change-Id: Ie77040f3506464c614760bd4d30280c8113373bd
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12468
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The Bolton FCH needs different firmware files than the Hudson FCH.
A small patch to vendorcode is probably needed to make the XHCI controller work.
XHCI_DEVID in pci_devs.h is probably wrong for Hudson.
Change-Id: Ib81c0881979edcde717217dc89d8af415520d7e5
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/9623
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The existing code did not set the northbridge throttle
values on Family 15h, leading to sporadic and random
deadlocks in the crossbar per AMD notes.
Properly set the northbridge throttle values on Family 15h.
Change-Id: I6304b63708c65fedb9c2d46b8c862b7f0adf1102
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12025
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Clear the precomputed checksums in hwinfo as they
will be updated in manufacturing process.
Change-Id: I952ca8f1ca32831c4b296de633c0d58da111ccba
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/12475
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Bail out if .xcompile is incomplete or can't be regenerated.
Change-Id: I74adeded7a3e849b25bf65c5b02f67820f29c7e2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12477
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
If the xcompile script fails (with an error message), we should delete
the generated file so that later builds try to regenerate the file and
re-report the problem if it still persists.
Change-Id: I70ec37ca8ccb8ed3d8d0da48b326f5e0d722f314
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12473
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This is the initial version of README.
AMD provides stable Bettong code in github. Add the link and bug fixed
list to README.
Change-Id: Ie8b761096fd1850afb9363ebb761aa4992b47643
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11737
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
1. Use write_pci_int_table to write registers 0xC00/0xC01.
2. Add GPIO, I2C and UART interrupt according
"BKDG for AMD Family 15h Models 60h-6Fh Processors",
50742 Rev 3.01 - July 17, 2015
3. The interrupt valudes are moved from bettong/mptable.c.
All devices work in Windows 10.
Change-Id: Iad13bc02c84a5dfc7c24356436ac560f593304d7
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11746
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
The HOSTCC should be set in .xcompile, which tests the existence of gcc
and cc. But the .xcompile has to be included after kconfig/Makefile. So
building util/kconfig uses the seperated HOSTCC definition above it,
instead of the one in .xcompile.
For the system which clang is the default host compiler, gcc is not
installed by default. In that case, we need to set HOSTCC as cc.
Change-Id: I1e51a37c4426e2c97d36a31f26a18ab4b0d0608d
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12331
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On system with clang, "as" is available but "objdump" is not by default.
So if ${gccprefix} is empty, "as" can run successfully and the "objdump"
below might report error. Mask that output.
Change-Id: I9940f069f66e097973ed6138cf3c696087fa5531
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11681
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
The second parameter is to set file permissions for the directory, which
is not needed in mingw.
Change-Id: I88e317f075e8a39f0a280b3dd6e597d119f0f741
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11723
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
If HOSTCC=clang, the -Wtautological-constant-out-of-range-compare is
set automaticaaly. That assume the value of type enum is in the defined
range. Then testing if a type enum is out of range causes build error.
Error:
coreboot/util/cbfstool/cbfs_image.c:1387:16: error:
comparison of constant 4 with expression of type 'enum vb2_hash_algorithm'
is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (hash_type >= CBFS_NUM_SUPPORTED_HASHES)
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
clang version:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
Change-Id: I3e1722bf6f9553793a9f0c7f4e790706b6938522
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12330
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
These platforms needed to be adjusted to fix various Kconfig warnings.
Both platforms needed MAINBOARD_HAS_NATIVE_VGA_INIT because they're setting
MAINBOARD_DO_NATIVE_VGA_INIT.
veyron_emile needed a few symbols that depend on CHROMEOS to be moved
into a new config CHROMEOS section. This matches the other CHROMEOS
platforms.
veyron_danger needed to select MAINBOARD_HAS_CHROMEOS before the
CHROMEOS symbol was set.
Change-Id: I8c7f594ba572a02513a68095c16314006fb4e379
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12462
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
EC_SOFTWARE_SYNC depends on CHROMEOS, so move it into the CHROMEOS section.
This fixes the kconfig warning:
warning: (CHROMEOS && BOARD_SPECIFIC_OPTIONS ...) selects
EC_SOFTWARE_SYNC which has unmet direct dependencies
(MAINBOARD_HAS_CHROMEOS && CHROMEOS && VBOOT_VERIFY_FIRMWARE)
Change-Id: I459f48fd18c7568c4584df7d4aefa69dec3e4907
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12460
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Found while doing code review.
Use a function to toggle IO reset signal.
Change-Id: I4cb0885ed9be763fbc4069e4d015a36a7183c823
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11916
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There are few drawbacks reading VPD from SPI flash in user land, including
"lack of firmware level authority" and "slow reading speed".
Since for many platforms we are already reading VPD in firmware (for
example MAC and serial number), caching the VPD data in CBMEM should
will speed up and simplify user land VPD processing without adding
performance cost.
A new CBMEM ID is added: CBMEM_ID_VPD, referring to a structure containing
raw Google VPD 2.0 structure and can be found by the new LB_TAG_VPD in
Coreboot tables.
BRANCH=smaug
BUG=chrome-os-partner:39945
TEST=emerge-smaug coreboot chromeos-bootimage # and boots successfully.
[pg: lots of changes to make it work with what happened in upstream
since 2013]
Change-Id: If8629ac002d52abed7b480d3d06298665613edbf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 117a9e88912860a22d250ff0e53a7d40237ddd45
Original-Change-Id: Ic79f424a6e3edfb6c5d168b9661d61a56fab295f
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/285031
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12453
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The EDID parsing code continued to update _some_ fields of the output
edid but not others if "did_detailed_timing" was already set. It also
then went on to print out this halfway mix of modes each time, despite
the fact that it didn't really update everything.
Let's fix that. We'll reduce code changes by using a temporary copy of
data in detailed_block() and then we'll copy it back if we decide we
should update.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=No more bogus printouts
Change-Id: Idbfa233e0997244c22ef21c892c4473a91621821
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4d69999cdd7ce3cd2c9332ab3f22ea8eb4b6f2e9
Original-Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309541
Original-Reviewed-on: https://chromium-review.googlesource.com/309609
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12444
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid
clock to use, but is quite hard to make a non-jittery clock from PLLs.
It's much easier to make 25.200 MHz, so let's do that.
The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems
better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia monitor works, so do others
Change-Id: I8aa124d04a90f5dcf9cfa923ed3b693fbb4a06d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e32ce13462101dc60cfed60b6948b7597e93525a
Original-Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309540
Original-Reviewed-by: Stphane Marchesin <marcheu@chromium.org>
Original-(cherry picked from commit 7f32c9f460991e5e3b947117d6ae4080e630a532)
Original-Reviewed-on: https://chromium-review.googlesource.com/309576
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12443
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The set to say that a standard timing was supported was not properly in
the "if" test. That meant that even when standard timings weren't
supported, we thought that they were. That had the side effect of never
using the detailed mode.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Adafruit panel works now
Change-Id: Ide3ed6c5682840f808d854755dac58e9057e6bda
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c99d3ee8d163fc6be207c5a7df2a7aecd7af7849
Original-Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309521
Original-(cherry picked from commit 4e4c2816e2239299bc02e3a57fb18056db62b56c)
Original-Reviewed-on: https://chromium-review.googlesource.com/309552
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12442
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The detailed_cvt_descriptor() function takes a parameter "out" for no
good reason. Remove it.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Build and boot
Change-Id: I1042dba9ddf2b4b543bd07615013088be5055950
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5c3474c9b1f9fb73f44d64d3a0592f92339da2df
Original-Change-Id: I4d695a6dba6606d2132578ce0ab4cb612c83d0f4
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309598
Original-(cherry picked from commit 39122e242e808d71a4e274e8a23e9a63f4984388)
Original-Reviewed-on: https://chromium-review.googlesource.com/309496
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12441
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This models gcc's (and other compilers') behavior to not bail
out with an error when one of the include paths does not exist.
Change-Id: Ic93a55cea6b32516fd76da9b49abe7b990829889
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12469
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
The existing HyperTransport register configuration values were incorrect
in many spots. Apply the correct values from the BKDG on Family 10h and
Family 15h processors.
Change-Id: I009b6f478340e2dbfcda2b4534473d4397f9ecef
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12022
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The screen dimensions need to be known in other files.
Change-Id: Idf6f02e4cadbece78096ccd464296ecec405574d
Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
Reviewed-on: http://review.coreboot.org/12439
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
- Only build IASL once for the 'all' targets instead of once for each.
- Change the control of what gets built from different targets to
variables on the build line.
- Clean up and correct the list of phony targets
- Don't keep the temporary files around while building all. This
takes up a lot of space. If it's desired behavior, add
BUILDGCC_OPTIONS=-t on the make command line.
- Add comments about CPU= and BUILDGCC_OPTIONS= variables
- Add KEEP_SOURCES option
Change-Id: I7752974e249f25717b42be25a841c69af84d5c69
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12300
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Otherwise </testsuite> is missing and jenkins can't make sense of
things.
Change-Id: If11a6d2506efc9d7c915f50896b2714bc66e3b65
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12478
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The previous LinuxBIOS-AMD64.tex was still working with subversion.
We need a document to give the preliminary steps to build coreboot
for a new guys.
Change-Id: I64240c8344456e724f0823680e0534cf1db4c4a8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4510
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We have had the "APIC: 00 missing read_resources" messages
for many years. It's obviously not an error, and also doesn't
cause boot failures. Therefore, remove the message.
Change-Id: I7f99c5950a3457df04e7ef6edb456b70dba9680c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12471
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The existing code for the Lenovo T400 works without changes on the
Lenovo R400. Same HDA verbs are provided by Lenovo BIOS on both
laptops.
Change-Id: I1dadddd7250ab80a4c40c2435865d72e3e5d99c9
Signed-off-by: Michał Masłowski <mtjm@mtjm.eu>
Signed-off-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-on: http://review.coreboot.org/8393
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The function fletcher is moved to amdfwtool.
Change-Id: I39eb05a184d8878a96f8de46caf4b5c6c433dc3a
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12455
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Combine all needed AMD firmware into one single firmware, which going to
be added as one single CBFS module.
Change-Id: Ib044098c1837592b8f7e9c6a7da4ba3a32117e25
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12419
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
only enable pcie gpp clocks when the corresponding clkreq pin is asserted
Change-Id: I7822d011bb94867d470c0194e6b652833c395cb2
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/12353
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
disable unconnected FCH clock outputs to save some power
Change-Id: Ib3efebb8656392d58d762c23827168017d273de8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/12082
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The Intel cave creek chipset needs to have port 80 routing configured
before any post codes can be sent to port 80h. Sending post codes out
before the routing is done will hang the system.
This patch allows us to disable the first couple of post codes that go
out before the routing can be configured.
The Kconfig symbol is selected by the cave creek chipset (fsp_i89xx).
Change-Id: I9bf41669ec32744f87a1ed2de011d31c72ea38da
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12422
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: York Yang <york.yang@intel.com>
According to C documentation, the range of tm_mon in struct tm is [0, 11].
Before the patch, the displayed month was indeed incorrect.
Change-Id: I9f95f1e978c45b3635e2edfe1ec496d7b0dec00a
Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
Reviewed-on: http://review.coreboot.org/12438
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
HAS_PRECBMEM_TIMESTAMP_REGION was dependent on COLLECT_TIMESTAMPS,
but should be allowed to be selected independently. My thought is that
the code may only be used when collecting timestamps, the HAS prefix
signifies that this is a platform configuration option.
This fix could also be done by adding 'if COLLECT_TIMESTAMPS' everywhere
that 'select HAS_PRECBMEM_TIMESTAMP_REGION' is used
Change-Id: Iaf4895475c38a855a048dc9b82d4c97e5e3f4e5c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11338
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Alignment of Intel Firmware Support Package 1.0 Rangeley
header and source files to the revision: POSTGOLD4
Detail changelog can be found at http://www.intel.com/fsp
FSP release date September 24, 2015
Change-Id: If1a6f95aed3e9a60af9af8cf9cd466a560ef0fe2
Signed-off-by: Marcin Wojciechowski <marcin.wojciechowski@intel.com>
Reviewed-on: http://review.coreboot.org/12418
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This fixes Family 15h multiple package support; the previous code
hung in CAR setup and romstage when more than one CPU package was
installed for a variety of loosely related reasons.
TEST: Booted ASUS KGPE-D16 with two Opteron 6328 processors
and several different RDIMM configurations.
Change-Id: I171197c90f72d3496a385465937b7666cbf7e308
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12020
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Merlin Falcon's FCH has GPIO, UART and I2C. All of them are controlled
by registers mapped at MMIO space.
This ASL code is used for Windows drivers.
TEST:
1. Boot Windows 8 or Windows 10.
2. Install AMD Catalyst driver.
3. AMD FPIO, UART and I2C can be found in device manager.
4. I2C passed Multi Interface Test Tool (MITT) test.
Change-Id: I7ffe3fe0046d9a078cc38176c29a8e334646a5a3
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11750
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
On one particular TV the TV was holding SDA low when it came up. It
would release the SDA when the SCL went low the first time.
Unfortunately the HDMI i2c port wouldn't transmit until the SDA was
released.
Let's detect this case and insert a bogus clock pulse to try to get the
other side to release SDA.
It's unclear why the kernel doesn't have this problem.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia TV works now
Change-Id: Ic9d27eb69bdc9c5fb11a68258e0c755cdc8b79d7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 356ee7503f04e741a41be37ad573b588067b7114
Original-Change-Id: I4b6361877e0576cc4ea2f643f073f1aab660e434
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309258
Original-Reviewed-by: Agnes Cheng <agnescheng@google.com>
Original-Commit-Queue: Agnes Cheng <agnescheng@google.com>
Original-Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Original-Tested-by: Agnes Cheng <agnescheng@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309546
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12451
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Pratik Prajapati