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
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/15818
Tested-by: build bot (Jenkins)
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Change-Id: I1ddd7827ee6fe3d4162ba0546f738a8f9decdf93
Reviewed-on: https://chromium-review.googlesource.com/363934
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Allow bootblock to get access to the static device tree like
other early stages. device_romstage.c was renamed to
device_simple.c to better articulate the usage since it's not
just being used in romstage.
BUG=chrome-os-partner:55357
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15837
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins)
Change-Id: I3d63d2754c737cc738c09a3e3b3b468362fb78d1
Reviewed-on: https://chromium-review.googlesource.com/363933
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
All mainboards (nyans) utilizing the cache_policy option
has it set to DCACHE_WRITETHROUGH. This option is for setting
the framebuffer's cache attribute. However, this option is
reliant on an architecture-specific enumeration. Just remove
the option and use DCACHE_WRITETHROUGH across the board. If
someone wants to reconfigure it at a later date one can
introduce a non-architecture specific option.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15838
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6a0848231f5e28d36ec2d56b239bed67619fe5a7
Reviewed-on: https://chromium-review.googlesource.com/363932
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Place a map file for the postcar stage and place it into
build/cbfs/fallback.
TEST=Build and run on Galileo Gen2
Change-Id: I349c06e3c610db5b3f2511083208db27110c34d0
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15845
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363390
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Move the ramstage files to the beginning of the section. Eliminate
duplicate conditionals.
TEST=Build and run on Galileo Gen2
Change-Id: I461a5b78a76bd0d2643b85973fd0a70bc5e89581
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15892
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363389
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Move the postcar commands to in between romstage and ramstage. Add the
stage header.
TEST=Build and run on Galileo Gen2
Change-Id: I530da6afd8ccbcea217995ddd27066df6d45de22
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15844
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363387
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The removal of ELOG_FLASH_BASE and ELOG_FLASH_SIZE resulted
in the FMAP region for the eventlog to be honored. However,
certain systems seem to have a large eventlog region that
wasn't being used in practice. Because of the malloc() in the
eventlog init sequence a large allocation was now being requested
that can exhaust the heap. Put back the 4KiB capacity until
the resource usage is fixed.
BUG=chrome-os-partner:55593
Change-Id: Ib54b396b48e5be80f737fc3feb0d58348c0d2844
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15835
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363386
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
XIP cachelines contain the executable to run, we never want
that to get modified. With the change such erronous writes
are ignored and next cacheline miss will fetch from boot
media (SPI / FWH flash).
Change-Id: I52b62866b5658e103281ffa1a91e1c64262f3175
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15778
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363385
Reviewed-by: Furquan Shaikh <furquan@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
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15761
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363384
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The build fails during postcar when ULZMA compression is not selected.
Fix cbfs.c to support LZ compression for ramstage as well.
The build error is:
build/postcar/lib/cbfs.o: In function `cbfs_load_and_decompress':
/home/lee/coreboot/public/src/lib/cbfs.c:116: undefined reference to
`ulzman'
make: *** [build/cbfs/fallback/postcar.debug] Error 1
TEST=Build and run on Galileo Gen2
Change-Id: I7fa8ff33c0d32e0c5ff5de7918e13e6efb1df38e
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15841
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363383
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Separate NO_XIP_EARLY_STAGES from loading FSP-M into cache-as-RAM.
Quark executes romstage directly from the SPI flash part (in-place),
but loads FSP-M into ESRAM. This split occurs because ESRAM is too
small to hold everything while debugging.
Platforms executing FSP-M directly from the SPI flash need to select
FSP_M_XIP.
TEST=Build and run on Galileo Gen2.
Change-Id: Ib5313ae96dcec101510e82438b1889d315569696
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15848
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363382
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Enable the display of cbmem during romstage and postcar. Add a Kconfig
value to prevent coreboot images from increasing in size when this
feature is not in use.
TEST=Build and run on Galileo Gen2
Change-Id: Ib70ad517ebf7d37a7f46ba503b4432c7c04d7ded
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15842
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363381
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
When we were pushing the updated sdram.c to coreboot.org, the compiler
there found that we were not initializing vref_value_dq in all code
possible code paths.
This patch updates those code paths to halt the system.
Branch=none
Bug=none
Test=Built with coreboot.org toolchain and verified that the compile
errors were gone.
Change-Id: I0ad4207dc976236d64b6cdda58d10bcfbe1fde11
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362726
Reviewed-by: Julius Werner <jwerner@chromium.org>
This allows the board to save the recovery request in case of unexpected
reboots caused by FSP.
With recovery module in vboot handling the saving of recovery reason
across reboots, there is no need to have special fsp reset handling
under soc.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15804
Tested-by: build bot (Jenkins)
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I0b7ce14868a322072d3e60c1dae43f211b43fdbf
Reviewed-on: https://chromium-review.googlesource.com/362976
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On some x86 platforms (skylake, apollolake), we observe reboots at
different steps during the FSP initialization. These additional reboots
result in loss of recovery request because vboot_reference library
clears recovery request on vbnv once verification is complete and it has
made a decision about which boot path to take(normal/dev, slot-a/slot-b,
recovery).
Provide a way to allow mainboards/chipsets to inform recovery module in
vboot2 to save recovery reason to survive unexpected reboots. The
recovery reason is set in vbnv after vboot_reference library completes
its verification and clears the reason in vbnv while jumping to
payload.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15802
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ie96be9aeb42c8209d8215943409e6327d6a8bf98
Reviewed-on: https://chromium-review.googlesource.com/362974
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add recovery module in vboot2 that checks if a recovery request is
pending and returns appropriate reason code:
1. Checks if recovery mode is initiated by EC.
2. Checks if recovery request is present in VBNV.
3. Checks if recovery request is present in handoff for post-cbmem
stages.
4. Checks if vboot verification is complete and looks up selected region
to identify if recovery is requested by vboot library.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I31e332a4d014a185df2434c3730954e08dc27281
Reviewed-on: https://chromium-review.googlesource.com/362972
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Remove unused functions/structures.
2. Add checks for NULL return values.
3. Change prefixes to vb2 instead of vboot for functions used internally
within vboot2/
4. Get rid of vboot_handoff.h file and move the structure definition to
vboot_common.h
5. Rename all functions using handoff structure to have prefix
vboot_handoff_*. All the handoff functions can be run _only_ after cbmem
is online.
6. Organize vboot_common.h content according to different
functionalities.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Reviewed-on: https://chromium-review.googlesource.com/362971
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
All the mainboards share the same config options for CHROMEOS. Instead
of duplicating those in every mainboard, move the CHROMEOS config to SoC
and make it dependent on MAINBOARD_HAS_CHROMEOS.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15822
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: Iafabb6373dfe16aaf0fe2cbc4e978952adeb403e
Reviewed-on: https://chromium-review.googlesource.com/362970
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
All the mainboards share the same config options for CHROMEOS. Instead
of duplicating those in every mainboard, move the CHROMEOS config to SoC
and make it dependent on MAINBOARD_HAS_CHROMEOS.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15821
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I2d54ff6beac9fca7596a8f104e3c1447cada5c05
Reviewed-on: https://chromium-review.googlesource.com/362879
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, on Intel Skylake the uCode binary is added to
CBFS based on the config option CBFS_EXTERNAL_HEADER. But
the entry is missing into the Firmware Interface Table, so
add it there.
BRANCH=none
BUG=chrome-os-partner:55403, chrome-os-partner:53077
TEST=built and verified FIT table has ucode entry.
Change-Id: I7dd7459ff7d2468f0aff66eb3ee9c2e3d7eda501
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15783
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361855
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This device has a built-in keyboard that should be enabled by default
or it will not work in firmware. This was tested to ensure that TAB
(display info) and Ctrl+D (enter developer mode) are functional at the
Chrome OS recovery screen.
BUG=chrome-os-partner:55549
Change-Id: I60156f1fc001b88deac69e03e02e9d8277fbc38d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15782
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362860
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The controller for device mode USB is not plan of record
on apollolake. However, one still needs to configure the
one port to be host mode by default such that the devices
work as expected when plugged into the board.
BUG=chrome-os-partner:54581,chrome-os-partner:54656
TEST=Enabled xdci controller. Used USB type C->A dongle to
check that a mass storage device worked on port 0 on
reef.
Change-Id: Ia9ec5076491f31bc5dc3d534e235fb49f7b2efac
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15781
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362769
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Now that FMAP is a first class citizen in coreboot
there's no reason to have alternate locations for ELOG.
If one wants eventlog support they need to specify the
ELOG entry in the FMAP. The one side effect is that
the code was previously limiting the size to 4KiB
because the default ELOG_AREA_SIZE was 4KiB. However,
that's no longer the case as the FMAP region size is
honored.
Change-Id: I4ce5f15032387155d2f56f0de61f2d85271ba606
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15814
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362768
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The fixed MTRRs cover the range [0:1MiB). While calculating the
variable MTRR usage the 1MiB boundary is checked such that
an excessive number of MTRRs aren't used because of unnatural
alignment at the low end of the physical address space. Howevever,
those checks weren't inclusive of the 1MiB boundary. As such a
variable MTRR could be used for a range which is actually covered
by the fixed MTRRs when the end address is equal to 1MiB. Likewise,
if the starting address of the range lands on the 1MiB boundary
then more variable MTRRs are calculated in order to meet natural
alignment requirements.
Before:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0
0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6
0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0
0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1
0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0
0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6
CPU physical address size: 39 bits
MTRR: default type WB/UC MTRR counts: 7/17.
MTRR: WB selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007ffff00000 type 0
MTRR: 1 base 0x000000007b800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0
MTRR: 3 base 0x0000000080000000 mask 0x0000007fe0000000 type 0
MTRR: 4 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0
MTRR: 5 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1
MTRR: 6 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
After:
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0
0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6
0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0
0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1
0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0
0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6
CPU physical address size: 39 bits
MTRR: default type WB/UC MTRR counts: 6/8.
MTRR: WB selected as default type.
MTRR: 0 base 0x000000007b800000 mask 0x0000007fff800000 type 0
MTRR: 1 base 0x000000007c000000 mask 0x0000007ffc000000 type 0
MTRR: 2 base 0x0000000080000000 mask 0x0000007fe0000000 type 0
MTRR: 3 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0
MTRR: 4 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1
MTRR: 5 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0
BUG=chrome-os-partner:55504
Change-Id: I7feab38dfe135f5e596c9e67520378a406aa6866
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15780
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362845
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Update the write protect GPIO reported in ACPI to GPIO_75.
Also update the controller ID to "INT3452:01" which will
point at the goldmont device and includes write protect GPIO.
BUG=none
BRANCH=none
TEST=verify crossystem output for wpsw_cur.
Change-Id: Id6b172e289976072836746c1814e0300544a06cb
Original-Signed-off-by: sselvar2 <susendra.selvaraj@intel.com>
Original-Reviewed-on: https://coreboot.intel.com/7771
Original-Reviewed-by: Sparry, Icarus W <icarus.w.sparry@intel.com>
Original-Reviewed-by: Petrov, Andrey <andrey.petrov@intel.com>
Original-Tested-by: Petrov, Andrey <andrey.petrov@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15496
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362844
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The gpio bank irq is not correct and hence gpio
bank handler is never called in case of gpio based irq.
Correct the gpio bank irq to enable gpio based irq.
BUG=chrome-os-partner:55433
TEST=cat /proc/interrupts | grep INT3452 should
output 14.
Change-Id: I54253786425b7d4c2007043d49a91dfa6db0397b
Original-Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15756
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362843
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The 'dram density' is a misnomer because the memory initialization
code treats that input parameter as a per rank density. Therefore,
update the variables to further clarify how it's actually being
used.
BUG=chrome-os-partner:55446
Change-Id: Ie4c944f35b531812205ac0bb1c70f39ac401495e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15773
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362840
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The 16Gb devices use two ranks per channel within the DRAM module.
However, the density settings are really on a per rank basis so
indicate dual rank with a device density of 8Gb.
BUG=chrome-os-partner:55446
Change-Id: Ib5dba6f9ed248750d68b726996c71def9b75961e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15772
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362689
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Despite the UPD comments the Chx_RankEnable fields are a bit
mask which indicates which ranks are enabled for physical
channel. Add the ability to set the rank mask correctly for
dual rank LPDDR4 modules.
BUG=chrome-os-partner:55446
Change-Id: I9dbed7bb6a4b512e57f6b4481180932a7cce91ff
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15771
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362688
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The reset requests are handled in the FSP 2.0 wrapper, but
the current code doesn't check any non-successful return
values. Provide parity with the memory init path which die()s
under those circumstances.
BUG=None
BRANCH=None
TEST=None
Change-Id: I9df61323f742b4e94294321e3ca3ab58a68ca4dd
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15766
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362687
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Not all are matched, but this makes it easier to backport
MTRR changes from haswell.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ida5943b1469fc0089a31ff3b18131fb82b0941c6
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15760
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362686
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Since the socket layer is implemented with this CPU model, there
could potentially be multiple CPU models included. There can be
only one cache_as_ram include, so select it directly within
the socket directory.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia52bb152276eddfd1fb33ddb7f5d153ab8e8163c
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15757
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362683
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
we need to enable dram ODT on kevin/gru board to imrove
dram signal. Note, if enable dram ODT and set to 120ohms,
sdram VREF need to adjust to 840mv. Besides, this patch also
doing following change:
1. For compatible old board, add the
"sdram-lpddr3-hynix-4GB-666-no-odt.inc" and
"sdram-lpddr3-hynix-4GB-800-no-odt.inc" files
which do not enable sdram ODT.
2. delete 300MHz dram inc file, the 300MHz sdram config just
reduce 666MHz to 300MHz base on 666MHz config file, and it is
not stable, so delete it.
3. deltet 928MHz dram inc file, 928MHz sdram config still in
debuging, delete it first.
BRANCH=none
BUG=chrome-os-partner:54871
TEST=run "stressapptest -M 1024 -s 1000" on kevin board and pass
Change-Id: I35f0685782d6fb178a95780ec77c45f565dd2194
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/358763
Commit-Ready: Dan Shi <dshi@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
when enabling controller ODT, the controller vref need to
correspond to ODT value and DQ drive strength.
BRANCH=none
BUG=chrome-os-partner:54871
TEST=run "stressapptest -M 1024 -s 1000" on kevin board and pass
Change-Id: I7e54b3473f68a382208a0fb0b0600552fe6390ad
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/358762
Commit-Ready: Dan Shi <dshi@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
As shown in testing, if CA use 34.3ohms drive strength, it leads
to an overshoot. To fix this, change the drive strength to 48 ohms.
BRANCH=none
BUG=chrome-os-partner:54871
TEST=run "stressapptest -M 1024 -s 1000" on kevin board and pass
Change-Id: I231f5b1bd45ff262686fbacbaf119a8a57fad27b
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/358761
Commit-Ready: Dan Shi <dshi@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change EVT3 board id to 5.
BUG=chrome-os-partner:55320
TEST=None.
BRANCH=None
Change-Id: I21a8764ff95892430944778f4898d2f1d4c97fd7
Signed-off-by: Kan Yan <kyan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/362391
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The EVT board uses an active high power control signal while
the previous board used an active low signal. Update the tables
to reflect the differences.
BUG=chrome-os-partner:55470
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15763
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I198c0e4e019fcffe2cf748d382351ac965a81077
Reviewed-on: https://chromium-review.googlesource.com/362345
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
