This change also makes sure that the sum the uma regions (TSEG, GSM,
GSM) is 4MiB aligned. This is needed to avoid cbmem_top floating between
2 usable ram region, since cbmem_top is aligned 4MiB down to easy MTRR
setup for ramstage. At least tianocore requires this and fails to boot
without it.
Better MTRR are achieved by making the memory 'hole' till 4GiB exactly
2Gib.
This code mimics how it is done in nb/intel/gm45 and achieves similar
results.
TSEG is enabled and set to 8M since this makes it easier to reuse the
common smm setup / parallel mp code and makes it possible to cache the
ramstage in there like how it's done on newer targets.
TESTED on Intel DG43GT.
Change-Id: I1b5ea04d9b7d5494a30aa7156d8c17170e77b8ad
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/21634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Programming CxDRB should be cumulative as explained in "Intel ® 4
Series Chipset Family datasheet".
This does not seem to have any real impact but better do according to
the documentation and what vendor firmware does.
This also removes some dead code.
Change-Id: I7ff3264824c843f84b9eb6c06a06aa3f151fe4b3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/22911
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This training find the optimal write DQ delay and read DQS delay
settings. It does so on all lanes at the same time, like
vendor (training each lane individually has poor results).
The results are stored in the sysinfo struct and restored on next
boots and S3 resume.
This potentially increases stability as optimal settings are chosen
and is more necessary for DDR3 raminit where the write DQS delays are
leveled/variable due to the flyby topology.
TESTED on Intel DG43GT with (2G + 1G) on each channel, see that the
results are quite close to the safe original ones (that previous
worked fine) and tested with memtest86+.
Change-Id: Iacdc63b91b4705d1a80437314bfe55385ea5b6c1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/22329
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Remove locking of PCI device 00:00.0 registers (nehalem/finalize.c)
and remove setting the zeroth bit of the MSR_LT_LOCK_MEMORY = 0x2e7 MSR
register (model_2065x/finalize.c) to fix a frozen boot and S3 resume issue
which became apparent with commit d533b16669.
More detailed, either setting the LSB of the 32 bit register at 0x98
of the PCI device 00:00.0 (in the intel_nehalem_finalize_smm function) or
setting the LSB of the the MSR register MSR_LT_LOCK_MEMORY = 0x2e7 (in the
intel_model_2065x_finalize_smm function) indepentenly causes a freeze
during bootup or a complete session loss on resuming from S3 as described
here: https://mail.coreboot.org/pipermail/coreboot/2018-April/086564.html
It seems like Nehalem CPUs do not have a MSR_LT_LOCK_MEMORY register.
Additionally, the "Intel Core i7-600, i5-500, i5-400 and i3-300 Mobile
Processor Series, Datasheet Volume Two" indicates that registers of the
PCI device 00:00.0 cannot be locked manually. Instead, they can only be
locked by TXT, VT-d, CMD.LOCK.MEMCONFIG, ME_SM_LOCK or D_LCK.
Finally, the addresses and sizes of these registers were partially wrong.
Tested on Lenovo X201i with a Core i3 330M (no AES-NI, no VT-d and no TXT
support compared to the Core i5 and Core i7 processors of a X201).
Change-Id: I9d568d5c05807ebf7e131b3e5be8e5445476d61b
Signed-off-by: Matthias Gazzari <mail@qtux.eu>
Reviewed-on: https://review.coreboot.org/25914
Reviewed-by: Nicola Corna <nicola@corna.info>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the thermal event handler method TEVT is defined as an extern,
then defined again in platforms with thermal event handling. In newer
versions of IASL, this generates an error, as the method is defined in
two places. Simply removing the extern causes the call to it to fail on
platforms where it isn't actually defined, so add a preprocessor define
where it's implemented, and only call the method on those platforms.
Change-Id: I64dcd2918d14f75ad3c356b321250bfa9d92c8a5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/25916
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Introduce bootmem custom memory tags and use them instead of reusing
LB_MEM tags.
Use asserts in bootmem_add_range to verify parameters.
Tested with uImage payload on Cavium SoC.
Change-Id: I7be8fa792fc7933ca218ecd43d250d3a9c55caa6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
* Adapt to coreboot coding style.
* Use coreboot's endian conversion functions.
* Fix header and header guards.
* Get rid of unused functions.
* Add Kconfig to build it on ramstage.
* Replace size32 with ALIGN_UP and DIV_ROUND_UP.
* Add NULL pointer checks
* Convert constants to defines
Required for Cavium's BDK and uImage FIT support.
Change-Id: I6e6cd9f78fb402bd54d684097326d26eb78d552a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25523
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Import from https://chromium.googlesource.com/chromiumos/platform/depthcharge
Required for general devicetree patching and FIT support.
Coding style and coreboot integration will be done in a separate commit.
Change-Id: Ida75d4786eae38d84bfc71bf53573dafca8eda40
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Besides the FSP codepath, Sandy Bridge has two codepaths, one native
and one in the form of a binary. This allows the use of the binary.
This can be useful to find flaws in the native raminit.
The native raminit is still selected by default.
Change-Id: I2d71fb7bc5f7b0976157be146c0e4c39a3ed5602
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
After commit 2188f57a (src/device: Update LTR configuration scheme)
coreboot will hang when reading resources on the ASMedia SATA
controller, although there is already an ASPM config override. So use
the ASPM blacklist driver instead of setting the ASPM override in the
devicetree.
Change-Id: I807d9bd4deef8c1528dff96c7646240ef75e1953
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/25819
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use of `device_t` has been abandoned in ramstage.
Change-Id: I0b969a5109276d108e6140bad338c74786b967f3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: I17675b004023453f137abd387cfacd308d9b98b5
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23652
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: I4b930a191130941c8349861cdd803a5be4219274
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23653
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use of `device_t` has been abandoned in ramstage.
Change-Id: I4c8acebb4a957a9600de15ea844f620a8909977b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23656
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: Ibd01659f518b7a2b1aaf334fe5b16cfb936b68b7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: Icec2e5f722c1f15493e5861b47f64698250f5813
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: I585aa48b99f4ef63905cab5d6d1502bfed0e6e42
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: Idcb8ff4081f2c45427aabb455a70fae1b46bcfc4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: Ib3e708a7fa9f0a78dc704a502a2f01ee0fe209ae
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23655
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t`has been abandoned in ramstage.
Change-Id: I2cc938958097e416b85f6592cb8a4e645a3746ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23654
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use of `device_t` has been abandoned in ramstage.
Change-Id: If064a4027265e8fc2ea919d9742a554abf29b8db
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/23667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
CONFIG_ALT_CBFS_LOAD_PAYLOAD has long since been removed.
Clean up the remnants in braswell.
Change-Id: I88483a4c3a74ed0c7defacf872b1564c3ce7f909
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This configures GPP_A23 as a wake source for the trackpad. We also
need to set up GPP_A GPE0_DW0, thus evicting GPP_B. We don't have any
interesting signals in GPP_B, so we won't be missing it.
I don't have hardware with A23 wired up, so i just tested the wake
source using A19 which is essentially identical to A23.
BUG=b:78541883
TEST=verified we can trackpad can wake system from suspend
Change-Id: If800464c8b2319d758b1823850571919f85bdc6c
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/25850
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Function gpio_output() is only setting the pin as an output, when in fact
it should also set the state (high/low) of the pin. Fix the procedure to
set the state of the pin.
BUG=b:78328773
TEST=None
Change-Id: I516192a0782a9bbb40124029f264a2711114c800
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/25871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently, google_chromeec_pd_get_amode infinitely loops if a TCPC port
is connected to a device with alternate mode(s) and the call is made
for the mode with the index higher than 0 (e.g. Zinger).
Cros EC manages alternative modes entered in an array (amode[]). The
command is designed to accept a query for an particular index and a
particular SVID.
Zinger has a 'Google' mode. It's stored in amode[0]. When AP queries
first time for DisplayPort with index=0, EC says 'no' as expected.
AP sends the next query with index=1 but EC_CMD_PROTO_VERSION (0x00)
is sent instead because cmd_code is cleared by google_chromeec_command.
res.svid is supposed to be 0 when EC hits the last index + 1 but
res.svid is set to 2 by the EC_CMD_PROTO_VERSION handler because
EC_PROTO_VERSION is currently 2. So, the call succeeds and AP goes to
the next index and this repeats forever.
Any USB-C device with non-DisplayPort alternate mode can cause this
hang unless HDMI port is used.
This patch resets all the fields of chromeec_command in each iteration
in case google_chromeec_command changes them.
BUG=b:78630899
BRANCH=none
TEST=Verify Fizz boots without monitors on Zinger. Verify the svid
enumeration happens as expected.
Change-Id: I388ed4bdfac9176d8e690c429e99674ed267004f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/25878
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All ARM architecture boards are supposed to have a TTB region for their
page tables. ARM systems cannot use the data cache without enabling
paging, so it is imperative to do that as soon as possible. They will
also fault on unaligned accesses when not using the cache, which breaks
assumptions in CBFS code.
Unfortunately, we have some old boards in various stages of disrepair in
the tree that don't always follow these sorts of standard conventions.
It's not clear whether they actually boot anymore and if anyone still
has the respective hardware available to maintain them. I cannot really
fix and test them right now, but we should at least create a fake TTB
section for them so that common architecture code may make the correct
assumptions about which regions exist.
Change-Id: I51aa259fbb7a9c0ade72db905b1762c1c721f387
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
New API required by sdm845 DDR init/training protocol
TEST=build & run
Change-Id: I8442442c0588dd6fb5e461b399e48a761f7bbf29
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/25818
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The layout command prints all FMAP regions in the final image among with
the region size. Extend this command to show the offset of each region
in the image.
Change-Id: I5f945ba046bd2f1cb50a93e90eb887f60c6fde8a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/25851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This creates a phaser variant for octopus. Nothing is set in the variant
files here; everything is picked up from baseboard.
BUG=b:78572180
TEST=None
Change-Id: Ia03e8af91741f1f7aa3a42ac28688b8b6a708932
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/25877
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Linux (4.16) assumes that the PIT interrupt is connected to the pin 0 of the
IOAPIC[0] and panics otherwise.
This might be a Linux bug. The MP Specification 1.4 does seem to mandate
sequential ordering for bus entries, but not for the I/O APICs.
Change-Id: Ibf823eb5b3a29e4590cba915069cdfe5f780edcd
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/25799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With only one entry for Write Protect gpio in the OIPG package, the sysfs
entry /sys/devices/platform/chromeos_acpi/GPIO.x is created as "GPIO"
instead of "GPIO.x". This was causing crossytem to return error for wpsw_cur.
BUG=b:78009842
Change-Id: Ica60f342420d95d09a45580f2f940443c03601de
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/25892
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
scan-build from Clang 4.0.1-3 from Debian Sid/unstable warns about the
issue below.
```
CC ramstage/southbridge/amd/cimx/sb800/lpc.o
src/southbridge/amd/cimx/sb800/lpc.c:102:6: warning: Value stored to 'end' is never read
end = resource_end(res);
^ ~~~~~~~~~~~~~~~~~
1 warning generated.
```
The variable is only used in the commented out print statement. So,
remove the unused variable, and directly use the value directly in the
print statement.
Change-Id: I3f759f6361ffeb07980cb10e17930e11d738a6a7
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/21463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Use acpigen method to return _STA instead of hardcoding unreadable
bytecode.
Change-Id: I290fb918675857e8ef798e3ab820bcfbdc6f5bdc
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/20982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
There is no physical LPC connector on apu3 mainboard. This board
contains only LPC debug test points with not all required pins exposed.
Change-Id: I83de16bb651846340788c6fa52c04b8e09e46a99
Signed-off-by: Piotr Król <piotr.krol@3mdeb.com>
Reviewed-on: https://review.coreboot.org/22630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Arthur Heymans