Provide default handler for some SMI events. Provide the framework for
extracting data from SMM Save State area for processors with SMM revision
30100 and 30101.
The SOC specific code should initialize southbridge_smi with event
handlers. For SMM Save state handling, SOC code should implement
get_smm_save_state_ops which initializes the SOC specific ops for SMM Save
State handling.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0aefb6dbb2b1cac5961f9e43f4752b5929235df3
Original-Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14615
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347390
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The current code was using !__PRE_RAM__ as a proxy for ramstage
conditional compilation. In the face of postcar stage not defining
__PRE_RAM__ (because it's after RAM is up) these code paths
can fail to compile with a __SIMPLE_DEVICE__ defined for the entire
stage. Remedy the current situation by just compiling explicity for
ramstage because that was the original intent. In the future,
the __SIMPLE_DEVICE__ selection for postcar can also be re-evaluated.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0f887f1e45f0cf5c235ae5144eaa227921e7119b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14958
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347169
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Some exceptions (like from calling a NULL function pointer) are easier
to narrow down with a dump of the call stack. Let's take a page out of
ARM32's book and add that feature to ARM64 as well. Also change the
output format to two register columns, to make it easier to fit a whole
exception dump on one screen.
Applying to both coreboot and libpayload and syncing the output format
between both back up.
BUG=None
BRANCH=None
TEST=None
Change-Id: I19768d13d8fa8adb84f0edda2af12f20508eb2db
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14931
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347166
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
On apollolake the boot media layout is different in that the
traditional "BIOS" region contains another data structure with
the boot assets such as CSE firmware, PMC microcode,
CPU microcode, and boot firmware to name a few. There's also a
sort of recovery mechanism where there is a second data structure
with similar contents halfway through the "BIOS" region. This
second structure is referred as the logical boot partition 2 (LBP2),
and it's optionally employed.
Add support for writing the LBP2 to a specified FMAP region to
accommodate platforms which require it.
BUG=None
BRANCH=None
TEST=None
Change-Id: I1959a790f763b409238dea6b62408b42122e590e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14924
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346994
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add a handler for soc/intel/apollolake to return the ACPI path for
GPIOs. There are 4 GPIO "communities" on apollolake that each have a
different ACPI device so return the appropriate name for the different
communities.
BUG=None
BRANCH=None
TEST=None
Change-Id: I596c178b7813ac6aaeb4f2685bb916f5b78e049b
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14859
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346993
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add a handler for the Intel Skylake SOC to return the ACPI path for
GPIOs. Since all GPIOs are handled by the same controller they all
have the same ACPI path and this is a simple handler that just returns
a pointer to the GPIO device that is defined in the DSDT.
BUG=None
BRANCH=None
TEST=None
Change-Id: I24ff3a6f2479d9e7eeace65d49e2f6c2e070f3e9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14843
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346992
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add a new function "gpio_acpi_path()" that can be implemented by
SoC/board code to provide a mapping from a "gpio_t" pin to a
controller by returning the ACPI path for the controller that owns
this particular GPIO.
This is implemented separately from the "acpi_name" handler as many
SOCs do not have a specific device that handles GPIOs (or may have
many devices and the only way to know which is the opaque gpio_t)
and the current GPIO library does not have any association with the
device tree.
If not implemented (many SoCs do not implement the GPIO library
abstraction at all in coreboot) then the default handler will return
NULL and the caller knows it cannot determine this reliably.
BUG=None
BRANCH=None
TEST=None
Change-Id: Iaa0ff6c8c058f00cddf0909c4b7405a0660d4cfb
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14842
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346991
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add a global ACPI device name handler for the Skylake SOC that will
translate skylake device paths into an ACPI path that matches the
device objects delcared in the DSDT at soc/intel/skylake/acpi/*.
The skylake implementation uses a global acpi_name handler for the
SOC and it is not necessary to add a function to every device.
This function is used by device drivers calling acpi_device_name()
and acpi_device_path() to generate ACPI AML in the SSDT.
BUG=None
BRANCH=None
TEST=None
Change-Id: I31cecf7905a51224e7bfc40c6c4ad2487f039097
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14841
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346990
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Add a function to "struct device_operations" to return the ACPI name
for the device, and helper functions to find this name (either from
the device or its parent) and to build a fully qualified ACPI path
from the root device.
This addition will allow device drivers to generate their ACPI AML in
the SSDT at boot, with customization supplied by devicetree.cb,
instead of needing custom DSDT ASL for every mainboard.
The root device acpi_name is defined as "\_SB" and is used to start
the path when building a fully qualified name.
This requires SOC support to provide handlers for returning the ACPI
name for devices that it owns, and those names must match the objects
declared in the DSDT. The handler can be done either in each device
driver or with a global handler for the entire SOC.
Simplified example of how this can be used for an i2c device declared
in devicetree.cb with:
chip soc/intel/skylake # "_SB" (from root device)
device domain 0 on # "PCI0"
device pci 19.2 on # "I2C4"
chip drivers/i2c/test0
device i2c 1a.0 on end # "TST0"
end
end
end
end
And basic SSDT generating code in the device driver:
acpigen_write_scope(acpi_device_scope(dev));
acpigen_write_device(acpi_device_name(dev));
acpigen_write_string("_HID", "TEST0000");
acpigen_write_byte("_UID", 0);
acpigen_pop_len(); /bin /boot /cdrom /dev /etc /home /initrd.img /initrd.img.old /lib /lib32 /lib64 /libx32 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old device */
acpigen_pop_len(); /bin /boot /cdrom /dev /etc /home /initrd.img /initrd.img.old /lib /lib32 /lib64 /libx32 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old scope */
Will produce this ACPI code:
Scope (_SB.PCI0.I2C4) {
Device (TST0) {
Name (_HID, "TEST0000")
Name (_UID, 0)
}
}
BUG=None
BRANCH=None
TEST=None
Change-Id: Ie149595aeab96266fa5f006e7934339f0119ac54
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14840
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346989
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
acpigen_write_uuid() will generate a ToUUID() 128-bit buffer object for a
common universally unique identifier that is passed as a string. The
resulting buffer is the UUID in byte format with a specific order of the
bytes as described in the ACPI specification:
ToUUID (uuid)
Compiles to:
Buffer (16) { uuid[3], uuid[2], uuid[1], uuid[0], uuid[5], uuid[4],
uuid[7], uuid[6], uuid[8], uuid[9], uuid[10], uuid[11],
uuid[12], uuid[13], uuid[14], uuid[15] }
BUG=None
BRANCH=None
TEST=None
Change-Id: Ibbeff926883532dd78477aaa2d26ffffb6ef30c0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14838
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346988
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
This function will turn a string of ASCII hex characters into an array
of bytes. It will ignore any non-ASCII-hex characters in the input
string and decode up to len bytes of data from it.
This can be used for turning MAC addresses or UUID strings into binary
for storage or further processing.
Sample usage:
uint8_t buf[6];
hexstrtobin("00:0e:c6:81:72:01", buf, sizeof(buf));
acpigen_emit_stream(buf, sizeof(buf));
BUG=None
BRANCH=None
TEST=None
Change-Id: I2de9bd28ae8c42cdca09eec11a3bba497a52988c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14837
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346987
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Certain mainboards, e.g. the ASUS KGPE-D16/KCMA-D8, require
board-specific configuration changes to the SuperIO. Expose
the functions needed to enter and exit configuration mode
on Winbond devices.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ic86651872ecafcfe1398201be2b0768bbe460975
Original-Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Original-Reviewed-on: https://review.coreboot.org/14891
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Original-Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346986
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
The src/acpi/Kconfig was being sourced close to the top of the Kconfig
tree, which doesn't allow it to be overridden by mainboards or chipsets.
Moving it lower in the tree allows for the defaults to be overridden.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0b100f5535c5f383e8c6db74d0024c5ff2e8c08d
Original-Signed-off-by: Martin Roth <martinroth@google.com>
Original-Reviewed-on: https://review.coreboot.org/14878
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346985
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Since FSP-M is run in CAR (as opposed to XIP), its default link
address may need to be changed. Since cbfstool can relocate FSP
blobs, take advantage of that feature.
BUG=None
BRANCH=None
TEST=None
Change-Id: I4353fe09d785c090843ce25ff4e654d45c64c381
Original-Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14866
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346984
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Follow the convention used on all other platforms and explicitly call
console_init() before any printk(). This call was most likely ommitted
by accident during rebase.
Also remove the "Starting romstage..." message, as console_init() will
print a standardized message. I don't have details on how this message
originally appeared.
BUG=None
BRANCH=None
TEST=None
Change-Id: Id91f0fc15ecbd3635d67a261907f4c6af9a499ab
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14864
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346982
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
We have a timestamp from before cache-as-ram setup saved in the MMX
registers. Recover that timestamp, and use it as the base timestamp
rather than letting lib/bootblock.c use a late timestamp.
This allows more accurate profiling of the boot flow, since CAR setup
time is no longer excluded from the timing information.
BUG=None
BRANCH=None
TEST=None
Change-Id: I055092c600438c5260ab67509434a38f1eb77fe4
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14863
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346981
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
This is useful, for example, in the bootblock, when a timestamp is
available which predates the call to main() in lib/bootblock.c
BUG=None
BRANCH=None
TEST=None
Change-Id: I17bb0add9f2d8721504b2e534dd6904d1201989c
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14862
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346980
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
timestamp_cache_get() would call timestamp_cache_init() whenever it
found a timestamp cache in the TIMESTAMP_CACHE_UNINITIALIZED state.
That means that timestamp_cache_get() will never reurn a cache in the
uninitialized state.
However, timestamp_init() checks against the uninitialized state, as
it does not expect timestamp_cache_get() to perform any initialization.
As a result, the conditional branch can never be reached.
Simply remove the timestamp_cache_init() call from timestamp_cache_get().
BUG=None
BRANCH=None
TEST=None
Change-Id: I573ffbf948b69948a3b383fa3bc94382f205b8f8
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14861
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346789
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
timestamp.c was not included in bootblock and postcar. This means that
these two stages would use the weak implementation in lib/timestamp.c
instead of the arch-specific implementation based on rdtsc.
This resulted in using timer_monotonic_get() which resets the
timestamps from 0. timer_monotonic_get() only provides per-stage
incrementing semantics on x86 because lapic implementation has
counting down values. A globally incrementing counter like rdtsc
provides the semantics like every other non-x86.
On the test configuration, the weak implementation of timestamp_get()
returned zero, resulting in wrong timestamps coming from the bootblock,
while romstage and ramstage used the arch implementation and returned
correct timestamps.
This is a great example of why weak functions are dangerous, and how
easy it is to miss subtle yet strong interactions between subsystems
and the coreboot buildsystem.
BUG=None
BRANCH=None
TEST=None
Change-Id: I656f9bd58a6fc179d9dbbc496c5b684ea9288eb5
Original-Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14860
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346788
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
The timer emulation works by deriving a frequency based off the
Common Timer Copy with a frequency of 19.2MHz.
The desired frequency = (19.2MHz * multiplier) >> 32;
With that knowledge update the code to let the compiler perform
the necessary math based on target frequency.
BUG=None
BRANCH=None
TEST=None
Change-Id: I716c7980f0456a7c6072bbaaddd6b7fcd8cd5b37
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/14889
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346787
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Having CFLAGS with -Os disables -falign-function, for
unlucky builds this may delay entry to ramstage by 600ms.
Build the low-level IO functions aligned with -O2 instead.
Change-Id: Ice6781666a0834f1e8e60a0c93048ac8472f27d9
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/14414
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 08311f5033)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346627
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As of now FSP-M can not be relocated and it can not be instructed
to use a specific resource for temporary memory. As result coreboot
is forced to use CAR layout dictated by default FSP-M configuration.
Change CAR size to 1MiB, link romstage at such CAR address so it
doesn't overlap with FSP-M's default heap/stack.
Change-Id: I56f78f043099dc835e294dbc081d7506bfad280d
Original-Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14804
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
(cherry-picked from commit 0e46307574)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346623
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, StackBase field doesn't work and changing it from default
value leads to crash.
Change-Id: Id3f3ea9a834d0c04a8381938535109d6a729cca2
Original-Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14803
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 5ede3d8cce)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add I2C chip initialization for the Galileo boards.
TEST=Build and run on Galileo Gen2
Change-Id: Ib5284d5cd7a67de2f3f98940837ceb2aa69af468
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14829
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 15843bdad0)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346616
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the I2C driver.
TEST=Build and run on Galileo Gen2
Change-Id: I53fdac93667a8ffb2c2c8f394334de2dece63d66
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14828
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit ac690b1e9b)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346615
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Set the base address and enable the GPIO and legacy GPIO controllers.
Call the mainboard routine to initialize the GPIO controllers.
TEST=Build and run on Galileo Gen2
Change-Id: I06aed5903d6655d2a0948fb544cf9e0db68faa26
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14827
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 3f0fe68c4b)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add Kconfig to configure coreboot for a specific Galileo board.
Configure the GPIOs for the specific Galileo board.
TEST=Build and run on Galileo Gen2
Change-Id: I992460d506b5543915c27f6a531da4b1a53d6505
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/14826
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 274d20a065)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346611
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
strlen(string) was on the negative side of the selection operator, the
side where string is NULL.
Change-Id: Ic421a5406ef788c504e30089daeba61a195457ae
Reported-by: Coverity Scan (CID 1355263)
Original-Signed-off-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Original-Reviewed-on: https://review.coreboot.org/14867
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@google.com>
(cherry-picked from commit 0ba307f0fe)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346610
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
