Hatch implements active high SD_PWR_EN and requires a workaround
in _PS0 and _PS3 control methods to make sure SD_PWR_EN stays low
in D3. Select MB_HAS_ACTIVE_HIGH_SD_PWR_ENABLE to enable the same.
BUG=b:123350329
Change-Id: I96ab9660eb50100207fe9a237f5924b65eae0928
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/31446
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
SD controller in CNL-PCH provides a ability to configure the behavior of
SD_VDD1_PWR_EN# as an active high or low signal. FSP provides an UPD
"SdCardPowerEnableActiveHigh" to control the same.
However, for platforms using SD_VDD1_PWR_EN# as active high, the SDXC
card connector is always powered and may impact system power. This is because
SD_VDD1_PWR_EN# does not de-assert during SDXC D3 or when SD card is not
inserted.
Workaround is to change the pad ownership of SD_VDD1_PWR_EN to GPIO and
force the TX buffer to low in _PS3. And restore the pad mode to native
function in _PS0.
Hence add a Kconfig option to update the UPD, which the board can select
based on how the SD_VDD1_PWR_EN is implemented on it. And, the workaround
gets applied based on this config.
BUG=b:123350329
Change-Id: Iee262d7ecdf8c31362aec3d95dd9b3e8359e0c25
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/31445
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
SD_CD# in Cannonlake PCH is also wired to an internal virtual GPIO,
expose that GPIO for kernel to configure card detect IRQ.
BUG=b:123350329
Change-Id: I566cc2eb11dc257366897a1efba905b8ddcf493d
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/31553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Adapted from Chromium commit 5351dc0d
[Edgar: To set the RX ODT limit and dram geometry with RAMID detection]
Several cyan variants require memory init parameters be passed to FSP
for handling of specific Micron modules; without these, RAM init will
fail when loading training data from the MRC cache, and boot will halt.
This was missed when I upstreamed edgar along with the other cyan
variants, so add the required memory init parameters for edgar as per
its source Chromium branch.
Test: build/boot on edgar board with affected Micron memory
modules, verify boot successful with populated MRC cache.
Change-Id: I6a2bc30b54ff1a17c854a90dfcb2308d27ee2be7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31615
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support measured boot, drop VBOOT_RETURN_FROM_VERSTAGE.
The SoC has enough CAR space to support a separate verstage.
Tested on OpenCellular Elgon.
Change-Id: I18022000f6f05df89d3037896ef627070bfcca06
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/31568
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
PMC initialization on Cannon Lake happens earlier in the boot sequence
than other SoCs because FSP-Silicon init hides PMC from PCI bus. As
ACPI disabling was done as part of PMC init, it was being called
earlier than what other SoCs do. This resulted in a different order of
events for some drivers e.g. ChromeOS EC. In case of ChromeOS EC, it
ended up clearing EC events (which happens as part of ACPI disabling
in SMM) before logging any events of interest that happen during
mainboard initialization.
This change moves the call to disable ACPI to pmc_soc_init just like
other SoCs to keep the order of events more aligned.
BUG=b:126016602
TEST=Verified that EC panic event gets logged to eventlog correctly.
Change-Id: Ib73883424a8dfd315893ca712ca86c7c08cee551
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/31614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Each smbios entry should be followed with two null bytes. In other
structures it's done by adding `u8 eos[2]` extra bytes at the end, it
was omitted in type38 (IPMI) though. This change fixes this - tables
decodes nicely:
```
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA2 (I/O)
Register Spacing: 32-bit Boundaries
```
Signed-off-by: Lukasz Siudut <lsiudut@fb.com>
Change-Id: I8efea9612448f48e23e7b2226aea2a9f3bc21824
Reviewed-on: https://review.coreboot.org/c/31482
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
There are functions defined on headers with no code written for. They
probably existed earlier, were removed and forgot in the headers. Remove
functions from headers if there's no actual code written for.
BUG=b:123564495
TEST=Build grunt.
Change-Id: Ia6a12e22a0944351c455dc2c3b534f09a258bd7b
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/c/31507
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This patch clarifies the definition of google_chromeec_command.
Currently absence of the definition isn't causing any problem because
wrapper APIs check 'ret != 0' or wrapper APIs check 'ret < 0' for an
interface which returns only negative error codes.
However, there is a chance that a new wrapper API will be addedl which
check 'ret < 0' to catch errors, assuming other interfaces behave the same.
Or existing wrapper APIs will be broken as soon as they're compiled for
another interface.
BUG=chromium:935038
TEST=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I2ce7109b5f2a1d5294f167719730bc1f039ba03f
Reviewed-on: https://review.coreboot.org/c/31613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On flapjack, retrieve the board information via CBI interface.
Also reserving 0x2 sku_id for the case of un-provisioned board as this is the id
used prior to the readiness of cbi.
BUG=b:123676982
BRANCH=kukui
TEST=provisioned cbi info and verify the sku_id.
Signed-off-by: YH Lin <yueherngl@google.com>
Change-Id: Iad7a52df38e2045abbdded8ba0a1f1544de961fc
Reviewed-on: https://review.coreboot.org/c/31586
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Cavium DRAM init might use the RNG for pattern generation.
Initialize it before running DRAM init.
Tested on OpenCellular Elgon.
The RNG generates non identical numbers.
Change-Id: I886f920e9941793fb76b56cc5a24a42e23b082e0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/31567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
coreboot performs MP-Init in a parallel way. That leads to the fact
that the order, in which the CPUs are woken up, can vary from boot to
boot. The creation of the MADT table just parses the devicetree and
takes the CPUs reported there as it is for creating the single local
APIC entries. Therefore, the OS will see different order of CPUs.
There are CPUs out there (like Apollo Lake for example) which have
shared caches on core-level and if the order is random this can end up
in assigning cores to different tasks or even OSes (in a virtual
environment) which uses the same cache. This in turn will produce
performance penalties across these distributed tasks/OSes.
Though there is a way to discover the core- and cache-topology it will
in the end be necessary to take the APIC-ID into account. To simplify
it, one can achieve the same output by sorting the APIC-IDs in an
ascending order. This will lead to the fact that CPUs that share a given
cache will be reported right next to each other in the MADT.
Change-Id: Ida74f9f00a4e2a03107a2124014403de60462735
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/31545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add an implementation for Bubble sort. For now, only integers can be
sorted in an ascending or descending order. It can be later simply
extended to cover other datasets like strings if needed.
The reasons for choosing bubble sort are:
* it is a simple algorithm
* bubble sort is stable, i.e. it does not exchange entries which are not
needed to be sorted as they are already in order
Change-Id: I2c5e0b5685a907243b58ebe6682078272d316bf6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/31544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Rather than attempt to maintain patches against upstream Tianocore, use
MrChromebox's coreboot framebuffer branch as the default build target.
Rework the Makefile to default to MrChromebox's coreboot_fb branch, but
also allow for aribitrary commits from upstream Tianocore to be used
as build targets.
Ensure the branch is synced on each build, as long as working directory
is clean, and that switching between commits or trees is handled sanely.
Eliminate TIANOCORE_MASTER as a selectable build target, since unpatched
it is unlikely to boot on any device. It can easily be specified via
the 'revision' option if desired.
Test: build for the default stable target, for upstream/master
as the specified revision, and for an arbitrary valid commit hash.
Change-Id: I4a83db3cd64c7d5b652c6e95780d10051f143e88
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/31543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
* Introduce a measured boot mode into vboot.
* Add hook for stage measurements in prog_loader and cbfs.
* Implement and hook-up CRTM in vboot and check for suspend.
Change-Id: I339a2f1051e44f36aba9f99828f130592a09355e
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/29547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMI handler on qemu returned early, due to missing SMM-Revision
Level support.
Add the ID qemu uses, which is AMD64 compatible for qemu-system-x86_64.
Fixes booting tianocore payload with SMM variable store on qemu.
Change-Id: I978b94150cfc49a39c2a0818eb14a649850e451d
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/31594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change default VESA/native framebuffer mode (needed for bootsplash and
graphical framebuffer console) from 117h (1024x768 64k-color (5:6:5))
to 118h (1024x768 16.8M-color (8:8:8)) mode.
This provides console output at Lenovo G505S even if e.g. GRUB is the
payload, while it is unlikely to cause any downsides for the other
boards.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: Ia348199bbd430532b1399706dd84490c9680b5f5
Reviewed-on: https://review.coreboot.org/c/31595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Upstream intelmetool is out of date; I suggest I archive it
instead of trying to merge coreboot's changes into it.
However I would like to preserve the licensing of files in the tool
as GPLv2+ where possible instead of GPLv2-only.
Change-Id: I47b1ff2734f54c65f4214b39244bd868ef44b83c
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/c/31587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Move ecam0_get_bar_val into the common folder and make it public.
Compile it for romstage and ramstage.
To be used by romstage PCI code.
Tested on OpenCellular Elgon.
Change-Id: I18b1ede56795bf8c1f9476592291b8ea610eccd4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/31566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Issue spotted using IASL 20190215 on mainboard GIZMOSPHERE_GIZMO2:
"Object is created temporarily in another method and cannot be accessed"
Change-Id: I1e4ca2c765083db3a27e415d3a69bef0912a606b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/31554
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This change fixes the power status events for AC and battery
events from the EC. The register that was being used is not
returning the expected information.
BUG=b:125472740
TEST=enable ACPI debug in the kernel and verify that AC and
battery insert/remove are detected properly.
Change-Id: I15f71fcf0ca6aa9438e951865787c9fc273792d8
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/31560
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Third parameter ConfigPtr of the callout is of type
AP_EXE_PARAMS and needs to be passed back to AGESA
with AmdLateRunApTask() call.
Change-Id: I1dad64b955b53bd19363737665235f95aa3d451e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/27277
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On every call of hwilib_find_blocks() the CBFS file will be mapped and
the contents are parsed to get the offsets for every single block. This
is not needed if the CBFS file name is the same for the different calls.
This patch adds a storage for the currently opened CBFS file name in
CAR_GLOBAL and checks on each call if the file to open is already open.
If yes, the file will not be mapped again which saves execution time.
Test=Booted mc_tcu3, mc_bdx1 and mc_apl1 and verified that hwinfo.hex
is only mapped once across several following hwilib_find_blocks() calls.
In addition a test was done to ensure that files with different names
get mapped correctly.
Change-Id: Id69e0f6c914c2b8e4551fd8a4fb7d452d176afb3
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/31518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
The change bcd84fe "mb/emulation/qemu-i440fx: change file handling"
introduced a regression where it loads only 4 bytes of the
ACPI and SMBIOS table, instead of the whole table.
Load the whole ACPI and SMBIOS table.
Tested on Qemu using GNU/Linux.
Change-Id: Ibacbf7caab9be5f181c12e9dd39a2893b13cf6c9
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/31593
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
USE_FSP_REPO used to rely on SOC_INTEL_COMMON_CANNONLAKE_BASE which was
getting selected for cometlake soc also. Since FSP is not yet upstreamed
for cometlake, compilation was failing due to FSP was not found.
So limiting USE_FSP_REPO option to coffeelake and whiskeylake soc only
and excluding for cometlake.
Change-Id: I5e5d5a9fdf3f5d3e79922e97719e8491aa514cef
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/31530
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
For some reason, wake does not currently work from GPP_D21, but IRQs
are working fine from that gpio. Thus, we have to switch IRQ to
GPP_D21 and wake to GPP_A21, which was previously used for IRQs from
the trackpad. Additionally, we need to use two gpios for irqs and
wake source at the moment because of b:123967687, where FSP is locking
down PCR and configuring ITSS. We need to configure the wake source
gpio as inverted and the IRQ gpio as non-inverted until the bug is
resolved.
BUG=b:121212459
BRANCH=None
TEST=run evtest with trackpad
Use trackpad with ChromeOS UI and make sure it reacts as expected.
Run powerd_dbus_suspend and press trackpad and make sure DUT
wakes.
Change-Id: I7b236136befc05c6586d9ba69185ed4b5d385273
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/31533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add UART PCI driver in cavium/common/pci.
Tested on opencellular/elgon.
The UART is still initialized and usable in Linux.
Change-Id: I0fa2f086aba9b4f9c6dba7a35a84ea61c5fa64e4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/30608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The latest rev. of the atlas board moves the WiFi wake source from
WAKE# to GPP_B7. The original GPP_A0 in the device tree is just
wrong. This also reconfigures DW1 to the GPP_B group so we can use
GPP_B7 as a wake source.
GPP_B7 is still configured as a no-connect in gpio.c, so this doesn't
actually enable WiFi wake. We'll follow up with another patch to set
up GPP_B7 properly on boards that support it.
BUG=b:122327852
BRANCH=none
TEST=atlas still boots
Change-Id: I1816500dd0ab6186fd51aa6945faf73d00c152fe
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Fix up the logic of when to include VBOOT2_WORK symbols on x86,
which are only needed when VBOOT_STARTS_IN_BOOTBLOCK is enabled.
Also correct the value of the __PRE_RAM__ macro in the case that
VBOOT_STARTS_IN_ROMSTAGE is selected. In this case, DRAM is
already up and verstage should not be considered pre-ram.
BUG=b:124141368, b:124192753
TEST=Build locally for eve
TEST=util/lint/checkpatch.pl -g origin/master..HEAD
TEST=util/abuild/abuild -B -e -y -c 50 -p none -x
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ie51e8f93b99ab230f3caeede2a33ec8b443e3d7a
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/31541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
VBT on Intel(R) systems is available via sysfs as
/sys/kernel/debug/dri/0/i915_vbt
However the size of this file reads as 0 causing
intelvbttool to fail. This patch implements incremental reads
with realloc for such cases or whenever the file size is not
available (e.g. reading from stdin).
After this patch is applied, intelvbttool can be used as follows:
sudo intelvbttool -f /sys/kernel/debug/dri/0/i915_vbt -d
Change-Id: I5d17095a5747550b7115a54a7619b7294a846196
Signed-off-by: Alex Feinman <alexfeinman@hotmail.com>
Reviewed-on: https://review.coreboot.org/c/31531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We experienced booting issues during FSP-M phase. Applying fix that was
introduced for wedge100s - 817994c1be (mb/ocp/wedge100s/romstage:
Workaround broken platform state) - helped and systems started to
boot properly.
Signed-off-by: Lukasz Siudut <lsiudut@fb.com>
Change-Id: Ibfbe9d19c7413098c56d1b6131640097fdf731ab
Reviewed-on: https://review.coreboot.org/c/31435
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a function in gpio ASL library to set pad mode.
BUG=b:123350329
Change-Id: I6c683f27ddffc3132001706d1694c71bb5664577
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/c/31444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Updating from commit id a32c930e:
2018-12-28 16:14:08 -0800 - (futility: updater: quirks: Support special released SNOW RO)
to commit id 1e177741:
2019-02-14 05:27:16 -0800 - (vboot: rename VB2_DISABLE_DEVELOPER_MODE)
This brings in 11 new commits.
Change-Id: I59d83de49006a6d081b206716002697d39099aa4
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/31542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When <symbols.h> was first introduced, it only declared a handful of
regions and we didn't expect that too many architectures and platforms
would need to add their own later. However, our amount of platforms has
greatly expanded since, and with them the need for more special memory
regions. The amount of code duplication is starting to get unsightly,
and platforms keep defining their own <soc/symbols.h> files that need
this as well.
This patch adds another macro to cut down the definition boilerplate.
Unfortunately, macros cannot define other macros when they're called, so
referring to region sizes as _name_size doesn't work anymore. This patch
replaces the scheme with REGION_SIZE(name).
Not touching the regions in the x86-specific <arch/symbols.h> yet since
they don't follow the standard _region/_eregion naming scheme. They can
be converted later if desired.
Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The BL31 on RK3399 is split into multiple segments... the majority goes
into DRAM, but small parts must be put into SRAM and PMUSRAM. With
CB:31123 only the DRAM part was added to memlayout, so the SRAM parts
will not be correctly marked in bootmem and BL31 loading fails the
selfload check. This patch adds the remaining regions to fix the
problem.
Change-Id: Ia0597216c08512c47361a1dc0beb34d022a8994f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/31538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ting Shen <phoenixshen@google.com>
Rizwan Qureshi