Add all of the PI source that will remain part of coreboot to
build with a binary AGESA PI BLOB. This includes the gcc makefiles,
some Kconfig, and the AGESA standard library functions.
Change vendorcode Makefile and Kconfig so that they can compile
AMD library files and use headers from outside the coreboot/src
tree.
Change-Id: Iad26689292eb123d735023dd29ef3d47396076ea
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10416
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds support for the Fintek F81866AD-I SuperIO,
which is very similar to the fintek/f81865f.
This code adds some fan control support, inspired by fintek/f71869ad.
Furthermore its possible to change the temp sensor type (thermistor or diode).
Datasheet: Name: F81866D/A-I, Release Date: Jan 2012, Version: V0.12P
Link: http://www.alldatasheet.com/datasheet-pdf/pdf/459085/FINTEK/F81866AD-I.html
Change-Id: Id2fc1119b37142f8101f71908e394ee69c45041d
Signed-off-by: Fabian Kunkel <fabi@adv.bruhnspace.com>
Reviewed-on: http://review.coreboot.org/10287
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Initialization for the Winbond W631GG6KB part using Synopsys
DDR uMCTL and DDR Phy.
This code adds a separate function for DDR3 initialization
and moves all the necessary defines in a separate header file.
The programming procedure that is executed at power up to bring
up the uMCTL, PHY and memories into a state where reads and
writes to the memory can be performed is the following:
1. uPCTL (Universal DDR protocol controller) initialization
The timining registers TOGCNT1U, TINIT, TOGCNT100N and TRSTH
needed for driving the memory power-up sequence are programmed
as a function of the internal timers clock frequency.
Organization (memory chip specific) values are set
(column/bank/row address width and number of ranks), together
with other static values (latency, timing, power up configuration).
All these values are static, provided by the datasheet,
being determined by the memory type, size and frequency.
2. PHY initialization
The PHY is programmed with datasheet provided values,
specifying the initialization values for it to send to the
external memory (timing parameters).
Also, delay lines (DLL) and strength of drive pads are
calibrated (based on external conditions: temperature,
voltage, noise) and locked. After that, the PHY goes
through a trainig process (also dependent on the
current conditions at boot time) to establish precise
timing configuration between the DDR clock and DQS (data strobe)
and between DQS and DQ (data).
3. Memory power up
4. Switch from configuration state to access state.
It was tested on Pistachio bring up board where DDR was initialized
properly and ramstage executed correctly
Change-Id: I3bcbce2044327a22fce09b184d85ee11228a6b2b
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10529
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Switching from active windowing DQS gating scheme to
passive windowing mode resolves boot stability issues
on chips found to have memory corruption issues during
boot or memory tests.
It was tested on Pistachio bring up board where DDR is
initialized properly and ramstage executed correctly;
We have cycled units over 12,000 times with no boot errors.
This option was chosen over the alternative of using
passive windowing mode for DQS training and after switching
back to active mode, as this option was recommended by
Synopsys. Using the alternative would give different
timing values during training that were not longer accurate
during normal activity.
Change-Id: Ie604eddc0a9a982b2f89198f44deb88a01b7b322
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10528
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix by checking the actual function return value (the search
address pointer), rather than the search length value (which isn't
guaranteed to be sane or useful).
Change-Id: I226c635ddbbc916b02494fcd97df27d141cc2c7f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10516
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Commit 899d13d (cbfs: new API and better program loading) broke
panther's lan init when no vpd.bin present from which to read
the MAC address. Fix this by checking the validity of the search
address pointer, rather than the search length.
Change-Id: I8c7ca410d8ce5c5d92242a21c4c2ff4c001a68bd
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10509
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The proper log level for any given printk statement is up to the
interpretation of the developer. This results in console output with
somewhat inconsistent levels of verbosity. This patch clearly defines each
log level and its use case, hopefully resulting in less ambiguity for
developers.
The concern with this patch might be that it leaves a lot of preexisting
printk statements using a log level that is inconsistent with the
description. I think that *most* statements map to these extended
definitions very nicely. The most discrepancies are between debug and
spew, but I'm willing to say that 95% of statements with a level lower than
debug are correct by these definitions.
There was some discussion dating back to 2010 on the mailing list about
renaming these constants to lose the 'BIOS_' prefix and to consolidate
some of them into a single constant. I disagree that it is necessary
to merge any of them, I think they all have unique use cases. But I do
think that if you all agree with these definitions, it might be useful to
rename them to reflect their use cases.
I also will add that I believe removing BIOS_NEVER is a good idea. I do
not see the use case, and it's used in only 4 files.
Change-Id: I8aefdd9dee4cb4ad2fc78ee7133a93f8ddf0720b
Signed-off-by: Nicky Sielicki <nlsielicki@wisc.edu>
Reviewed-on: http://review.coreboot.org/10444
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
It's derived from EEPROM on Lenovo machines and not from user config
which is ignored.
Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7055
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
This change adds cache management after loading stages.
Before jumping to a new stage we should flush the data
caches to memory and invalidate instruction cache.
After all segments are loaded CBFS cache is also
flushed.
With this change all stages of coreboot are now executed
successfully. This was tested on Pistachio bring up board,
also known as Urara.
Change-Id: I86e07432c21a803ef1cfc41b633c5df42b99de90
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10456
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The coreboot table address is passed as an argument when jumping
to payload.
With this change depthcharge is loaded and executed properly on urara.
Change-Id: I230d474a91b8d38aff070aa4aac623b6c8f0809c
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10460
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use cbmem_initialize_empty() after DDR configuration so that
cbmem is always initialized from scratch on each boot.
Change-Id: Ic9ca34867b26aab82cf3154280694b6fb61ee11f
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10458
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The default ordering for the base kconfig entries has the CPU
directory coming before the SOC directory, which means that the
values in the CPU Kconfig take precedence.
The first visible consequence of this is that CONFIG_SMM_TSEG_SIZE
will be set to 0 on all SOC implementations.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados
Change-Id: Ifd56a2ceb73ab335a86126e48d35ff4c749990ac
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0cddae37d3de1cbf3dd6afcf4a0707b7af9436fa
Original-Change-Id: I98e3bf249650b50667dde62b6be9c1bf587ad0b2
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/276189
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10478
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
The type1 family setting from chromium was mis-merged into the
type2 function. Move it to the correct type1 function.
Bad commit: 51bdc47816
Change-Id: I72e6ef80bbf185a39fcf169c8247dc16462e6bc3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10498
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The type of a resource is really an enumeration but our implementation
is as a bitmask. Compare all relevant bits and remove the shadowed
declarations of IORESOURCE bits.
Change-Id: I7f605d72ea702eb4fa6019ca1297f98d240c4f1a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8891
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No board in the tree selects this and it looks like the implementation
was done at chipset level while it should be part of PCI subsystem.
When enabled, at least AMD K8 and f14, f15tn and f16kb fail build test.
Feature of placing prefetchable PCI memory above 4GB may not work if
there is any 32-bit only prefetchable PCI BARs in the system.
Change-Id: I40ded2c7d6d05f461423721aa5d78a78f9f9ce1e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8705
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On modern mainboards with multiple PCI-e devices and a single
graphics card the default MMIO hole size of 512M is inadequate,
leading to resource-hungry PCI-e devices (such as an external
graphics card) being assigned invalid MMIO ranges. This, in
turn, causes the entire PCI subsystem to become unavailable,
leading to a failure to boot.
TEST: Booted KGPE-D16 with NVIDIA 7300LE and verified proper
operation of PCI/PCI-e devices, including text mode VGA operation
via the add-on card and its VGA option ROM.
Change-Id: I8d25f4b19f2d0860644ab1ee002c15041437121f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10428
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
For console drivers which use udelay() we can deadlock
in the printk path on the spinlock. The reason is that
on the first call to udelay() from within a console driver
it will go back down the printk() path deadlocking oneself.
Just remove the printk() as it was asymmetric on romstage
vs ramstage.
Change-Id: I30fe7d6e5b4684f17d4f353c0816b64f9242de0a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10483
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Instead of having the chipset code make the approrpiate
calls at the appropriate places use the cbmem init hooks
to take the appropriate action. That way no chipset code
needs to be changed in order to support the external
stage cache.
Change-Id: If74e6155ae86646bde02b2e1b550ade92b8ba9bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It can be helpful to certain users of the cbmem init hooks
to know if recovery was done or not. Therefore, add this
as a parameter to the hooks.
Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
CPU-side logic is unchanged for this range of CPUs as long as all of them
use TSEG (or ASEG, just needs to be consistent). So uplift 206ax code while
extracting southbridge and APIC code into separate functions.
Change-Id: Ib365681d1da8115922c557fddcc59afc156826da
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10465
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The cbmem util needs the CBMEM_IDs and the strings for
reporting and shares the cbmem.h file with coreboot. Split out
the IDs so for a simpler sharing and no worries about overlap of
standard libraries and other things in the header that coreboot
requires, but the tool does not.
Change-Id: Iba760c5f99c5e9838ba9426e284b59f02bcc507a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10430
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Taken from CrOS, including everything up to commit da4c33913.
Adapted to upstream.
Change-Id: I095e6726a220200ba17719fc05fcdc521da484e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10432
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SOUTHBRIDGE_INTEL_FSP_I89XX symbols are never defined in any Kconfig
file or used anywhere in the existing coreboot tree. Removing them as
unnecessary. If the southbridge code ever gets uploaded, these can be
re-added at that point.
Change-Id: I36f9ca8e25e08ce154d10ea9d764a73095590244
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10436
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Mimic vendor BIOS in switching off the led once coreboot has booted
successfully. Currently the led behavior is inconsistent. The led turns on
during poweron and stays on forever. When entering S3 and during S3 it
blinks and turns off after wake from S3. The behavior associated with S3
is the same under vendor BIOS and under coreboot. Switching off the led
before jumping to the payload makes the led behavior consistent within
coreboot before S3 and after wake from S3 and it makes the led behavior
consistent to vendor BIOS.
Change-Id: I0dec10b842b83dfc8054cd56d2750b724c4e8576
Signed-off-by: Axel Holewa <mono-for-coreboot@donderklumpen.de>
Reviewed-on: http://review.coreboot.org/10454
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Change the Kconfig board name symbol to uppercase to match
other symbols and to match the capitalization in the Kconfig
file where it's used in an expression.
Change-Id: I04ccb57cc15a6d7430f8d04136beb8384caa6c04
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10440
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
generate_sata_ssdt_ports() generates ports based on sata enable map
Change-Id: Ie68e19c93f093d6c61634c4adfde484b88f28a77
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9708
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
