Age | Commit message (Collapse) | Author |
|
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: Ia410b61c4babdfa3c984539527a9739462d3ad80
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5141
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Change-Id: I978b6009c09c31be4429f57be40ef82f438f7574
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Also relocate and split header files, there is some interest
for EHCI debug support without PCI.
Change-Id: Ibe91730eb72dfe0634fb38bdd184043495e2fb08
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5129
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: I2ecfd9733b65b6160bc2232d22db7b16692a847f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5149
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.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>
|
|
The access to control registers were scattered about.
Provide a single header file to provide the correct
access function and definitions.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted using this infrastructure. Also objdump'd the
assembly to ensure consistency (objdump -d -r -S | grep xmm).
Change-Id: Iff7a043e4e5ba930a6a77f968f1fcc14784214e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172641
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4873
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>
|
|
Improve clang compatibility by dropping an opaque hack
The section attribute was only ever meant for specifying
section names, not their properties - otherwise they would
have provided section(name,attribute,class) instead of only
section(name).
The hack to add attribute and class to the name, and commenting
out the "real" definitions inserted by the compiler (see the
terminating "#"), is refused by clang developers.
This is a cleaner implementation in that the section is first
declared with its properties, then used later-on, expecting that
later conflicting declarations are ignored.
It can still break in two ways:
1. The assembler or linker could complain about a section declared
in two different ways.
2. The assembler could just use the latest declaration, not the first,
to determine the section's properties.
I won't sort these out unless they actually happen.
Change-Id: I4640b0fc397b301102dde6dc3ea1a078ce9edf1c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4716
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
On x86, log2() is defined as an inline function in arch/io.h. This is
a remnant of ROMCC, and forced us to not include clog2.c in romstage.
As a result, romstage on ARM has no log2().
Use the inline log2 only with ROMCC, but otherwise, use the one in
clog2.c.
Change-Id: Ifef2aa0a7b5a1db071a66f2eec0be421b8b2a56d
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4681
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This changes eliminates a warning from the ASL compiler.
Change-Id: I502cca731b6b4cd3e17c57fc191f1eed10a5a1fe
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4093
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
THis reduces risks of bufer overflows.
Change-Id: I77f80e76efec16ac0a0af83d76430a8126a7602d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
CBMEM console buffer size is adjustable in menuconfig, but this would
not correctly adjust the overall allocation made for CBMEM.
HIGH_MEMORY_SIZE is aligned to 64kB and definitions are moved down in
the header file as HIGH_MEMORY_SIZE is not used with DYNAMIC_CBMEM.
Try to continue boot even if CBMEM cannot be created. This error would
only occur during development of new ports anyways and more log output
is better.
Change-Id: I4ee2df601b12ab6532ffcae8897775ecaa2fc05f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4621
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
This function was for logging only, but we have both base and size
already logged elsewhere.
Change-Id: Ie6ac71fc859b8fd42fcf851c316a5f888f828dc2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Handler is ACPI/x86 specific so move details out of cbmem code.
With static CBMEM initialisation, ramstage will need to test for
S3 wakeup condition so publish also acpi_is_wakeup().
Change-Id: If591535448cdd24a54262b534c1a828fc13da759
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4619
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
If there is trouble setting up usbdebug, it may be useful to delay
usbdebug init to run in ramstage.
Change-Id: I31de5a06d3f9ce19f71c422cce0c8cb0fd50f396
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4488
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This patch implements the basic infrastructure required to use the USB
A-A firmware upload feature on Exynos5 processors with Coreboot. It will
require a corresponding host-side script that activates the feature and
uploads the correct image parts in the correct order to harcoded target
addresses, as described in the comments of alternate_cbfs.c.
Also fixes a bug in the Google Snow mainboard where it would not
correctly initialize the pinmux configuration for the SPI flash bus.
During a normal SPI boot the IROM would already do that for you, but
when booting from USB you have to do it yourself.
Change-Id: I40a39f8f5d1d70b58dbf258015c1653a27097d67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64875
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4456
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The ACTLR provides implementation defined configuration and control options for
the processor.
Change-Id: I74df1ed7887eb3f16a1b8297db998ec2f8b18311
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65107
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4447
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
To configure multi-processors, we need the intrinsic functions to get core ID,
put core into idle state, and to wake up cores.
Change-Id: I87a62dab6efd6c8bb0c8e46373da7c7eb7b16b35
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65112
Reviewed-on: http://review.coreboot.org/4444
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This adds inline wrappers to read the L2 cache auxiliary control
register (L2ACTLR).
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iec603d7c738426232f7ce3a4a474d01c85fa3f2f
Reviewed-on: https://gerrit.chromium.org/gerrit/64861
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4437
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I128e3ecc3773fe7c28616e93ef60b48c5862f302
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64839
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4436
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
On ARM, if the .car section is marked as NOLOAD, there's nothing that sets it
to zero. Some code in the cbmem console depends on a global variable being
zero initially, and if that's not true bad things happen.
Change-Id: Ic72a9fb0ee0c5a608190be6f24d0d7de7c34fc1f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64769
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The CBMEM console pointer in romstage is actually a zero byte array.
This means CBMEM area has to live at the end of the allocations or
else CBMEM console will overwrite whatever comes after it.
Change-Id: Icc59e982b724a2d396370c3a5abd8898e08baf26
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63997
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4428
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
That symbol isn't used by anything and doesn't appear in other linker scripts.
Change-Id: Iab54ecb3be2e262d7674ef8ee7ed13ea2e5b56f3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63776
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4399
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The CBMEM API is different for dynamic CBMEM,
so hide the functions that get in the way (but
our compiler complains about)
Change-Id: I7634a202059548e56c74fe3fe6eff57bc60f1a1b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4546
Tested-by: build bot (Jenkins)
|
|
Despite calling romstage memory CAR in this case, the variables actually
do live in SRAM on the Exynos CPUs. However, in order to share as much
generic code as possible, we're using the same infrastructure here.
Change-Id: I85173c37099a25f3e55980e88120401826cdf29c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62188
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4394
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
This functions are by definition changing the data pointed to by their
arguments, so they shouldn't by const.
Change-Id: Id29b3f76526aba463f8bb744f53101327f9c7bde
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63777
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4400
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The OP assigned by dcache_clean_by_mva must be handled in dcache_op_mva.
Change-Id: Ia7631a08be6afacb13dfff406ac4db20efc98926
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61076
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4343
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
walkcbfs() is used only with ROMCC. Besides finding stages during the
bootblock, it's also used when applying microcode updates during the
bootblock phase. The function used to return only a pointer to the data of
the CBFS file, while making the header completely inaccessible. Since the
header contains the length of the CBFS file, the caller did not have a way
to know how long the data was. Then, other conventions had to be used to
determine the EOF, which might present problems if the user replaces the
CBFS file. This is not an issue when jumping to a stage (romstage), but can
present problems when accessing a microcode file which has not been
NULL-terminated.
Refactor walkcbfs_asm to return a pointer to the CBFS file header rather
than the data. Rename walkcbfs() to walkcbfs_head(), and reimplement a new
walkcbfs() based on walkcbfs_head(). Thus current usage of walkcbfs()
remains unaffected.
The code has been verified to run successfully under qemu.
Subsequent patches will change usage of walkcbfs() to walkcbfs_head where
knowing the length of the data is needed.
Change-Id: I21cbf19e130e1480e2749754e5d5130d36036f8e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The original intention was to only run UPDATE_FIT when a microcode file was
included in CBFS. This happens when either CPU_MICROCODE_CBFS_GENERATE or
CPU_MICROCODE_CBFS_EXTERNAL is selected, however, the makefile checked that
CPU_MICROCODE_IN_CBFS was selected instead. The end result was that on
hasswell, the UPDATE-FIT step was always run, even when no microcode was
included, generating a build error.
Instead, introduce a new variable which tells if a microcode update is
added in CBFS during the build.
Change-Id: I28638912ed6f77761ef8a584f7636dc907b7a9b7
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4480
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The source files were removed with commit 3e4e3038.
Change-Id: I2df9d8cce0ec1462dcba4790a6c62abade0d223c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/4298
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
Reviewed-on: http://review.coreboot.org/4230
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
Reviewed-on: http://review.coreboot.org/4229
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
The CMOS post code storage mechanism does back-to-back
CMOS reads and writes that may be interleaved during
CPU bringup, leading to corruption of the log or of other
parts of CMOS.
Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4227
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Some code was previously removed regarding elf notes. However,
that code left a dangling comma under !CONFIG_MULTIBOOT
configs for inline assembly constraints. Instead, place the comma
within the #ifdef stanza.
Change-Id: I805453ef57d34fbfb904b4d145d8874921d8d660
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56844
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
Reviewed-on: http://review.coreboot.org/4207
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Mainboards were defining their own SMBIOS type41
write function. Instead pull this into the generic
SMBIOS code and change the existing mainboards to
make use of it.
Change-Id: I3c8a95ca51fe2a3118dc8d1154011ccfed5fbcbc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4187
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
In order for the FIT entries to be populated in the table the
update-fit command needs to be done on the coreboot image. That
way the microcode entries are added to the table properly.
Change-Id: I44595aee1ca710f4f04d482d8900cf95fbc1797f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50317
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4159
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The mainboard_interrupt_handlers() argument for the function
pointer was using void * as the type. This does not allow the compiler
to catch type differences for the arguments. Thus, some code has been
committed which violates the new interrupt callbacks not taking any
arguments. Make sure the compiler provides a type checking benefit.
Change-Id: Ie20699a368e70c33a9a9912e0fcd63f1e6bb4f18
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48970
Reviewed-on: http://review.coreboot.org/4141
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@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>
|
|
Make manufacturer, product_name and uuid smbios fields (type 1)
configurable at runtime, simliar to version and serial number.
Change-Id: Ibc826225e31fa42aa944fa43632dd6a406d5c85d
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4085
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: Ia710eb59f23a52afba2a8ef6e0ff2b2306107245
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4033
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
SeaBIOS’ Makefile requires cpp (C Preprocessor) to build. Modify
the xcompile script to search for cpp program path, and pass it to
SeaBIOS’ `Makefile.inc`. Also pass the program path for as (GNU assembler).
This is needed, so the crossgcc toolchain to build the SeaBIOS payload
under Mac OSX. OSX ships a cpp program, but it works differently
from GNU CPP, so we need to override it.
Change-Id: If996ffbb76ec4bd16079b54b41f3fac07bfe25be
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3896
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
|
|
It is expected this will always be a casted get_top_of_ram() call
on x86, no reason to do that under chipset.
Change-Id: I3a49abe13ca44bf4ca1e26d1b3baf954bc5a29b7
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3972
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
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>
|
|
Dummy get_top_of_ram() is removed from romstage to fail already at
build-time for cases where cbmem_initialize() would not complete.
The mechanisms behind CAR_GLOBAL migration only work correctly when
romstage can succesfully make the cbmem_initialize() call.
Change-Id: I359820fb196ef187b9aa2e8a3e8f658a0550f237
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3969
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This reverts commit de1fe7f655c549e8dce5b34218221890fa5ccc34.
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>
|
|
and add an ARMv7 version.
Change-Id: I14fbff88d7c2b003dde57a19bf0ba9640d322156
Signed-off-by: Stefan Reinauer <reinauer@google.com>
[km: rebased fa004acf8 from chromium git]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3939
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
If romstage does not make cbmem_initialize() call, linker should
optimize the code for CAR migration away.
This simplifies design of CBMEM console by a considerable amount.
As console buffer is now migrated within cbmem_initialize() call there
is no longer need for cbmemc_reinit() call made at end of romstage.
Change-Id: I8675ecaafb641fa02675e9ba3f374caa8e240f1d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3916
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
These features depend on CAR_GLOBAL region, which is not available
when romstage is built with ROMCC. Exclude these from romstage, keep
them available for ramstage.
A follow-up patch will fix the dependencies and allows enabling these
features in menuconfig.
Change-Id: I9de5ad41ea733655a3fbdc734646f818e39cc471
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3919
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
These dependencies came indirectly through kconfig.h which was included
automatically with a -include option which was either part of INCLUDES or
specified directly. With this change, I'm able to build for beaglebone with
make -j 48.
Change-Id: Ib57d0c6a755b747165b235c2328c3c30bd6dd67d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3922
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
AMD northbridges have a complex way to resolve top_of_ram.
Once it is resolved, it is stored in NVRAM to be used on resume.
TODO: Redesign these get_top_of_ram() functions from scratch.
Change-Id: I3cceb7e9b8b07620dacf138e99f98dc818c65341
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3557
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
For both romstage and ramstage, this calls an arch-specific function
get_cbmem_table() to resolve the base and size of CBMEM region. In ramstage,
the result is cached as the query may be relatively slow involving multiple PCI
configuration reads.
For x86 CBMEM tables are located right below top of low ram and
have fixed size of HIGH_MEMORY_SIZE in EARLY_CBMEM_INIT implementation.
Change-Id: Ie8d16eb30cd5c3860fff243f36bd4e7d8827a782
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Unify checks and writing of CBMEM tables for x86 and ARMv7.
Change-Id: I89c012bce1b86d0710748719a8840ec532ce6939
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3559
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
This helper function is for compatibility only for chipsets that do
not implement get_top_of_ram() to support early CBMEM.
Also remove references to globals high_tables_base and _size under
arch/ and from two ARMv7 boards.
Change-Id: I17eee30635a0368b2ada06e0698425c5ef0ecc53
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3902
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
We can postpone the call to set_top_of_ram_once() outside the
loops and make just one call instead.
As set_top_of_ram() is now only called once, it is no longer
necessary to check if high_tables_base was already set.
Change-Id: I302d9af52ac40c7fa8c7c7e65f82e00b031cd397
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Prepare for removal of globals high_tables_base and _size
by replacing the references with a helper function.
Added set_top_of_ram_once() may be called several times,
but only the first call (with non-zero argument) takes effect.
Change-Id: I5b5f71630f03b6a01e9c8ff96cb78e9da03e5cc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3894
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.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)
|
|
Declare the functions that may be used in both romstage and ramstage
with simple device model. This will later allow to define PNP access
functions for ramstage using the inlined functions from romstage.
Change-Id: I2a0bd8194acaf9c4c7252a29376eec363397e3a6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3871
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Declare the functions that may be used in both romstage and ramstage
with simple device model. This will later allow to define PCI access
functions for ramstage using the inlined functions from romstage.
Change-Id: I32ff622883ceee4628e6b1b01023b970e379113f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Add Kconfig option SQUELCH_EARLY_SMP and have it enabled by
default.
Console drivers have unpredictable results if multiple threads
attempt to share same resources without spinlock. Serial UARTs
have not had huge problems, only distorted output, but those
relying on cache-as-ram (CBMEM and usbdebug) may require this.
Change-Id: I7f406fdea7b6dc6a341c4da2fab56f7b7ff568b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3854
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
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>
|
|
src/arch/x86/boot/tables.c and src/include/device/pci_ids.h are also
changed because these two files depend on F16kb northbridge macros
Change-Id: Iedc842f0b230826675703fc78ed8001a978319c5
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Bruce Griffith <bruce.griffith@se-eng.com>
Tested-by: Bruce Griffith <bruce.griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/3782
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
The tests for __PRE_RAM__ or __SMM__ were repeatedly used
for detection if dev->ops in the devicetree are not available
and simple device model functions need be used.
If a source file build for ramstage had __PRE_RAM__ inserted
at the beginning, the struct device would no longer match the
allocation the object had taken. This problem is fixed by
replacing such cases with explicit __SIMPLE_DEVICE__.
Change-Id: Ib74c9b2d8753e6e37e1a23fcfaa2f3657790d4c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3555
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Taking device_t as a parameter, this allows to alter the PCI config
access handlers. This is useful to add tracing of PCI config writes
for devices having problems to initialise correctly.
On older AMD platform PCI MMIO may not be able to fully configure all
PCI devices/nodes, while MMIO_SUPPORT_DEFAULT would be preferred due
to its atomic nature. So those can be forced to IO config instead.
Change-Id: I2162884185bbfe461b036caf737980b45a51e522
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3608
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
The code to figure out how to set num_starts was
starting to get kludgy. It's a constant for a given
CPU; constants should be constant; make it a config variable.
This change includes an example of how to override it.
Build but not boot tested; drivers welcome.
Change-Id: Iddd906a707bb16251615c7b42f2bfb5a044379b4
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3796
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
|
|
At least when building with the gnu toolchain, the headers the linker
automatically generate save space for the actual ELF headers in one of the
loadable segments. This creates two problems. First, the data you intended to
be at the start of the image doesn't actually show up there, it's actually the
ELF headers. Second, the ELF headers are essentially useless for firmware
since there's currently nothing to tell you where they are, and even if there
was, there isn't much of a reason to look at them. They're useful in userspace
for, for instance, the dynamic linker, but not really in firmware.
This change adds a PHDRS construct to each of the linker scripts used on ARM
which define a single segment called to_load which does not have the flag set
which would tell the linker to put headers in it. The first section defined in
the script has ": to_load" to tell the linker which segment to put it in, and
from that point on the other sections go in there by default.
Change-Id: I24b721eb436d17afd234002ae82f9166d2fcf65d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3580
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Id338968429435bac26595c4843b07cdbb91dd64d
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3618
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The vendor and part name from coreboot is normally stored in these
SMBIOS structure fields, but it can be useful to override them.
On Lenovo ThinkPads an override is e.g. needed to convince the Linux
thinkpad_acpi.c driver that it is actually running on a ThinkPad.
Change-Id: I0dfe38b9f6f99b3376f1547412ecc97c2f7aff2b
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/1556
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
|
|
This version is taken from arch/arm/lib/memmove.S in the Linux kernel.
Change-Id: Ic875d0cf5b1cb407606530b7f465c406b134f0fa
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3763
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This is from memcpy_32.c in the Linux kernel. There was no copyright header
in the original file either.
Change-Id: Ifd259cb8a87615dce79ed1e551cc4bacb0414b4f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3762
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>
|
|
Some kernel assembly code uses a W macro to optionally add a .w to
instructions that need to be 32 bit thumb. The gnu assembler doesn't seem to
need the .w and won't assemble if it's provided.
Change-Id: I0a288177788b5c61810ee7bd3d2debea66835de2
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3759
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Split PCI IO configuration and MMIO configuration cycles to separate
files. Modern hardware does not use IO cycles for PCI configuration
after initial setup in bootblock.
Note that the pci_mmio_ and pcie_ functions were different in masking
the alignment for register address. PCI standard requires that 16-bit
and 32-bit configuration register writes do not cross boundaries.
Change-Id: Ie6441283e1a033b4b395e972c18c31277f973897
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3554
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
PCI bus operations are static through the ramstage, and should be
initialized from the very beginning. For all the replaced instances,
there is no MMCONF_SUPPORT nor MMCONF_SUPPORT_DEFAULT selected for
the northbridge, so these continue to use PCI IO config access.
Change-Id: I658abd4a02aa70ad4c9273568eb5560c6e572fb1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Move ehci_debug_info allocation from console to lib, as console code
was only built for ramstage.
Implement dbgp_ehci_info() to return the EHCI context. Alread alias this
as dbgp_console_input() and _output() to return the console stream context
later on.
Change-Id: Id6cc07d62953f0466df61eeb159e22b0e3287d4e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3625
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Change-Id: I89bf8a229dba7e1330accadf9a732d831ebc4827
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3694
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This is already called in ARMv7 bootblock_simple.c so we don't
want to do it twice
Change-Id: I80cb41035b8a77787e04f2ea58a1cd372cea97d8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3692
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Currently, the exception handling code on ARM turns on alignment checks as an
easy way to generate an exception for testing purposes. It was leaving it on
which disabled unaligned accesses for other, unlreated code running later.
This change adjusts the code so the original value of the alignment bit is
restored after the test exception.
Change-Id: Id8d035a05175f9fb13de547ab4aa5496d681d30c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3690
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The dmb should be executed before reading operations, and before/after writing
operations.
Change-Id: I572136a2f9a07eb2c38a112f5deeb2de0c0fd46c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3682
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The code has been there for quite a while but was never enabled.
Change-Id: I4ec3dcbb3c03805ac5c75872614e5d394df667cf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3675
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3671
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
remove some unused code
Change-Id: I41602fb391c1910c588a4f9dcc7c2edefe8ab5bc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3669
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3664
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
Change-Id: Ia200d62dbcf7ff1fa59598654718a0b7e178ca4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3663
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This stuff is not used, so let's drop it.
Change-Id: I671a5e87855b4c59622cafacdefe466ab3d70143
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
With only 19 source files it doesn't make a whole lot of sense to
create sub directories in arch/armv7, especially since the files
were distributed somewhat randomly.
Change-Id: I029c7848e915edf1737e1c401c034837c95d179d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3659
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When modifying the page tables, use writel to ensure the writes happen, flush
the page tables themselves to ensure they're visible to the MMU if it doesn't
look at the caches, and invalidate the right TLB entries.
The first two changes are probably safer but may not be strictly necessary.
The third change is necessary because we were invalidating the TLB using i
which was in megabytes but using an instruction that expects an address in
bytes.
One symptom of this problem was that the framebuffer, which was supposed to be
marked uncacheable, was only being partially updated since some of the updates
were still in the cache. With this change the graphics show up correctly.
Change-Id: I5475df29690371459b0d37a304eebc62f81dd76b
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3653
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ifea10f0180c0c4b684030a168402a95fadf1a9db
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3727
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The page tables need to be aligned to a 16KB boundary and are 16KB in size.
The CBMEM allocator only guarantees 512 byte alignment, so to make sure
things are where they're supposed to be, the code was allocating extra space
and then adjusting the pointer upwards. Unfortunately, it was adding the size
of the table to the pointer first, then aligning it. Since it allocated twice
the space of the table, this had the effect of moving past the first table
size region of bytes, and then aligning upwards, pushing the end of the table
out of the space allocated for it.
You can get away with this if you push things you don't care about off the
end, and it happened to be the case that we were allocating a color map we
weren't using at the start of the next part of cbmem.
Change-Id: I6b196fc573801b02f27f2e667acbf06163266651
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3651
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3647
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3642
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3640
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
... and drop the wrapper on ARMv7
Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3639
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These are not specific to Intel. Further work needs to be done to
combine these with MMCONF_SUPPORT in arch/io.h.
Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3502
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Define at one place whether to use IO 0xcf8/0xcfc or MMIO via
MMCONF_BASE_ADDRESS for PCI configuration access funtions in ramstage.
The implementation of pci_default_config() always returned with
pci_cf8_conf1. This means any PCI configuration access that did
not target bus 0 used PCI IO config operations, if PCI MMIO config
was not explicitly requested.
Change-Id: I3b04f570fe88d022cd60dde8bb98e76bd00fe612
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3606
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
On ARM, there's frequently some firmware built into the SOC which runs
first and which loads other firmware like Coreboot from some other
media. To prevent the bootblock from having to know how to find and load
the ROM stage from what may be a complicated source (sd card,
netbooting, etc.), we can put the ROM stage immediately after the
bootblock and ensure that they're both loaded at the same time.
This change adjusts the Makefile.inc for ARM so that the ROM stage is put
into the image before any other files so that we know it comes first.
This changes the behavior of the CONFIG_UPDATE_IMAGE config option used
by abuild, although it's not entirely clear whether that's still used.
Change-Id: I832386243788156db5f5abbc9760a4e2026cf2cd
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3420
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
This patch adds a qemu x86 cpu chip. It has no initialization function
as this isn't needed on virtual hardware. A virtual machine can have
pretty much any CPU: qemu emulates a wide range of x86 CPUs (try 'qemu
-cpu ? for a list), also with 'qemu -cpu host' the guest will see a cpu
which is (almost) identical to the one on the host machine. So I've
added X86_VENDOR_ANY as wildcard match for the cpu_table.
Change-Id: Ib01210694b09702e41ed806f31d0033e840a863f
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3344
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer
since it was defined in sandybridge. It is really
more of an x86 thing however, and we now have
three systems that can use it.
I considered making this more general, since it technically
can apply to PTE-based systems like ARM, and maybe we should.
But the 'WRCOMB' moniker is usually closely tied to the x86.
Change-Id: I3eb6eb2113843643348a5e18e78c53d113899ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3349
Tested-by: build bot (Jenkins)
|
|
Without that fix we have with CONFIG_USE_OPTION_TABLE:
OPTION cmos_layout.bin
build/util/nvramtool/nvramtool -y /home/gnutoo/x86/coreboot-alix/src/mainboard/pcengines/alix1c/cmos.layout -L build/cmos_layout.bin
make: *** No rule to make target `nvramtool', needed by `build/coreboot.pre1'. Stop.
rm build/util/sconfig/sconfig.tab.c build/cbfs/fallback/bootblock.elf build/util/sconfig/lex.yy.c
That log was captured with make V=1 but the error also appear with make.
Tested on the PC Engines ALIX.1C with the following commit (Change-Id: Ia87b090) [1]:
PC Engines ALIX.1C: Add CMOS defaults.
[1] http://review.coreboot.org/#/c/3323/
Change-Id: I548005a58f430ed7b6da5249a24bbdcae440a1e9
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/3223
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|