This patch generalizes the approach previously used for ARM32
TTB_SUBTABLES to "auto-detect" whether a certain region was defined in
memlayout.ld. This allows us to get rid of the explicit Kconfig for the
TIMESTAMP region, reducing configuration redundancy and avoiding
confusion when setting up future boards.
(Removing armv4/bootblock_simple.c because it references this Kconfig
and it is a dead file that I just forgot to remove in CL:12076.)
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that all pre-RAM timestamps are still
there. Built Nyan and Falco.
Change-Id: I557a4b263018511d17baa4177963130a97ea310a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move the payloads section of the kconfig tree out of the top level
kconfig file and into a separate Kconfig just for payloads before
it starts to get added to.
Change-Id: I4f52818f862bf1aeba538c1c6ed93211a78b9853
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13608
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Add a target at the end of the build that can be used to run additional
scripts or additional targets after coreboot.rom is built.
- Source a site-local Kconfig file to allow site-specific configuration.
This eliminates the need to add a hook for a script at the end of the
build because you can add one yourself in site-local.
Example site-local/Makefile.inc:
build_complete::
ifeq ($(CONFIG_SITE_LOCAL),y)
echo "Running additional steps in site-local"
# run some script here to make my build unreproducible.
endif
.phony: build_complete
Example site-local/Kconfig:
menu "site-local"
config SITE_LOCAL
bool "site-local enabled"
help
Enable my site-local configuration to do stuff.
endmenu
Change-Id: Id4d1e727c69b5cdb05e7d52731bbb1d1e201864a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13413
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
We just had a user who spent a fair amount of time debugging a
failing build due to this option being enabled. Add a little
guidance that it probably shouldn't be enabled in the help text.
Change-Id: I9339e442876c1fcd18ea564041c6cc1201c18ae5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13066
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a new Kconfig variable to enable the generation of
position and alignment attributes for cbfs files which
has constraints on this parameters.
In addition, modify Makefile.inc to support that option.
Change-Id: Ibd725fe69a4de35964bdb2dde106d9a7c37ffb47
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/12968
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are generated from depthcharge's board/*/fmap.dts using the
dts-to-fmd.sh script.
One special case is google/veyron's chromeos.fmd, which is used for a
larger set of boards - no problem since the converted fmd was the same
for all of them.
Set aside 128K for the bootblock on non-x86 systems (where the COREBOOT
region ends up at the beginning of flash). This becomes necessary
because we're working without a real cbfs master header (exists for
transition only), which carved out the space for the offset.
Change-Id: Ieeb33702d3e58e07e958523533f83da97237ecf1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12715
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
- While we're working on fixing clang for coreboot, mark it as not
currently working so that it doesn't look like a reasonable choice.
- Add help on how to make the toolchains
Change-Id: Ib37093ca98d0328fad40dd7886c98d00f78bd58e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13053
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of depending BOOTBLOCK_CONSOLE on a set of architectures,
allow the arch or platform to specify whether it can provide a C
environment. This simplifies the selection logic.
Change-Id: Ia3e41796d9aea197cee0a073acce63761823c3aa
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/12871
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Intel's SST (Smart Sound Technology) employs audio support
which may not consist of HDA. In order to define the topology
of the audio devices (mics, amps, codecs) connected to the
platform a NHLT specification was created to pass this
information from the firmware to the OS/userland.
BUG=chrome-os-partner:44481
BRANCH=None
TEST=Tested on glados. Audio does get emitted and some mic recording
works.
Change-Id: I8a9c2f4f76a0d129be44070f09d938c28a73fd27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2472af5793dcffd2607a7b95521ddd25b4be0e8c
Original-Change-Id: If469f99ed1a958364101078263afb27761236421
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312264
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/12935
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When microcode updates are enabled, this fixes an issue identical
to that described in GIT hash 7b22d84d:
* drivers/pc80: Add optional spinlock for nvram CBFS access
Change-Id: Ib7e8cb171f44833167053ca98a85cca23021dfba
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12063
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The FMD is board-specific, so it makes sense to have it in the
mainboard menu.
Change-Id: I52fba5ced869d51d10065f8c9ebd258d3a1d4156
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/12805
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Boots to console on Gigabyte GA-G41M-ES2L
Ram initialization *not* included in this patch
VGA native init works on analog connector
Change-Id: I5262f73fd03d5e5c12e9f11d027bdfbbf0ddde82
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/11305
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When enabling the IOMMU on certain systems dmesg is spammed with I/O page faults like the following:
AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.0 domain=0x000a address=0x000000fdf9103300 flags=0x0030]
Decoding the faulting address:
0x000000fdf9103300
fdf91x Hypertransport system management region
33 SysMgtCmd (System Management Command) = 0x33
3 Base Command Type = 0x3: STPCLK (Stop Clock request)
3 SMAF (System Management Action Field) = [3:1] = 0x1
1 Signal State Bit Map = [0] = 0x1
Therefore, the error appears to be triggered by an upstream C1E request.
This was eventually traced to concurrent access to the SP5100's SPI Flash controller by
multiple APs during startup. Calls to the nvram read functions get_option and read_option
call CBFS functions, which in turn make near-simultaneous requests to the SPI Flash
controller, thus placing the SP5100 in an invalid state. This limitation is not documented
in any public AMD errata, and was only discovered through considerable debugging effort.
Change-Id: I4e61b1ab767b1b7958ac7c1cf20eee41d2261bef
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12061
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
If we select CONFIG_GDB_STUB without CONFIG_SERIAL:
build/console/console.romstage.o: In function `__gdb_hw_init':
[...]src/include/console/uart.h:74: undefined reference to `uart_init'
build/console/console.romstage.o: In function `__gdb_tx_byte':
[...]/src/include/console/uart.h:75: undefined reference to `uart_tx_byte'
build/console/console.romstage.o: In function `__gdb_tx_flush':
[...]/src/include/console/uart.h:76: undefined reference to `uart_tx_flush'
build/console/console.romstage.o: In function `__gdb_rx_byte':
[...]/src/include/console/uart.h:77: undefined reference to `uart_rx_byte'
Note that CONFIG_GDB_STUB should also work trough usbdebug,
But due to the lack of testing, it has been disabled when added.
This commit gives more information on the issue:
f2f7f03 console: Add console for GDB
Change-Id: I9accf8189dfd2c4ae379c03649d2e5863183457b
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: https://review.coreboot.org/12708
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This paves the way for AP printk spinlock on AMD platforms
Change-Id: Ice42a0d3177736bf6e1bc601092e413601866f20
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/11958
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We still add a master header for compatibility purposes, and the default
layouts don't cover anything non-coreboot (eg. IFD regions) yet.
The default layouts can be overridden by specifying an fmd file, from
which the fmap is generated.
Future work:
- map IFD regions to fmap regions
- non-x86: build minimalistic trampolines that jump into the first cbfs
file, so the bootblock can be part of CBFS instead of reserving a
whole 64K for it.
- teach coreboot's cbfs code to work without the master header
- teach coreboot's cbfs code to work on different fmap regions
Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/11692
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
We've actually got more warnings now than when I first tested IASL
warnings as errors. Because of this, I'm adding it with the option
to have it disabled, in hopes that things won't get any worse as we
work on fixing the IASL warnings that are currently in the codebase.
- Enable IASL warnings as errors
- Disable warnings as errors in mainboards that currently have warnings.
- Print a really obnoxious message on those platforms when they build.
***** WARNING: IASL warnings as errors is disabled! *****
***** Please fix the ASL for this platform. *****
Change-Id: If0da0ac709bd8c0e8e2dbd3a498fe6ecb5500a81
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10663
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
HAS_PRECBMEM_TIMESTAMP_REGION was dependent on COLLECT_TIMESTAMPS,
but should be allowed to be selected independently. My thought is that
the code may only be used when collecting timestamps, the HAS prefix
signifies that this is a platform configuration option.
This fix could also be done by adding 'if COLLECT_TIMESTAMPS' everywhere
that 'select HAS_PRECBMEM_TIMESTAMP_REGION' is used
Change-Id: Iaf4895475c38a855a048dc9b82d4c97e5e3f4e5c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11338
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The existing arm64 architecture code has been developed for the Tegra132
and Tegra210 SoCs, which only start their ARM64 cores in ramstage. It
interweaves the stage entry point with code that initializes a CPU (and
should not be run again if that CPU already ran a previous stage). It
also still contains some vestiges of SMP/secmon support (such as setting
up stacks in the BSS instead of using the stage-peristent one from
memlayout).
This patch splits those functions apart and makes the code layout
similar to how things work on ARM32. The default stage_entry() symbol is
a no-op wrapper that just calls main() for the current stage, for the
normal case where a stage ran on the same core as the last one. It can
be overridden by SoC code to support special cases like Tegra.
The CPU initialization code is split out into armv8/cpu.S (similar to
what arm_init_caches() does for ARM32) and called by the default
bootblock entry code. SoCs where a CPU starts up in a later stage can
call the same code from a stage_entry() override instead.
The Tegra132 and Tegra210 code is not touched by this patch to make it
easier to review and validate. A follow-up patch will bring those SoCs
in line with the model.
BRANCH=None
BUG=None
TEST=Booted Oak with a single mmu_init()/mmu_enable(). Built Ryu and
Smaug.
Change-Id: I28302a6ace47e8ab7a736e089f64922cef1a2f93
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12077
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When we first added ARM support to coreboot, it was clear that the
bootblock would need to do vastly different tasks than on x86, so we
moved its main logic under arch/. Now that we have several more
architectures, it turns out (as with so many things lately) that x86 is
really the odd one out, and all the others are trying to do pretty much
the same thing. This has already caused maintenance issues as the ARM32
bootblock developed and less-mature architectures were left behind with
old cruft.
This patch tries to address that problem by centralizing that logic
under lib/ for use by all architectures/SoCs that don't explicitly
opt-out (with the slightly adapted existing BOOTBLOCK_CUSTOM option).
This works great out of the box for ARM32 and ARM64. It could probably
be easily applied to MIPS and RISCV as well, but I don't have any of
those boards to test so I'll mark them as BOOTBLOCK_CUSTOM for now and
leave that for later cleanup.
BRANCH=None
BUG=None
TEST=Built Jerry and Falco, booted Oak.
Change-Id: Ibbf727ad93651e388aef20e76f03f5567f9860cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12076
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Per IRC and Gerrit discussion, the normal / fallback
selector code is a rather weak spot in coreboot, and
did not function correctly for certain use cases.
Rework the selector to more clearly indicate proper
operation, and also remove dead code. Also tentatively
abandon use of RTC bit 385; a follow-up patch will
remove said bit from all affected mainboards.
The correct operation of the fallback code selector
approximates that of a power line recloser, with
a user option to attempt normal boot that can be
cleared by firmware, but never set by firmware.
Additionally, if cleared by user, the fallback
path should always be used on the next reboot.
Change-Id: I753ae9f0710c524875a85354ac2547df0c305569
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/12289
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The possibility of adding a bootsplash image to ROM should be independent
from VGA_ROM_RUN and VESA menuconfig options.
For example, the stored image could be saved in CBFS not for coreboot
but for later use in SeaBIOS.
Change-Id: I3a0ed53489c40d4d44bd4ebc358ae6667e6c797f
Signed-off-by: Konstantin Aladyshev <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/12129
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It works there, we want it, disable that restriction.
Change-Id: Idc023775f0750c980c989bff10486550e4ad1374
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/12094
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It builds only on veyron_* which already select it, no need to ask user.
Change-Id: Ie508b9eade16e0f39073b23dc0da6b6d1e0a4c73
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10380
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
board_id() returns an integer which is platform-specific. 0 for one port
is different from 0 for another port. So there is no default board_id()
and hence enabling it on boards other than urara would cause build failure.
Not enabling it on urara or just setting id to "(none)" as is default results
in board_id() = 0 which means urara and an error message on console.
Change-Id: I94618f36a75e7505984bbec345a31fe0fa9cc867
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10379
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
The EM100Pro allows the debug console to be sent over the SPI bus.
This is not yet working in romstage due to the use of static variables
in the SPI driver code. It is also not working on chipsets that have
SPI write buffers of less than 10 characters due to the 9 byte
command/header length specified by the EM100 protocol.
While this currently works only with the EM100, it seems like it would
be useful on any logic analyzer with SPI debug - just filter on command
bytes of 0x11.
Change-Id: Icd42ccd96cab0a10a4e70f4b02ecf9de8169564b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
After much consideration, and many years of an EXPERT mode sitting
almost completely unused, we've seen that it doesn't work for us.
There is no standard on what constitutes EXPERT, and most of
coreboot's options Kconfig are expert-level.
We even joked that not selecting "EXPERT" should prevent coreboot
from compiling:
@echo $(shell whoami) is not permitted to compile coreboot
Change-Id: Ic22dd54a48190b81d711625efb6b9f3078f41778
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11365
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
CBFS_SIZE is living as a mainboard attribute. Because
of the Kconfig include ordering the SoC *cannot* set
the default. Remove from the soc Kconfig and add a
default Kconfig for SOC_INTEL_SKYLAKE.
BUG=chrome-os-partner:43419
BRANCH=None
TEST=built glados
Original-Change-Id: I8808177b573ce8e2158c9e598dbfea9ff84b97c7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289833
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Icf52d7861eee016a35be899e5486deb0924a0f3c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11168
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Build now decides the stack size by correctly referencing the
value in /src/mainboard/emulation/qemu-riscv/memlayout.ld.
Note that while the size is correct, the placement is still
wrong, and causes the stack to be corrupted by the coreboot
tables. Still needs to be addressed
Change-Id: I86c08bd53eeb64e672fecba21e06220694a4c3dd
Signed-off-by: Thaminda Edirisooriya <thaminda@google.com>
Reviewed-on: http://review.coreboot.org/10870
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The integration of external payloads in coreboot
is a bit messy. You have to change the to level Kconfig
file for every payload (something that we recently fixed
for mainboards and chipsets). This means that updating
e.g. the SeaBIOS version requires a change outside of the
SeaBIOS directory.
With this patch you can create a new directory under
payloads/external and place a Kconfig and Kconfig.name
file in there, and the payload will automatically show
up when you do "make menuconfig".
Change-Id: I293abcb8eae581d4b3934e64897c0d339a27e7c1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10828
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to accommodate tracking timestamps in all the
__PRE_RAM__ stages (bootblock, verstage, romstage, etc)
of a platform one needs to provide a way to specify
a persistent region of SRAM or cache-as-ram to store
the timestamps until cbmem comes online. Provide that
infrastructure.
Based on original patches from chromium.org:
Original-Change-Id: I4d78653c0595523eeeb02115423e7fecceea5e1e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223348
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Change-Id: Ie5ffda3112d626068bd1904afcc5a09bc4916d16
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/224024
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Change-Id: I8779526136e89ae61a6f177ce5c74a6530469ae1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10790
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
- Add the common/firmware subdir to the baytrail & fsp_baytrail
makefiles and remove the code it replaces.
- Update baytrail & fsp_baytrail Kconfigs to use the common code.
- Update the IFD Kconfig help and prompts for the TXE vs ME.
- Whittle away at the CBFS_SIZE defaults. All the fsp_baytrail
platforms have their own defaults.
Change-Id: I96a9d4acd6578225698dba28d132d203b8fb71a0
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10647
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've got a lot of duplicated code to set up the IFD/ME/TXE/GBE/ETC.
This is the start of creating a common interface for all of them.
This also allows us to reduce the chipset dependencies for CBFS_SIZE.
Change-Id: Iff08f74305d5ce545b5863915359eeb91eab0208
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10613
Tested-by: build bot (Jenkins)
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The CBFS size is really mainboard specific, since it really depends on
size of the chip on the mainboard, so it makes sense to have it in
the mainboard menu along with the ROM-chip size.
- Move the CBFS_SIZE definition up in src/kconfig
- Move the Mainboard Menu markers out of src/mainboard/kconfig into
src/Kconfig so CBFS_SIZE can live in the mainboard menu.
- Add a long list setting default values to do what the chipset
directories were previously defaulting the values to. This will
be trimmed down in a following patch that creates a common set of
IFD routines. (Who knew that kconfig supported line wrapping?)
- Update the help text.
Change-Id: I2b9eb5a6f7d543f57d9f3b9d0aa44a5462e8b718
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10610
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Because Kconfig uses the first valid default that it comes across, the
'source' commands to load sub-Kconfigs should be ordered from the
most specific (mainboards) to less specific (chipsets) to least specific
(architectures). This allows the mainboards to override chipsets and
architecture Kconfig files.
Because the architecture files were getting loaded ahead of the chipset
and cpu Kconfigs, the preferred defaults values for things such as
NUM_IPI_STARTS or RISCV_BOOTBLOCK_CUSTOM could not be set.
Change-Id: Ic327452833f012ec06dabb5b5ef661aba3aff464
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10609
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
It's derived from EEPROM on Lenovo machines and not from user config
which is ignored.
Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7055
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
The default ordering for the base kconfig entries has the CPU
directory coming before the SOC directory, which means that the
values in the CPU Kconfig take precedence.
The first visible consequence of this is that CONFIG_SMM_TSEG_SIZE
will be set to 0 on all SOC implementations.
BUG=chrome-os-partner:40635
BRANCH=none
TEST=build and boot on glados
Change-Id: Ifd56a2ceb73ab335a86126e48d35ff4c749990ac
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0cddae37d3de1cbf3dd6afcf4a0707b7af9436fa
Original-Change-Id: I98e3bf249650b50667dde62b6be9c1bf587ad0b2
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/276189
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10478
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
generate_sata_ssdt_ports() generates ports based on sata enable map
Change-Id: Ie68e19c93f093d6c61634c4adfde484b88f28a77
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9708
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
RELOCATABLE_MODULES controls inclusion of rmodule support but including it
without having anything that uses it is a pure waste of space. So instead
make RELOCATABLE_MODULES be selected exactly when there is something using it.
Change-Id: I377a955f0cd95b0f811b986df287864c3dc9f89a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10377
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Export SLIC table from file in CBFS.
Change-Id: Id0e7fe0a49b9cd50b5e43cd15030e1c2098728ec
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7202
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
All boards now use per-device ACPI. This patch finishes migration
by removing transitional kludges.
Change-Id: Ie4577f89bf3bb17b310b7b0a84b2c54e404b1606
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7372
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
This adds a compiler for a language whose textual representation of flashmap
regions will be used to describe the layout of flash chips that contain more
than just a single CBFS. Direct integration with cbfstool (via a new
command-line switch for the create action) is forthcoming but will be added
separately.
BUG=chromium:461875
TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for
panther. Using the latter file as a reference, write a corresponding
fmap.fmd file and feed it through fmaptool. Run both binary output files
though the flashmap project's own flashmap_decode utility. Observe only
the expected differences.
BRANCH=None
Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142
Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9942
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific
directory. See follow-on patches for sharing of common code.
Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
RTC drivers now select RTC, so that code which depends on them
can implement fallback behavior for systems that lack the
hardware or driver.
Change-Id: I0f5a15d643b0c45c511f1151a98e071b4155fb5a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9953
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds manual board id support to coreboot and
selects manual board ids vs automatic (ie strap based)
where appropriate in the mainboards.
CQ-DEPEND=CL:262935
BRANCH=none
BUG=chrome-os-partner:37593
TEST=emerge-urara coreboot, see no board_id file
emerge-buranku coreboot, see board_id file
Change-Id: Ia04e5498a01f35c5418698ecaf3197f56415e789
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3bdb1fa092005be24de9fc68998053982648da85
Original-Change-Id: I4f0820233a485bf92598a739b81be2076d4e6ae7
Original-Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262745
Original-Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-on: http://review.coreboot.org/9905
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code guarded by BOARD_ID_SUPPORT does not use this library.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BRANCH=none
BUG=none
TEST=emerge-storm coreboot succeeds in building an image.
Change-Id: If8c5c326265441f0c10999e3882706432139fd89
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f49b89e0b03f482a30dc652e5956494fb994cc70
Original-Change-Id: Ie2cd2cd049fdb20fa5cc368bee08babd3f7a551c
Original-Reviewed-on: https://chromium-review.googlesource.com/262744
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Original-Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9900
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ramstage is loaded from romstage, so the LZMA scratchpad buffer used
to decompress it is part of the romstage BSS in SRAM. On RK3288, SRAM
cannot be cached which makes the decompression so slow that it's faster
to just load an uncompressed image from SPI. Disable ramstage
compression on this SoC to account for that.
[pg: implementation avoids restructuring all of Kconfig]
BRANCH=None
BUG=None
TEST=Built for Pinky and Falco, confirmed that the former didn't have
COMPRESS_RAMSTAGE in its .config and the latter still did. Measured a
speed-up of about 35ms on Pinky. (For some weird reason, the
decompression of the payload also takes way longer than on other
platforms, although not as long as the ramstage. I have no explanation
for that and can't really think of a good way to figure it out... maybe
the Cortex-A12 is just terrible at some operation that LZMA uses a lot?)
Change-Id: I9f67f7537696ec09496483b16b59a8b73f4cb11b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9792
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch fixes a bug that caused non-x86 boards to use the poor man's
assert() version with a lot more instructions per invocation and
hexadecimal line numbers in __PRE_RAM__ environments. This was really
just an oversight in the ARM port... even x86 uses a proper printk() in
most cases (those with CAR) and there's no reason not to do so on the
generally even more flexible SRAM-based architectures.
Additionally, it adds a new Kconfig option to make failed assertions and
BUG() calls halt again. This seems to have been the original intention,
but was commented out once out of fear that this might prevent
production systems from booting. It is still a useful debugging feature
though (since otherwise assertions can easily just scroll past and get
overlooked), so the user should be able to decide the this based on his
needs.
(Also changed error messages for both to include the word "ERROR", since
grepping for that is the most sophisticated way we currently have to
detect firmware problems. Some automated Chromium OS suspend tests check
for that.)
BRANCH=veyron
BUG=None
TEST=Booted Jerry. Compared binary sizes before and after, new version's
bootblock is some ~600 bytes smaller.
Change-Id: I894da18d77e12bf104e443322e2d58e60564e4b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6a5343124719c18a1c969477e3d18bda13c0bf26
Original-Change-Id: I0268cfd67d8c894406b18bb3759a577944bcffb1
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/250661
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9775
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This patch introduces a new option (CONFIG_MULTIPLE_CBFS_INSTANCES) to
allow multiple CBFS instances in the bootrom.
When the new option is enabled, the code running on the target
controls which CBFS instance is used. Since all other then header CBFS
structures use relative addressing, the only value which needs
explicit setting is the offset of the CBFS header in the bootrom.
This patch adds a facility to set the CBFS header offset. The offset
value of zero means default. i.e. the CBFS initialization code still
discovers the offset through the value saved at the top of the ROM.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=with the rest patches in, storm target successfully boots from RW
section A.
Change-Id: Id8333c9373e61597f0c653c727dcee4ef6a58cd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e57a3a15bba7cdcca4a5d684ed78f8ac6dbbc95e
Original-Change-Id: I4c026389ec4fbaa19bd11b2160202282d2f9283c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237569
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Commit 54229a7 (arm: Fix checkstack() to use correct stack size) didn't
quite hit the mark. Due to the crazy way our Kconfig includes work, It
accidentally set CONFIG_STACK_SIZE to 0 even on architectures that need
it.
This patch fixes the issue by moving everything back to a single entry
in src/Kconfig, making sure we end up with the intended numbers on all
architectures.
BRANCH=None
BUG=chrome-os-partner:34750
TEST=Built for Pinky, Urara, Falco and Ryu. Confirmed that the generated
.config contained CONFIG_STACK_SIZE=0x0 for the former two, and
CONFIG_STACK_SIZE=0x1000 for the latter.
Original-Change-Id: Ib18561925aafe7c74e6c4f0b10b55000a785e144
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236753
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c64b127e163f98162f3f7195b6ed09bd5a4b77c4)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I2c747b04760bc97f43523596640bfb15317e5730
Reviewed-on: http://review.coreboot.org/9696
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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.
[pg: this was already partly upstreamed. These are the remains.
Further cleanup is necessary and on the short-term TODO, but beyond
the scope of this commit]
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().
Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76
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>
Reviewed-on: http://review.coreboot.org/9602
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the RAM config code to the coreboot tables. The purpose is
to expose this information to software running at higher levels, e.g.
to print the RAM config coreboot is using as part of factory tests.
The prototype for ram_code() is in boardid.h since they are closely
related and will likely have common code.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=tested w/ follow-up CLs on pinky
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Idd38ec5b6af16e87dfff2e3750c18fdaea604400
Original-Reviewed-on: https://chromium-review.googlesource.com/227248
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 77dd5fb9347b53bb8a64ad22341257fb3be0c106)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibe7044cafe0a61214ac2d7fea5f7255b2c11829b
Reviewed-on: http://review.coreboot.org/9438
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.
BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky
Change-Id: Iaf1cac6e90b6c931100e9d1b6735684fac86b8a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93db63f419f596160ce2459eb70b3218cc83c09e
Original-Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228322
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9413
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.
BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.
Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed
Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With kconfig understanding wildcards, we don't need
Kconfig files that just include other Kconfig files
anymore.
Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9298
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's an unfortunate side effect of our different-archs-per-stage
mechanism that all src/arch/*/Kconfig files are always parsed with no
if blocks to exclude them if they're not relevant. This makes it very
easy to accidentally rely on a Kconfig default set by a totally
different and not applying architecture.
This patch moves a few Kconfigs from ARM and X86 that leaked out like
this into a common Kconfig file for clarity. It also gives ARM64 its
own BOOTBLOCK_CUSTOM mechanism so that it doesn't leech off the ARM one
(currently not used by any board).
In the future, we should maybe prefix all options in the arch/*/Kconfig
files with the architecture name (such as X86_BOOTBLOCK_NORMAL and
ARM_LPAE are already doing), to make it more apparent when they are used
in the wrong place.
BUG=None
TEST=None (tested together with dependent changes)
Change-Id: I3e8bb3dfbb2c4edada621ce16d130bd7387d4eb8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5528aa9252cdf711af3c160da387c6a7bebe9e76
Original-Change-Id: Ieb2d79bae6c6800be0f93ca3489b658008b1dfae
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219171
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9235
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These boards are supposed to be able to determine the board ID at run
time based on GPIO settings.
BUG=chrome-os-partner:30489
TEST=verified that all boards build. Checked that storm proto0 reports
board ID of 0 on the console
Original-Change-Id: Iadd758a799d69e1e34579d7d495378856b64c45b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210119
(cherry picked from commit f4d41ddf906c1bf0d10da38011998fa0a630c332)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d5f94d3428157a70f0a9d711b57432e3f796733
Reviewed-on: http://review.coreboot.org/8722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Board ID value is usually of interest to bootloaders. Instead of
duplicating the board ID discovery code in different bootloaders let's
determine it in coreboot and publish it through coreboot table, when
configured.
BUG=chrome-os-partner:30489
TEST=none yet
Change-Id: Ia1e36b907ac15b0aafce0711f827cb83622e27bb
Original-Change-Id: Iee247c44a1c91dbcedcc9058e8742c75ff951f43
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210116
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit b2057a02db9391e2085b138eea843e6bb09d3ea2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8719
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
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>
Under certain conditions, e.g. automated testing, it is useful
to have the payload (e.g. Linux) reset the reboot_bits CMOS
value. This allows automated recovery in the case of coreboot
starting properly but the payload failing to start due to bad
configuration data provided by the coreboot image under test.
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Change-Id: Ifc8f565f8292941d90b2e520cc9c5993b41e9cdd
Reviewed-on: http://review.coreboot.org/8698
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
In specific configurations, such as homogeneous supercomputing systems,
changeable NVRAM parameters are more of a liability than a useful tool.
This patch allows a coreboot image to be compiled that will always set
the NVRAM parameters to their default values, reducing maintainance
overhead on large clusters.
Change-Id: Ic03e34211d4a58cd60740f2d9a6b50e11fe85822
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8446
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
SeaVGABIOS supports both the coreboot linear framebuffer and native EGA
text mode. To use SeaBIOS interactively on standard VGA hardware a VBIOS
is needed; SeaVGABIOS is one such option.
TEST: Booted KFSN4-DRE with XGI Volari Z9s and SeaVGABIOS. Was able to
interact with SeaBIOS and comboot menu, then booted Linux successfully.
VGA display was continuously usable from power on to Linux login.
Change-Id: Id4bd4cb5cece9114457633832c5f0e5280c02b47
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8368
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
We can now create CBMEM with dynamic allocation even if CBMEM
location is resolved late in ramstage.
Change-Id: I8529ccbcd4a0e567ebe0a46232ac5d16476e81a8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7861
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
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)
In preparation to remove the static CBMEM allocator, tag the chipsets
that still do not implement get_top_of_ram() for romstage.
LATE_CBMEM_INIT also implies BROKEN_CAR_MIGRATE.
Change-Id: Iad359db2e65ac15c54ff6e9635429628e4db6fde
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7850
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I9210241c902ad8a88980a7c9cdb0d52c460b2541
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/8025
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Coreboot has all necessary infrastructure to use the proper SPI flash
interface in bootblock for CBFS. This patch creates a common CBFS
wrapper which can be enabled on different platforms as required.
COMMON_CBFS_SPI_WRAPPER, a new configuration option, enables the
common CBFS interface and prevents default inclusion of all SPI chip
drivers, only explicitly configured ones will be included when the new
feature is enabled. Since the wrapper uses the same driver at all
stages, enabling the new feature will also make it necessary to
include the SPI chip drivers in bootblock and romstage images.
init_default_cbfs_media() can now be common for different platforms,
and as such is defined in the library.
BUG=none
TEST=manual
. with this change and the rest of the patches coreboot on AP148
comes up all the way to attempting to boot the payload (reading
earlier stages from the SPI flash along the way).
Original-Change-Id: Ia887bb7f386a0e23a110e38001d86f9d43fadf2c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197800
Original-Tested-by: Vadim Bendebury <vbendeb@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 60eb16ebe624f9420c6191afa6ba239b8e83a6e6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7b0bf3dda915c227659ab62743e405312dedaf41
Reviewed-on: http://review.coreboot.org/7932
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.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>
Its scope is limited to a single mainboard and is only to go through ifdef.
Kill it and move the value to the code.
Change-Id: I76a87e2790d57dee8f37b51e33d0689fffd3a59d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7135
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Works in the RISCV version of QEMU.
Note that the lzmadecode is so unclean that it needs a lot of work.
A cleanup is in progress.
We decided in Prague to do this as one thing, because it forms a nice case study
of the bare minimum you need to add to get a new architecture going in qemu.
Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7584
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
There are no reasons to not load ramstage @ 0x100000.
Boards with HAVE_ACPI_RESUME enabled have performance penalty in using
excessive RAMTOP. For these boards, this change releases 11 MiB of RAM from CBMEM allocation to OS.
Change-Id: Ib71995aba5e9332d0ec1626b3eb3b4ef6a506d1c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7094
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Only one setting actually works (exact value depends on board). So
no need to show it.
Change-Id: I2a85719264bbac07791ef6a9279590ba768c309e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7359
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
Currently clang/llvm builds are not fully supported. As such,
let us tone down treating errors as warnings until we actually
build the entire tree.
Change-Id: If7f90f9887e27250f5e6d73d1692505676be9d47
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7230
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The reg_script functionality is only used by specific chipsets so have
it selected instead of defaulting to y for ARCH_X86.
Change-Id: I8fb9466e148eed7896ca8ed80755c77ba1190583
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7006
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Move generic options to the "General Setup" menu.
Move device specific options to the "Devices" menu.
Change-Id: I514a021305d43f026b24fd3016477300700ed401
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/7089
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
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>
Julius Werner