Replace the use of the old device_t definition inside
northbridge/intel/gm45.
The patch has been tested both with the arch/io.h definition of device_t
enabled and disabled in order to ensure compatibility while the
transaction takes place.
Change-Id: I87754799f922cf241fb456071bac04e6fe1eab34
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16402
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/amd/amdht.
Change-Id: I7dfb8f001504c691aeddf1bfbc3be05cc7d31ce4
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16468
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/amd/amdk8.
Change-Id: I5209dd309f0685f83d8a468c50309d5fda77973a
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16467
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/amd/amdfam10.
Change-Id: I5037feb31c51d06ccc672b0771d5d6e8c0dac949
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16466
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Replace the use of the old device_t definition inside
northbridge/intel/x4x.
Change-Id: I65cd02eacf57cb41ded434582ca6e9d9f655e6ea
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16472
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/intel/i5000.
Change-Id: Ic049d882ef22f117ee52ba497351f548e2355193
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16471
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/intel/e7505.
Change-Id: Ie819f380ec06667e11bcff3e9e993126a86b2c89
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16469
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/intel/fsp_rangeley.
Change-Id: I4c1e6af64fe70211db2fafdba9f39182dfea66fc
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16470
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Previously the ME PCI interface (HECI) was being reported as present in
the DMAR ACPI table even when ME firmware was missing or the PCI device
was hidden and HECI would be unresponsive.
Now we check via the PCI config space itself to verify if the HECI
is present or not.
Note that this test could fail if ME firmware is present but
HECI is disabled in devicetree, because it would not advertise that the HECI
exists even though there is a running ME. Perhaps this behaviour is desirable
because in this case you won't see the HECI in the lspci tree anyway.
Change-Id: Ib692d476d85236b4886ecf3d6e6814229f441de0
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/16330
Tested-by: build bot (Jenkins)
Reviewed-by: Swift Geek <swiftgeek@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This is necessary for PCI express graphics card add-ons,
otherwise the pci allocator cannot fit the mmio for the
add on card into the space it has available and the OS
turns off the card. Old value was 1GiB.
Change-Id: I606994501b15e636fe209d1ed4b3d3f73b42bf5c
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/16494
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No more hang on DMI init when wait for DMI is re-enabled.
Previously the virtual channel arbitration table was not being
set up in the south/north bridges causing invalid DMI state.
This has been tested on GA-G41M-ES2L with patches following.
An NVIDIA GT218 card was detected by the OS and displayed using
the nouveau driver with no blobs.
Change-Id: I35e03c40f5f7aa4915afd5d26db7ab053abcf0cd
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/16491
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
According to "G45: Volume 3: Display Register
Intel ® 965G Express Chipset Family and Intel ®
G35 Express Chipset Graphics Controller" some registries
are set incorrectly in gm45/gma.c.
Some values are changed after comparing them with the values
the i915 linux kernel (3.13 was used) module sets while modesetting.
The values were obtained using 'intel_reg' from intel-gpu-tools,
during a normal boot and with 'nomodeset' as a kernel argument.
Some registers that don't exist on gm45 are set in gma.c, which is
probably the result of copying code from a more recent intel
northbridge.
The result is that that gm45 laptops with wxga displays still work as
before. gm45 laptops with wxga+ or higher resolution now just work,
where previously a black screen was shown.
TEST: build with native graphic init and flash on a gm45 target, like
lenovo x200.
Change-Id: If66b60c7189997c558270f9e474851fe7e2219f1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16217
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Remove an unusued function declaration that caused problems while
compiling the target.
Change-Id: Idfd73693e9b0e1777cafa4706113fde394e95795
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16435
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/intel/i945.
The patch has been tested both with the arch/io.h definition of
device_t enabled and disabled in order to ensure compatibility
while the transaction takes place.
Change-Id: I041c150a7b50261e26955ad9287ef05b9a06e412
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16371
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Replace the use of the old device_t definition inside
northbridge/intel/sandybridge.
The patch has been tested both with the arch/io.h definition of device_t
enabled and disabled in order to ensure compatibility while the
transaction takes place.
Change-Id: I35cc76ec7b6baa216666d06f6f325f43ac69067e
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16409
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On i945 the vram size is the default 8mb. It is also possible
to set it 1mb or 0mb hardcoding the GGC register in early_init.c
The intel documentation on i945, "Mobile Intel® 945 Express Chipset
Family datasheet june 2008" only documents those three options.
They are set using 3 bits. The documententation also makes mention
of 4mb, 16mb, 32mb, 48mb, 64mb but not how to set it.
The other non documented (straight forward) bit combinations allow
to change the VRAM size to those other states.
What this patch does is:
- add those undocumented registers with their respective vram size to
the i945 NB code;
- make this a cmos option on targets that have this northbridge.
TEST: build, flash to target, set cmos as desired and boot linux.
On Debian it can be found using "dmesg | grep stolen".
NOTE: dmesg message about reserved vram are quite different depending
on linux version
Change-Id: Ia71367ae3efb51bd64affd728407b8386e74594f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/14819
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This allows to set the preallocated memory for the IGD on x4x
using a cmos option.
If no cmos option is found a default value of 64M is used.
TESTED most options on ga-g41m-es2l with 2G dimm in one slot and 2x2G.
352M also works in contrast with gm45 where it is known to cause issues
with certain ram combinations.
Change-Id: I9051d080be82f6dfab37d353252e29b2ed1fca7f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/15492
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Intel documtentation, "Intel ® 4 Series Chipset Family"
mentions the possibility of 1, 4, 8 and 16M of preallocated
memory for the IGD, but does not document this.
This allows to set those undocumented values.
TESTED on ga-g41m-es2l with 2G dimm in one slot and 2x2G.
Change-Id: I92beb8d78907d4514a5aaf69248dd607dcf227c0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/15491
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now hardcode maximum memory frequency capability to 800MHz, as
all chipsets in x4x family support PC2-6400 according to the datasheet.
CAS latency detection also relies on this, and has been cleaned up.
Ram initialization does not work with FSB 1333MHz / DDR2 800MHz combination,
so disable this combination for now, and reduce to 667MHz instead.
Still don't know why this is the case, but FSB1333/667 works.
These changes should now allow existing configurations to continue working,
while providing support for previously unworking configurations, due to
previous buggy CAS latency detection code.
TESTED: on GA-G41M-ES2L
CPU: E5200 @ 2.50GHz (FSB 800MHz)
2x 1GB 667MHz hynix worked @ 667
1x 2GB 800Mhz ARAM worked @ 800
1x 1GB 667Mhz StarRam worked @ 667
2x 2GB 800Mhz (generic) worked @ 800
Change-Id: I1ddd7827ee6fe3d4162ba0546f738a8f9decdf93
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/15818
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Match the definition and use of these variable with haswell, such that
DCACHE_RAM_MRC_VAR_SIZE is not included in DCACHE_RAM_SIZE.
Change-Id: I5af20f63cd0cb631d39f7c7fe0e2a99ebd3ce986
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15761
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix and use the failsafe CAS detection logic rather than
recalulating the values from raw SPDs.
Tested on GA-G41M-ES2L with 2x2GB DDR2-800 DIMMs
(which worked before and still work)
Change-Id: I6af0f1705d099f7bcbff8c9baa94a68dae689e01
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/15726
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
If S3 support was implemented for this platform later on, use
romstage handoff structure instead.
Change-Id: I03c1e07a7fcc17c27203d0c4e32e3958f2ba5273
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15716
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Damien Zammit <damien@zamaudio.com>
If S3 support was implemented for this platform later on, use
romstage handoff structure instead.
Change-Id: Ib0cf3ad41753baee26354c5ed19294048e7fb533
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15715
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Previously, any 800MHz DIMMs were being slowed to 667MHz
for no reason other than there was a bug in the maximum
frequency detection code for the MCH.
Change-Id: Id6c6c88c4a40631f6caf52f536a939a43cb3faf1
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/15257
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Broken with commit:
5c10abe nb/intel/sandybridge: increase MMCONF_BASE_ADDRESS
Available sandybridge/systemagent-r6.bin has MMCONF hard-coded
at some places and samsung/lumpy fails at boot here:
CBFS: Locating 'mrc.bin'
CBFS: Found @ offset 9fec0 size 2fc94
System Agent: Starting up...
System Agent: Initializing
These are the last lines as captured over USB debug.
Change-Id: I441847f0e71a5e1be9c8ef6a04a81eb7bdd8a6d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15328
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of programming unsupported CAS use the highest supported
value. Start at DDR3 maximum of CAS 18T.
Increase error message verbosity level.
Useful for overclocking.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
Allows to run a DDR3-1600 DIMM at 933Mhz.
Change-Id: I2e8aadd541f06fa032ad7095c9a2d5e3bb7613f3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15217
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Calculate the value from current DDR frequency.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
Change-Id: I57ffbfeb291fc2fede278d18527993e7432e9bd8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15184
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Set max_mem_clock_mhz in devicetree to 933Mhz.
Allows to run the memory at up to DDR3-1866.
The same frequency was allowed within the first vendor bios,
but Lenovo than decided to limit it to DDR3-1333.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
The RAM is now running at DDR3-1600 instead of DDR3-1333.
This gives about 4% performance increase in glmark2 using the
Intel GPU.
Change-Id: If15be497402d84a2778f0434b6381a64eda832d6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15158
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15190
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
