Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934)
This patch is essentially a squash of aarch64 changes made by
these patches:
d955885 coreboot: Rename coreboot_ram stage to ramstage
a492761 cbmem console: Locate the preram console with a symbol instead of a sect
96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3
3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry
ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage
25fd2e9 aarch64: Remove CAR definitions from early_variables.h
65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM
9484873 aarch64: Change default exception level to EL2
7a152c3 aarch64: Fix formatting of exception registers dump
6946464 aarch64: Implement basic exception handling
c732a9d aarch64/foundation-armv8: Basic bootblock implementation
3bc412c aarch64: Comment out some parts of code to allow build
ab5be71 Add initial aarch64 support
The ramstage support is the only portion that has been tested
on actual hardware. Bootblock and romstage support may require
modifications to run on hardware.
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6915
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add the option to coreboot to set the SeaBIOS buffers below 0xC0000.
This is a requirement on the Intel Rangeley processor
because it is designed so that only the processor can write
the higher memory areas. This prevents USB and SATA from bus-mastering
into the buffers when they're set in the typical 0xE0000 area.
This will be set to Y unless defaulted to N by the mainboard or
chipset.
Push the SeaBIOS buffers down to 0x90000 segment for Mohon Peak
Change-Id: I15638605d1c66a2277d4b852796db89978551a34
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6364
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.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)
This approach avoids having same basic tables 150-lines mantra over 100 times
in codebase.
Change-Id: I76fb2fbcb9ca0654f2e5fd5d90bd62392165777c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6801
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Stop polluting first screen of all boards.
Change-Id: I1ab88075722f7f0d63550010e7c645281603c9c3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Move SeaBIOS' build directory out of build/
This allows the user to delete build/ in the top dir
and keep the built binary in payloads/external/SeaBIOS/seabios/out/
Change-Id: Ia7d515cd7e349beebcd9b62c9d956137acb73c82
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/6460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
On ARM platforms the TPM is not attached through LPC but through I2C.
This patch adds an I2C TPM driver that supports the following chips:
* Infineon SLB9635
* Infineon SLB9645
In order to select the correct TPM implementation cleanly, CONFIG_TPM
is moved to src/Kconfig and does the correct choice.
Old-Change-Id: I2def0e0f86a869d6fcf56fc4ccab0bc935de2bf1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/167543
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit b4049a0e96f6335a93877e1e884f9a440487c421)
i2c tpm: Remove mostly useless delay code/tables.
I assume from the code in the TPM driver that the TPM spec defines
different types of delays and timeouts which each have a particular
duration, and that the TPM can tell you how long each type is if you ask
it. There was a large table, some members of a data structure, and a
function or two which managed the timeouts and figured their value for
different operations. The timeout values for the various "ordinals"
were never set in the vendor specific data structure, however, and
always defaulted to 2 minutes. Similarly the timeouts a, b, c, and d
were never overridden from their defaults. This change gets rid of all
the timeout management code and makes the "ordinal" timeout 2 minutes
and the a, b, c, and d timeouts 2 seconds, the larger of the two default
values.
This is a port from depthcharge to coreboot, original change:
https://chromium-review.googlesource.com/#/c/168363/
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Old-Change-Id: I79696d6329184ca07f6a1be4f6ca85e1655a7aaf
Reviewed-on: https://chromium-review.googlesource.com/168583
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit b22395a73f361c38626911808332a3706b2334fe)
TPM: Stop requesting/releasing the TPM locality.
The locality is requested when the TPM is initialized and released when
it's cleaned up. There's no reason to set it to the same thing again and
restore it back to the same value before and after every transaction.
forward ported from https://chromium-review.googlesource.com/#/c/168400
Old-Change-Id: I291d1f86f220ef0eff6809c6cb00459bf95aa5e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168584
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit cc866c20c6f936f349d2f1773dd492dca9bbf0c1)
Squashed three commits for the i2c tpm driver.
Change-Id: Ie7a50c50fda8ee986c02de7fe27551666998229d
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6519
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fixed spelling and added empty lines to separate the help
from the text automatically added during make menuconfig.
Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6313
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
After commit
2ca2afe ACPI S3 support: Add acpi_s3_resume_allowed()
ACPISCRATCH region in CBMEM was no longer allocated, causing
AGESA platforms to fail S3 resume.
IS_ENABLED() did not evaluate true here with non-zero parameter.
Also avoid multiple defined defaults for HIGH_SCRATCH_MEMORY_SIZE.
Change-Id: Id99e4bee91581b8ac3d1ec44763b2d792b721832
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6093
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Martin Roth <gaumless@gmail.com>
SeaBIOS 1.7.4 was released in December 2013 [1] and, besides other
things, supports writing debug messages to CBMEM console.
The new SeaBIOS Kconfig option `DEBUG_COREBOOT` has to be added to the
SeaBIOS configuration file `.config` as otherwise the SeaBIOS build
from within coreboot (`PAYLOAD_SEABIOS`) is interrupted as it is
detected as a new option.
This option was already added and enabled in commit 7c1a49bc [1]
SeaBIOS: have coreboot pass the choice to run optionroms in parallel
so SeaBIOS messages are now written to the CBMEM console.
Successfully tested on the Asus M2V-MX SE.
[1] http://seabios.org/Releases
[2] http://review.coreboot.org/5443
Change-Id: I675a50532735b4921a664e4b24d98be17b9a1002
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5093
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This drops the scan-build related Kconfig options
since it's now possible to simply run
scan-build [-o outdir] make
and get coreboot built with its report.
There's also no inner make process anymore, and the way
things work should be clearer now.
Also adapt abuild to this new reality.
Change-Id: I03e03334761ec83f718b3235ebf811834cd2e3e3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5774
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Remove arch-level Kconfig menu option as it shows all available architectures in
make menuconfig. Instead pull the bootblock options for choice and update image
to top-level Kconfig since it is already present for both x86 and arm.
Change-Id: Iab9c4539f05cd54a7f751565fefcaf7b6f0edc86
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5673
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- Move the non chipset-specific fsp pieces out of the chipset into a
shared area. This is used by northbridge / southbrige / SOC code. It
pulls in pieces from Kconfig, Makefile and FSP specific code.
- Enabled in the CPU code with a Kconfig "select PLATFORM_USES_FSP"
Change-Id: I7ffa934c1df09b71d48a876a56e3b888685870b8
Signed-off-by: Martin Roth <gaumless@gmail.com>
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/5635
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the
architecture specific to that stage i.e. we will have CONFIG_ARCH variables for
each of the three stages. This allows us to have an SOC with any combination of
architectures and thus every stage can be made to run on a completely different
architecture independent of others. Thus, bootblock can have an x86 arch whereas
romstage and ramstage can have arm32 and arm64 arch respectively. These stage
specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain
and compiler flags for every stage.
These options can be considered as either arch or modes eg: x86 running in
different modes or ARM having different arch types (v4, v7, v8). We have got rid
of the original CONFIG_ARCH option completely as every stage can have any
architecture of its own. Thus, almost all the components of coreboot are
identified as being part of one of the three stages (bootblock, romstage or
ramstage). The components which cannot be classified as such e.g. smm, rmodules
can have their own compiler toolset which is for now set to *_i386. Hence, all
special classes are treated in a similar way and the compiler toolset is defined
using create_class_compiler defined in Makefile.
In order to meet these requirements, changes have been made to CC, LD, OBJCOPY
and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others.
Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the
toolsets are defined using create_class_compiler.
Few additional macros have been introduced to identify the class to be used at
various points, e.g.: CC_$(class) derives the $(class) part from the name of
the stage being compiled.
We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER
as they do not make any sense for coreboot as a whole. All these attributes are
associated with each of the stages.
Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5577
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names (bootblock, romstage) and to allow any
Makefile rule generalization, required for patches to be submitted later.
Change-Id: Ib66e43b7e17b9c48b2d099670ba7e7d857673386
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5567
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There is redundancy in terms of use of init_timer. We have a Kconfig option to
decide whether a board has init_timer as well as we use a stub for init_timer in
places where we do not have any init_timer defined. Thus, remove the Kconfig
option. Henceforth, all boards that do not have init_timer functionality can
include a stub_timer if required.
Change-Id: I35d38ec686f4dc92861cf9248f9b540323cd98ae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/5569
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Other toolchains just don't cut it.
Change-Id: I7a0bdf60d89b5166c9a22c9e9f3f326b28f777b8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4584
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use of CAR_GLOBAL is not safe after CAR is torn down, unless the
board properly implements EARLY_CBMEM_INIT.
Flag vulnerable boards that only do cbmem_recovery() in romstage on S3
resume and implementation with Intel FSP that invalidates cache before
we have a chance to copy the contents.
Change-Id: Iecd10dee9b73ab3f1f66826950fa0945675ff39f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5419
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This is based on the RCBA configuration setup from haswell.
It handles PCI, BARs, IO, MMIO, and baytrail-specific IOSF.
I did not extend it to handle MSR yet but that would be another
potential register type.
There are a number of approaches to this kind of thing, but in the
end they have a lot of switch statements and a mass of #defines.
I'm not particularly set on any of the details so comments welcome.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=emerge-rambi chromeos-coreboot-rambi
Change-Id: Ib873936ecf20fc996a8feeb72b9d04ddb523211f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175206
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4923
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The initial Bay Trail code is intended to support
the mobile and desktop version of Bay Trail. This support
can train memory and execute through ramstage. However,
the resource allocation is not curently handled correctly.
The MRC cache parameters are successfully saved and reused
after the initial cold boot.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted on a reference board through ramstage.
Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4847
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Haswell was the original chipset to store the cache
in another area besides CBMEM. However, it was specific
to the implementation. Instead, provide a generic way
to obtain the location of the ramstage cache. This option
is selected using the CACHE_RELOCATED_RAMSTAGE_OUTSIDE_CBMEM
Kconfig option.
BUG=chrome-os-partner:23249
BRANCH=None
TEST=Built and booted with baytrail support. Also built for
falco successfully.
Change-Id: I70d0940f7a8f73640c92a75fd22588c2c234241b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172602
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4876
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
In order to incorporate external blobs into
CBFS besides MRC have a notion of a reference code
blob. By selecting HAVE_REFCODE_BLOB and providing
the file name the refcode blob will be added to
cbfs as a stage file.
BUG=chrome-os-partner:22866
BRANCH=None
TEST=Using this option and other patches able to build,
boot, and run blob code.
Change-Id: I472604d77f4cb48f286b5a76b25d8b5bfb0c7780
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174423
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4895
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
GRUB2-as-payload doesn't use them. Libpayload can live with just coreboot tables
if loaded as payload. memtest86+ can use them but is buggy with them. Solaris
needs a huge boot archive not supported by coreboot and too big to fit in
flash (dozens of megabytes). All-in-all looks like no users are left for this.
Change-Id: Id92f73be5a397db80f5b0132ee57c37ee6eeb563
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4628
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change allows Kconfig options ROM_SIZE and CBFS_SIZE to be
set with values that are not power of 2. The region programmed
as WB cacheable will include all of ROM_SIZE.
Side-effects to consider:
Memory region below flash may be tagged WRPROT cacheable. As an
example, with ROM_SIZE of 12 MB, CACHE_ROM_SIZE would be 16 MB.
Since this can overlap CAR, we add an explicit test and fail
on compile should this happen. To work around this problem, one
needs to use CACHE_ROM_SIZE_OVERRIDE in the mainboard Kconfig and
define a smaller region for WB cache.
With this change flash regions outside CBFS are also tagged WRPROT
cacheable. This covers IFD and ME and sections ChromeOS may use.
Change-Id: I5e577900ff7e91606bef6d80033caaed721ce4bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4625
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
K8 Rev F raminit code cannot be built without RAMINIT_SYSINFO,
so have the option enabled together with K8_REV_F_SUPPORT.
Also move the option under AMD K8.
Change-Id: I91fa0b4ae7e3e54fbcb4a4f91eb043956cd0fb60
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Since a long time GRUB 2 is a viable payload alternative to SeaBIOS and
FILO. So make it easy for coreboot users to use GRUB 2 as a payload by
integrating it into coreboot’s build system, so it can be selected in
Kconfig.
As the last GRUB 2 release 2.00 is too old and has several bugs when
used as a coreboot payload only allow to build GRUB 2 master until a new
GRUB release is done. The downside is, that accidental breakage in
GRUB’s upstream does not affect coreboot users.
Currently the GRUB 2 payload is built with the default modules which
results in an uncompressed size of around 730 kB. Compressed it has a
size of 340 kB, so it should be useable with 512 kB flash ROMs.
Tested with QEMU.
Change-Id: Ie75d5a2cb230390cd5a063d5f6a5d5e3fab6b354
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4058
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As boards without EARLY_CBMEM_INIT do not initialize CBMEM in romstage,
and have no CAR migration, these features are available for ramstage only.
Change-Id: Ic3f77ccdedd4e71ba693619c02c9b98b328a0882
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This reverts commit de1fe7f655.
While things appeared to work, there were actually invalid references
to CAR storage after CAR was torn down on boards without
EARLY_CBMEM_INIT. It was discussed use of CAR_GLOBAL should be
restricted to boards that handle CAR migration properly.
Change-Id: I9969d2ea79c334a7f95a0dbb7c78065720e6ccae
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3968
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Assume EARLY_CBMEM_INIT=y everywhere and remove option from Kconfig.
If romstage does not make the cbmem_initialize() call, features like
COLLECT_TIMESTAMPS and early CBMEM_CONSOLE will execute during
romstage, but that data will get lost as no CAR migration is
executed.
Change-Id: I5615645ed0f5fd78fbc372cf5c3da71a3134dd85
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3917
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Clean whitespace errors that have gotten past lint-stable-003-whitespace
and gerrit review.
Change-Id: Id76fc68e9d32d1b2b672d519b75cdc80cc4f1ad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3920
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These allow to define a kernel image, initrd and command line.
Change-Id: I40155b812728a176b6d15871e1e6c96e4ad693c8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3893
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It wasn't even hooked up to the build system anymore.
Change-Id: I4b962ffd945b39451e19da3ec2f7b8e0eecf2e53
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3892
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
SEABIOS_PS2_TIMEOUT needs a default, otherwise the "allyesconfig" target
hangs in an endless loop.
The given default is correctly overridden by the (currently sole) user,
the lenovo/x60 target.
Change-Id: I3f5e347c29ccbb4d711a489d067b6c909f030bd0
Reported-by: Kyösti Mälkki
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3874
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
This allows mainboards to preconfigure a ps2-keyboard-spinup
timeout when SeaBIOS is chosen as the payload.
The Kconfig option can be changed manually if CONFIG_EXPERT is set.
Change-Id: I5732b18ef04f4bdef6236f35039656ad02011aec
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3734
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add option to log changes in USB 2.0 EHCI debug port connection.
For romstage move usbdebug as the last initialised console so one
actually can see these messages.
Init order of consoles in ramstage is undetermined and unchanged.
Change-Id: I3aceec8a93064bd952886839569e9f5beb6c5720
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3387
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Change-Id: I4b6a57e7d8e7e685c609b1d85368585b9dd197dc
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3761
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The options that keep track of whether there are arch versions of the standard
string functions shouldn't be in the arch/x86 directory since they apply to
all architectures. Move them into the higher level, shared Kconfig defaulting
to off. Then, in each applicable arch (currently all of them) they can be
selected to on.
Change-Id: I7ea64a583230fdc28773f17fd7cc23e0f0a5f3d6
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3760
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch was made by listenning to what Ron Minnich told
me to do on #coreboot IRC channel on Freenode with my
adaptations on top.
i915tool is at https://code.google.com/p/i915tool/ ,
the one in coreboot is outdated.
Change-Id: I13cd684f4c290114836fbd7babd461153e8d6124
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3277
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This feature has not been used and was never fully integrated.
In the progress of cleaning up coreboot, let's drop it.
Change-Id: Ib40acdba30aef00a4a162f2b1009bf8b7db58bbb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3251
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
Change-Id: Ie39b9eb565eb189676c06645bdf2a8720fe0636a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3207
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c). All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.
The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.
Note that the intention on when to yield a thread will be on
calls to udelay().
Change-Id: Ia4d67a38665b12ce2643474843a93babd8a40c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3206
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This option has not been enabled on any board and was considered
obsolete last time it was touched. If we need the functionality,
let's fix this in a generic way instead of a K8 specific way.
This was mostly a speedup hack back in the day.
Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Capitalizing CBMEM seems to be the official spelling as can be seen
in the descriptions around the `EARLY_CBMEM_INIT` Kconfig option.
Change-Id: I046a678c3b04ef7e681de46aa137cedc405d546f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3143
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A timer queue provides the mechanism for calling functions
in the future by way of a callback. It utilizes the MONOTONIC_TIMER
to track time through the boot. The implementation is a min-heap
for keeping track of the next-to-expire callback.
Change-Id: Ia56bab8444cd6177b051752342f53b53d5f6afc1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3158
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The notion of a monotonic timer is introduced. Along with it
are helper functions and other types for comparing times. This
is just the framework where it is the responsibility of the
chipset/board to provide the implementation of timer_monotonic_get().
The reason structs are used instead of native types is to allow
for future changes to the data structure without chaning all the
call sites.
Change-Id: Ie56b9ab9dedb0da69dea86ef87ca744004eb1ae3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are assumptions that COLLECT_TIMESTAMPS and CONSOLE_CBMEM
rely on EARLY_CBMEM_INIT. This isn't true in the face of
DYNAMIC_CBMEM as it provides the same properties as EARLY_CBMEM_INIT.
Therefore, allow one to select COLLECT_TIMESTAMPS and CONSOLE_CBMEM
when DYNAMIC_CBMEM is selected. Lastly, don't hard code the cbmem
implementation when COLLECT_TIMESTAMPS is selected.
Change-Id: I053ebb385ad54a90a202da9d70b9d87ecc963656
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Dynamic cbmem is now a requirement for relocatable ramstage.
This patch replaces the reserve_* fields in the romstage_handoff
structure by using the dynamic cbmem library.
The haswell code is not moved over in this commit, but it should be
safe because there is a hard requirement for DYNAMIC_CBMEM when using
a reloctable ramstage.
Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2849
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a parallel implementation of cbmem that supports
dynamic sizing. The original implementation relied on reserving
a fixed-size block of memory for adding cbmem entries. In order to
allow for more flexibility for adding cbmem allocations the dynamic
cbmem infrastructure was developed as an alternative to the fixed block
approach. Also, the amount of memory to reserve for cbmem allocations
does not need to be known prior to the first allocation.
The dynamic cbmem code implements the same API as the existing cbmem
code except for cbmem_init() and cbmem_reinit(). The add and find
routines behave the same way. The dynamic cbmem infrastructure
uses a top down allocator that starts allocating from a board/chipset
defined function cbmem_top(). A root pointer lives just below
cbmem_top(). In turn that pointer points to the root block which
contains the entries for all the large alloctations. The corresponding
block for each large allocation falls just below the previous entry.
It should be noted that this implementation rounds all allocations
up to a 4096 byte granularity. Though a packing allocator could
be written for small allocations it was deemed OK to just fragment
the memory as there shouldn't be that many small allocations. The
result is less code with a tradeoff of some wasted memory.
+----------------------+ <- cbmem_top()
| +----| root pointer |
| | +----------------------+
| | | |--------+
| +--->| root block |-----+ |
| +----------------------+ | |
| | | | |
| | | | |
| | alloc N |<----+ |
| +----------------------+ |
| | | |
| | | |
\|/ | alloc N + 1 |<-------+
v +----------------------+
In addition to preserving the previous cbmem API, the dynamic
cbmem API allows for removing blocks from cbmem. This allows for
the boot process to allocate memory that can be discarded after
it's been used for performing more complex boot tasks in romstage.
In order to plumb this support in there were some issues to work
around regarding writing of coreboot tables. There were a few
assumptions to how cbmem was layed out which dictated some ifdef
guarding and other runtime checks so as not to incorrectly
tag the e820 and coreboot memory tables.
The example shown below is using dynamic cbmem infrastructure.
The reserved memory for cbmem is less than 512KiB.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000002ffff: RAM
2. 0000000000030000-000000000003ffff: RESERVED
3. 0000000000040000-000000000009ffff: RAM
4. 00000000000a0000-00000000000fffff: RESERVED
5. 0000000000100000-0000000000efffff: RAM
6. 0000000000f00000-0000000000ffffff: RESERVED
7. 0000000001000000-000000007bf80fff: RAM
8. 000000007bf81000-000000007bffffff: CONFIGURATION TABLES
9. 000000007c000000-000000007e9fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 00000000fed10000-00000000fed19fff: RESERVED
12. 00000000fed84000-00000000fed84fff: RESERVED
13. 0000000100000000-00000001005fffff: RAM
Wrote coreboot table at: 7bf81000, 0x39c bytes, checksum f5bf
coreboot table: 948 bytes.
CBMEM ROOT 0. 7bfff000 00001000
MRC DATA 1. 7bffe000 00001000
ROMSTAGE 2. 7bffd000 00001000
TIME STAMP 3. 7bffc000 00001000
ROMSTG STCK 4. 7bff7000 00005000
CONSOLE 5. 7bfe7000 00010000
VBOOT 6. 7bfe6000 00001000
RAMSTAGE 7. 7bf98000 0004e000
GDT 8. 7bf97000 00001000
ACPI 9. 7bf8b000 0000c000
ACPI GNVS 10. 7bf8a000 00001000
SMBIOS 11. 7bf89000 00001000
COREBOOT 12. 7bf81000 00008000
And the corresponding e820 entries:
BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
BIOS-e820: [mem 0x0000000000001000-0x000000000002ffff] usable
BIOS-e820: [mem 0x0000000000030000-0x000000000003ffff] reserved
BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable
BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x0000000000efffff] usable
BIOS-e820: [mem 0x0000000000f00000-0x0000000000ffffff] reserved
BIOS-e820: [mem 0x0000000001000000-0x000000007bf80fff] usable
BIOS-e820: [mem 0x000000007bf81000-0x000000007bffffff] type 16
BIOS-e820: [mem 0x000000007c000000-0x000000007e9fffff] reserved
BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
BIOS-e820: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
BIOS-e820: [mem 0x00000000fed84000-0x00000000fed84fff] reserved
BIOS-e820: [mem 0x0000000100000000-0x00000001005fffff] usable
Change-Id: Ie3bca52211800a8652a77ca684140cfc9b3b9a6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2848
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds an option to build the ramstage as a reloctable binary.
It uses the rmodule library for the relocation. The main changes
consist of the following:
1. The ramstage is loaded just under the cmbem space.
2. Payloads cannot be loaded over where ramstage is loaded. If a payload
is attempted to load where the relocatable ramstage resides the load
is aborted.
3. The memory occupied by the ramstage is reserved from the OS's usage
using the romstage_handoff structure stored in cbmem. This region is
communicated to ramstage by an CBMEM_ID_ROMSTAGE_INFO entry in cbmem.
4. There is no need to reserve cbmem space for the OS controlled memory for
the resume path because the ramsage region has been reserved in #3.
5. Since no memory needs to be preserved in the wake path, the loading
and begin of execution of a elf payload is straight forward.
Change-Id: Ia66cf1be65c29fa25ca7bd9ea6c8f11d7eee05f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2792
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
In certain situations boot speed can be increased by providing an
alternative implementation to cbfs_load_payload(). The
ALT_CBFS_LOAD_PAYLOAD option allows for the mainboard or chipset to
provide its own implementation.
Booted baskingridge board with alternative and regular
cbfs_load_payload().
Change-Id: I547ac9881a82bacbdb3bbdf38088dfcc22fd0c2c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2782
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
A rmodule is short for relocation module. Relocaiton modules are
standalone programs. These programs are linked at address 0 as a shared
object with a special linker script that maintains the relocation
entries for the object. These modules can then be embedded as a raw
binary (objcopy -O binary) to be loaded at any location desired.
Initially, the only arch support is for x86. All comments below apply to
x86 specific properties.
The intial user of this support would be for SMM handlers since those
handlers sometimes need to be located at a dynamic address (e.g. TSEG
region).
The relocation entries are currently Elf32_Rel. They are 8 bytes large,
and the entries are not necessarily in sorted order. An future
optimization would be to have a tool convert the unsorted relocations
into just sorted offsets. This would reduce the size of the blob
produced after being processed. Essentialy, 8 bytes per relocation meta
entry would reduce to 4 bytes.
Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2692
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Update coreboot to use SeaBIOS' tag rel-1.7.2.1
Change-Id: I01969407964a7cf64f7c4800b59c6aed845b24f9
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/2575
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This allows to drop some special cases in romstage.c
Change-Id: I53fdfcd1bb6ec21a5280afa07a40e3f0cba11c5d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2551
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It's been on for all boards per default since several years now
and the old code path probably doesn't even work anymore. Let's
just have one consistent way of doing things.
Change-Id: I58da7fe9b89a648d9a7165d37e0e35c88c06ac7e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2547
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
REQUIRES_BLOB assumes that all blob files come from the 3rdparty directory,
builds failed when all files were configured to point to other sources.
This change modifies the blob mechanism so that cbfs-files can be tagged as
"required" with some specification what is missing.
If the configured files can't be found (wrong path, missing file), the build
system returns a list of descriptions, then aborts.
Change-Id: Icc128e3afcee8acf49bff9409b93af7769db3517
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2418
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Multiboot is an x86 only thing. Drop support on ARM.
Change-Id: I13fafa464a794206d5450b4a1f23a187967a8338
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2392
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This seemed to have been introduced in fe422184.
Change-Id: I4f9ecfbec42aa8c0bb8887675a3add8951645b98
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2327
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The console drivers (especially serial drivers) in Kconfig were named in
different styles. This change will rename configuration names to a better naming
style.
- EARLY_CONSOLE:
Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE
because it also supports non-serial)
- CONSOLE_SERIAL:
Enable serial output console, from one of the serial drivers. (Renamed
from SERIAL_CONSOLE because other non-serial drivers are named as
CONSOLE_XXX like CONSOLE_CBMEM)
- CONSOLE_SERIAL_UART:
Device-specific UART driver. (Renamed from
CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped)
- HAVE_UART_SPECIAL:
A dependency for CONSOLE_SERIAL_UART.
Verified to boot on x86/qemu and armv7/snow, and still seeing console
messages in romstage for both platforms.
Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2299
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We don't need a special Kconfig variable anymore
because the FV _is_ the payload, unlike with the
old tianocoreboot implementation.
Change-Id: I349b5a95783e4146e3ab7f926871188cf2021935
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2284
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This unplugs Stefan's PIANO project.
Change Tianocore payload configuration to use corebootPkg.
As argument you have to give it the COREBOOT.FD generated by
the Tianocore build system.
It automatically determines base address and entry point.
Compression setting is honored (ie. no compression if you don't
want), but corebootPkg currently assumes that coreboot is doing
it. Loading a 6MB payload into CBFS without compression will fail
more often than not.
Change-Id: If9c64c9adb4a846a677c8af40f149ce697059ee6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a Tiano Core loader payload based on libpayload. It
will load a Tiano Core DXE core from an UEFI firmware volume
stored in CBFS.
Currently Tiano Core dies because it does not find all the UEFI services it needs:
coreboot-4.0-3316-gc5c9ff8-dirty Mon Jan 28 15:37:12 PST 2013 starting...
[..]
Tiano Core Loader v1.0
Copyright (C) 2013 Google Inc. All rights reserved.
Memory Map (5 entries):
1. 0000000000000000 - 0000000000000fff [10]
2. 0000000000001000 - 000000000009ffff [01]
3. 00000000000c0000 - 0000000003ebffff [01]
4. 0000000003ec0000 - 0000000003ffffff [10]
5. 00000000ff800000 - 00000000ffffffff [02]
DXE code: 03e80000
DXE stack: 03e60000
HOB list: 03d5c000
Found UEFI firmware volume.
GUID: 8c8ce578-8a3d-4f1c-9935-896185c32dd3
length: 0x0000000000260000
Found DXE core at 0xffc14e0c
Section 0: .text size=000158a0 rva=00000240 in file=000158a0/00000240 flags=60000020
Section 1: .data size=00006820 rva=00015ae0 in file=00006820/00015ae0 flags=c0000040
Section 2: .reloc size=000010a0 rva=0001c300 in file=000010a0/0001c300 flags=42000040
Jumping to DXE core at 0x3e80000
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3E96708
HOBLIST address in DXE = 0x3E56010
Memory Allocation 0x00000003 0x3E80000 - 0x3EBFFFF
FV Hob 0xFFC14D78 - 0xFFE74D77
InstallProtocolInterface: D8117CFE-94A6-11D4-9A3A-0090273FC14D 3E95EA0
InstallProtocolInterface: EE4E5898-3914-4259-9D6E-DC7BD79403CF 3E9630C
Security Arch Protocol not present!!
CPU Arch Protocol not present!!
Metronome Arch Protocol not present!!
Timer Arch Protocol not present!!
Bds Arch Protocol not present!!
Watchdog Timer Arch Protocol not present!!
Runtime Arch Protocol not present!!
Variable Arch Protocol not present!!
Variable Write Arch Protocol not present!!
Capsule Arch Protocol not present!!
Monotonic Counter Arch Protocol not present!!
Reset Arch Protocol not present!!
Real Time Clock Arch Protocol not present!!
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT /home/reinauer/svn/Tiano/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(461): !EFI_ERROR (Status)
Change-Id: I14068e9a28ff67ab1bf03105d56dab2e8be7b230
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2154
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
and disable IO mapped UARTs on ARMV7 per default
Change-Id: I712c4677cbc8519323970556718f9bb6327d83c8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2021
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The ARM architecture is really many architectures, and most
of them need their own toolchain. After discussing with Ron
and David, we decided that we're going to call the architecture
of our ARM board armv7.. This patch cleans out the remainders
of ARCH_ARM in the tree and moves on to consistent ARMv7 naming.
As of now, we only support little endian ARMv7 CPUs. We can
fix that for big endian if/when it comes our way.
Change-Id: Id70c7ef615f600e4d09961d811e7ac974fce4811
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1968
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
to match src/include/device
Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1960
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Not all architectures have PCI. This new config variable allows control
of whether PCI support is configued in. It is selected for ARCH_X86.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: Ic5fe777b14fd6a16ba605ada1e22acf3e8a2c783
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1947
Tested-by: build bot (Jenkins)
This adds a dummy config for ARMV7 for developing various
follow-up patches which rely on ARCH_ARMV7.
Change-Id: Id913054d916f41607d10ebc02aaf74082e14b554
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1939
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Per a conversation with Stefan, these chip-dependent files are moved
to the src tree, in the manner of other chips (north and southbridge).
Change-Id: I12645ba05eb241eda200ed06cb633541a6a98119
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Reviewed-on: http://review.coreboot.org/1925
Tested-by: build bot (Jenkins)
Some boards selected GENERATE_ instead of HAVE_
Change-Id: I450c22d7b044f0c88c21692246d452d516a68a83
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1841
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- move VGA handling options into devices/Kconfig
- make Devices a top level menu
- move some options "closer" to the code they control
Change-Id: Ia79541d18b2b0d9b89a8b154255e312060627c48
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1840
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Both remaining options, DRIVERS_PS2_KEYBOARD and ID_SECTION_OFFSET
are not likely to go away any time soon, so let's not keep them
in Kconfig.deprecated_options but move them close to the code they
control.
Change-Id: I310b877c5b3d5a3444056641c4aee07a48c4c4be
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1839
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
hard_reset was indeed consolidated and moved into the southbridge
code a while ago, but the config variable was still kept alife, with
some duplicate code.
Change-Id: I60d4a87de916667f6e89353dfbe1a7b9eca380f7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1837
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Right now coreboot's build process produces images that are
not booting on actual hardware because they are smaller than
the actual flash device and also don't have an IFD nor an ME
firmware in them. In order to produce bootable images, you
needed a wrapper script / extra step until now. With this
change, the resulting coreboot.rom is actually bootable.
Change-Id: I82714069fb004d4badc41698747a704bd9fed4da
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1771
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
pirq_routing_irqs assumed that only four links are available for PIRQ
routing, INTA to INTD. Some chipsets provide more, up to INTH.
When pirq_routing_irqs found a link number greater than 4 in the pirq table,
it would not assign that IRQ. This is a shame, as it limits the flexibility
of routing IRQs.
Make the maximum number of links a Kconfig variable, and modify the code to
respect it. This works beatifully on the VX900, which provides 8 routable
interrupts.
While we're at it, also refactor pirq_routing_irqs, and add some much
needed comments.
Rename pirq_routing_irqs to pirq_route_irqs to demistify the role of this
function.
The copyrights added were determined from git log filename.
Change-Id: I4b565315404c65b871406f616474e2cc9e6e013e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1482
Tested-by: build bot (Jenkins)
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Here's a quick demonstration on how to use it(tested on M4A785T-M).
(gdb) file ./build/cbfs/fallback/coreboot_ram.debug
Reading symbols from [...]/build/cbfs/fallback/coreboot_ram.debug...done.
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
_text () at src/arch/x86/lib/c_start.S:85
85 call hardwaremain
Change-Id: Ia49cbecc41deb061433bc39f5b81715da49edc98
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1134
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Being a diligent soul, I changed the "enter a numeric value for the
mode you want" option to a choice of common modes. New modes can be
added quite easily.
Change-Id: I8cf4572c2d36ced6549541ec173c0c02d8eaca4a
Signed-off-by: Steve Goodrich <steve.goodrich@se-eng.com>
Reviewed-on: http://review.coreboot.org/1036
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
This driver is taken from u-boot and adapted to match
coreboot. It still contains some hacks and is ICH specific
at places.
Change-Id: I97dd8096f7db3b62f8f4f4e4d08bdee10d88f689
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/997
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Prefix all CBFS output messages with CBFS:
- Add an option DEBUG_CBFS that is off by default. Without DEBUG_CBFS
enabled, the code will no longer print all the files it walks for
every file lookup.
- Add DEBUG() macro next to LOG() and ERROR() to specify which messages
should only be visible with DEBUG_CBFS printed.
- Actually print a message when the file we're looking for was found. :)
old:
Searching for fallback/coreboot_ram
Check cmos_layout.bin
Check pci8086,0106.rom
Check fallback/romstage
Check fallback/coreboot_ram
Change-Id: I2d731fae17a5f6ca51d435cfb7a58d6e017efa24
Stage: loading fallback/coreboot_ram @ 0x100000 (540672 bytes), entry @ 0x100000
Stage: done loading.
new:
CBFS: Looking for 'fallback/coreboot_ram'
CBFS: found.
CBFS: loading stage fallback/coreboot_ram @ 0x100000 (507904 bytes), entry @ 0x100000
CBFS: stage loaded.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/993
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
One option to allow using the repo (defaults to no),
one to let boards state that they require it in the
current configuration.
The build system checks out the repo if allowed, and
fails if the repo is requested by the configuration
but not desired by the user.
Change-Id: If71d80b329cf528aa467fcb0b4d9d7c7434aab27
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/957
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
- Add documentation for COMPILER_GCC, and COMPILER_LLVM_CLANG.
- SCANBUILD_ENABLE, CCACHE: Amend documentation.
- SCANBUILD_REPORT_LOCATION: Document default dir, names of scan-build dirs.
- INCLUDE_CONFIG_FILE: Add more verbose docs, show how to use it.
- Fix typos/cosmetics/indentation, improve wording on some items.
Change-Id: I6b67b2c777868e4421405caaffe6631e69dddad2
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Reviewed-on: http://review.coreboot.org/893
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
1. Move the Stack to high memory.
2. Restore the MTRR before Coreboot jump to the wakeup vector.
Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
instead of having to edit the source code of tpm.c
Change-Id: I519d9ada14dd383e668a2da4219e5373a24c7c3d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/757
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
and initialize the TPM on S3 resume
This patch integrates the TPM driver and runs TPM resume upon an ACPI S3
resume without including any other parts of vboot.
We could link against vboot_fw.a but it is compiled with u-boot's CFLAGS
(that are incompatible with coreboot's) and it does a lot more than we
want it to do.
Change-Id: I000d4322ef313e931e23c56defaa17e3a4d7f8cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... and hook it up in Kconfig. More code to come.
Change-Id: I24542d8ef97e2bce112c3aface681ceeb1a7c061
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/813
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a new flag, make it dependent on EARLY_CBMEM_INIT
Change-Id: Idbebcaf298238f31a73e9eb4a9af7b03e857bc74
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/712
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
We want to be able to communicate information between rom and ram
stages of coreboot. This configuration option will be used to
compile such ability in.
Change-Id: I6736fdc264ecd0b63369b28462d7bb96e4c2b012
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/710
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I would prefer to see the exception dump on serial rather than cryptic
GDB protocol.
Change-Id: Ib25513d33e6a31da24586fecb00adb5206bb43bd
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/811
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Edward O'Callaghan