Urara CBFS header configuration is broken. CBFS header needs to be
right above the bootblock, and the CBFS data - 0x100 bytes above, to
allow room for proper CBFS wrapper structures.
Ideally only the header offset should be specified (and even that
could be derived from the bootblock size). But this is a more generic
problem to be addressed with different architectures' image layout
requirements in mind.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=coreboot image passes the integrity check now (it was failing
before because CBGS header was overlaying the bootblock)
$ FEATURES=noclean emerge-urara coreboot
$ /build/urara/tmp/portage/sys-boot/coreboot-9999/work/coreboot-9999/build/util/bimgtool/bimgtool \
/build/urara/firmware/coreboot.rom.serial
$ cbfstool /build/urara/firmware/coreboot.rom.serial print
coreboot.rom.serial: 1024 kB, bootblocksize 9956, romsize 1048576, offset 0x4100
alignment: 64 bytes, architecture: mips
Name Offset Type Size
fallback/romstage 0x4100 stage 7100
fallback/ramstage 0x5d00 stage 18995
config 0xa780 raw 2452
(empty) 0xb140 null 1003096
Change-Id: Id615bdcc6261dea9f36a409bd90f1e4764353bb9
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8a0115963aa7460e4c7255ab8508d7d52d67fb67
Original-Change-Id: Id200ab5421661ef39b7c7713e931c39153fdc8be
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227523
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9187
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit f69a99db (coreboot: x86: enable gc-sections) added
gc-sections to the linker command line. The SMM-specific
linker scripts were not interrogated to see if all the
sections were being included properly. .data, .bss, and .sbss
did not have the proper globs set to put the SMM programs in
the expected order.
Lastly, explicitly set the ENTRY for the SMM programs.
Change-Id: Ibb579d18d4819af666d6ec7dfc30776e8c404b71
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9160
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It's x86 specific.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Iacb91b47c89041435dd27c2c9ad34a231adf21d2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9115
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
We have .lb, .lds, and .ld in the tree. Go for .ld everywhere.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I3126af608afe4937ec4551a78df5a7824e09b04b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This resolves an issue where large sections of the cbmem logs
were being dropped on AMD Fam10h boards.
Change-Id: I0e4e86e169aa4f20f06472f1a6e3136705ae4f9d
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8851
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add build infrastructure and basic support code for the ImgTec Danube
SoC. This support is sufficient to run on a simulator.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I59e36589765bf06b075fd4850215a0ef71246bb1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 881278d7fbb8e6803bc8f6f9e84c64640b097401
Original-Change-Id: Ia7ed7288b13085db7ff37b5ad75d978b6137f958
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8762
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the build infrastructure and basic architectural support required
to build for targets using the MIPS architecture. This is sufficient
to run on a simulator, but will require the addition of some cache
maintenance and timer setup in order to run on real hardware.
BUG=chrome-os-partner:31438, chromium:409082
TEST=none yet
Change-Id: I027902d8408e419b626d0aab7768bc564bd49047
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fcc0d934d7223922c878b1f87021cb5c2d7e6f21
Original-Change-Id: If4f99554463bd3760fc142477440326fd16c67cc
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207972
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8760
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mainboards/amd/fam10: Initialize cbmem area after raminit
When GFXUMA is enabled, CBMEM is placed at TOM - UMASIZE
When GFXUMA is disabled, CBMEM is placed at TOM
This matches the behaviour present before conversion to early
CBMEM.
The CBMEM location code implicitly assumes TOM does not change
between romstage and ramstage. TOM is set by romstage raminit,
and is never changed by romstage or ramstage afterward. As
the CBMEM location is positioned at a specific offset from TOM
that is known to both romstage and ramstage early CBMEM is safe
on Fam10h systems.
TEST: Booted ASUS KFSN4-DRE and verified both cbmem timestamp
tables from romstage and cbmem log tables from ramstage.
Change-Id: Idf9e0245fe91185696ff664b06182c26b376c196
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8489
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
The GCC 4.9.2 update showed that the boot_state_init_entry
structures were being padded and assumed to be aligned in to an
increased size. The bootstate scheduler for static entries,
boot_state_schedule_static_entries(), was then calculating the
wrong values within the array. To fix this just use a pointer to
the boot_state_init_entry structure that needs to be scheduled.
In addition to the previous issue noted above, the .bs_init
section was sitting in the read only portion of the image while
the fields within it need to be writable. Also, the
boot_state_schedule_static_entries() was using symbol comparison
to terminate a loop which in C can lead the compiler to always
evaluate the loop at least once since the language spec indicates
no 2 symbols can be the same value.
Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In some previous attempt to enable monotonic timers on all platforms,
the LAPIC monotonic timer was selected for Haswell devices, despite
the fact that LAPIC timers are not used in coreboot on Haswell
(See haswell Kconfig) and there already was a monotonic timer
implementation enabled that just needed to be added for SMM as well.
Change-Id: I6beb2977864e507956636860ed463e1991cea1ed
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8702
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
From GCC's documentation:
Optimize debugging experience. -Og enables optimizations that do not interfere
with debugging. It should be the optimization level of choice for the standard
edit-compile-debug cycle, offering a reasonable level of optimization while
maintaining fast compilation and a good debugging experience.
Change-Id: I9a3dadbf8e894cb28e29d7b2f4e9add252e7bbb3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8689
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This makes the change to the cpu/amd/pi/00730F01 that was
made for the cpu/amd/agesa based boards in:
commit 48518f0d
AGESA: Add amd_initcpuio() and amd_initmmio()
These are not wrappers for AGESA as they do not enter vendorcode at all.
We expect most of the added fixme.c file to be written without use of AMDLIB.h
and parts relocated as northbridge enable_resources().
The equivalent change has already been made for cpu/amd/pi/00630F01.
Change-Id: I591b50ee807436f5a1dee14d2c88a77462024744
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8670
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
BIOS Writer's Guide, rev 1.6.0, June 2012:
This MSR controls whether and FERR message is sent over the system bus
when unmasked x87 exceptions are generated.
This feature is not supported from Sandy Bridge processor onwards.
Change-Id: I19b260ca4b62f57c26989430693b00b9853bc441
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8658
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This was added to handle cases of Intel FSP platforms that had
EARLY_CBMEM_INIT but could not migrate CAR variables to CBMEM.
These boards were recently fixed.
To support combination of EARLY_CBMEM_INIT without CAR migration was
added maintenance effort with little benefits. You had no CBMEM
console for romstage and the few timestamps you could store were
circulated via PCI scratchpads or CMOS nvram.
Change-Id: I5cffb7f2b14c45b67ee70cf48be4d7a4c9e5f761
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8636
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Since commit ee894357 (cpu/intel (non-FSP): Use microcode from
blobs repository), selecting the option to generate the
microcode from tree fails without allowing to use the BLOBs/
3rdparty repository, which is the default setting.
Therefore, only show the option, if the user has selected the
option to allow the use of the BLOBs repository.
Change-Id: Ide20da0f946aae43dc2c8cdce54941c704d3d288
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8627
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change brings all agesawrappers in a single file to make it
easier to understand the actual execution flow.
Change-Id: Ifbb2b16e4cccfaa17aaf10887a856797be9b6877
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8605
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We do not allow platforms to mess around with memory layout.
Change-Id: I316ff522c8833fa3b7ad20f2c5a9cae21f4174d8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8604
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The former pstates_algorithm() function has two early exit
points now, and so it might never get around to writing
pstates data.
Change-Id: I19ca937375c6d33b78bd5b1859fa5c25473be9b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8610
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
If a certain register returns crap values, we
determine core_power using an uninitialized variable.
That doesn't sound healthy.
Change-Id: I1e890b78bfcc3bf0255a3d4f6561a783134b1719
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/8508
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Moved mctGetLogicalCPUID() to a separate file and made it available in
both romstage and ramstage.
Change-Id: I959c1caa8f796947b627a7b379c37d7307e2898e
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8499
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Now that we use the microcode updates in the blobs repository, remove
them from the main repo. Since the microcode updates are blobs, it
makes more sense to ship them in the blobs repo rather than the main
one.
The update-microcodes.sh script is also deleted, as a more current
version resides in 3rdparty.
Change-Id: Iee74a3ede3b5eb684ef0386d270120e70173c1b4
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4531
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that microcode has been added to blobs, use that one instead of
the one included in the tree. Microcode from the tree will be
removed in a subsequent patch. Since the microcode updates are blobs,
they belong in the blobs repository.
This change may introduce a build failure if the "Generate from tree"
microcode option is selected, but the blobs repository is not
enabled. We have to live with this for now, until microcode is moved
to blobs for all CPUs, at which point we may adjust Kconfig
accordingly.
Leave the FSP cpu alone for now, as that will need approval from
SAGE.
Change-Id: Ia77ba2e26c083da092449b04ab2323b91a2ca15b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4530
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The goto statement skipped all the code that is necessary
to fill in the data structures that are read right after
the jump.
Since there doesn't seem to be useful data, why write these
ACPI objects in the first place?
Change-Id: I1d06c11a7a31517b81e54159355d5c27e3cc3735
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/8507
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This copies a change made in commit 1cc3338 that allows alloc_cbmem()
to be called only in ramstage. This will allow the */cpu/amd/agesa/*
field to be removed from the list of illegal_globals EXCLUDE_FILEs.
TEST: Booted the amd/parmer board.
Change-Id: I2d4b5352815aae090ffce7b83e487f7c0a4d0c88
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8504
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Without this change the builder would fail with the complaint
that there was a global static variable in romstage. alloc_cbmem()
is only called in ramstage. The alternative was to add
*/cpu/amd/pi/*.romstage.o to the list of illegal_globals
EXCLUDE_FILEs in arch/x86/init/romstage.ld.
TEST: Booted the amd/lamar board.
Change-Id: I5167910ff790a3152a4ad8e5af0a4a3b17894f0f
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8256
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds the AMD Family 15h model 30 CPU.
S3 suspend/resume currently is not supported.
Tested on the amd/lamar platform.
Change-Id: Ifef55747a5d715b17937fc75ab9d35945b59f0e6
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/7248
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The coreboot I²C API was completely reworked in commit
* cdb61a6 i2c: Replace the i2c API.
For the allwinner I²C driver, wrappers to the old API were provided
on a "best guess" basis. Replace these wrappers with proper
transaction handling based on the i2c_seg API.
Change-Id: Ibdda3b022ce4876deb2906e17a5a0ca9e939aada
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8431
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
These settings are specific to the SteppeEagle SOC and should
be made in its northbridge code rather than the CPU code.
Change-Id: I1a231f95225e1414b0cbc026a2a7b7797bd91fca
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8254
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
They seem to have been copy-pasted during the backport from sandybridge.
Change-Id: I2277bb90e6da2676b31eb2665b7c15f074e3d4bf
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8295
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
The existing code generated invalid ACPI processor objects
if the core number was greater than 9. The first invalid
object instance was autocorrected by Linux, but subsequent
instances conflicted with each other, leading to a failure
to boot if more than 10 CPU cores were installed.
The modified code will function with up to 99 cores.
Change-Id: I62dc0eb61ae2e2b7f7dcf30e9c7de09cd901a81c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8422
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The default linking behavior of ramstage was changed in commit
* 8f99378 ARMv7/Exynos: Fix memory location assumptions
However, that commit failed to address the issue of maintaining
linking behavior on non-Exynos chips. As a result we ended up
linking ramstage at address 0, which is outside of SDRAM.
Explicitly link ramstage at SDRAM base for A10. This patch does not
address the issue on other chips that were broken by commit 8f99378.
Change-Id: I90fa41d3eabf110b5ab24c31b78ac6d0474e4083
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8443
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The core count identification code in the PowerNow! _PSS
ACPI object generation code was incorrectly copied from the
model_fxx code. This code has been rewritten to properly
return the number of cores installed in the system.
Change-Id: I19567486f2de9dc2c43970addf4d91fa3d233a99
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8421
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
microcode updates are extracted from: www.amd64.org/microcode.html
Mircocode versions of 1020h and 1022h are more recent in coreboot
than inside the AMD archive.
Change-Id: I9f52accc1ebc7057890a769a059048e9982109d2
Signed-off-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-on: http://review.coreboot.org/8354
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Improve documentation of lock down MSRs in finalize().
Most of these aren't documented in public MSRs.
Change-Id: I4fc47bb9b71bdd7907aae65fc18b419a17ae8547
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8294
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Peter Stuge <peter@stuge.se>
Fix a mistake that led to an invalid 0ms latency in the automatically
generated PowerNow! ACPI _PSS objects.
TEST: Booted FreeBSD and Linux and verified correct latency values.
Found-by: Coverity Scan
Change-Id: I03cecab694708136dc555ca2af7ee9a0bf9be5af
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8376
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
1) Save the pointer to the FSP HOB list to low memory at address 0x614.
This is the same location as CBMEM_RESUME_BACKUP - the two aren't used
in the same platform, so overlapping should be OK. I didn't see any
documentation that actually said that this location was free to use, and
didn't need to be restored after use in S3 resume, but it looks like
the DOS boot vector gets loaded juat above this location, so it SHOULD
be ok. The alternative is to copy the memory out and store it in cbmem
until we're ready to restore it.
2) When a request for the pointer to a CAR variable comes in, pass back
the location inside the FSP hob structure.
3) Skip the memcopy of the CAR Data. The CAR variables do not
get transitioned back into cbmem, but used out of the HOB structure.
4) Remove the BROKEN_CAR_MIGRATE Kconfig option from the FSP platform.
Change-Id: Iaf566dce1b41a3bcb17e4134877f68262b5e113f
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8196
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tests on CPUID are valid regardless of revision.
Change-Id: I5a3a01baca2c0ecfb018ca7965994ba74889a2e2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8337
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Include microcode updates in CBFS for every CPU revision the platform
can support, as changing to different CPU revision should not require
a coreboot rebuild.
This increases CBFS usage from 2 kB to 14 kB.
Change-Id: I6bf90221a688f1a54e49641ce3ba378c5bf659f9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4521
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
This option is now deperecated by loading microcode updates from cbfs.
Remove this option in anticipation of implementing CBFS loading for
AMD cpus. Removing it beforehand results in less patch overhead.
Change-Id: Ibdef7843db686734e2b6b1568692720fb543b240
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8322
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Move mapping tables to struct and prevent OOB array
access that was crashing the APs during CAR initialization.
Change-Id: I9e2554b50ad60a8d02ef4bd3fbee6fddb238d83f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8310
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Skeleton and ACPI generator interface taken from
model_fxx powernow_acpi.c
Small portions of FIDVID MSR code taken from
model_10xxx fidvid.c
Nearly completely rewritten for the P-state-based K10 CPU
TEST: KFSN4-DRE with dual Opteron 8356 CPUs
Verified CPU per-core dynamic state change with system load
Verified reported P-state count and frequencies
Stress-tested each CPU (all cores simultaneously) to verify
proper P0 transition and configuration.
Change-Id: Icf620ec96a3f163b62d96b5988184996641dd439
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8284
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Drop the implementation of statically allocated high memory
region for CBMEM. There is no longer the need to explicitly
select DYNAMIC_CBMEM, it is the only remaining choice.
Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7851
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
The name was always obscure and confusing. Instead define cbmem_top()
directly in the chipset code for x86 like on ARMs.
TODO: Check TSEG alignment, it used for MTRR programming.
Change-Id: Ibbe5f05ab9c7d87d09caa673766cd17d192cd045
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7888
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Move the CAR migration call to arch -specific part of CBMEM init,
it is truly a x86 specific thing.
Change-Id: I715417e54f197b8745e0670d6b900a5660178141
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7860
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
With the change it becomes irrelevant if memcpy() car.global_data or
cbmemc_reinit() is done first.
Change-Id: Ie479eef346c959e97dcc55861ccb0db1321fb7b2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8032
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This reverts the revert commit 5780d6f387
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Propagate commit 9107e53 from amd/agesa and fix some
related #includes under cpu/amd/pi.
Change test to return true on S2 wakeup too. In S2 CPU would
have been powered down so MTRR recovery is required.
Change-Id: I18cb31c1124da53e5fcba2610f6b02d755feb092
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8171
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This adds a block in the SMI handler to call init functions for
drivers which may be used in SMM. A static variable is used to
ensure the init functions are only called once.
BUG=chrome-os-partner:29580
BRANCH=mccloud
TEST=Built and booted on mccloud, system no longer hangs when
pressing power button at the dev mode screen. Also tested on parrot.
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I225f572f7b3072bec2bc06aac3fb50d90a2e30ee
Original-Reviewed-on: https://chromium-review.googlesource.com/204764
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 9315c485deb5f24df753e2d69f4819b2cb6accc2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8d2b21765c35c7ac7746986d5334dca17dcd6861
Reviewed-on: http://review.coreboot.org/8134
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Because we had no stack on romcc boards, we had a separate, not as
powerful clone of printk: print_*. Back in the day, like more than
half a decade ago, we migrated a lot of boards to printk, but we never
cleaned up the existing code to be consistent. instead, we worked around
the problem with a very messy console.h (nowadays the mess is hidden in
romstage_console.c and early_print.h)
This patch cleans up the cpu code to use printk() on all non-ROMCC
boards.
Change-Id: I233c53300f9a74bce4b828fc4074501a77f7b593
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8114
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
The doxygen parameter names in the comments no longer matched the
functions they were attached to. Doxygen complains about extra
parameter comments and uncommented parameters in the functions.
Change-Id: I21b8a951f8d8d04b07c3779000eeaf1e69fed463
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/8101
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The static allocator only worked for x86 anyway.
Change-Id: I0d2b63465620512e62334d7aa0c885fc5ab3e589
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8030
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The static allocator only worked for x86 anyway.
Change-Id: Iadaab225fea04b455c559c25b918a2a842b9faca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8029
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We relocate GDT to CBMEM, this can be done late in ramstage.
Note: We currently do this for BSP CPU only.
Change-Id: I626faaf22f846433f25ca2253d6a2a5230f50b6b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7858
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This patch adds I2C emulation in software through raw toggling of the
SDA/SCL lines. Platforms need to provide bindings to toggle their
respective I2C busses for this to work (e.g. by pinmuxing them as GPIOs,
currently only enabled for Tegra).
This is mostly useful as a debugging feature, to drive unusual states on
a bus and closely monitor the device output without the need of a bus
analyzer. It provides a few functions to "wedge" an I2C bus by aborting
a transaction at certain points, which can be used to test if a system
can correctly recover from an ill-timed reboot. However, it can also
dynamically replace the existing I2C transfer functions and drive
some/all I2C transfers on the system, which might be useful if a driver
for the actual I2C controller hardware is not (yet) available.
Based on original code by Doug Anderson <dianders@chromium.org> and
Hung-ying Tyan <tyanh@chromium.org> for the ChromeOS embedded
controller project.
BRANCH=None
BUG=chrome-os-partner:28323
TEST=Spread tegra_software_i2c_init()/tegra_software_i2c_disable()
through the code and see that everything still works.
Original-Change-Id: I9ee7ccbd1efb38206669a35d0c3318af16f8be63
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198791
Original-Reviewed-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 8f71503dbbd74c5298e90e2163b67d4efe3e89db)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id6c5f75bb5baaabd62b6b1fc26c2c71d9f1ce682
Reviewed-on: http://review.coreboot.org/7947
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The following patches had to be squashed
to properly build all the different ARM boards.
ipq8064: storm: re-arrange bootblock initialization
The recent addition of the storm bootblock initialization broke
compilation of Exynos platforms. The SOC specific code needs to be
kept in the respective source files, not in the common CPU code.
As of now coreboot does not provide a separate SOC initialization API.
In general it makes sense to invoke SOC initialization from the board
initialization code, as the board knows what SOC it is running on.
Presently all what's need initialization on 8064 is the timer. This
patch adds the SOC initialization framework for 8064 and moves there
the related code.
BUG=chrome-os-partner:27784
TEST=manual
. nyan_big, peach_pit, and storm targets build fine now.
Original-Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197835
(cherry picked from commit 3ea7307b531b1a78c692e4f71a0d81b32108ebf0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
arm: Redesign mainboard and SoC hooks for bootblock
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 257aaee9e3aeeffe50ed54de7342dd2bc9baae76)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id055fe60a8caf63a9787138811dc69ac04dfba57
Reviewed-on: http://review.coreboot.org/7879
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Always build CBMEM for romstage, even for boards that will not use it.
We further restrict car_migrate_variables() runs to non-ROMCC boards without
BROKEN_CAR_MIGRATE.
This fixes regression of commit 71b21455 that broke CBMEM console support
for boards with a combination of !EARLY_CBMEM_INIT && !HAVE_ACPI_RESUME.
Change-Id: Ife91d7baebdc9bd1e086896400059a165d3aa90f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7877
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
When using fixed MTRRs for CAR setup, CONFIG_DCACHE_RAM_BASE is ignored
and was not correctly set on affected sockets and boards. It was still
referenced in romstage linker script. This was discovered by clang builds
failing for cases where DCACHE_RAM_BASE = 0, while gcc builds passed.
The actual DCACHE_RAM_BASE programming is base = 0xd0000 - size, as taken
from intel/cpu/cache_as_ram.inc.
Change-Id: Ied5ab2e9683f12990f1aad48ee15eaf91133121c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7887
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
CPU_MICROCODE_CBFS_LOC used a non-existing dependency variable
CPU_MICROCODE_IN_CBFS. This broke alignment of microcode in CBFS.
Remoce CPU_MICROCODE_CBFS_LOC from global namespace as it is only
used with PLATFORM_FSP.
CPU_MICROCODE_CBFS_LEN was no longer used at all.
Change-Id: I0454397924d2526d97b1f095cc371ba962873c99
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7957
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Not part of wrapper to AGESA, but workaround for enable_resources().
Also remove remains of comments in non-fam14 wrappers.
Change-Id: I2526821ca283feb6a506b602b86f817f8b03b341
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7816
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
These are not wrappers for AGESA as they do not enter vendorcode at all.
We expect most of the added fixme.c file to be written without use of AMDLIB.h
and parts relocated as northbridge enable_resources().
Change-Id: Iba6d59e2a7672349208e9a65fcd2cb1094ab7d50
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7815
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Board has no chance of working without a cache_as_ram.inc, but without
a specified CAR region we also break builds.
Change-Id: I98e9db38c5e0a7bf4a1b8d2f8a693cc8d0c773b9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7863
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
commit 8b685398 (ARM: Overhaul the ARM Makefile.)
changes config flags for cpu and mainboard bootblock initialization.
Tested on beaglebone black.
Change-Id: I70cbe3abad8443c5dc71c8ba76a35973a5284477
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/7189
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Only used for AMD K8 siemens/sitemp_g1p1 with southbridge rs690.
Change-Id: Ie98a77ce190b1bd35996c7f25da0a0fe9819c9c3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7809
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Only used on non-AGESA board siemens/sitemp_g1p1 and already dropped
from other AGESA families.
Change-Id: Ifa726d38216c8b684af06af26b701daa99c42e8c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7808
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
There is no Cache As Ram for these boards, let's get rid of them.
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ia70befc59708c360ad02ed7e3a49d3b0f95dc707
Reviewed-on: http://review.coreboot.org/7119
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is no Cache As Ram for these boards, let's get rid of them.
Change-Id: Ib41f8cd64fc9a440838aea86076d6514aacb301c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/7117
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Flag the boards with BROKEN_CAR_MIGRATE, as testing for EARLY_CBMEM_INIT
is not enough to disable CBMEM console for romstage on these platforms.
To have CBMEM early in ramstage, define get_top_of_ram() on sandy/ivy.
Change-Id: Ieefc12099a0e043eb1a7e14bdc7c6e3d209b3d8f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7468
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Martin Roth <gaumless@gmail.com>
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Original-Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193561
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 00c423fb2c06c69d580ee3ec0a3892ebf164a5fe)
This cherry-pick required additional changes to the following:
src/cpu/allwinner/a10/twi.c
src/drivers/xpowers/axp209/axp209.c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I691959c66308eeeec219b1bec463b8b365a246d7
Reviewed-on: http://review.coreboot.org/7751
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BOOT_MEDIA_SPI_BUS is a Kconfig variable used on some ARM-based
platforms to set up CBFS media. It turns out it can also be helpful
for setting up the eventlog which is intended to reside on the same
SPI flash as CBFS. Setting it for x86 will allow us to remove an
assumption about which SPI bus is used for this flash device.
Long term this can go away as we come up with a better abstraction
for the eventlog's backing store. This is only intended to help us
get from here to there.
BUG=none
BRANCH=none
TEST=built and booted on Link
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I1d84dc28592fbece33a70167be59e83bca9cd7bc
Original-Reviewed-on: https://chromium-review.googlesource.com/191202
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 200aa7c5b1b1f4c74412893cf7231a12e2702463)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: If988bcff5244ec6a82580203471b25fac49c45ef
Reviewed-on: http://review.coreboot.org/7752
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
powernow_acpi.c array TDP has 20 entries, yet the loop that reads it
processes 21 entries. This causes a gcc 4.9.2 build failure. Limit
processing to 20 entries.
Change-Id: Ice173b276293184386cd8943a3213f3154f86458
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7791
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Following the same reasoning as commit
ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library
Since AGESA is stage-independent, we can build it just once, and use
the resulting static library in both rom and ram stages.
Change-Id: I8fbb318daacf64a14a71022705eb040a01c34fa8
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7699
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The contents of these files were guarded by a check for the _MSC_VER
macro, which we don't use.
Change-Id: Ic595c8e6284c54e1449cf21e0cebee8c9ce7c682
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7670
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Move the Kconfig variable into a .h file - this does not need to be
in Kconfig.
Change-Id: I1db20790ddb32e0eb082503c6c60cbbefa818bb9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/7646
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Originally from commit 4ca72139 move this code now from
cpu/ to northbridge/.
Change-Id: I38517cff273dd8f78bf5eda1d48fd1cd820ced88
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7603
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
commit 8b685398 (ARM: Overhaul the ARM Makefile.)
changes config flags for cpu and mainboard bootblock initialization.
Tested on a20/cubieboard2.
Change-Id: I753aa60ff66de9a3352a3a0759e4d0be9d8ae1c7
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/7187
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
No need to pass calls through gcc in one case and
directly to binutils in another. Just always call
binutils.
Change-Id: Icf9660ce40d3c23f96dfab6a73c169ff07d3e42b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7610
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Let's just call ld directly for gcc, too.
Change-Id: I305eb92ed0d21b098134a7eb5a9f9fe3b126aeea
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7553
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We build with either gcc or clang, no need to keep both around
Change-Id: I9af2cc7636bdc791a68ba8ed6e7c5a81973c5dfd
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7552
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
gcc 4.8.3 broke on it, and the u-boot code that this was
derived from contains the same change.
Change-Id: I3936567a1bee3eceb469373a81e464b1238fdf9c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7538
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Presumably this output made sense when the code was first being
developed.
Change-Id: I3380d6996838a9405b324d57ec449830ed88a99a
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7544
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This interface is common with AMD PI implementations.
Change-Id: Ifabfce97db749e04aa19e53f62216be78158b282
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7150
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
To backport features introduced with recent Chromebooks and/or Intel
boards in general, heavy work on the AMD AGESA platform infrastructure
is required. With the AGESA PI available in binary form only, community
members have little means to verify, debug and develop for the said
platforms.
Thus it makes sense to fork the existing agesawrapper interfaces, to give
AMD PI platforms a clean and independent sandbox. New directory layout
reflects the separation already taken place under 3rdparty/ and vendorcode/.
Change-Id: Ib60861266f8a70666617dde811663f2d5891a9e0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7149
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
The sequence of bytes to create a method is used several times in codebase.
Put it into a function with logical arguments rather than duplicating magic
bytes everywhere.
Change-Id: I0e55d8dc7d5e8e92a521c7a83117c470d0614008
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7347
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Old routine copied all of CAR region as-is right below CONFIG_RAMTOP.
Most of this region was reserved to interleave AP CPU address spaces
and unused on BSP CPU. The only part of CAR region requiring a copy
in RAM is the sysinfo structure.
Improved routine changes this as follows:
A region of size 'backup_size' below CONFIG_RAMTOP is cleared. In
case of S3 resume, OS context from this region is first copied to
high memory (CBMEM_ID_RESUME).
At stack switch, CAR stack is discarded. Top of the stack for BSP
is located at 'CONFIG_RAMTOP - car_size' for the remaining part
of the romstage. This region is part of 'backup_size' and was zeroed
before the switch took place.
Before CAR is torn down the region of CAR_GLOBALS (and CAR_CBMEM),
including the relevant sysinfo data for AP nodes memory training,
is copied at 'CONFIG_RAMTOP - car_size'.
NOTE: While CAR_GLOBAL variables are recovered, there are currently
no means to calculate their offsets in RAM.
NOTE: Boards with multiple CPU packages are likely already broken since
bbc880ee amdk8/amdfam10: Use CAR_GLOBAL for sysinfo
This moved the copy of sysinfo in RAM from above the stack to below
the stack, but code for AP CPU's was not adjusted accordingly.
Change-Id: Ie45b576aec6a2e006bfcb26b52fdb77c24f72e3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4583
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Broken linkage rule for Clang builds on one side of a
branch. Hence refactor out common rules from branch.
Change-Id: I00e5a2f5f9af1b7882a453caebb378ef74d2d51e
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7425
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Ensure that the SMM build stage links properly using the compiler-rt
runtime under a Clang build.
Change-Id: Iead28c46d63f5bbb27757b7dc66fe06b4813d03c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6462
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The fan can stop but can't run again. "AGESA: Call get_bus_conf() just
once" (commit ef40ca57) results to this problem.
This patch can resolve this problem.
Change-Id: I1b5bf3f6f7a66c60743f78918dc5442cdfc8b6e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6981
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
We had lots of casts that caused warnings when compiling on RISCV.
Clean them up.
Change-Id: I46fcb33147ad6bf75e49ebfdfa05990e8c7ae4eb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7066
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As currently many systems would be barely functional without ACPI,
always generate ACPI tables if supported.
Change-Id: I372dbd03101030c904dab153552a1291f3b63518
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4609
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Fix up the following commit by enabling the MTRR's before enabling caching.
7756fe7 x86: Minimize work done with the caches disabled in mtrr functions.
Also fix two typos in comments.
Change-Id: If751b815f9dab781fc38c898cf692f0940c57695
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6969
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The code in src/cpu/x86/mtrr/mtrr.c disables caching in a few places when
changing mtrr settings. While I can't find anything that says that's actually
required, I can believe it's necessary. With that said, other code around the
wrmsr instructions which actually modify the settings should be able to run
with caching enabled with no ill effects.
This is particularly true for two calls to printk, one in the fixed mtrr code
and one in the variable, which could result in an arbitrary amount of work
being done without caching. When changing the implementation of the cbmem
console, these two printks caused a significant regression in boot performance
on link of about 70ms which is about 10% of total firmware boot time. When the
window where the cache is disabled is minimized, both this and the new
implementation were about 30ms faster than the original boot time.
For the variable MTRRs, we now store what we want to set the MSRs to and then
write them all at once at the end of commit_var_mtrrs(). This way we don't
have some set and some not, but we still minimize the time we spend with the
caches disabled.
Change-Id: I5139b262bd2d13f79afd88e2e2c0f514fb3e27c9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187811
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 31529d6d965676c6cedeb62137eabc26819956fc)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6952
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This is essentially a revert of commit 10bd772d. The CAR_MIGRATE
mechanism is only useful to migrate variables from a special region
(e.g. cache as RAM) into DRAM-backed CBMEM between different parts of
the romstage (it does not persist into ramstage). Since ARM devices use
SRAM for which there is no reason to become inaccessible in later parts
of the romstage, this mechanism isn't useful for them. Removing it makes
the romstage.ld script much simpler, which has the nice side-effect of
putting the BSS at the end of the memory image (so that cbfstool can
actually figure out that it doesn't need to be part of the ROM image).
Old-Change-Id: I50e91d8bd51b5deb19446d9da48699edecbef6ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176761
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit ebfd698e57c902e2f39a0cfc1bc2b02665e47ec6)
console: Make cbmem depend on x86.
The cbmem implementation isn't supported on anything other than x86 right now
and actually causes memory corruption on ARM machines. Until that's fixed, this
will prevent people from turning it on and causing hard to track down errors.
Old-Change-Id: I00e8aacf008acfe2f76d4eab82570f7c1cc89cab
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/191107
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit e54f16e346a7f2c66d802fb78a6b24e53b732b83)
Squashed two related commits for cbmem support on arm.
Change-Id: I2be48cea348ee5dc8ca3632d743500aa111bab08
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6888
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Currently there is no way to enable or disable VMX during runtime using
CMOS/NVRAM. It is only possible to configure it during build time by
setting the Kconfig option `CONFIG_ENABLE_VMX`. So update the comment
accordingly.
Change-Id: I4e3294cb39a40cf30d294fd566bc97420592262f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/6228
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
Ubuntu's HDMI audio has noise and echo. Disable NoSnoopEnable can
resolve this issue. The posted amd_late_init.c northbridge code
is missing a test for Steppe Eagle northbridges. See coreboot Gerrit
change 3934, commit ID 4ca721399c (AMD Olive Hill: Disable
NoSnoopEnable to fix HDMI audio corruptions with Ubuntu).
Change-Id: I89894d0ce4ad72ea16d61b445edb9e67920bca24
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6822
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add the CPU files required to support the Steppe Eagle and Mullins
models of Family 16h SoC processors from AMD. This CPU is based on
the Jaguar core and is similar to Kabini.
Change-Id: Ib48a3f03128f99a1242fe8c157e0e98feb53b1ea
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6679
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
The Exynos family and most ARM products are SoC, not just CPU.
We used to put ARM code in src/cpu to avoid polluting the code base for what was
essentially an experiment at the time. Now that it's past the experimental phase
and we're going to see more SoCs (including intel/baytrail) in coreboot.
Change-Id: I5ea1f822664244edf5f77087bc8018d7c535f81c
Reviewed-on: https://chromium-review.googlesource.com/170891
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit c8bb8fe0b20be37465f93c738d80e7e43033670a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6739
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
Old-Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
(cherry picked from commit 8cdaf73e3602e15925859866714db4d5ec6c947d)
snow: Fix a typo in devicetree.cb that was breaking the snow build.
A typo in a recent change broke the snow build.
Old-Change-Id: I93074e68eb3d21510d974fd8e9c63b3947285afd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171014
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 154876c126a6690930141df178485658533096d2)
Squashed a fix into the initial patch and updated nehalem/gma.c
to have a non-static gtt_poll.
Change-Id: I2f4342c610d87335411da1d6d405171dc80c1f14
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6657
Tested-by: build bot (Jenkins)
The register indexes and bitfield masks were guarded by the UART8250 config
options, but it might be (is) necessary to use them in a driver that is
UART8250 like without actually using the 8250 driver itself. To avoid any name
collision with other drivers, also change the constant prefix from UART_ to
UART8250_.
Change-Id: Ie606d9e0329132961c3004688176204a829569dc
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171336
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a93900be8d8a8260db49e30737608f9161fbf249)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6715
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The ARM Makefile was copied from x86 and then modified, and as a result it
was carrying a lot of baggage. On top of that, the extra complication made it
inflexible, and we need a lot of flexiblity in order to support the fact that
the Tegra124 starts on an ARMv4 coprocessor instead of one of the ARMv7 main
CPUs.
Change-Id: Ia6ddc27619bdb51e152ad0c628ad6f3037c103ce
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171017
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 512d942788336c8d52470135b43ee4e6a1c95f6c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6709
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The INTERMEDIATE variable was used to hook dd-ing the BL1 into the image for
Exynos SOCs, but we can do that directly without having a special hook.
Change-Id: I434506b52ca4ea1d01e25a785cbfe66dfdea21c4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170921
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8db03c387ad654227d064e2a7fa5ecf09d07e3c5)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6714
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Trustzone needs to be initialized/disabled both on boot and on wake, so it
needs to be done before ramstage which doesn't run on wake. cpu.c isn't
compiled into romstage and fixing that causes other problems, so the trustzone
functions were split out.
Change-Id: I8fc630237ebec1f02a91600f8baf3d4e9ea66d0e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169817
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 055ed0e28476123b0bd666109af90baf40aadcee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I just spent half a day (including the time to implement a stack dumper)
to figure out that I am reading from a NULL pointer. A problem this
simple should be more easy to catch. Let's mark the address range below
SRAM as uncached so that the MMU can yell at you right away for being
the bad programmer you are when you access a NULL pointer.
Change-Id: I4a3a13f75bf21b25732be2ecb69d47503eff1b53
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170112
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 7316732ea0ccdc0d607bde81dbb38ca9abd29fa9)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6650
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The UART / serial console is put in retention state by kernel during suspend /
resume path, which caused Coreboot not able to print any messages during resume.
Sending values to the padret_uart_opt inside PMU may release UART, but that may
also cause unexpected output when kernel is back. However, it's still very
helpful when we are debugging suspend/resume inside Coreboot.
To get UART message on resume, call wakeup_enable_uart() in boot block or
romstage (before console_init).
Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265
Reviewed-on: https://chromium-review.googlesource.com/170440
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 547fbbfe2eeb6da4e161f36be2caf8099f9eac9b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6649
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds support for the DesignWare3 USB 3.0 DRD controller and
PHY to the Exynos5250 and Exynos5420 CPUs. It also adds code to the
Google Snow and Pit boards to turn these controllers on where
applicable.
Change-Id: Idcca627363a69f1d65402e1acb9a62b439f077ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit e9809ae12ef8b8bd6cd61d3f604cb9e4718cf7eb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6642
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Vadim Bendebury