| Age | Commit message (Collapse) | Author |
|---|
|
Fix regression, S3 resume not working on sandy/ivy after commit
9d6f365 ACPI S3: Remove HIGH_MEMORY_SAVE where possible
There is some 20ms delay with ACPI S3 wakeup time due to MTRR setup
being done after the backup copy. Moving to RELOCATABLE_RAMSTAGE fixes
this delay by removing need of this backup entirely.
Change-Id: Ib72ff914f5dfef8611f5f6cf9687495779013b02
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15248
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
These settings should be always made by the firmware, no matter if we
set up graphics or not. It looks like Linux doesn't even know these
registers.
The values are taken from the PRMs for Sandy Bridge and Ivy Bridge [1,
2]. They match the settings that were done in the native graphics path
for Ivy Bridge. I expect the differences to be an update (i.e. the set-
tings we did on the Sandy Bridge path were just outdated). Also, these
settings affect the PCH and not the CPU which are independent from each
other.
[1] Intel® OpenSource HD Graphics Programmer’s Reference Manual (PRM)
Volume 3 Part 3: PCH Display Registers (SandyBridge)
Doc Ref #: IHD-OS-V3 Pt3 – 05 11
https://01.org/sites/default/files/documentation/snb_ihd_os_vol3_part3.pdf
[2] Intel ® OpenSource HD Graphics Programmer’s Reference Manual (PRM)
Volume 3 Part 4: South Display Engine Registers (Ivy Bridge)
Doc Ref #: IHD-OS-V3 Pt 4 – 05 12
https://01.org/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf
Change-Id: I83cc90c7558b93273a727f332fb0d8ced47ed70e
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17073
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I2b8c4ef75cca9f9d5251789cda4187a02076b69d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16964
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
An epic battle to fix Nehalem finally ended when we found an odd mask
set in SMRR. This was caused by a wrong calculation of TSEG size. It
was assumed that TSEG spans the whole space between TSEG base
and GTT. This is wrong as TSEG base might have been aligned down.
TEST: On X201, copied 1GiB from usb key to sd-card and verified.
Change-Id: Id8c8a656446f092629fe2517f043e3c6d0f1b6b7
Found-by: Alexander Couzens, Nico Huber
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: Ib06ecd083f00c74f1d227368811729d2944dd1ef
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16851
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Iea0352f85f4d5f47fc906edbe625e7bbf3f03afd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16863
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
Compilation (w/o native raminit) fails due to missing include
Change-Id: Ic79a77006257b32e0181c88c4e24d7c1f5c5f7ce
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/16735
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Padding the VBT id string is now done automatically.
Change-Id: I8f9baf7b1585026bc29b82d07e451aa11e284ffb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16740
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
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>
|
|
Change-Id: I53208ce5db06d2c65f954e6d59222924ab87722e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16304
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
These non-ascii & unprintable characters aren't needed.
Change-Id: I129f729f66d6a692de729d76971f7deb7a19c254
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15977
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I5aa27f06f82a8309afb6e06c9e462e5792aa9986
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15940
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@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>
|
|
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>
|
|
Reading cpuid leaf 0 is incorrect for testing cpu family.
Use leaf 1 instead. See Intel SDM 2a Table 3-17.
Change-Id: Ib2c95cdd1fb93db06a08ecd7266f6b88700caf83
Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-on: https://review.coreboot.org/15346
Tested-by: build bot (Jenkins)
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
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>
|
|
Change-Id: Ib3250677ee926deaa957c83aca7479eb0159358c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15231
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>
|
|
Simplify calculation of value.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
Change-Id: I3ecd12c431b46a8d2218f33d7eb3e10de3bcd61d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15181
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
Change-Id: I3c517fc55dd333b1a457324f1d69aeb6f70acec2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15197
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.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>
|
|
Instead of hardcoding the PCI mmio size read it from devicetree.
Set a default value of 2048 MiB and 1024MiB for laptops without
discrete graphics.
Tested on Sandybridge Lenovo T520.
Change-Id: I791ebd6897c5ba4e2e18bd307d320568b1378a13
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15140
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Remove code duplication and use the common function
store_current_mrc_cache instead.
No functionality is changed.
Tested on Sandybridge Lenovo T520.
Change-Id: I4aa5463f1b1d5e1afbe44b4bfc659524d86204db
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15074
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Items under DEVICE_SPECIFIC_OPTIONS got selected without
the driver being selected.
Change-Id: I1797fa6175620a9291873559a6308eaea85a090e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14823
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The PLL will never lock if the requested frequency is already set.
As the fallback may request the same frequency again exit early
to prevent a hang.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: I625b2956346d8c50cca84def6190c076bf99dbec
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14174
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add the following fallbacks:
* Try decreasing clock frequency.
In case of DDR1600 the next possible value of DDR1333 is being used.
* Try decreasing clock frequency.
In case of DDR1333 the next possible value of DDR1066 is being used.
* Disable failing channel.
The system may be able to boot with a single channel enabled.
The fallbacks are untested.
Change-Id: I3be7034ad25312b3ebf47a54f335a3893f8d7cc1
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14173
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix regression introduced by:
Ib48fe8380446846df17d37b22968f7d4fd6b9b13
Don't run channel_test on S3 resume as it overrides memory
that might be in use.
Fixes MCE events reported by the GNU/Linux kernel that
low memory has been modified.
Reset on failed s3 resume.
Change-Id: Ibadea286619c7906225f86a93aaa0b4caf26cabe
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14439
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Always use MRC cache if possible.
Added a CRC16 array to make sure the DIMMs haven't been replaced.
In case one of the CRC's doesn't match, start normal RAM training.
Use new fallback in case of broken mrc cache.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Test result:
The system boots a lot faster using the MRC cache.
On swapping DIMMs the CRC16 doesn't match and normal ram training
is started.
Change-Id: Ib48fe8380446846df17d37b22968f7d4fd6b9b13
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14172
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In error case die in top level function.
No functionality is changed.
Change-Id: Ie15b01184d40bdbce20d49dcab2f9fb607068c7a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14171
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Return errors to top level ram init function.
Required by the folowing series to implement a fallback.
No functionality is changed.
On error case the system still halts in every test.
Change-Id: I6278c4a1d7b4a96be8988a60671fc3d72cd6cb3d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14170
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
In order to add a fallback mechanism, move the ram training code
into a new function. This function will be called multiple times
and must return error or success to the calling function.
Change-Id: I5ee1b3a528290d8252d236b9152b81291736958a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14169
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It's required to store the dimm_info in ramctr_timing as only ramctr_timing
is written to mrc cache.
Allows to fill SMBIOS type 17 if mrc cache is used.
Change-Id: I7634b05069df307d471938d9854997a018de81b3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/14168
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The sourcecode is 99% the same. Only two lines differ, but not
in functionality.
Also rename mrccache.c -> mrc_cache.c
Tested-on: boot + suspend/resume on x220
Change-Id: I36f79d066336f223b608c70c847ea6ea6e4ad287
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/14007
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The mrc_cache definition and the struct mrc_container are the same
over all intel platforms.
Change-Id: I128a4b5693d27ead709325c597ffe68a0cc78bab
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/13998
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I2738da99e4651598faeaa228fba447d0872e9ded
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/13999
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Sandy and Ivy Bridge processors use the same socket, and a mainboard
with the socket can support both types of CPUs. However, they use
different native graphics init code for LVDS and cause a crash if
running the wrong code.
This change detects the CPU type and then selects the right code to
run. It will add some more code in ramstage. It also merges the
{SANDY,IVY}BRIDGE_LVDS symbol to one SANDYBRIDGE_IVYBRIDGE_LVDS.
Tested on a Lenovo T520 with i7-2630qm and i7-3720qm
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Change-Id: I4624759f9c92d56d547db1ab4b9a1d611a182a91
Reviewed-on: https://review.coreboot.org/12087
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Fill minimal info required for SMBIOS type 17.
Report
* DIMM size
* channel
* rank per DIMM
* speed in Mhz
* DIMM type
* slot
* manufacturer ID
* serial
Allows dmidecode to print the current RAM configuration.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* Linux 4.3
* dmidecode 3.0
dmidecode output:
Handle 0x0005, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0000
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 8 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: Channel-0-DIMM-0
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Unknown (cd04)
Serial Number: None
Asset Tag: Not Specified
Part Number: F3-1866C9-8GSR
Rank: 2
Configured Clock Speed: 1600 MHz
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Handle 0x0006, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0000
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 8 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: Channel-1-DIMM-1
Bank Locator: BANK 0
Type: DDR3
Type Detail: Synchronous
Speed: 1600 MHz
Manufacturer: Unknown (cd04)
Serial Number: None
Asset Tag: Not Specified
Part Number: F3-1866C9-8GSR
Rank: 2
Configured Clock Speed: 1600 MHz
Minimum Voltage: Unknown
Maximum Voltage: Unknown
Configured Voltage: Unknown
Change-Id: I4e5f772d68484b9cb178ca8a1d63ad99839f3993
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13852
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Instead of hardcoding the maximum supported DDR frequency to
800Mhz (DDR3-1600), read the fuse bits that encode this information.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: I515a2695a490f16aeb946bfaf3a1e860c607cba9
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13487
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The code can't handle cyclic zero runs. Make sure it will never
wrap around by setting the top-most bit to constant one.
Fixes "Mini channel test failed (2)".
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: I55e610d984d564bd4675f9318dead6d6c1e288a3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13853
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
I first found the missing of #include guards when I tried to include
both sandybridge/gma.h and sandybridge/sandybridge.h, but
sandybridge.h includes gma.h in it and gives a compile error.
Change-Id: I13fdb8014b82e6065be2064137b7ea10062deaca
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/13775
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Improved version of
I1a115a45d5febf351d89721ece79eaf43f7ee8a0
The first version wasn't well tested due to the lack of hardware
and it was to aggressive.
With timC being direct function of timB's 6 LSBs it's critical to match
timC and timB.
Some tests increments the value of timB by a small value,
which might cause the 6bit value to overflow, if it's close
to 0x3F.
Increment the value by a small offset if it's likely
to overflow, to make sure it won't overflow while running
tests and bricks the system due to a non matching timC.
In comparission to the first attempt, only 4 out of 128 timB values
are considered bad.
Needs test on real hardware !
Fixes a "edge write discovery failed" on my test system.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: If9abfc5f92e20a8f39c6f50cc709ca1cedf6827d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13714
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ib73abb0ada7dfdfab3487c005719e19f51ef1812
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: https://review.coreboot.org/13779
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Some vendors store lower frequency profiles in the regular SPD,
if the SPD contains a XMP profile. To make use of the board's and DIMM's
maximum supported DRAM frequency, try to parse the XMP profile and
use it instead.
Validate the XMP profile to make sure that the installed DIMM count
per channel is supported and the requested voltage is supported.
To reduce complexity only XMP Profile 1 is read.
Allows my DRAM to run at 800Mhz instead of 666Mhz as encoded in the
default SPD.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
Change-Id: Ib4dd68debfdcfdce138e813ad5b0e8e2ce3a40b2
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13486
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
Use printram() in more places and use printk() only where
it makes sense.
Remove spamming "MRd: %x <= %x\n".
Use common syntax for timing output.
Change-Id: I38965967a029994112d7ab63afd4d9968a7728c5
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13414
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Issue observed:
The PCIe Root port shows up in GNU/Linux but no PCIe device
is being detected.
Test system:
* Gigabyte GA-B75M-D3H (Intel Pentium CPU G2130)
* Lenovo T530 (Intel Core i5-3320M CPU)
Problem description:
The PEG Root port link training on Ivy Bridge needs to be manually started.
Problem solution:
The bits are set in early_init to meet PCIe reset timeout of 100msec.
The bits should be set in PCI device enable function, but this causes the
PCI enumeration to not detect the card, as it's still booting. Adding
a fixed delay of 100msec resolves this problem, but this would
increase boot time.
Read the PCI base revision mask to make sure it's any IvyBridge CPU.
Don't run the code on MRC path as it has its own PEG initilization code.
Tested with:
* Nvidia NVS 5400M (PCIe2)
* ATI Radeon HD4780 (PCIe2)
* Nvidia GeForce 8600 GT (PCIe1)
Untested:
* PCIe3 devices
Final test results:
The PEG device shows up under GNU/Linux and can be used without issues.
Change-Id: Id8cfc43e5c4630b0ac217d98bb857c3308e6015b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/11917
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Use shared gpio code from common folder.
Bd82x6x's gpio.c and gpio.h is used by other southbridges
as well and will be removed once it is unused.
Change-Id: I8bd981c4696c174152cf41caefa6c083650d283a
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13614
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It looks like the falling timing was missing the shift offset.
Not sure if this was intentional, I guess not.
Tested on my hardware and produced no regressions.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Please test on real hardware !
Change-Id: Id8c60217093a48bf322f406ea258c10a02c936e8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13682
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Otherwise the image is simply unusable.
Change-Id: I1e2562ba17279d14dc73b05e4f8fa493e06fbcd2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13699
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Tested by making lenovo x230 configurable despite pretty MRC bugs.
Change-Id: Ia2a123f24334f5cd5f42473b7ce7f3d77c0e65b7
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13658
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I11e09804ed1d8a7ae8b8d4502bd18f6be933f9fa
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13656
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In the same time remove few native gfx options which were improperly set
and only added dead code to the binary.
Change-Id: I4ed3fec03a1655ae0a779c3aa3845de273cb12e1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13649
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
This is needed for stout EC init.
Change-Id: I5c73499c17763229840152a473a2d820802ee2f6
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13535
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This reverts commit 0e06f5bd70b45fd330d8dfb1dc77cce043caf841.
It breaks gm45 and also does some magic without being asked too. It
disables bridge devices permanently if no device was found on the se-
condary bus. In a simple notebook world this might be ok, but it breaks
hot-plugging and late detection (if a secondary bus device comes up too
slow for the firmware to detect and the OS has to enumerate it).
Change-Id: Ia2010640d7c55b0bdd44164b81c75dd4be50410b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/13609
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Walk the bus and try to find enabled devices.
Disable the PEG port if no devices are attached.
Change-Id: I67fcc831fd78ecc6dba83f4e0662ec7549cc2591
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/12894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Issue observed:
The system boots with 4G in channel 0 and 4G in channel 1.
The system doesn't boot with any combination of 4G + 1G in
channel 0 and 4G in channel 1.
In both cases DIMM1 failed, while DIMM0 showed no issues.
Problem description:
The CLK to CMD/CTL was off by a half clock cycle.
The find the issue I X-Y plotted timC vs timB for every
lane on the failing rank.
You can see an offset by 32 units for timB, that is not present on
other ranks.
It turns out that the XOVER CMD/XOVER CTL enable bit for DIMM1 was
missing in program_timings(), which caused the clock offset.
Problem solution:
Add two functions to calculate XOVER CMD and XOVER CTL and use both
to set XOVER in program_timings() and dram_xover().
Final testing result:
The system boots with 4G + 1G in channel 0 and 4G in channel 1.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: I88694c86054ade77e9d8bb2f1fdaf7bc559c1218
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13415
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
It break x230 access to channel 1.
This reverts commit 9f1fbb9a3002e8d74d53d7973bd1c7e3d4879238.
Change-Id: I8a3b13d17729f25cea3460ac2f87bca3c193d388
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Count DIMMs on current memory channel instead of all memory channels.
The current code is only able to correctly handle the following memory
configurations:
One DIMM installed in either channel.
Four DIMMs installed, two in each channel.
Two DIMMs installed, both in the same channel.
For systems that have any other configuration the DRAM On-Die-Termination
setting is wrong.
For example:
Two DIMMs installed, one in each channel.
Test system:
* Gigabyte GA-B75M-D3H (Intel Pentium CPU G2130)
Change-Id: I0e8e1a47a2c33a326926c6aac1ec4d8ffaf57bb6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/12892
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
Remove redundant call to dram_mrscommands().
Change-Id: I157915b4432093c556b538433e3337db1e9c525f
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/12891
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The remainder of the divide operation was being placed into a Local,
but was never being used, causing an IASL warning. Since this
field is optional, just remove the Local.
Fixes IASL warning:
dsdt.aml 640:Divide (Multiply (CTDN, 125), 100, Local0, PL2V)
Warning 3144 - Method Local is set but never used ^ (Local0)
Change-Id: I0b43ef638b1bc3e1163c45f31f8da57aa0d39e22
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12706
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
The ALIGN_CURRENT macro relied on a local variable name
as well as being defined in numerous compilation units.
Replace those instances with an acpi_align_current()
inline function.
Change-Id: Iab453f2eda1addefad8a1c37d265f917bd803202
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12707
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Found while doing code review.
Use a function to toggle IO reset signal.
Change-Id: I4cb0885ed9be763fbc4069e4d015a36a7183c823
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11916
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Add lots of comments for better documentation.
Change-Id: Ia203cb649857f979bb6c1c2d405b74f2ccc8f99d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11915
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Fix regression introduced by:
3660c0fc658e4e20ef079f762dfc7ad05c83544c
"northbridge/intel/sandybridge: Enable PEG clock-gating on demand"
Issue observed:
GNU/Linux kernel crashes in earlyinit on systems without PEG devices.
The crash occurs on every boot in different functions.
There's no problem on systems with PEG enabled.
Test system:
* Lenovo T530
* Intel Core i5-3320M CPU
* Fedora GNU/Linux 4.1
* PEG disabled in devicetree
Problem description:
Tests shows that modifing PEG chicken bit or device enable bits
after setting BIOS_RESET_CPL causes random crashes in GNU/Linux.
Problem solution:
Disable PEG devices before setting BIOS_RESET_CPL.
Final testing results:
No more random kernel crashes.
Change-Id: I4a967c2d00d7d1e4426cf5abdd5f616c21557da7
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/12112
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Issue observed:
Coreboot stops at: "Not enough MTRRs available!"
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* ATI Radeon HD4780
Problem description:
In case the IGD does not claim VGA decode, the code path taken results
in an integer overflow as uma_memory_base isn't initialized.
The MTRR assignment will fail, because of invalid memory regions.
Problem solution:
Properly initialize uma_memory_base to prevent possible integer overflow.
Final testing results:
The system boots again with IGD not claiming VGA decode.
Change-Id: I025be23b1defb6155469a3eee66569e49a695e7f
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11918
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Issue observed:
Intel raminit works in about 50% of all test-cases on lenovo x220.
Problem solution:
Prefer a smaller valid value over the measured one for
initial timB timings.
Final testing result:
Tests on x220 shows that the issue was resolved.
The test system booted successfully ten times in a row.
Tests on Gigabyte GA-B75M-D3H revealed no regressions.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMM: "Crucial 2GB 256Mx64 CT2566aBA160BJ"
Change-Id: I1a115a45d5febf351d89721ece79eaf43f7ee8a0
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11248
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
The touched workaround for Sandy Bridge reserves two memory regions that
could cause graphics corruption if mapped by the integrated graphics
device. To the best of our knowledge, the workaround is not needed for
Ivy Bridge revisions.
Tested on kontron/ktqm77 (Ivy Bridge): Booted Linux and checked the
memory regions are not reserved. Couldn't test on Sandy Bridge, due to
lack of hardware.
Change-Id: I4273d1d804b490cf93c23426782eb1ffaf29f7d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12326
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
|
|
Add a DMAR table to advertise IOMMU and IRQ remapping capabilities to
the OS.
Tested with kontron/ktqm77. Under Linux, the table is detected and
interrupt remapping is enabled automatically.
Change-Id: Id6ee601a0a8543ed09c6bb8d308a3a3549fc34e5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12195
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Sandy Bridge and Ivy Bridge processors have two IOMMU units. One for the
integrated graphics controller and one for all other PCI devices. Assign
resources for both IOMMUs and apply some quirks.
Tested with kontron/ktqm77 and a Muen based system that makes use of the
IOMMUs. Not tested on Sandy Bridge, but register dumps show the same
settings that are applied here.
Change-Id: I43b5e20b750e7529f448acac35de173185678fd9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12194
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Issue observed:
In a multi GPU setup (IGD and PEG) the system still uses the IGD.
CONFIG_ONBOARD_VGA_IS_PRIMARY has no effect on Sandy/Ivy Bridge.
Test system:
* Gigabyte GA-B75M-D3H
* Intel Pentium CPU G2130
* ATI Radeon HD4780
Problem description:
The GMA is missing a disable function.
Problem solution:
Add a GMA disable function. Deactivate PCI device until remaining multi
GPU issues are resolved. Do not claim VGA decode any more.
Final testing results:
The system is able to boot using the PEG device as primary VGA
device.
Change-Id: I52af32df41ca22f808b119f3a4099849c74068b3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/11919
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
On Broadwell, this reduces the number of 'remarks' in the IASL build
from 222 to 3.
Fixes these remarks:
Object is not referenced (Name is within method [_CRS])
The ACPI compiler is trying to be helpful in letting us know
that we're not using various fields in the MCRS ResourceTemplate
when we define it inside of the _CRS method. Since we're not
intending to use those objects in the method, it shouldn't be an
issue, but the warning is annoying and can mask real issues.
Moving the creation of the MCRS object to outside of the CRS
method and referencing it from there solves this problem.
This change was made for fsp_baytrail in commit 2eaa0d49
fsp_baytrail: Fix ACPI 'Object is not referenced' warnings
Change-Id: I67a1faf963d1868f4133c7747a43a511cd28a44b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11268
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Consolidate some common (and mostly broken) code. Will try to fix things
in separate commits.
Maybe, igd.asl taken from gm45 (the non-PCH case) could also be used for
i945 and sch. But this needs further investigation.
Change-Id: Id3663bf588458e1e71920b96a3149f96947921e9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11702
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Only one value would work with corresponding gma code currently (which one
depends on board). Going forward, it's possible to compute which number can
be used, so there is no need to keep this info around.
Change-Id: Iadc77ef94b02f892860e3ae8d70a0a792758565d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11862
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Make sure edge write test results are sane.
Check rn.all to make sure rn.start and rn.end are valid.
Most likely the following test is going to fail on the same
rank anyway.
Change-Id: Ifa601406e6c74ceb8d70063be5ce1bf6bc512c18
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11247
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Don't disable PEG bits while turning on IGD.
Fixes PCI device enumeration of PEG devices.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Sidenote: This should be taken from a CMOS option instead.
Change-Id: I2d6522504e4404f2d57f9c319351d08317aefdcb
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11058
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Activate PEG clock-gating only if all PEG devices are disabled.
Fixes system hang when trying to access PEG registers.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Change-Id: I7d62fbb83c16741965639cea1a0e4978d4e3d6da
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11059
Tested-by: build bot (Jenkins)
|
|
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
While the romstage code flow is not consistent across all
mainboards/chipsets there is only one way of running ramstage
from romstage -- run_ramstage(). Move the
timestamp_add_now(TS_END_ROMSTAGE) to be within run_ramstage().
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados. TS_END_ROMSTAGE still present in
timestamp table.
Change-Id: I4b584e274ce2107e83ca6425491fdc71a138e82c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11700
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We don't build-test with native VGA init, so if the code is broken by
a commit, we won't see it when it's guarded by #ifdefs. This has
already happened in the past. Instead of gurading entire files, use
the IS_ENABLED() macro, and return early. This at least enables us to
build-test the code to some extent, while linker garbage collection
will removed unused parts.
BONUS: Indenting some blocks also makes the difference between
framebuffer init and textmode init clearer.
Change-Id: I334cdee214872f967ae090170d61a0e4951c6b35
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11586
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Native VGA init no longer compiles from commit:
* 7dbf9c6 edid: Use edid_mode struct to reduce redundancy
Change-Id: I51a4f4874ce77178cab96651eb7caf2edd862aa2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11491
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The reason for hardcoding the position of the MRC cache was to satisfy
the alignment to the erase size of the flash chip. Hardcoding is no
longer needed, as we can specify alignment directly. In the long term,
the MRC cache will have to move to FMAP, but for now, we reduce
fragmentation in CBFS.
Note that soc/intel/common hardcoding of mrc.cache is not removed, as
the mrc cache implementation there does not use CBFS to find the cache
region, and needs a hardcoded address.
Change-Id: I5b9fc1ba58bb484c7b5f687368172d9ebe625bfd
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11527
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The BOOT_STATE_INIT_ENTRY macro can only be used in ramstage, however
the current state of the header meant bad build errors in non-ramstage.
Therefore, people had to #ifdef in the source. Remove that requirement.
Change-Id: I8755fc68bbaca6b72fbe8b4db4bcc1ccb35622bd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11492
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The Kconfig symbol CACHE_MRC_BIN was getting forced enabled everywhere
it existed.
Remove the Kconfig symbol and get rid of the #if statements
surrounding the code.
This fixes the Kconfig warning for Haswell & Broadwell chips:
warning: (NORTHBRIDGE_INTEL_HASWELL &&
NORTHBRIDGE_INTEL_SANDYBRIDGE &&
NORTHBRIDGE_INTEL_SANDYBRIDGE_NATIVE &&
NORTHBRIDGE_INTEL_IVYBRIDGE &&
NORTHBRIDGE_INTEL_IVYBRIDGE_NATIVE &&
CPU_SPECIFIC_OPTIONS) selects CACHE_MRC_BIN
which has unmet direct dependencies
(CPU_INTEL_SOCKET_RPGA988B || CPU_INTEL_SOCKET_RPGA989)
Change-Id: Ie0f0726e3d6f217e2cb3be73034405081ce0735a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11270
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Found while doing code review.
Simplify the code by using a loop for positive and negative phase
adjustments.
Change-Id: I0980443d0d2815bccef969709fddecc07d61a788
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10890
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Issue observed:
Two memory DIMMs are placed in the same channel, but only one shows up.
The SPD is read and printed, but the first DIMM isn't recognized any more.
Due to an existing but unconfigured memory DIMM the timB test failed.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMMs:
* crucial 2GB 256Mx64 CT2566aBA160BJ
* corsair 8GB CMZ16GX3M2A1866C9
Problem description:
The channel's rankmap was overwritten by the second slot's rankmap.
Problem solution:
Logical OR the channel's rankmap with every slot's rankmap.
Final testing result:
The DIMM is recognized and can be properly configured and used.
The timB test doesn't fail any more.
Change-Id: I17a205ff4d344c13d9ddfe71aaae2f3cef047665
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10960
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Change-Id: Ide0fd757cdd31a5b5ff184f7ab2d48e62ea50015
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/10896
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It never made sense to have bootblock_* in init, but
pirq_routing.c in boot, and some ld scripts on the main
level while others live in subdirectories.
This patch flattens the directory hierarchy and makes
x86 more similar to the other architectures.
Change-Id: I4056038fe7813e4d3d3042c441e7ab6076a36384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10901
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Print the old timB value to observes changes made.
Change-Id: Iecec4918f1d95560b6e7933a169ccce83fcf073d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10891
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Issue observed:
Any memory DIMM placed in channel0 slots stops at "c320c discovery failed".
The same memory DIMM works when placed in channel1 slots.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
* DIMMs:
* elixir 1GB 1Rx8 PC3-10600U M2Y1G64CB88A5N
* crucial 2GB 256Mx64 CT2566aBA160BJ
* corsair 8GB CMZ16GX3M2A1866C9
Problem description:
In case of good timmings (all bits are set) an offset of 3*64 was applied.
The following test (c320c discovery) failed only on those byte-lanes.
Problem solution:
Don't modify timB in case of good timings measured.
Final testing result:
The system boots with every DIMM placed in channel 0 slots.
Change-Id: Iea426ea4470640ce254f16e958a395644ff1a55c
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10889
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Remove whitespace errors.
Change-Id: If69244a5d47424e3e984fdf782ea9d2d3c466d86
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10888
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Add VGA pci device id 0x0152 for Intel IvyBridge CPUs.
Test system:
* Intel Pentium CPU G2130
* Gigabyte GA-B75M-D3H
Change-Id: Ia546fdf0cc3bbd4c0ef6b5fd969232f105bceb22
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10798
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
This fixes building the ELOG_GSMI feature by using the TSC as time source for
the flash drivers.
It's not the most precise clock, but should be good enough for the purpose.
Change-Id: I2d416c34268236228300a9e868628c35e22bf40c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10813
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This reverts commit a3aa8da2acec28670b724b7897ae054592746674.
Chrome OS builds require the monotonic timer API in SMM for ELOG_GSMI,
but sandy/ivy doesn't provide it. The commit tried to work around that
by using generic LAPIC code instead, but this leads to multiple
definition errors in other configurations (and it may be unreliable once
the OS reconfigured the APIC timers anyhow).
This fixes the situation for the non-ELOG_GSMI case (which is more or
less everybody but Chrome OS). ELOG_GSMI requires a separate fix.
Change-Id: If4d69a122b020e5b2d2316b8da225435f6b2bef0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10811
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Found while doing code review.
Rename reg_4004_b30 to cmd_stretch.
Found in 4th-gen-core-family-desktop-vol-2-datasheet.pdf chapter 4.2.1.
Change-Id: Ib07059625ed458332708562e836803f2b587d5d8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: http://review.coreboot.org/10789
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
This fixes an issue with using the flash driver in SMM for writing
the event log through an SMM call.
Change-Id: If18c77634cca4563f770f09b0f0797ece24308ce
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10762
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
