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>
The cbmem string for 'AFTER CAR' didn't have the proper spacing
so when that entry is added to cbmem it results in a misaligned
log entry with the others.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15735
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: If940e85b7dc5fb8372d7e2845270dadad67ab3a0
Reviewed-on: https://chromium-review.googlesource.com/361648
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Chrome OS options that will be shipped on this platform were
being set in the chromium repo with an external config file. Set
the options in the mainboard Kconfig file so there's no discrepancy
as to what will be used.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15733
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I05f0d1245611c16f54273728519a08e6edff3429
Reviewed-on: https://chromium-review.googlesource.com/361646
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix and use the failsafe CAS detection logic rather than
recalulating the values from raw SPDs.
Tested on GA-G41M-ES2L with 2x2GB DDR2-800 DIMMs
(which worked before and still work)
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/15726
Tested-by: build bot (Jenkins)
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Change-Id: I6af0f1705d099f7bcbff8c9baa94a68dae689e01
Reviewed-on: https://chromium-review.googlesource.com/361644
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function is unused since coreboot starts payloads in machine mode,
and it uses the obsolete eret instruction.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15729
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I98d7d0de5a3959821c21a0ba4319efb610fdefde
Reviewed-on: https://chromium-review.googlesource.com/361643
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using the opcode directly is necessary for the transition to the GCC
6.1.0 based toolchain, because the old toolchain only supports eret and
the new toolchain only supports mret.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15290
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I17e14d4793ae5259f7ce3ce0211cbb27305506cc
Reviewed-on: https://chromium-review.googlesource.com/361642
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
