Add the ACPI Operating System Capabilities Method and let the
operation system control everything.
Commit »AMD Fam14 DSDT: Add OSC method« (00a0e76b) [1] is used as
a template.
The Lenovo X60 [2] running the Parabola GNU/Linux distribution [3] is
used for testing.
Before that change:
$ dmesg | egrep -e OSC -e ASPM
[ 0.108036] pci_root PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM
[ 0.108040] pci_root PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08)
[ 0.118089] ACPI _OSC control for PCIe not granted, disabling ASPM
[ 16.874569] e1000e 0000:01:00.0: Disabling ASPM L0s L1
With that change:
$ dmesg | egrep -e OSC -e ASPM
[ 0.107962] pci_root PNP0A08:00: Requesting ACPI _OSC control (0x1d)
[ 0.108003] pci_root PNP0A08:00: ACPI _OSC control (0x1d) granted
[ 0.111052] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 17.537970] e1000e 0000:01:00.0: Disabling ASPM L0s L1
[1] http://review.coreboot.org/2738
[2] http://www.coreboot.org/Lenovo_x60x
[3] https://parabolagnulinux.org/
Change-Id: I1caffa44eea447d553c01caaf431f2db241ea5ea
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2938
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The code has been taken from the google link mainboard
and modified to fit the ThinkPad X60.
Change-Id: Ie16e45163acdc651ea46699ecc33055bfd34099c
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/2998
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
If ROM caching is selected the sandybridge chipset code will
will enable ROM caching after all other CPU threads are brought
up.
Change-Id: I3a57ba8753678146527ebf9547f5fbbd4f441f43
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The graphics memory can be accessed in a faster manner by
setting it to write-combing mode. Add an option to enable
write-combining for the graphics memory.
Change-Id: I7d37fd78906262aabef92c2b4f4cab0e3f7e4f6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2894
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The graphics memory can be accessed in a faster manner by
setting it to write-combing mode. Add an option to enable
write-combining for the graphics memory.
Change-Id: I797fcd9f0dfb074f9e45476773acbfe614eb4b0a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2893
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The old MTRR code had issues using too many variable
MTRRs depending on the physical address space layout dictated
by the device resources. This new implementation calculates
the default MTRR type by comparing the number of variable MTRRs
used for each type. This avoids the need for IORESOURE_UMA_FB
because in many of those situations setting the default type to WB
frees up the variable MTTRs to set that space to UC.
Additionally, it removes the need for IORESOURCE_IGNORE_MTRR
becuase the new mtrr uses the memrange library which does merging
of resources.
Lastly, the sandybridge gma has its speedup optimization removed
for the graphics memory by writing a pre-determined MTRR index.
That will be fixed in an upcoming patch once write-combining support
is added to the resources.
Slight differences from previous MTRR code:
- The number of reserved OS MTRRs is not a hard limit. It's now advisory
as PAT can be used by the OS to setup the regions to the caching
policy desired.
- The memory types are calculated once by the first CPU to run the code.
After that all other CPUs use that value.
- CONFIG_CACHE_ROM support was dropped. It will be added back in its own
change.
A pathological case that was previously fixed by changing vendor code
to adjust the IO hole location looked like the following:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6
0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6
As noted by the output below it's impossible to accomodate those
ranges even with 10 variable MTRRS. However, because the code
can select WB as the default MTRR type it can be done in 6 MTRRs:
MTRR: default type WB/UC MTRR counts: 6/14.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0
MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0
MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0
Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2889
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mmio_resource() was previously being used for reserving
RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute.
Instead, be more explicit for those uses with
reserved_ram_resource(). bad_ram_resource() now calls
reserved_ram_resource(). Those resources are marked as cacheable
but reserved.
The sandybridge and haswell code were relying on the implementation
fo the MTRR algorithm's interaction for reserved regions. Instead
be explicit about what ranges are MMIO reserved and what are RAM
reserved.
Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2886
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Convert the existing haswell code to support reloctable ramstage
to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as
this option is a hard requirement for relocatable ramstage.
Aside from converting a few new API calls, a cbmem_top()
implementation is added which is defined to be at the begining of the
TSEG region. Also, use the dynamic cbmem library for allocating a
stack in ram for romstage after CAR is torn down.
Utilizing dynamic cbmem does mean that the cmem field in the gnvs
chromeos acpi table is now 0. Also, the memconsole driver in the kernel
won't be able to find the memconsole because the cbmem structure
changed.
Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Dynamic cbmem is now a requirement for relocatable ramstage.
This patch replaces the reserve_* fields in the romstage_handoff
structure by using the dynamic cbmem library.
The haswell code is not moved over in this commit, but it should be
safe because there is a hard requirement for DYNAMIC_CBMEM when using
a reloctable ramstage.
Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
This makes use of the new functions from pmutil.c that take
care of the differences between -H and -LP chipsets.
It also adds support for the LynxPoint-LP GPE0 register block
and the SMI/SCI routing differences.
The FADT is updated to report the new 256 byte GPE0 block on
wtm2/wtm2 boards which is too big for the 64bit X_GPE0 address
block so that part is zeroed to prevent IASL and the kernel
from complaining about a mismatch.
This was tested on WTM2. Unfortunately I am still unable to get an
SCI delivered from the EC but I suspect that is due to a magic
command needed to put the EC in ACPI mode. Instead I verified that
all of the power management and GPIO registers were set to expected
values.
I also tested transitions into S3 and S5 from both the kernel and
by pressing the power button at the developer mode screen and they
all function as expected.
Change-Id: Ice9e798ea5144db228349ce90540745c0780b20a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2816
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM region is available for multipurpose use before the SMM
handler is relocated. Provide a configurable sized region in the
TSEG for use before the SMM handler is relocated. This feature is
implemented by making the reserved size a Kconfig option. Also
make the IED region a Kconfig option as well. Lastly add some sanity
checking on the Kconfig options.
Change-Id: Idd7fccf925a8787146906ac766b7878845c75935
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2804
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that there is a way to disseminate the presence of s3 wake more
formally use that instead of hard coded pointers in memory and stashing
magic values in device registers. The northbridge code picks up the
field's presence in the romstage_handoff structure and sets up the
acpi_slp_type variable accordingly.
Change-Id: Ida786728ce2950bd64610a99b7ad4f1ca6917a99
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2799
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Provide the implemenation of cbmem_get_table_location() so that
cbmem can be initialized early in ramstage when CONFIG_EARLY_CBMEM_INIT
is enabled. The cbmem tables are located just below the TSEG region.
Change-Id: Ia160ac6aff583fc52bf403d047529aaa07088085
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2798
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is not needed in haswell.
Change-Id: I23817c2e01be33855f9d5a5e389e8ccb7954c0e2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2847
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The save_mrc_data() was previously called conditionally
in the raminit code. The save_mrc_data() function was called
in the non-S3 wake paths. However, the common romstage_common()
code was checking cbmem initialization things on s3 wake. Between
the two callers cbmem_initialize() was being called twice in the
non-s3 wake paths. Moreover, saving of the mrc data was not allowed
when CONFIG_EARLY_CBMEM_INIT wasn't enabled.
Therefore, move the save_mrc_data() to romstage_common. It already has
the knowledge of the wake path. Also remove the CONFIG_EARLY_CBMEM_INIT
requirement from save_mrc_data() as well as the call to cbmem_initialize().
Change-Id: I7f0e4d752c92d9d5eedb8fa56133ec190caf77da
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2756
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This structure is not used nor the variable being instantiated on the
stack. Remove them.
Change-Id: If3abe2dd77104eff49665dd33570b07179bf34f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2753
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It was found that the Haswell reference code was smashing through the
stack into the reference code's heap implementation. The reason for this
is because our current CAR allocation is too small. Moreover there are
quite a few things to coordinate between 2 code bases to get correct.
This commit separates the CAR into 2 parts:
1. MRC CAR usage.
2. Coreboot CAR usage.
Pointers from one region can be passed between the 2 modules, but one
should not be able to affect the others as checking has been put into
place in both modules.
The CAR size has effectively been doubled from 0x20000 (128 KiB) to
0x40000 (256KiB). Not all of that increase was needed, but enforcing
a power of 2 size only utilizes 1 MTRR.
Old CAR layout with a single contiguous stack with the region starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| MRC global variables |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+
| ROM stage stack |
| |
| |
+---------------------------------------+
| MRC Heap 30000 bytes |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
There was some hard coded offsets in the reference code wrapper to start
the heap past the console buffer. Even with this commit the console
can smash into the following region depending on what size
CONFIG_CONSOLE_CAR_BUFFER_SIZE is.
As noted above This change splits the CAR region into 2 parts starting
at CONFIG_DCACHE_RAM_BASE:
+---------------------------------------+
| MRC Region |
| CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes |
+---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE
| ROM stage stack |
| |
| |
+---------------------------------------+
| ROM stage console |
| CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes |
+---------------------------------------+
| ROM stage CAR_GLOBAL variables |
+---------------------------------------+ Offset 0
Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE,
which represents the expected stack usage for the romstage. A marker
is checked at the base of the stack to determine if either the stack
was smashed or the console encroached on the stack.
Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2752
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The acpi_fill_mcfg() was still using ivy/sandy PCI device ids which Hawell
obviously doesn't have. This resulted in an empty MCFG table. Instead of
relying on PCI device ids use dev/fn 0/0 since that is where the host
bridge always resides. Additionally remove the defines for the IB and SB
pci device ids. Replace them with mobile and ult Haswel device ids and
use those in the pci driver tables for the northbridge code.
Booted to Linux and noted that MCFG was properly parsed.
Change-Id: Ieaab2dfef0e9daf3edbd8a27efe0825d2beb9443
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2748
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM handler resides in the TSEG region which is far above
CONFIG_RAM_TOP (which is the highest cacheable address) before
MTRRs are setup. This means that calling initialize_cpus() before
performing MTRR setup on the BSP means the SMM handler is copied
using uncacheable accesses.
Improve the SMM handler setup path by enabling performing MTRR setup on
for the BSP before the call to initialize_cpus(). In order to do this
the haswell_init() function was split into 2 paths: BSP & AP paths.
There is a cpu_common_init() that both call to perform similar
functionality. The BSP path in haswell_init() then starts the APs using
intel_cores_init(). The AP path in haswell_init() loads microcode and
sets up MTRRs.
This split will be leveraged for future support of bringing up APs in
parallel as well as adhering to the Haswell MP initialization
requirements.
Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2746
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There was a mix of setup code sprinkled across the various components:
southbridge code in the northbridge, etc. This commit reorganizes the
code so that northbridge code doesn't initialize southbridge components.
Additionally, the calling dram initialization no longer calls out to ME
code. The main() function in the mainboard calls the necessary ME
functions before and after dram initialization.
The biggest change is the addition of an early_pch_init() function
which initializes the BARs, GPIOs, and RCBA configuration. It is also
responsible for reporting back to the caller if the board is being
woken up from S3. The one sequence difference is that the RCBA config
is performed before claling the reference code.
Lastly the rcba configuration was changed to be table driven so that
different board/configurations can use the same code. It should be
possible to have board/configuration specific gpio and rcba
configuration while reusing the romstage code.
Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG
region is setup as cacheable through the MTTRs, accesses to the TSEG
region before SMM relocation are cached. This allows for the setup of
SMM relocation to be faster by caching accesses to the future TSEG
(SMRAM) memory.
MC MAP: TOM: 0x140000000
MC MAP: TOUUD: 0x18f600000
MC MAP: MESEG_BASE: 0x13f000000
MC MAP: MESEG_LIMIT: 0x7fff0fffff
MC MAP: REMAP_BASE: 0x13f000000
MC MAP: REMAP_LIMIT: 0x18f5fffff
MC MAP: TOLUD: 0xafa00000
MC MAP: BGSM: 0xad800000
MC MAP: BDSM: 0xada00000
MC MAP: TESGMB: 0xad000000
MC MAP: GGC: 0x209
TSEG->BGSM:
PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4
BGSM->TOLUD:
PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5
Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 512MB, type WB
Setting variable MTRR 2, base: 2560MB, range: 256MB, type WB
Adding hole at 2776MB-2816MB
Setting variable MTRR 3, base: 2776MB, range: 8MB, type UC
Setting variable MTRR 4, base: 2784MB, range: 32MB, type UC
Zero-sized MTRR range @0KB
Allocate an msr - basek = 00400000, sizek = 0023d800,
Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB
Setting variable MTRR 6, base: 6144MB, range: 256MB, type WB
Adding hole at 6390MB-6400MB
Setting variable MTRR 7, base: 6390MB, range: 2MB, type UC
MTRR translation from MB to addresses:
MTRR 0: 0x00000000 -> 0x80000000 WB
MTRR 1: 0x80000000 -> 0xa0000000 WB
MTRR 2: 0xa0000000 -> 0xb0000000 WB
MTRR 3: 0xad800000 -> 0xae000000 UC
MTRR 4: 0xae000000 -> 0xb0000000 UC
I'm not a fan of the marking physical address space with MTRRs as being
UC which is PCI space, but it is technically correct.
Lastly, drop a comment describing AP startup flow through coreboot.
Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2690
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Devoutly to be wish'd. To die,—to sleep;—
To sleep! perchance to dream:—ay, there's the rub;
For in that sleep of death what dreams may come,
(Since who could argue with William Shakespeare?)
Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/2733
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
It's possible that TOUUD can be 4GiB in a small physical memory
configuration. Therefore, don't add a 0-size memory range resouce
in that case.
Change-Id: I016616a9d9d615417038e9c847c354db7d872819
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2691
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Link native graphics commit 49428d84 [1]
Add support for Google's Chromebook Pixel
was missing some of the higher level bits, and hence could not be
used. This is not new code -- it has been working since last
August -- so the effort now is to get it into the tree and structure
it in a way compatible with upstream coreboot.
1. Add options to src/device/Kconfig to enable native graphics.
2. Export the MTRR function for setting variable MTRRs.
3. Clean up some of the comments and white space.
While I realize that the product name is Pixel, the mainboard in the
coreboot tree is called Link, and that name is what we will use
in our commits.
[1] http://review.coreboot.org/2482
Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2531
Tested-by: build bot (Jenkins)
This wasn't previously spotted because the printk's were correct.
However if one needed to get the value of the BDSM or BGSM register
the value would reflect the other register's value.
Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2689
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Add ME device ID for Lynxpoint LP
- Add GPU device IDs for ULT
- SATA init tweaks from checking against DXE reference code
- Remove the ICH7 from the SPI driver so it works on all lynxpoint
without having to add more LPC device ID checks
- Add function disable for audio dsp and xhci, remove PCI bridge
- Add interrupt route registers for new devices (needs romstage setup)
Change-Id: Idb48f50d0bacb6bf90531c3834542b9abb54fb8a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2680
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Device IDs for northbridge and GPU.
Also mask off the lock bit in the memory map registers.
Change-Id: I9a4955d4541b938285712e82dd0b1696fa272b63
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2646
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some of the Lynx Point ids were off. Correct those and make
the pei data BAR fields consistent with the others.
Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2622
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove
the pcie explicit accesses. The default config accesses use
MMIO.
Change-Id: I8406cec16c1ee1bc205b657a0c90beb2252df061
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2618
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order for coreboot to assign resources properly the pci
drivers need to have th proper device ids. Add the host controller
and the LPC device ids for Lynx Point.
Resource assignment works correctly now w/o odd behavior because
of conflicts.
Change-Id: Id33b3676616fb0c428d84e5fe5c6b8a7cc5fbb62
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2638
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
The reference code sends the dram init done command to the ME.
Therefore, there is no need for coreboot to do this.
Change-Id: I6837d6c50bbb7db991f9d21fc9cdba76252c1b7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2633
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a FIXME about checking a MCHBAR register that isn't setup yet.
Also, remove revision updating because I can't find anything in the
docs that suggest this is required for haswell.
Change-Id: Ia8a6e08f82e18789e31c6c2ec2c1d63740c18dc4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2631
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The intel-framework code has an updated pei_data structure.
Use the new structure and revision. Also, remove the scrambler
seed saving in CMOS since that appears to be handled in the saved
data from the reference code.
Change-Id: Ie09a0a00646ab040e8ceff922048981d055d5cd2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2630
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change the hard coded values in udelay.c to use the #defines
for MSRs and BCLK.
Change-Id: I2bbeb0b478d2e3ca155e8f82006df86c29a4f018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2629
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the steps outlined in the BWG.
It seems this is a lot simpler now (so far) which is good.
To test, boot to chromeos with 3.7 kernel + i915.preliminary_hw_support=1 and
see that the i915 driver complains a lot less than before and that a
splashscreen is displayed.
Change-Id: I722c90ecd351860949cedab24533f6c10e5b90e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/2696
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a bootblock.c file for the northbridge and setup the
PCIEXBAR as the first thing using IO PCI config acceses.
After that all PCI config accesses can use MMIO.
Change-Id: I51d229c626c45705dda1757c2f14265cbc0e6183
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2617
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore,
the southbridge support is included as well. The basis for this code is
the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires
more attention, but this is a good starting point.
This code partially gets up through the romstage just before training
memory on a Haswell reference board.
Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2616
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add PEI updates and ACPI updates for supporting EHCI to XHCI
USB port support.
Change-Id: I9ace68a1b3950771aefb96c1319b8899291edd9a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2519
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since there are and will be other files in nb/sb folders, we change
the general spi.h to a file name which is not easy to be duplicated.
Change-Id: I6548a81206caa608369be044747bde31e2b08d1a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2309
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
And move the corresponding #define to speedstep.h
Change-Id: I8c884b8ab9ba54e01cfed7647a59deafeac94f2d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2339
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As we move to supporting other systems we need to get rid of assembly
where we can. The log2 function in src/lib is identical to the assembly
one (tested for all 32-bit signed integers :-) and takes about 10 ns
to run as opposed to 5ns for the non-portable assembly version. While speed
is good, I think we can spare the 15 ns or so we add to boot time
by using the C version only.
Change-Id: Icafa565eae282c85fa5fc01b3bd1f110cd9aaa91
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1928
Tested-by: build bot (Jenkins)
This broke because those components were not yet
committed when the patch to drop the driver class
was made.
Change-Id: I29948223503a6c4b196eafa169c064cd26da1be1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1934
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The code supports DDR3 boards only. RAM init for DDR2 is sufficiently
different that it requires separate code, and we have no boards to
test that.
Change-Id: I9076546faf8a2033c89eb95f5eec524439ab9fe1
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1689
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Makes it more similar to what realmode looks like.
Change-Id: I4407431f2d979c43dd186114d67ed11845907afe
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1892
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If the PEI System Agent doesn't run PCIe initialization, the PEG
clock gating will not be setup. Add the PEG clock gating when
pei_data->pcie_init is 0.
Change-Id: I7e31bcebd11feb4807aa29b528adf09fb013c3ce
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1827
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The IvyBridge reference code does some slow and
extensive PCIe init that we do not need on Link.
Hence, add a flag to disable/enable running that
init code from coreboot.
NMode was used during bringup. We'll switch
the setting back to auto, to let MRC decide the right thing.
Change-Id: Ia989bb9ea079aadfeb41dc3029b7c2c623e84760
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1826
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will enable DDR3 1.35V support for memory training in
the reference code. It requires the board to be setup for
1.35V with whatever board-specific GPIOs are available.
Change-Id: I14e4686c20f9610f90678e6e3bece8ba80d8621a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1825
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I added a comment to the pei_data.h to remind users about
how the OC pins are mapped.
Change-Id: I4d74eb69fc78816a69e61260c2c9b2b3e58cafec
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1824
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Let memory initialization code use the coreboot romstage console. This
simplifies the code and makes sure that all output is available in
/sys/firmware/log.
The pei_data structure is modified to allow passing the console output
function pointer. Romstage console_tx_byte() is used for this purpose.
Change-Id: I722cfcb9ff0cf527c12cb6cac09d77ef17b588e0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1823
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The MRC cache code, as implemented, in some cases uses configuration
settings for MRC cache region, and in some cases - the values read
from FMAP. These do not necessarily match, the code should use FMAP
across the board.
This change also refactors mrccache.c to limit number of iterations
through the cache area and number of fmap area searches.
Change-Id: Idb9cb70ead4baa3601aa244afc326d5be0d06446
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1788
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On Sandybridge and Ivybridge systems the firmware image has to
store a lot more than just coreboot, including:
- a firmware descriptor
- Intel Management Engine firmware
- MRC cache information
This option allows to limit the size of the CBFS portion in
the firmware image.
Change-Id: Ib87fd16fff2a6811cf898d611c966b90c939c50f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1770
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These can be stored in the code segment, since it's never changed.
Change-Id: I8b3827838e08e6cc30678aad36c39249fbca0c38
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1749
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Until now, the MRC cache position and size was hard coded in Kconfig.
However, on ChromeOS devices, it should be determined by reading the
FMAP.
This patch provides a minimalistic FMAP parser (libflashmap was too
complex and OS centered) to allow reading the in-ROM flash map and
look for sections.
This will also be needed on some partner devices where coreboot will
have to find the VPD in order to set up the device's mac address
correctly.
The MRC cache implementation demonstrates how to use the FMAP parser.
Change-Id: I34964b72587443a6ca4f27407d778af8728565f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1701
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
This is purely cosmetic. All error messages in the Sandybridge raminit
code printed a newline at the end.
Change-Id: I880d291928291d487039850a2a3d53a1101124ba
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1699
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
This will allow the lower bank to be cleared without impacting the
ability to suspend/resume.
Change-Id: Iaec3c9e7e40c334053c814eaddd1f614df245a73
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1696
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Unfortunately the reference tool chain was updated
without ever even testing it on an abuild run. This
broke a number of ports.
This change gets coreboot at least compiling again
for all supported systems.
Change-Id: I92c7cbc834de6d792fdab86b75df339e2874c52e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1670
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Without this, the output of "Setting up ACPI…" continues right
after the output of stepping.
Change-Id: I2ad7cc3e55884ff509600b01274258b8e8250981
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1632
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
I don't know if the size main memory supposed to be in PCI(0,0) reg 0x9c
but it is not written there. The size of memory is written in
src/northbridge/intel/sch/raminit.c to SCH port(2, 8, 4) (look for
"Setting up TOM").
Change-Id: Iea04a5185bda56f61d1c382533d5a0dac429ebbd
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1629
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The GGC register which contains the size of memory that is used for GPU
is in PCI device 2,0 and not 0,0. It is set to to 4MiB in
src/mainboard/iwave/iWRainbowG6/romstage.c.
Change-Id: Ie9f1cc60544ecd9cad770f34c83c33564a6129d4
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1628
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Without this, the hightables are placed just before the end of memory.
However we might have the GPU memory located at the exact same spot,
that is in the last 4 MiB. So without this patch, this area won't remain
marked as "CONFIGURATION TABLES" within coreboot's memory table but
becomes "RESERVED" because it is part of the PCI(2,0) device.
Change-Id: Ibd111c167c2f6ac03b0ba68581a74ecbd2c9c160
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-on: http://review.coreboot.org/1627
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Also deletes files not included in build:
src/southbridge/amd/cimx/sb700/chip_name.c
src/southbridge/amd/cimx/sb800/chip_name.c
src/southbridge/amd/cimx/sb900/chip_name.c
Change-Id: I2068e3859157b758ccea0ca91fa47d09a8639361
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1473
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
... but no-one told intel/sch.
Change-Id: I68eaae6910bd6fc579c35b5bc038b9597cd1b3e7
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1537
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name is derived directly from the device path.
Change-Id: If2053d14f0e38a5ee0159b47a66d45ff3dff649a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This was broken, fixing according to related patch for i945
Change-Id: I925cd205ee5beb918181740a7b981a4209688ac6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1412
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The includes removed here were previously required for
struct lb_memory and lb_add_memory_range().
Change-Id: Ie6c0d4ef55c2225aa709cf3fbad30ff1080e3610
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1391
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The names were set at various times during development, but
the way the code works, you might end up with the wrong name
being displayed in the logs. Instead of doing magic, just
display both names for each component
Change-Id: I1f8ce44d156442f5f7d717e1a2b47ed1218d4527
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1413
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use of uma_resource() in northbridge code created a memory
resource marked as reserved. Such resources are removed
from system memory in write_coreboot_table().
Change-Id: I14bfd560140d8d30ec156562f23072bfae747bde
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1238
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
With SandyBridge northbridge code, uma_memory_size was reset to
zero before variable MTRRs were set. This means MTRR setup routine
did not previously create a un-cacheable hole for uma.
Keep the behaviour that way, mmio_resource() has a prerequisuite that
the new region does not overlap with any cacheable ram_resource().
The result is not optimal setup in the number of used MTRRs, but
continue with this approach until MTRR algorithm is improved.
Change-Id: I63c8df19ad6b6350d46a3eca3055abf684b8b114
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1373
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reserved memory resources will get removed from memory table at
the end of write_coreboot_table(),
Change-Id: I02711b4be4f25054bd3361295d8d4dc996b2eb3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1372
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
MRC messes with USB devices, so we have to reinitialize
USB debug after MRC has finished.
Change-Id: I45c0a687cebd69d0a31235bb870f8c455f42d4f2
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1377
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit 2d42b34003 changed the
variable MTRR setup and removed compensation of uma_memory_size in
the cacheable memory resources.
Since the cacheable region size was no longer divisible by a large
power of 2, like 256 MB, this caused excessive use of MTRRs.
As first symptoms, slow boot with grub and poor user response.
As a solution, register the actual top of low ram with ram_resource(),
and do not subtract the UMA/TSEG regions from it.
TSEG may require further work as the original did not appear exactly
right to begin with. To have UMA as un-cacheable, use uma_resource().
Change-Id: I4ca99b5c2ca4e474296590b3d0c6ef5d09550d80
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1239
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
No need for the test, tomk is at most 1GB on these chipsets.
Even if there was no room, adjusting the memory resource would not
not divert accesses in the hardware from DRAM to PCI.
Change-Id: I2213b8d9d2e6ab8da8fd3e8081cc62bb05b6b316
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1369
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
No need for the test, tomk is top of low memory and always below 4GB.
Change-Id: Ifc8f29268b761aa9b07b578673236a673f0c70b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1368
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Our driver infrastructure became more flexible recently.
Make use of it.
These are the low hanging fruits (files with 5 device
variants or more), but there are still lots of files
with less potential for deduplication.
Change-Id: If6b7be5046581f81485a511b150f99b029b95c3b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1358
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Otherwise there is a flurry of TDP changes with suspend/resume
as the kernel powers devices off on suspend and brings them
back online in resume.
This also adds a mutex around the TDP operations since it is
split across two methods and can't just rely on being Serialized.
Change-Id: I7757d3ddad34ac985a9c8ce2fc202e2b2dcb2527
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1348
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The required power MSRs are mirrored in MCHBAR so
it is possible to configure TDP at runtime via ASL.
This adds the required fields and a set of methods to
configure "TDP down" and "TDP nominal". It explicitly
does not support "TDP up" at the moment.
PSSS: method is added to assist in searching the _PSS
table for the appropriate entry that corresponds to the
desired max non-turbo ratio.
STND: Set TDP Down from Nominal. This will limit CPU to
the TDP down configuration by sequencing the required
changes in the right order.
STDN: Set TDP Nominal from Down. This will set the CPU
back to nominal configuration by sequencing the required
changes in the correct (reverse) order.
This does not introduce any functional changes and must
be paired with additional changes to be useful.
The current configured TDP can be checked to see that
the transition to/from a desired level is successful.
> mmio_read8 0xfed15f50
0x00 # TDP-Nominal
> mmio_read8 0xfed15f50
0x01 # TDP-Down
Change-Id: I31a2f30cc9d134cc5eee980ae9288ae45e71c6e6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This maintains a 32bit monotonically increasing boot counter
that is stored in CMOS and logged on every non-S3 boot when
the event log is initialized.
In CMOS the count is prefixed with a 16bit signature and
appended with a 16bit checksum.
This counter is incremented in sandybridge early_init which is
called by romstage. It is incremented early in order notice
when reboots happen after memory init.
The counter is then logged when ELOG is initialized and will
store the boot count as part of a 'System boot; event.
Reboot a few times and look for 'System boot' events in the
event log and check that they are increasing. Also verify
that the counter does NOT increase when resuming from S3.
171 | 2012-06-23 16:02:55 | System boot | 285
176 | 2012-06-23 16:26:00 | System boot | 286
182 | 2012-06-23 16:27:04 | System boot | 287
189 | 2012-06-23 16:31:10 | System boot | 288
Change-Id: I23faeafcf155edfd10aa6882598b3883575f8a33
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1315
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MRC returns specific error codes; print the according error
message if we know what it means.
Change-Id: Iaaf1512b9d577d4291fccfb94d879043ab5b11b5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The count was only incrementing for a wake from S5 and
it was not incrementing in the normal reboot case.
Change-Id: I73bc6db6bd02e6c4677f7e44a5c098c6dcb51747
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/1328
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
MCHBAR 0x5f10[7:0] should be set to 0x30 for ivybridge
and 0x20 for sandybridge. Move this code to ramstage
and set it per-chipset.
Power Aware Interrupt Routing is supported in ivybridge,
enable it and set fixed priority.
Boot on ivybridge device and read MCHBAR 0x5f10:
mmio_read8 0xfed15f10
0x30
And verify PAIR is enabled (bit4=1):
mmio_read8 0xfed15418
0x24
Change-Id: If017d5ce2bd5ab5092c86f657434f2b645ee6613
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1303
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Ivybridge B0+ CPUs are capable of supporting multiple TDP levels.
This complicates the default case because now the registers that
were reporting max non-turbo ratio are reporting that value for
the highest possible TDP level.
For now this change just forces everything to use the Nominal TDP
values instead of the higher (or lower) levels.
- When building P-state tables, determine the P[1] (max non turbo)
ratio based on the Nominal ratio if available.
- Set the turbo activation ratio to the Nominal max ratio.
- Mirror the power level settings in new MCHBAR register after
they are written, which happens after BIOS_RESET_CPL is set.
- Set the current ratio to Nominal ratio at boot.
1) Verify that P-state table is generated properly with
P[0]=1801MHz (ratio 0x1C) and P[1]=1800MHz (ratio 0x12)
PSS: 1801MHz power 17000 control 0x1c00 status 0x1c00
PSS: 1800MHz power 17000 control 0x1200 status 0x1200
2) Verify power limits in MCHBAR match PKG_POWER_LIMIT:
> rdmsr 0 0x610
0x800080aa00dc8088
> mmio_read32 0xfed159a4
0x000080aa
> mmio_read32 0xfed159a0
0x00dc8088
3) Verify turbo activation ratio is set to nominal ratio:
> rdmsr 0 0x64c
0x0000000000000012
4) Check that proper ratio was set at boot on one core only:
> grep 'frequency set to' /sys/firmware/log
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
model_x06ax: frequency set to 1800
Change-Id: I592e60a7740f31b140986a8269dca91b4adbb270
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1304
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and don't require it to specify a cache type.
This function is only used on romcc boards, and should go away
(because all boards should be switched to CAR)
Change-Id: Ic32ca3be1afffc773c72c140e88b338d48a0c8ca
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1288
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On systems with socketed CPUs we want to be able to
drop in a Sandy Bridge or Ivy Bridge CPU without recompiling the
firmware. Hence, detect the north bridge dynamically. In order
for this to work, we need Ivy Bridge MRC and coreboot configured
for Ivy Bridge.
Change-Id: I635bef2c61d47d36a3fdd87f8ecb6e69097ba969
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1281
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The function is empty (a left-over from i945) and should be removed.
Change-Id: I91e573b5e37cb9133ea1037aef7e6daf3c292864
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1290
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This lets the SPI driver and the LPC driver know about HM70 and NM70.
Change-Id: Id2f1e0e5586a2f7200b2d24785df3f2be890da98
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1300
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Right now, if we have an unknown PCH, coreboot will print something like
this:
PCH type: Unknown rev id 4
Instead, it should also print the PCI ID of the device, so we can add it
to the list of known PCHes.
Change-Id: Ib0b96e287c36d2895d1287b1734ca13d75e7985a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1287
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This is as per Intel's suggestion on how to display their name strings.
Change-Id: Ie82341305e58baa8041e50a61a11b395fa7d9582
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1298
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
When no valid MRC cache area is found, the mrc_cache data structure
was used without prior initialization. This sometimes caused a long
delay when booting because compute_ip_checksum would checksum up to
4GB of memory.
Change-Id: I6a0ca1aa618838bbc3d042be425700fc34b427f2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1277
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- The unneeded poll on non-MT force-wake bit was timing out
and causing the gma_pm_init_pre_vbios() function to exit
early so it was not preparing PM registers properly.
I changed the gtt_poll() calls to not return on timeout
unless it can't proceed so we don't see half-initialized
registers.
- RC6+ (Deep Render Standby) is not working reliably so we
can just enable RC6 in the BIOS and let the kernel decide
if it wants to enable RC6+ later.
This Kernel message is new in kernel 3.4:
[drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
Change-Id: I69d005ba56be8c7684a4ea1133a1d761f7c07acc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1268
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's shut down, but UMA memory is not reclaimed. A later extension
could optionally do the magic register dance that allows initialization
of IGD as secondary graphics device.
Change-Id: I2a92bb71755005b886a8e1825325c678a9991bf2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1252
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use of the uma_memory_base and _size variables is very scattered.
Implementation of setup_uma_memory() will appear in each northbridge.
It should be possible to do this setup entirely in northbridge
code and get rid of the globals in a follow-up.
Change-Id: I07ccd98c55a6bcaa8294ad9704b88d7afb341456
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The current code didn't reserve static resource the right way.
Also reduce TOLM to 0xd0000000, because those boards have so many PCI
devices that 0xe0000000 isn't sufficient.
Change-Id: Ia75a81905eea1a096aed464b63ac154e044bc99c
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1220
Tested-by: build bot (Jenkins)
Don't stop if RAM init fails at first try. It's better to restart
and try again instead of failing on the first try if the second
try would have worked.
Change-Id: Ib5660265d5b10a01588f2e4022dac2ee34f2c6d0
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1191
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
This is mostly necessary for reboot, but it doesn't hurt the boot process.
On reboot explicitely reset the integrated graphics, otherwise the VGABIOS
might not be able to reinitialize it properly, and you either have a still
of the last pre-reboot image, garbage or an empty screen, but no text-mode.
Change-Id: Ic3d6932fbaf720d88daaac7e4b09c3c0b9f0b0e2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1178
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
As Mathias Krause pointed out, using movw/outw on %al is clearly invalid.
Let's do another typo fix...
Change-Id: Ib95832a11097f599a236ab30c64c26ef429a1699
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1119
Tested-by: build bot (Jenkins)
Reviewed-by: Mathias Krause <minipli@googlemail.com>
Peter and Ron pointed out two typos. They have no side effects, but
it's still worth to fix them.
Change-Id: I9aecccdbc72beb2623fbe558a06e4f1b050f6e74
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1117
Tested-by: build bot (Jenkins)
Not doing a hard reset leaves the BOFL0 register cleared, which
prevents the BSP selection from working. To make sure we start
with known values, use the SPAD0 register for soft reset detection.
If there's a value other than 0, do a hard reset.
Change-Id: I390e3208084cfd32d73cce439ddf2bc9d4436a62
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1103
Tested-by: build bot (Jenkins)
Originally, ChromeBooks would get the offset of the MRC cache
from an entry in the u-boot device tree. Not everyone wants to
use u-boot on Sandybridge systems, however.
Since the new code (based on Kconfig) is now fully working, we
can drop the u-boot device tree remnants.
Change-Id: I4e012ea981f16dce9a4d155254facd29874b28ef
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1051
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The MRC region is described by Kconfig variables, no further math
or parsing is required at this point.
Change-Id: I290d8788b69ef007e9ea2317ce55aefa2d791883
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1046
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Requirements:
- must be in ramstage (locking flash while executing code from there
might not work)
- must be after cbmem is reinitialized (so the mrc cache copy of the
current run can be found)
Change-Id: I8028fb073349ce2b027ef5f8397dc1a1b8b31c02
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1002
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Separate Sandybridge from ChromeOS a bit
The Sandybridge code depends on chromeos features a whole lot.
As a first step, provide a code path to look up the MRC cache
without depending on u-boot.
- Move mrc cache handling to separate file
This enables us to handle the MRC cache from ramstage,
where we can write the flash safely (eg. to update the
cache).
Also teach it to lookup the current MRC cache from CBMEM,
as the original data block isn't available anymore.
After all the preparations, finally write to the SPI
as necessary. It's a simple round robin wear levelling
that erases the entire MRC cache region when it's full
and starts from the beginning.
Change-Id: I4751385574cf709b03d5c9d153b7481ffc90ce12
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1001
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This fixes my build when specifying an absolute path to the binary.
Change-Id: I95fb3960be70f78146c6afeb9cc777dccdca6b5b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/987
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It is important to have the system configuration reported as early as
possible to have a better idea what exact chipset the platform is
running with.
This change adds code to have an early coreboot module report the CPU
and PCH information. CPU info includes the 32 bit feature information
word, the symbolic processor brand string, and information about some
features support, as obtained through CPUID instructions.
The PCH information includes the symbolic device name and PCI device
version.
Change-Id: If6c21ad5ffb76d7d57d89f4f87d04bdd7192480a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/975
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- New table for GT1
- Updates to GT2 17W table
- New table for GT2 35W SKU
- New table for GT2 Other
This also includes a workaround to poll on a different register
when deasserting force wake. On some SKUs the kernel is hanging
when bringing up graphics unless this register is also polled.
Change-Id: I2badf62b464e901cfb0eaf4fc196f59111c71564
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/974
Tested-by: build bot (Jenkins)
- Add config options to set backlight registers
- Update powermeter weight tables for IvyBridge GT1 and
add a new table for GT2 SKU
- Fix a few registers used during GPU PM init sequence
Change-Id: I1500bc07e3ba1bc10c77e7856089e716489dc07a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/973
Tested-by: build bot (Jenkins)
This is done inside the SystemAgent binary on Ivybridge.
Change-Id: I8fb0f593a65a4803e160b284c21b9d5021e2e4a0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/970
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The ASPM setting for the Direct Media Interface should no longer be done on
Ivybridge/PantherPoint based systems.
Change-Id: Id30de1beb1b162564048e76712736ccf7049dc7c
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/969
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This fixes a few cosmetics with the following three boards:
- Intel Emerald Lake 2
- Samsung ChromeBook
- Samsung ChromeBox
The following issues were fixed:
- rely on include path in ASL code instead of specifying relative
paths
- use updated ALIGN_CURRENT in acpi_tables.c
- use preprocessor defines instead of hard coded values where possible
Change-Id: Ia5941be3873aa84c30c13ff2f0428d1c52daa563
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/963
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
This code is still using libfdt which was denied for inclusion
in coreboot, so it won't compile as is.
Without MRC cache, waking from suspend won't work, and cold boots are
significantly slower (adds around 300-400ms per channel IIRC).
A rework of this code is currently in the works, but will take a little bit
more time (and should not hold back the mainboards being merged)
Change-Id: Ifb9e7d7b86c1f52378803a748810da0d51b58384
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/948
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- When calling map_oprom_vendev() the vendor ID and device ID
are joined into a 32 bit value. They were reversed from the
order that I would have expected - Device ID as the high 16 bits
and the Vendor ID as the low 16. This patch reverses them so
so that the the dword comparison in map_oprom_vendev() matches
what's entered into Kconfig for vendor,device.
- Change files calling map_oprom_vendev()
Change-Id: I5b84db3cb1a359a7533409fde7d05fbc6ba3fcc4
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/938
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Cougar Point southbridge does udelay in SMM, hence add it on Sandybridge
systems.
Change-Id: I6e5520ca27e7c6eaae632992fb68612067bc1e30
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/937
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
No longer include northbridge files directly in the source for
mainboard romstage.c and fix includes.
Also make required adjustments to function declarations.
Change-Id: Iafdcc0766ed44c64cc628e5935eef2c6372f5f22
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/906
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It takes about 3 seconds to scrub 8GiB DDR266 RAM.
After ECC scrub XIP cache is disabled for system stability. There is
very little to do in romstage after ECC scrub, especially when RAM
debug messages are turned off. So the delay caused by this is hardly
noticeable.
Cache for complete ROM is re-enabled before ramstage is decompressed,
and it has no unstability issues. So the code required to re-enable
cache for ROM currently already exists in cache-as-ram_ht.inc.
A Kconfig option HW_SCRUBBER enables the scrub to be run on hard
reboots and power-ons.
Change-Id: Icf27acf73240c06b58091f1229efc0f01cca3f85
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/905
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Drop comments (from e7501 era) which no longer seem to apply with
e7505. Write the semi-constant D0:F0 table as code. Some register
settings seem to be in different order compared with vendor BIOS,
and will be handled by follow-up patches.
Split RCOMP register copy function in two parts.
Drop some uses of inline and local_mdelay().
Change-Id: I8739d3b2bbad5861118e8b16ccea1dd86991204f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/896
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Makes the code a bit more readable, IMO. There is no clean way
to implement this as the affected registers are undocumented.
Seems ROMCC cannot handle the enum. Also any of my future changes
would not be even abuild tested as there is no longer a board with
ROMCC and this chipset. E7505 chipset is CAR only from now on.
Change-Id: I0e2d8ba0c7ed7cce46d9eafb8d8badf04cf75f7a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/895
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some places still hardcoded the address instead of using IO_APIC_ADDR.
Change-Id: I3941c1ff62972ce56a5bc466eab7134f901773d3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix delay loop comments. Time waited and the comments did not match
in the origin (e7501), so delays currently "just work".
Move reset detection to main raminit and don't use generic
sdram_initialize for now, as there are local debug
functions I need to use. Fix AOpen respectively.
Disable ecc scrub, until I have it fixed for cache-as-ram use.
Change-Id: I0529297f43c565d30b5fb7d1836700278ac029c4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/883
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Drop maybe-prefix in registers and tables.
Have a name in place of PCI_DEV(x,y,z) to avoid confusion.
Change-Id: I88f51b50d7fd83294aa14455a83418630e1bab85
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/882
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use NORTHBRIDGE_INTEL_I945 to select the driver directory for build.
Use _SUBTYPE_945GC and _SUBTYPE_945GM to define at compile-time
which model of I945 the driver is built for.
Change-Id: I11b1e0998d0fc28f8946bad4f0989036a9b18af4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/684
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Also mark the corresponding lint test stable.
Change-Id: Ib7c9ed88c5254bf56e68c01cdbd5ab91cd7bfc2f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/772
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current directory is always part of the search path of cpp when
using #include "..."
Change-Id: I74fe39e0c79835e4b9a927afcbeab21040d8ae52
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/648
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the spirit of the earlier renames.
Change-Id: I458a42c79a164483120169d1822ffa6861cc3aff
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If both FSBs on i5000 are equipped with CPU packages, one CPU
from each package is elected as BSP. To prevent races between
both BSPs, hlt the second BSP.
Change-Id: I6bfcb17d34e9f028280acff1694309e37307ec21
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/615
Tested-by: build bot (Jenkins)
