Create Intel Common ITSS code. This code currently only contains
the code for Interrupt initialization required in Bootblock phase.
More code will get added up in the subsequent phases.
Change-Id: I133294188eb5d1312caeafcb621fb650a7fab371
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/19125
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The SRS bit which is supposed to indicate reset button press
is non-functional. If it did work the system reset event it
was associated with is overly specific. Therefore, use the
warm reset status bit.
BUG=b:37687843
Change-Id: I34dd09c03d2bca72da9a5cdf23121e0d0e621fa6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19484
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
It's come to attention that apollolake doesn't support a full retrain
on warm reset. Therefore force a cold reset when a full retrain is
requested in the non-S5 path.
BUG=b:37687843
Change-Id: If9a3de1fa8760e7bb2f06eef93a0deb9dbd3f047
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19483
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Update default ODT config to have correct CA ODT settings as the
current defaults are incorrect for all the current apollolake designs.
All the current designs pull both A and B channels' LPDDR4 modules' ODT
pins to 1.1V. Therefore, the correct impedance setting needs to be
applied.
In order for the settings to take effect one needs to clear the
memory training cache in deployed systems. Trigger this by bumping
the memory setting version for the SoC.
If needed in the future support for allowing the override of this
setting from the mainboard should be straight forward. It's just not
necessary at this time.
BUG=b:37687843
TEST=BAT test, warm, reboot, S3 cycle test
Change-Id: I9a2f7636b46492a9d08472a0752cdf1f86a72e15
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19397
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
On Chrome OS systems a memory setting change is needed to be deployed
without updating the FSP blob proper. Under such conditions one needs
to trigger retrain of the memory. For ease of use provide an option,
FSP_PLATFORM_MEMORY_SETTINGS_VERSIONS, which incorproates the SoC
and mainboard memory setting version number into the FSP version
passed to the platform. The lower 8 bits of the FSP version are the
build number which in practice is normally 0. Use those 8 bits to
include the SoC and mainboard memory settings version. When FSP,
SoC, or mainboard memory setting number is bumped a retrain will be
triggered.
BUG=b:37687843
Change-Id: I6a269dcf654be7a409045cedeea3f82eb641f1d6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19452
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
BUG=b:35647967
TEST=boot from bob
Change-Id: I756513f02ac13e159d5b8b1ac2346fa42cf3c219
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cf18ed7b8fdf11594f812e5c48a2bd0fde5cb820
Original-Change-Id: I50c053ab7a6f6c14daee4fb2ab1cdcaeee2d67da
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/452286
Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com>
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19434
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=b:35647967
TEST=boot from bob
Change-Id: I5de902ab26fe768b641f69d85a5294baf6d916e3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 223257d486b026c06a1f3a7a830b829efb9932dc
Original-Change-Id: I055ad5f59285cee3110d1e7cb1a53a60144712e4
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/452285
Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com>
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19433
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
SD card detect pins should normally have a pull-up. It seems that for
micro-SD cards this doesn't really matter all that much, but for the
full-size slots we have on some Oak-derivatives (like Hana) it does.
BRANCH=oak
BUG=b:35854317
TEST=Booted Hana, confirmed that card detect no longer seemed stuck-on.
Booted Elm and confirmed that SD card behavior didn't change.
Change-Id: I9b20e0f6fe310e724d191e36ca0a81ab4fe5f593
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c2781eeef50f52c6f02ee9344274ddf4dcb0a946
Original-Change-Id: I428ac92efb07f94265673b04e0e0dd452649b9fd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/452861
Original-Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://review.coreboot.org/19432
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Ironically enough, libsanitizer is notorious for creating "uninitialized
variable" warnings with different compiler versions than the one it's
shipping with.
Since we don't need it for building the real compiler, just skip it.
Fixes building our compilers using the gnat-gpl 2014 compilers.
Change-Id: I2130dfdf3eaf07d77cd70777419fc0ae4642b843
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/19478
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Add basic SMM support for Broadwell-DE SoC.
The code is mainly based on the SMM implementation of Broadwell with a
few differences:
- EMRR is now called PRMRR and the UNCORE part of it is not available
- SMM_FEATURE_CONTROL is no longer a MSR but is now located in PCI space
- currently only SERIRQ-SMI has a handler
Change-Id: I461a14d411aedefdb0cb54ae43b91103a80a4f6a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/19145
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On Apollo Lake it was discovered that our current FADT implementation is
valid for ACPI version 3.0 but misses fields for ACPI version 5.0. We
run into booting issues with Windows 10 using version 5 in the FADT
header. In commit 2b8552f49bc3a7d0290f96a84b573669de396011
(intel/apollolake: Switch FADT to ACPI version 3.0) we go back to
version 3 for Apollo Lake. Skylake is now the last platform that uses
version 5 in FADT header.
Change-Id: I2d0367fae5321dee4ccac417b7f99466f8973577
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/19453
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current implementation of the FADT structure is only ACPI 3.0 compliant.
Setting the version to ACPI 5.0 results in a corrupt FADT. Linux seems
to be able to deal with it but Windows 10 hangs in a really early stage
without any notification to the user.
If ACPI 5.0 is mandatory, the FADT structure needs to be adjusted to
match the specification. Therefore the members sleep_ctl and sleep_stat
needs to be added to FADT structure.
Change-Id: I51c7a7a84d10283f5c2a8a2c57257d53bbdee7ed
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/19146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the images around in the image stitching. This addresses
an issue found with PSP firmware loading on the Google Kahlee
mainboard.
Note firmware1 must come before firmware2 in the image or
the PSP will not allow APU to execute.
Change-Id: I85963fa93d6efd707cedfbc04b92d302ad5de3b1
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19170
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The new touchpad firmware uses i2c-hid instead of custom reporting
protocol. The touchpad also exposed another slave address (0x1e) for
kernel to communicate with the touchpad EC.
Change-Id: Iecaf14f7b8aed836120569e9ade9c3115bc00264
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://review.coreboot.org/19461
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add a check for vboot when locating the binaryPI image.
There is currently an ordering problem using cbmem to locate the
image when vboot is present. Vboot inserts its locator into the
search process so that memory can be checked before flash is queried.
For the earliest calls using the wrapper, DRAM has not been set up
and cbmem not initialized in romstage. This change prevents an
endless loop when vboot searches cbmem.
This change has another side effect. When vboot is in effect, the
change forces the RO binaryPI to be used even when on either of the
RW paths. There is currently no ability to relocate the XIP image
for use in a RW region.
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit 6efe9217c38cf93fd9b38e52cf3ec90fee3d0474)
Change-Id: I0c14bd729f8a67bca37cbdbd3a5e266c99c86d54
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/18438
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
AMD VBIOS option ROMs often modify themselves during initialization.
Check for the presence of a VBIOS at 0xc0000 before populating the
VFCT table. If a matching ROM is found, use it for the source of
the copy.
Tested on Gardenia (Stoney) variant by observing amdgpu driver's
dmesg output.
Change-Id: I5be7e1562bde51800c5b0e704c79812d85bcf362
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/19383
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We need to rewrite libtool's files (foo.la) a couple of times so it
knows where to look
(while still whining that $DESTDIR$TARGET != $TARGET. well, duh.)
Change-Id: I54cafd47c76d855222ba905b5eb4533a23bdfd34
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/19463
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order for PD charge events to properly notify the OS when a charger is
attached we need to enable the PD MCU device and event source from the EC.
Without this change the charging still happens, but the OS does not notice
and update the charge state icon in the Chrome OS UI.
BUG=b:35586577
BRANCH=none
TEST=On a poppy board that has the VBUS rework applied, plug in a charger to
either port and see charge status updated to indicate charging in the
power_supply_info tool and the Chrome OS UI.
Change-Id: I59dcfc1cb5d11841f56cac7f4ffe461c2f9ec52a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://review.coreboot.org/19441
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
If the mainboard supports VBNV, call init_vbnv_cmos() instead of
the normal init_cmos(). The VBNV version does some VBNV pre
and post setup around the normal init_cmos().
Change-Id: I34b02409019b945cd68c830e006e99338643f29c
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19399
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Once the PCI command register is written the bridge forwards
future IO and memory regions, as programmed in the respective base
and limit registers, to the secondary PCI bus.
Since the LPC function claims the resources for IOAPIC, ROM and
low IO (0x0-0xfff) in its read_resources() call, the PCI-to-PCI
configuration will not overlap those regions and does not hide
the resources mentioned in the original comment.
The bridge was disable in the following commit [1]
commit a8e1168064
Author: Stefan Reinauer <stepan@coresystems.de>
Date: Wed Mar 11 14:54:18 2009 +0000
This patch contains some significant updates to the i82801gx component and will
be required for a series of later patches. Roughly it contains:
but unfortunately it was not noted which system this caused
problems with.
[1] http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=a8e1168064b34b46494b58480411a11bc98340f6
Change-Id: I75128d83a344f4a0e09a3ea623c7f92a016ebfb9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/2706
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For this debug.c needs to be linked too.
Change-Id: I9cd1ffff2c39021693fe1d5d3f90ec5f70891f57
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19030
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
BUG=b:37486021
BRANCH=None
TEST=compile coreboot and make sure sda and sdb show
up in /sys/class/block.
Change-Id: I11344a4a5fc7e5b5d907d25439f92744a5fb70da
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://review.coreboot.org/19450
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This reverts commit e7394ca903.
Configuration register for ACPI PM base address is initially configured
inside the PI blob. Therefore, the value of HUDSON_ACPI_IO_BASE needs
to be the same as DFLT_ACPI_PM1_EVT_BLOCK_ADDRESS used in the build
of binaryPI blob.
Change-Id: I36700e49e21cc675e8e22b06efffb40e9c1e4236
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19454
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Tested-by: build bot (Jenkins)
Replace ram_check with quick_ram_check, because ram_check is slow and
is destructive for dram content.
Change-Id: I5fb1bfe711549aabb6e597bda22848988a7e9cbe
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19416
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is not needed.
Change-Id: Id19a00c1546b7a71d90aa8c7e43e6efde1e9fbbc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19425
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
MMA blobs are SOC specific (not board). So far MMA
is supported by big cores (SKL and KBL).
Change-Id: I922789a2a12d55360624dd6de15ab9f0bb5f0acf
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/19260
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a function to send the TPM decode to the SPI interface.
Enables use of SPI TPMs on Hudson mainboards.
Change-Id: I0e85ed92163e38eca6a55456708ab322d6a90d4c
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19402
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change spaces to tabs and do general whitespace cleanup.
Change-Id: I4a4ecd42f91c9c6015a4f065b7386b17523ac6d9
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19401
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Move the ACPI IO registers from 0x800 to 0x600 to avoid the
IO space required by the Google EC, also at 0x800.
This shouldn't have any conflicts on other AMD systems.
Change-Id: Iac7388c15e899277fd506fb37965164488358335
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19171
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add a function to enable LPC IO decode AKA WideIO.
This can enable up to 3 regions, which may be 512 or 16
bytes wide.
Change-Id: I2bed3a99180188101e00b4431d634227e488cbda
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19160
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It turns out that there are quite a few other projects that can access
the CBMEM console by now. If we ever want to make another structural or
behavioral change to it, we need to know where these implementations are
so we can make sure they're all getting updated. Let's try to build a
comprehensive list in the file that should be the source of truth for
all (coreboot's own implementation).
Change-Id: Ia3d6a87230f5bfdde9d812bc7154e22880c1377a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19439
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a basic GPIO get function.
Note that GPIO set, ACPI/GPE, and other features should come
in future commits. Future changes to be modeled on the other soc/
gpio functions.
Change-Id: I8f681865715ab947b525320a6f9fc63af1334b59
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/19159
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The silicon specific mainboard_romstage_entry() in amd/cpu/car.h,
which is used by all AMD silicon car code, caused a conflict.
Move the silicon specific defines to silicon header files. Also,
no longer include car.h in the romstage file.
Change-Id: Icfc759c4c93c8dfff76f5ef9a1a985dd704cfe94
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/18769
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
These files are actually indentical, but unfortunately, the formatting
was changed without caring for the already present files. Fix that. Use
the license formatting where less lines are used.
The next step is to put that in a common location.
Change-Id: Iecb263b9d321a33e64988b315220893df2e0045c
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/19423
Tested-by: build bot (Jenkins)
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
According to the comment above the default should dump the EC ram,
though is never reached since the variable 'write_addr' is not 0, but
initialized at -1.
Also removes brackets around one line statement below if to make
checkpatch.pl happy.
Change-Id: I390996b253f2f20682cd9ab2d4f560de6eccfc57
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19152
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
When setting output to verbose, it incorrectly reports that it times
out on every command.
TESTED on Thinkpad X60.
Change-Id: I24f05f0c165462d5ba2604c7e2fe139400683275
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/19151
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Utilize the postcar stage for tearing down CAR and initializing
the MTRRs once ram is up. This flow is consistent with apollolake
and allows CAR_GLOBAL variables to be directly accessed and no
need for migrating CAR_GLOBAL variables as romstage doesn't
run with and without CAR being available.
Change-Id: I76de447710ae1d405886eb9420dc4064aa26eccc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19335
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The devicetree data structures have been available in more than just
ramstage and romstage. In order to provide clearer and consistent
semantics two new macros are provided:
1. DEVTREE_EARLY which is true when !ENV_RAMSTAGE
2. DEVTREE_CONST as a replacment for ROMSTAGE_CONST
The ROMSTAGE_CONST attribute is used in the source code to mark
the devicetree data structures as const in early stages even though
it's not just romstage. Therefore, rename the attribute to
DEVTREE_CONST as that's the actual usage. The only place where the
usage was not devicetree related is console_loglevel, but the same
name was used for consistency. Any stage that is not ramstage has
the const C attribute applied when DEVTREE_CONST is used.
Change-Id: Ibd51c2628dc8f68e0896974f7e4e7c8588d333ed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19333
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The console log level variable doesn't really rely on ROMSTAGE_CONST
proper. Instead, the mutability of the variable is based on the current
implementation of ROMSTAGE_CONST (__PRE_RAM__). As such directly
use that logic for the code. In addition, refactor the code to let
the compiler and linker optimize out accesses instead of using
the pre-processor.
Change-Id: I44bcc409266ef52b9be29f75efde73a6707a53f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19438
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The ramstage-c-ccopts variable needs to be double dereferenced
for the cbfs-files-processor-struct handler so all the ccopts
are included since the ramstage-c-ccopts is fully constructed
later by another function. Without this not all the flags
are present on the command line.
Change-Id: I5425b3c1f23d767c61f654dd287584403f85d719
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19380
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
In the safety considerations, we should make sure the slot of SD is
enabled first, since we want to the power switch of corresponding is
powered up.
The different boards have the different power switch for sdmmc.
Some power switch IC need turn on delay for long time.
let's move the slot power of SD to romstage and avoid explicit delays
or per-board.
BRANCH=none
BUG=b:35813418, b:35573103
TEST=check the signal for children of gru, and boot up from sd card.
Change-Id: Id164e4c4c900c6b1ca0251fc27db4cd36c56f6ff
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ea1b01cc13628033b85251dbb44407f075efdc85
Original-Change-Id: I48ab543143d3de9be46608fc12d78e09decf8d79
Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/447076
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19430
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Delete the write to PM register 0xee. This register is not
listed in the current BKDG and S4 is not currently supported
on this APU.
NDA document #47517 "A55/.../A85X fusion Controller Hub Register
Reference Guide" provides some clues on the intent of this write.
This register has always been observed to power on with a value
of 0x08 so the write has no effect.
This should be revisited again when SMI and PSP fully implement
the support required for S3.
Change-Id: I35e6c5f7ad1de7f51b018543d2f7ce82182f11e4
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/18494
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Create new functions similar to read and write of other sizes.
Change-Id: I35a08c498f25227233604c65c45b73b1c44fae1f
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/19394
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Unlike other oak derivatives, Rowan uses an 8-lane BOE tv097qxm-nu0
MIPI/DSI panel that requires dual DSI support.
Rework oak display initialization to special case Rowan, which uses a
provided edid struct for its panel, special panel backlight sequencing
and needs to configure mtk_ddp and mtk_dsi to use dual dsi mode.
BRANCH=none
BUG=b:35774871
TEST=Boot Rowan in developer mode and see output on the panel
Change-Id: I136ba5bd1ab12c4ad92995e066fc6d6cf54d0898
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/19389
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The MT817x display output pipeline can be configured to drive an 8-lane
MIPI/DSI panel using "dual DSI" mode. For the "dual DSI" video data path,
the UFO block is configured to reorder the data stream into left and right
halves which are then sent by the SPLIT1 block to the DSI0 and DSI1
respectively. The DSI0 and DSI1 outputs are then synchronously clocked at
half the nominal data rate by their respective MIPI_TX0/MIPI_TX1 phys.
Also, update the call sites in oak mainboard to avoid build breakage.
BRANCH=none
BUG=b:35774871
TEST=Boot Rowan in developer mode and see output on the panel
Change-Id: Id47dfd7d9e98689b54398fc8d9142336b41dc29f
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/19361
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Barnali Sarkar