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>
I mistakenly assumed the order of the bits matched how one
would assign values as they wrote them msb .. lsb. However, the
gpio lib doesn't do that. Correct the order so that values are
read out correctly.
BUG=chrome-os-partner:54949t
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15753
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I5304dfe2ba6f8eb073acab3377327167573ec2cc
Reviewed-on: https://chromium-review.googlesource.com/362344
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Zero-filling memory below 1 MiB resets car_migrated variable so
any CAR GLOBALs are not addressed correctly for the remaining
time in romstage. Also there is no actual need to do this as
ramstage loader handles BSS.
This fixes regression with commit 70cd54310 that broke fam10 boards
with romstage spinlocks enabled.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15754
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Change-Id: I7418821997a980ae5b818bd57e8a1b6507a543af
Reviewed-on: https://chromium-review.googlesource.com/362342
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
When no CFLAGS are explicitly provided to it, the GMP configure script
will figure out the best optimization flags to use on its own. In
particular, it will setup the march, mfpu and mtune flags based on
hardware detection.
However, when CFLAGS are provided, they are used as-is and such
detection doesn't happen. When the march, mfpu and mtune flags are not
provided (which happens when GMP wasn't built already), not only will
related optimizations be disabled, but some code might not build because
of missing support. This happens with NEON instructions on ARMv7 hosts.
Thus, it is better not to set CFLAGS and leave it up to the GMP
configure script to get them right and still reuse those later.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15452
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6ffcbac1298523d1b8ddf29a8bca1b00298828a7
Reviewed-on: https://chromium-review.googlesource.com/362341
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Read timestamps from the last boot sequence and display the information
as if using cbmem -t.
Tested on QEMU with a SeaBIOS payload.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/15600
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I44f1f6d6e4ef5458aca555c8a7d32cc8aae46502
Reviewed-on: https://chromium-review.googlesource.com/362139
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The tpm2_marshal_command() function returns a negative value on error,
so we must use a signed type for the return value.
This was found by the coverity scan:
https://scan.coverity.com/projects/coreboot?tab=overview
CID:1357675
CID:1357676
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Found-by: Coverity Scan
Reviewed-on: https://review.coreboot.org/15717
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: I56d2ce7d52b9b70e43378c13c66b55ac2948f218
Reviewed-on: https://chromium-review.googlesource.com/362136
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add missing break to LEG_GPIO_REGS case to return the correct value for
legacy GPIO reads. Fixes coverity issue CID 1357460.
Found by Coverity, Fixes:
* CID 1357460 (#1 of 1): Unused value (UNUSED_VALUE)
returned_value: Assigning value from reg_legacy_gpio_read(step->reg)
to value here, but that stored value is overwritten before it can be
used.
value_overwrite: Overwriting previous write to value with value from
reg_pcie_afe_read(step->reg).
TEST=Build and run on Galileo Gen2.
BUG=None
BRANCH=None
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15732
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I6c52e8801a32f510ac94276fe0c097850cbfde57
Reviewed-on: https://chromium-review.googlesource.com/362135
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
_Static_assert() gets evaluated even when the code path it's in is
unreachable (e.g. inside an if (0) block). Unfortunately, Kconfigs that
depend on a disabled Kconfig are always 0, meaning that
CONFIG_CONSOLE_SERIAL_UART_ADDRESS on Gru cannot evaluate to UART2 when
CONFIG_CONSOLE_SERIAL (which it depends on) is disabled. Switch the
condition it is wrapped in to a preprocessor #if so that the
_Static_assert() is not evaluated when building without serial support.
BRANCH=None
BUG=None
TEST=Built and booted Kevin without serial
Change-Id: I33d51d4ef09b218c14173d39a12795f0cef6bb40
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361581
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Fix the board ID handling.
Recovery switch and WP status GPIO has been reassigned in board rev3.
Configure related GPIOs based on Board ID.
BUG=chrome-os-partner:55320
TEST=Verified GPIO assignment for Rev.1 board.
BRANCH=None
Change-Id: I6d3d5df2e9017f7845edc3cd0b2c19ad7c58a97c
Signed-off-by: Kan Yan <kyan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/361393
Reviewed-by: David Hendricks <dhendrix@chromium.org>
At first boot CSE spends long time preparing media for use. As result
it may not be able to deal with a CPU reset. Add reset_prepare()
callback that polls CSE readiness.
BUG=chrome-os-partner:55055
BRANCH=None
TEST=build with release version of fsp, reboot, observe polling for
CSE, then proper reboot happening
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15721
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I639ef900b97132f1a7f269bb864d70009df9fdfe
Reviewed-on: https://chromium-review.googlesource.com/361784
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Ensure that the stack provided to FSPM doesn't overlap the current
program which is loading the FSPM component. If there is a conflict
that's an error since it could cause the current program to crash.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15746
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Change-Id: Ifff465266e5bb3cb3cf9b616d322a46199f802c7
Reviewed-on: https://chromium-review.googlesource.com/361779
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Utilizing the FSP revision while saving the memory training data is
important because it means when the FSP is updated the memory training
is redone. The previous implementation was just using '0' as a revision.
Because of that behavior a retrain would not have been done on an FSP
upgrade.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15744
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I1430bd78c770a840d2deff2476f47150c02cf27d
Reviewed-on: https://chromium-review.googlesource.com/361777
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are issues that were found by the updated toolchain at
coreboot.org:
* mode_sel was possibly being used before being initialized, so
initialize it. Note that this can't actually happen after adding the
halt for the unknown DRAM type, but the compiler still complained.
* vref_mode and speed were possibly being used without being
initialized, so halt if they don't get initialized. Note that this
change was pushed to coreboot.org before the latest refactoring,
and it looks like speed isn't being used at all now. I'll remove
that in a follow-on change.
BRANCH=none
BUG=none
TEST=none
Change-Id: I3f25e7980f1b0620517f25667ac744f4c9edc4b3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361363
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are some minor changes that were made at coreboot.org
as patches were pulled in.
* Fix grammar and spelling in comments
* Change setup (noun) to set up (verb)
* Change workaround (noun) to work around (verb)
* Capitalize EDID and Rockchip.
* Add whitespace around * operators
* Add period at the end of a sentence in a comment
BRANCH=none
BUG=none
TEST=none
Change-Id: Ic23e4255e51e9181b6139cba31ae5bdbff518569
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are some minor changes that were made at coreboot.org
as patches were pulled in.
* Add whitespace around comments
* Remove trailing whitespace from text
* Update error text for grammar
BRANCH=none
BUG=none
TEST=none
Change-Id: Ic72b1577de80010f538dfe6ee8ffefffde8cfd23
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361361
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are some non-functional changes that were made at coreboot.org
as patches were pulled in.
* Remove second include of board.h
* Remove leading whitespace for comments
* Add coreboot license headers
* Add a line after the license header
BRANCH=none
BUG=none
TEST=none
Change-Id: I092cf64ddcde1ed07f38a8107766cbffded71796
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361360
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The FSPS component loading was just loading to any memory address
listed in the header. That could be anywhere in the address space
including ramstage itself -- let alone corrupting the OS memory on
S3 resume. Remedy this by loading and relocating FSPS into cbmem.
The UEFI 2.4 header files include path are selected to provide the
types necessary for FSP relocation.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15742
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: John Zhao <john.zhao@intel.com>
Change-Id: Iaba103190731fc229566a3b0231cf967522040db
Reviewed-on: https://chromium-review.googlesource.com/361775
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: John Zhao <john.zhao@intel.com>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: John Zhao <john.zhao@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The previously implementation for loading the FSPM component didn't
handle platforms which expects FSPM to be XIP. For the non-XIP case,
romstage's address space wasn't fully being checked for overlaps.
Lastly, fixup the API as the range_entry isn't needed any longer.
This API change requires a apollolake to be updated as well.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15741
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I24d0c7d123d12f15a8477e1025bf0901e2d702e7
Reviewed-on: https://chromium-review.googlesource.com/361774
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current FSP component loading mechanism doesn't handle all the
requirements actually needed. Two things need to be added:
1. XIP support for MemoryInit component
2. Relocating SiliconInit component to not corrupt OS memory.
In order to accommodate those requirements the validation
and header initialization needs to be a separate function.
Therefore, provide fsp_validate_component() to help achieve those
requirements.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15740
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I53525498b250033f3187c05db248e07b00cc934d
Reviewed-on: https://chromium-review.googlesource.com/361773
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of performing the same tasks in the chipset code move
the common sequences into the FSP 2.0 driver. This handles the
S3 paths as well as saving and restoring the memory data. The
chipset code can always override the settings if needed.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15739
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I098bf95139a0360f028a50aa50d16d264bede386
Reviewed-on: https://chromium-review.googlesource.com/361772
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The amount of reserved memory just below the DRAM limit in
32-bit space is defined in the FSP 2.0 specification within
the FSPM_ARCH_UPD structure. There's no need to make the
chipset code set the same value as needed for coreboot.
The chipset code can always change the value if it needs
after the common setting being applied.
Remove the call in soc/intel/apollolake as it's no longer
needed.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15738
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Change-Id: I69a1fee7a7b53c109afd8ee0f03cb8506584d571
Reviewed-on: https://chromium-review.googlesource.com/361771
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The gcc compiler treats sizeof(void) == 1. Therefore requesting
a 1 byte reservation in cbmem and writing a pointer into the
buffer returned is wrong. Fix the size of the request to be
32-bits because FSP 2.0 is in 32-bit space by definition. Also,
since the access to the field happens across stage boundaries
it's important to ensure fixed widths are used in case a later
stage has a different pointer bit width.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15737
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ib4efc7d5369d44a995318aac6c4a7cfdc73e4a8c
Reviewed-on: https://chromium-review.googlesource.com/361770
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>