We don't seem to need it, and it currently confuses the payload.
(credit to Gabe Black for this, I'm just uploading it)
Change-Id: I4e3a60eceb9b24e3bc8e50db431c1a731d1cdbae
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/2385
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This removes some files leftover from the initial port. Some are
leftover from U-Boot and some were leftover from the skeleton code
derived from x86.
There's a bit more that we'll get in another sweep.
Change-Id: I325793ecb902b3b9430dcf531714ce025d201de6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mmu_setup() was originally written in U-Boot to utilize board-specific
global data. Since we're trying to avoid that, we added start and size
parameters so that board-specific info can be passed in via mainboard
code. Let's start using it that way.
Change-Id: I7d7de0e42bd918c9f9f0c177acaf56c110bf8353
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2378
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The comment introduced in
commit 50c0a50ac6
Author: David Hendricks <dhendrix@chromium.org>
Date: Thu Jan 31 17:05:50 2013 -0800
armv7: unify stage hand-off routines
Reviewed-on: http://review.coreboot.org/2254
contained a typo, which is corrected now.
Change-Id: I87f7cfa82fcd12b6961d3329e634b4c201cc047e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2372
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is just to get us to the payload.
TODO: Do we want to implement any of the stuff from the x86 version,
such as copying coreboot to a new location?
Change-Id: Ia0544f111d7a1189ebd92d0ba3e11448eabd6252
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2363
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
RAMBASE and RAMTOP are leftovers from the x86 port and do not apply
the same way on ARM platforms. On x86 they refer to the low memory
region where coreboot tables reside.
However on ARM we don't have such a region which is architecturally
defined. So instead we'll use the CPU-defined DRAM base address and
the mainboard-defined DRAM size.
This also has the pleasant side-effect of fixing the coreboot tables
to not clobber ramstage code...
Change-Id: I5548ecf05e82f9d9ecec8548fabdd99cc1e39c3b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This places the .id section toward the lower region of the coreboot
image, before the bootblock. It's easier for humans to find by dumping
the image and it also eliminates ID_SECTION_OFFSET which is currently
the upper bound on our image size.
Change-Id: I7d737b901dac659ddf9aa437cee5dc32f1080546
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a .bl1 and .start symbol that is placed at the beginning
of the .rom section.
The goal is to move the .id section in between the reset vector and
bootblock_main.
Change-Id: Ie732ce656d697c059cc0fa40c844b39f53fc214c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Kconfig variable indicates KB, but the number used was bytes.
Let's just assume KB is correct for now.
Change-Id: I910c126104f0222fc48b70a18df943f2afddeca3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Except for one board, the flags can be derived from CONFIG_MMX
and CONFIG_SSE.
Change-Id: I64a11135ee7ce8676f3422b2377069a3fa78e24d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2336
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The bootblock is typically run before fpu/mmx/sse setup, so
we can't rely on -mcpu=p4 and the like to increase the
register space.
bootblock_romccflags does that for SSE, but they're controlled
separately.
Change-Id: I2b0609ac18b2394a319bf9bbbee1f77d2e758127
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2335
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a first-pass attempt at cleaning up the coreboot tables
for ARM. The most noticable difference is that there is no longer
both a high and a low table.
Change-Id: I5ba87ad57bf9a697b733511182c0326825071617
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2329
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a BL1_SIZE_KB config variable so that we can get rid of
some magic constants.
Change-Id: I9dbcfb407d3f8e367be5d943e95b032ce88b0ad0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Explicitly including it allows us to get rid of some magic constants
in the bootblock linker script.
Change-Id: I095899babc997addce6b383f00e5ebf135e99d5e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2331
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Use same console initialization procedure for all ARM stages (bootblock,
romstage, and ramstage):
#include <console/console.h>
...
console_init()
...
printk(level, format, ...)
Verified to boot on armv7/snow with console messages in all stages.
Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Revise console source file dependency (especially for EARLY_CONSOLE) and
interpret printk/console_init according to EARLY_CONSOLE setting (no-ops if
EARLY_CONSOLE is not defined).
Verified to boot on x86/qemu and armv7/snow. Disabling EARLY_CONSOLE correctly
stops romstage messages on x86/qemu (armv7/snow needs more changes to work).
Change-Id: Idbbd3a26bc1135c9d3ae282aad486961fb60e0ea
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2300
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The console drivers (especially serial drivers) in Kconfig were named in
different styles. This change will rename configuration names to a better naming
style.
- EARLY_CONSOLE:
Enable output in pre-ram stage. (Renamed from EARLY_SERIAL_CONSOLE
because it also supports non-serial)
- CONSOLE_SERIAL:
Enable serial output console, from one of the serial drivers. (Renamed
from SERIAL_CONSOLE because other non-serial drivers are named as
CONSOLE_XXX like CONSOLE_CBMEM)
- CONSOLE_SERIAL_UART:
Device-specific UART driver. (Renamed from
CONSOLE_SERIAL_NONSTANDARD_MEM because it may be not memory-mapped)
- HAVE_UART_SPECIAL:
A dependency for CONSOLE_SERIAL_UART.
Verified to boot on x86/qemu and armv7/snow, and still seeing console
messages in romstage for both platforms.
Change-Id: I4bea3c8fea05bbb7d78df6bc22f82414ac66f973
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2299
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Remove duplicated / testing code and share more driver for bootblock, romstage
and ramstage.
The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is
executed before RAM is initialized.
Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2282
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
"SPL" from U-Boot is deprecated by bootblock in coreboot/arm, so we don't need
it anymore.
Change-Id: Id16877075d0b870839a10160073ad70777a2af0a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2297
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
hang() is the legacy function from U-boot and should be replaced by hlt() in
coreboot.
Change-Id: I0f390b1b6f9ff71487ea36cf16c462724b66d8ca
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2298
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The common part of the bootblock resets the nvram data if it's found
to be invalid. Since that code is compiled with romcc in i386 mode,
there's a shortage on registers.
Try to reduce the strain by doing things smarter: cmos_write_inner
is the same as cmos_write, just that it doesn't check if the RTC is
disabled. Since we just disabled it before, we can assume that it is so.
Change-Id: Ic85eb2a5df949d1c1aff654bc1b40d6f2ff71756
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2296
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
For arm/snow, current bootblock is larger than previously assigned CBFS offset
and will fail to boot. To prevent this happening again in future, cbfstool now
checks if CBFS will overlap bootblock.
A sample error message:
E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000)
E: Failed to create build/coreboot.pre1.tmp.
arm/snow offset is also enlarged and moved to Kconfig variable.
Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2295
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We don't need a special Kconfig variable anymore
because the FV _is_ the payload, unlike with the
old tianocoreboot implementation.
Change-Id: I349b5a95783e4146e3ab7f926871188cf2021935
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2284
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This removes the hack implemented in http://review.coreboot.org/#/c/2280
(and should make using 64bit Tiano easier, but that's not yet supported)
Change-Id: Ie30129c4102dfbd41584177f39057b31f5a937fd
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2281
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Usage Changes: To support platforms with different memory layout, "create" takes
two extra optional parameters:
"-b": base address (or offset) for bootblock. When omitted, put bootblock in
end of ROM (x86 style).
"-H": header offset. When omitted, put header right before bootblock,
and update a top-aligned virtual address reference in end of ROM.
Example: (can be found in ARM MAkefile):
cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \
-a 64 -b 0x0000 -H 0x2040 -o 0x5000
Verified to boot on ARM (Snow) and X86 (QEMU).
Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2214
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To support platforms without top-aligned address mapping like ARM, "locate"
command now outputs platform independent ROM offset by default. To retrieve x86
style top-aligned virtual address, add "-T".
To test:
cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T
# Example output: 0xffffdc10
Change-Id: I474703c4197b36524b75407a91faab1194edc64d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2213
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This unplugs Stefan's PIANO project.
Change Tianocore payload configuration to use corebootPkg.
As argument you have to give it the COREBOOT.FD generated by
the Tianocore build system.
It automatically determines base address and entry point.
Compression setting is honored (ie. no compression if you don't
want), but corebootPkg currently assumes that coreboot is doing
it. Loading a 6MB payload into CBFS without compression will fail
more often than not.
Change-Id: If9c64c9adb4a846a677c8af40f149ce697059ee6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If somebody makes use of CONFIG_LOCALVERSION show this
user provided config string for DMI bios_version.
As requested I have attached example output.
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
...
root@OT:~# cat /sys/class/dmi/id/bios_version
4.0-3360-g5be6673-dirty
CONFIG_LOCALVERSION="V1.01.02 Beta"
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
...
root@OT:~# cat /sys/class/dmi/id/bios_version
V1.01.02 Beta
Change-Id: I5640b72b56887ddf85113efa9ff23df9d4c7eb86
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/2279
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marcj303@gmail.com>
This removes some duplicate code from Snow's mainboard bootblock
by utilizing the bootblock build class.
Change-Id: I153247370a8c5127260082dcdca3ebdc5e104fb8
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2270
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For ARM platform, the bootblock may need more C source files to initialize
UART / SPI for loading romstage. To preventing making complex and implicit
dependency by using #include inside bootblock.c, we should add a new build class
"bootblock".
Also #ifdef __BOOT_BLOCK__ can be used to detect if the source is being compiled
for boot block.
For x86, the bootblock is limited to fewer assembly files so it's not using this
class. (Some files shared by x86 and arm in top level or lib are also changed
but nothing should be changed in x86 build process.)
Change-Id: Ia81bccc366d2082397d133d9245f7ecb33b8bc8b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Eliminate the warning message:
ld: warning: cannot find entry symbol _start; defaulting to 040000000
The "_start" from c_start.S is deprecated so we need to define entry
point again in link description file.
Change-Id: I174428faa2e7f08cd91fe96a53e6efea9dc3634e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2258
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This removes a few lines which are obsolete or unneeded.
We may want to do something with SMP eventually (can we use it for
decompression?) but for now we'll assume non-bootstrap cores are idle
until the OS does something with them.
Change-Id: Iff6b196e008e803bcfd00e5de07cf471bd2357ea
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2257
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This replaces the current stage-specific exit/entry functions with
generic versions. Now all stages compile with stage_entry(), which
is placed at .text.stage_entry.armv7, and stage_exit().
Snow's ramstage files are also updated to avoid build breakage.
Change-Id: I953a2c4b8121bd4b66c3362557997a9ca3aa53b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
People make mistakes. Hanging the box is not a good reason to kill the firmware,
esp. since this is probably happening in a printk.
The only issue with the recursive call to printk is that we may
deadlock if we have locked something. But we can at least try.
Hanging is certainly not what we want ...
Change-Id: Ib3bc87bc395ae89e115cf6d042f4167856422ca1
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2233
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is a Tiano Core loader payload based on libpayload. It
will load a Tiano Core DXE core from an UEFI firmware volume
stored in CBFS.
Currently Tiano Core dies because it does not find all the UEFI services it needs:
coreboot-4.0-3316-gc5c9ff8-dirty Mon Jan 28 15:37:12 PST 2013 starting...
[..]
Tiano Core Loader v1.0
Copyright (C) 2013 Google Inc. All rights reserved.
Memory Map (5 entries):
1. 0000000000000000 - 0000000000000fff [10]
2. 0000000000001000 - 000000000009ffff [01]
3. 00000000000c0000 - 0000000003ebffff [01]
4. 0000000003ec0000 - 0000000003ffffff [10]
5. 00000000ff800000 - 00000000ffffffff [02]
DXE code: 03e80000
DXE stack: 03e60000
HOB list: 03d5c000
Found UEFI firmware volume.
GUID: 8c8ce578-8a3d-4f1c-9935-896185c32dd3
length: 0x0000000000260000
Found DXE core at 0xffc14e0c
Section 0: .text size=000158a0 rva=00000240 in file=000158a0/00000240 flags=60000020
Section 1: .data size=00006820 rva=00015ae0 in file=00006820/00015ae0 flags=c0000040
Section 2: .reloc size=000010a0 rva=0001c300 in file=000010a0/0001c300 flags=42000040
Jumping to DXE core at 0x3e80000
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 3E96708
HOBLIST address in DXE = 0x3E56010
Memory Allocation 0x00000003 0x3E80000 - 0x3EBFFFF
FV Hob 0xFFC14D78 - 0xFFE74D77
InstallProtocolInterface: D8117CFE-94A6-11D4-9A3A-0090273FC14D 3E95EA0
InstallProtocolInterface: EE4E5898-3914-4259-9D6E-DC7BD79403CF 3E9630C
Security Arch Protocol not present!!
CPU Arch Protocol not present!!
Metronome Arch Protocol not present!!
Timer Arch Protocol not present!!
Bds Arch Protocol not present!!
Watchdog Timer Arch Protocol not present!!
Runtime Arch Protocol not present!!
Variable Arch Protocol not present!!
Variable Write Arch Protocol not present!!
Capsule Arch Protocol not present!!
Monotonic Counter Arch Protocol not present!!
Reset Arch Protocol not present!!
Real Time Clock Arch Protocol not present!!
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT /home/reinauer/svn/Tiano/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c(461): !EFI_ERROR (Status)
Change-Id: I14068e9a28ff67ab1bf03105d56dab2e8be7b230
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2154
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently "cbfstool locate" outputs a hex number without "0x" prefix.
This makes extra step (prefix 0x, and then generate another temp file) in build
process, and may be a problem when we want to allow changing its output format
(ex, using decimal). Adding the "0x" in cbfstool itself should be better.
Change-Id: I639bb8f192a756883c9c4b2d11af6bc166c7811d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2201
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The previous incarnation did not use all of mmu_setup, which meant
we did not carefully disable things before (possibly) changing them.
This code is tested and works, and it's a bit of a simplification.
Change-Id: I0560f9b8e25f31cd90e34304d6ec987fc5c87699
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2204
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
This begins to remove references to global data which u-boot used.
There are still many commented out references to gd-> and bd-> which
we'll fix once we're happy with the replacements.
Change-Id: Ie1b40a997e28a118f8f3ad96a2f9a2462d32fbe3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2210
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This just removes unused code. If for some reason we don't want to
initialize cache, then the CPU or mainboard specific init routines
don't need to call these.
Change-Id: Ieb7393b6cbc103e490753da4ed27114156466ded
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2209
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
No need to keep duplicate variants of counting ioapic interrupts.
Change-Id: I512860297309c46e05cc5379bf61479878817b1e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2185
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Apply the same fix for `setup_ioapic` as done in the following commit.
commit 23c046b6f1 Author: Nico Huber <nico.huber@secunet.com> Date: Mon Sep 24 10:48:43 2012 +0200
Fix reading of number of interrupts for IO-APICs
The number read from the io-apic register represents the index of the
highest interrupt redirection entry, i.e. the number of interrupts
minus one.
Change-Id: I54c992e4ff400de24bb9fef5d82251078f92c588
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1624
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I7b730d016a514c95c3b32aee6f31bd3d7b2c08cb
Signed-off-by: Aladyshev Konstantin <aladyshev@nicevt.ru>
Reviewed-on: http://review.coreboot.org/2043
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This replaces the call() function with a stub which is compiled
separately using -marm. See http://review.coreboot.org/#/c/2175/
for details.
Change-Id: I7f8c45b5e63ec97b0a82294488129d1c97ec0cbf
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2180
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch does a few things to get us into romstage:
- Add romstage as a stage (a later patch adds it as a binary, which
is probably wrong). The Makefile magic is complex enough that we
let it build the XIP file for now, but we no longer use it.
- Replace findstage with loadstage. Loadstage will find a stage,
load the code to memory, and zero the remaining part of memory.
Now we can link the romstage to go anywhere!
- Eliminate magic offsets from code/ldscripts and centralize Kconfig
variables in src/cpu/samsung/exynos5250/Kconfig.
- Tidy up code and serial output
Change-Id: Iae4d2f9e7f429cb1df15d49daf9a08b88d75d79d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2174
Tested-by: build bot (Jenkins)
This adds a wrapper around main() in romstage which is compiled using
-marm. This assumes that the bootblock branches to romstage in ARM
mode.
The long-term idea is to enforce ABI compatibility when handing off to
the next stage by using shims which are which are compiled in a pre-
determiend manner and leave the main portions of each stage up to
whatever the compiler wants. So it will eventually look like this:
1. bootblock_main (ARM/Thumb)
2. bootblock_exit (ARM)
3. romstage_entry (ARM)
4. romstage_main (ARM/Thumb)
(credit to Gabe Black for writing the patch, I'm just uploading it)
Change-Id: I4fdb8d2c6c2c0a7178bcb9154c378ddce0567309
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/2175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the bloated Snow bootblock which includes:
- SPI driver
- UART, including requisite I2C, Maxim PMIC, and clock config code.
- Adjustments for magic offsets (id section, stack pointer address)
This is just a temporary solution until we have romstage loading.
Once that happens, we'll rip out all but the code necessary for
copying SPI ROM content into SRAM.
Change-Id: I2a11e272eb9b6f626b5d9783eabb4a720a1d06be
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2170
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We've had obscure errors as the size of the bootblock changes.
This fix allows us to use a 32-bit constant. Please test on
real hardware before you ack.
Change-Id: Ic3d9f4763554bd6104ae9c4ce5bbacd17b40872c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2168
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Our earlier attempt was jumping straight from asm to the old u-boot
board_init_f in lowlevel_init_c.c. We are getting ready to transition
to using a real bootblock for ARM, so add romstage.c to the files
compiled and we'll make main() our entry point.
This also updates romstage.ld to place main() (*(.text.startup)) at
the beginning of romstage.
Change-Id: Ifc77a6bfba27d915c4cad62c6c8040665294628a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2163
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This replaces hard-coded bootblock offsets using the new scheme.
The assembler will place the initial branch instruction after BL1,
skip 2 aligned chunks, and place the remaining bootblock code after.
It will also leave an anchor string, currently 0xdeadbeef which
cbfstool will find. Once found, cbfstool will place the master CBFS
header at the next aligned offset.
Here is how it looks:
0x0000 |--------------|
| BL1 |
0x2000 |--------------|
| branch |
0x2000 + align |--------------|
| CBFS header |
0x2000 + align * 2 |--------------|
| bootblock |
|--------------|
TODO: The option for alignment passed into cbfstool has always been
64. Can we set it to 16 instead?
Change-Id: Icbe817cbd8a37f11990aaf060aab77d2dc113cb1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This lays out the groundwork for using a proper bootblock on ARM.
Currently we bypass the bootblock entirely and go straight to
romstage. However we want to utilize CBFS to maximize flexibility
of placing code without relying on a lot of magic numbers which
will break depending on the SoC in use.
Change-Id: I9cc2a8191d2db38b27b6363ba673e5a360de9684
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2118
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and delete traces in source files.
Change-Id: Ie0f70a479f1eadadc654a41fa3c426d1d4ac2f2b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2152
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since coreboot is compiled into 32bit code, and userspace
might be 32 or 64bit, putting a pointer into the coreboot
table is not viable. Instead, use a uint64_t, which is always
big enough for a pointer, even if we decide to move to a 64bit
coreboot at some point.
Change-Id: Ic974cdcbc9b95126dd1e07125f3e9dce104545f5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2135
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This replaces 0x02023400 with an SoC-specific Kconfig variable.
Change-Id: I21482d54a1e1fa6c4437c030ddae2b0bb3331551
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2130
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This doesn't seem to be strictly required (so far), but makes sense.
Change-Id: I18416c427ff886507ae09c7fc1a018baf94af24a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2131
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't pass arguments when we jump out of assembly code.
Change-Id: Iccf3a6f713e260b08f9ff47e8b542b9e96369166
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2122
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We moved to using __ASSEMBLER__ years ago since it is set by as.
Change-Id: I60103ba23ebe87be1d0bc63beed0ef5b05eed4f2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2111
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It's a bad Linux heritage.. We have no userland in firmware.
Change-Id: Ib19e5ba713078ca37514571213d19f418417b964
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2108
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It makes no sense to have directories with one file.
Change-Id: I65ba93dda5e6a4bcc5a7cc049c1378ebf5d6abcd
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2105
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This reverts commit ec8d35fe91
We are almost certain that this is not necessary.
Change-Id: I70e94f883be95655da00a0b127ed9ffd7c81c63b
Reviewed-on: http://review.coreboot.org/2104
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Our reference toolchain uses -mabi=aapcs whereas we started
forcing -mabi=aapcs-linux. Drop this to prevent ABI incompatibility.
Also drop -fno-common since that's set in the top level Makefile.inc
already.
Change-Id: I4afdcf5da9a5d86c2f9e5de5c7d523ccd2f5f1e0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2103
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We accidently checked in some files from libgcc as well as
a Makefile from u-boot and a duplicate implementation of div0.
Drop all those files to reduce the confusion.
Change-Id: I8ff6eabbced6f663813f8cc55f19c81839d03477
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2102
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There was a misuse of bool that would cause the dcache policy to not be
set up correctly, but instead present options "y" and "n" in the Kconfig
menu.
Also, TINY_BOOTBLOCK was removed a while ago, everything is
TINY_BOOTBLOCK now. Hence remove the option.
Change-Id: I5c28ac828955c69614c7bdaf106f79db51e68723
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2101
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This updates $CFLAGS used for armv7. Most of them were just added
to be consistent with what u-boot does. The important ones here
are -march=armv7-a and -mthumb (to allow 16-bit Thumb instructions).
I removed the hard float support because it got errors and
coreboot should never use floats anyway. We're still having trouble
with enums but I want to see how far it gets with this patch.
Also, put the flags in a form that makes diffs easier to read. It's
almost impossible otherwise.
Finally, move some flags to the architecture Makefile, and
rely on the fact that some are set for all architectures.
Depends-On: I6f730d017391f9ec4401cdfd34931c869df10a9e
Change-Id: Ia8a1ae22959933e06f7b996d1832cea40819f1ff
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2075
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This mirrors the naming convention of handlers in
northbridge and southbridge.
Change-Id: I45d97c569991c955f0ae54ce909d8c267e9a5173
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2058
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This replaces a somewhat useless calculation used earlier (which
always evaluated to 0) with an offset to specify the location
of the Coreboot bootblock.
Change-Id: Ib85aaccf138cebeb6bf8aedf82308861206dff48
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2094
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The old start.S file did a lot of work and had AP-specific #ifndef's.
The new init.S will eventually contain only bare minimum generic ARM
code for use by the bootblock. Processor-specific stuff and things
that take place later in the boot process should go elsewhere.
Change-Id: I7db0a77ee4bbad1ddecb193ea125d8941a50532b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2083
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is still a work-in-progress, but it seems to work better than
before and is less complicated...
Change-Id: I6f730d017391f9ec4401cdfd34931c869df10a9e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2041
Tested-by: build bot (Jenkins)
While "payload none" is undesirable for instant flashing,
assume that it was a conscious user choice.
(more immediate: jenkins isn't happy with escape sequences)
Change-Id: I9958b34a037b4d10bb7dba893335a63917623a70
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2055
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Initialize the pointer fadt to NULL to prevent a later comparison
(if (fadt == NULL)) when the pointer had the *possibility* of never
having been initialized.
Change-Id: Ib2a544c190b609ab8c23147dc69dca5f4ac7f38c
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2037
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
cbfstool was called with the wrong parameters
Change-Id: I405d0fd7c84b46da3c98a36fd19ef0034dc175cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2022
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
stddef.h should be fairly generic across all platforms we'd want to
support, so let's move it to generic code.
Change-Id: I580c9c9b54f62fadd9ea97115933e16ea0b13ada
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2007
Tested-by: build bot (Jenkins)
The first ARMv7 CPU we're going to support is the Exynos 5250
used in the Google Snow ChromeBook.
Change-Id: I4de8433bbc6202eb8fef2556a11186a3376d411b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2004
Tested-by: build bot (Jenkins)
Instead of adding regparm(0) to each assembler function called
by coreboot, add an asmlinkage macro (like the Linux kernel does)
that can be different per architecture (and that is empty on ARM
right now)
Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1973
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
to match src/include/device
Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1960
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change allows to override default bootblock_mainboard_init() with
mainboard-specific code.
If the default bootblock_mainboard_init() handler is replaced, with
one from file BOOTBLOCK_MAINBOARD_INIT, one needs to take care the
replacement calls all the necessary bootblock_x_init() functions.
Change-Id: Ie8c667cdba7cafe9ed2d4b19ab2bd21d941ad4ca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1845
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Makes it a bit easier to implement mainboard-specific behaviour
while executing the bootblock.
Change-Id: I04e87f89efb4fad1c0e20b62ea6a50329a286205
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1844
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is an initial re-factoring of CBFS code to enable multiple
architectures. To achieve a clean solution, an additional field
describing the architecture has to be added to the master header.
Hence we also increase the version number in the master header.
Change-Id: Icda681673221f8c27efbc46f16c2c5682b16a265
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1944
Tested-by: build bot (Jenkins)
This adds a dummy config for ARMV7 for developing various
follow-up patches which rely on ARCH_ARMV7.
Change-Id: Id913054d916f41607d10ebc02aaf74082e14b554
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1939
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This provides weak empty declaration for mainboard_ops.
The struct chip_operations is not defined for __PRE_RAM__ so
the declaration is also moved upwards in the output.
Change-Id: I101f0b8b9f0a55fb51a7c6475d53cc588c84026d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1931
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As we move to supporting other systems we need to get rid of assembly
where we can. The log2 function in src/lib is identical to the assembly
one (tested for all 32-bit signed integers :-) and takes about 10 ns
to run as opposed to 5ns for the non-portable assembly version. While speed
is good, I think we can spare the 15 ns or so we add to boot time
by using the C version only.
Change-Id: Icafa565eae282c85fa5fc01b3bd1f110cd9aaa91
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1928
Tested-by: build bot (Jenkins)
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
c_start.o has a special case in the build system, which we can
eliminate, somewhat simplifying the build.
To ensure that the entry point is at the beginning, introduce a
new section .textfirst that is placed appropriately. In principle
the ENTRY() definition in the linker script should be enough, but
better be safe.
Change-Id: I9737f7f5731e12ceb2119eb432b0e09832bc53fa
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1909
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ramstage.a has two issues:
1. duplicate source filenames don't survive the ar(1)
treatment properly (so files aren't considered)
2. ld doesn't resolve symbols if it isn't forced to, in
particular no overrides of weak symbols
Downside: The resulting binaries get slightly larger.
Link time optimizations should fix that, as would tighter
rules in the build system (to not compile unused code in
the first place).
Change-Id: Iaae771ec8f92b42069237acd3b79c14e5bf9c03d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1566
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
e.g.
-#if CONFIG_LOGICAL_CPUS == 1
+#if CONFIG_LOGICAL_CPUS
This will make it easier to switch over to use the config_enabled()
macro later on.
Change-Id: I0bcf223669318a7b1105534087c7675a74c1dd8a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1874
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This ensures that there's only one disable/enable cycle for
the entire rewrite instead for every single byte.
Change-Id: Ic06e6dcb08976d158ff784660838c0fbad875176
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1869
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
intel_irq_routing_table is a local structure that should not be used
globally, because it might not be there on all mainboards.
Instead, the API has to be corrected to allow passing a PIRQ table in
where needed.
Change-Id: Icf08928b67727a366639b648bf6aac8e1a87e765
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Both remaining options, DRIVERS_PS2_KEYBOARD and ID_SECTION_OFFSET
are not likely to go away any time soon, so let's not keep them
in Kconfig.deprecated_options but move them close to the code they
control.
Change-Id: I310b877c5b3d5a3444056641c4aee07a48c4c4be
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1839
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Add mainboard_smi.c from arch/x86/Makefile if it's there
- Add mainboard's chromeos.c from the chromeos Makefile
Change-Id: I3f80e2cb368f88d2a38036895a19f3576dd9553b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1835
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch is the beginning of a Kconfig cleanup series
- drop CONFIG_HAVE_BUS_CONFIG and add get_bus_conf.c if it
exists in the mainboard directory
- drop duplicate ACPI_SSDTX_NUM from mainboard Kconfig
if it only defines the defaul value of 0
- Add mptable.c, fadt.c, reset.c and ssdtX.asl when they
exist, not based on some Kconfig magic
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia14a7116dad6a724af7e531920fee9a51fd0b200
Reviewed-on: http://review.coreboot.org/1832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
YABEL's version of mainboard_interrupt_handlers() was hidden behind an
inline stub. This fixes it.
Change-Id: Ie53424a8ce074e93a720c0ef94cb39994cacd023
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM GNVS pointer is normally updated only when the
ACPI tables are created, which does not happen in the
resume path.
In order to restore this pointer it needs to be available
at resume time. The method used to locate it at creation
time cannot be used again as that magic signature is
overwritten with the address itself. So a new CBMEM ID
is added to store the 32bit address so it can be found
again easily.
A new function is defined to save this pointer in CBMEM
which needs to be called when the ACPI tables are created
in each mainboard when write_acpi_tables() is called.
The cpu_index variable had to be renamed due to a conflict
when cpu/cpu.h is added for the smm_setup_structures()
prototype.
Change-Id: Ic764ff54525e12b617c1dd8d6a3e5c4f547c3e6b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Let memory initialization code use the coreboot romstage console. This
simplifies the code and makes sure that all output is available in
/sys/firmware/log.
The pei_data structure is modified to allow passing the console output
function pointer. Romstage console_tx_byte() is used for this purpose.
Change-Id: I722cfcb9ff0cf527c12cb6cac09d77ef17b588e0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1823
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This addition is in support of future multicore support in
coreboot. It also will allow us to remove some asssembly code.
The CPU "index" -- i.e., its order in the sequence in which
cores are brought up, NOT its APIC id -- is passed into the
secondary start. We modify the function to specify regparm(0).
We also take this opportunity to do some cleanup:
indexes become unsigned ints, not unsigned longs, for example.
Build and boot on a multicore system, with pcserial enabled.
Capture the output. Observe that the messages
Initializing CPU #0
Initializing CPU #1
Initializing CPU #2
Initializing CPU #3
appear exactly as they do prior to this change.
Change-Id: I5854d8d957c414f75fdd63fb017d2249330f955d
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1820
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Right now coreboot's build process produces images that are
not booting on actual hardware because they are smaller than
the actual flash device and also don't have an IFD nor an ME
firmware in them. In order to produce bootable images, you
needed a wrapper script / extra step until now. With this
change, the resulting coreboot.rom is actually bootable.
Change-Id: I82714069fb004d4badc41698747a704bd9fed4da
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1771
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The currently encoded register constraints fails compilation
for SMM code or any code that compiles with -fPIC. The reason
is that the ebx register is used for GOT base register.
I don't believe the comment eluding to register constraints for AMD
processors still applies. Therefore remove mmio_conf.h, and use the
mmio methods in io.h.
Change-Id: I391e5c2088ebc760b3a6ed6c37b65bbecab40a5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/1801
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Adding more and more optional and non-optional parameters
bloated cbfstool and made the code hard to read with a lot
of parsing in the actual cbfs handling functions. This change
switches over to use getopt style options for everything but
command and cbfs file name.
- This allows us to simplify the coreboot Makefiles a bit
- Also, add guards to include files
- Fix some 80+ character lines
- Add more detailed error reporting
- Free memory we're allocating
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7
Reviewed-on: http://review.coreboot.org/1800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the modules use their own rolled pci_or_configX functions.
Therefore, make them first class so everyone can use them without
copying them.
Change-Id: I9a4d3364c832548dbfe18139c27cce2d60c3316d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/1797
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Double equal sign like "test a == b" works. It really does, except NetBSD.
But I haven't found any clue in the manual for the command test about "==".
Change-Id: I37254cfeb688fd1092f2e549d24f8eb270f02fd8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1817
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
coreboot uses about 2K of stack on the BSP, and about 1K of stack on the
APs. No reason to use an overdimensonal stack of 32k per core/thread.
Change-Id: I734c240b992d40e1e35db3df5437c36da0a755cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1780
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
At least when CONFIG_CHROMEOS is turned on, it's possible for
CONFIG_FRAMEBUFFER_KEEP_VESA_MODE to be set but for there not to be any valid
information to put into the framebuffer coreboot table. That means that what's
put in there is junk, probably all zeroes from the uninitialized global
variable the mode information is stored in (mode_info).
When a payload uses libpayload and turns on the coreboot framebuffer console,
that console will attempt to scroll at some point and decrease the cursor's y
coordinate until it is less than the number of rows claimed by the console.
The number of rows is computed by taking the vertical resolution of the
framebuffer and dividing it by the height of the font. Because the mode
information was all zeroes, the coreboot table info is all zeroes, and that
means that the number of rows the console claims is zero. You can't get the
unsigned y coordinate of the cursor to be less than zero, so libpayload gets
stuck in an infinite loop.
The solution this change implements is to add a new function,
vbe_mode_info_valid, which simply returns whether or not mode_info has anything
in it. If not, the framebuffer coreboot table is not created, and libpayload
doesn't get stuck.
Change-Id: I08f3ec628e4453f0cfe9e15c4d8dfd40327f91c9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/1758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
And move the pre-hardwaremain post code to 0x79
so it comes before hardwaremain at 0x80.
Emit these codes from ACPI OS resume vector as well
as the finalize step in bd82x6x southbridge.
Change-Id: I7f258998a2f6549016e99b67bc21f7c59d2bcf9e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On Sandybridge and Ivybridge systems the firmware image has to
store a lot more than just coreboot, including:
- a firmware descriptor
- Intel Management Engine firmware
- MRC cache information
This option allows to limit the size of the CBFS portion in
the firmware image.
Change-Id: Ib87fd16fff2a6811cf898d611c966b90c939c50f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1770
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will use 3 bytes of CMOS to keep track of the POST
code for the current boot while also leaving a record of
the previous boot.
The active bank is switched early in the bootblock.
Test:
1) clear cmos
2) reboot
3) use "mosys nvram dump" to verify that the first byte
contains 0x80 and the second byte contains 0xF8
4) powerd_suspend and then resume
5) use "mosys nvram dump" to verify that the first byte
contains 0x81 and the second byte contains 0xFD
Change-Id: I1ee6bb2dac053018f3042ab5a0b26c435dbfd151
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a slight improvement over the rep movsb loop
Change-Id: Id71d9bfe5330b154a5c62fac85ce3955ae89b057
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Our linker script for romstage checks for global variables and
makes the build fail if there are any (on non-AMD systems).
This is great, but having the build fail without any indication
which variables are global is not very useful.
Moving the check to the Makefile allows us to let the linking stage
succeed and reveil which variable names end up in the data and bss
sections of the binary.
To test, add "int foo;" as the first line in src/mainboard/samsung/lumpy/romstage.c
and build coreboot for Lumpy. See the build break the following
way:
LINK cbfs/fallback/romstage_null.debug
Forbidden global variables in romstage:
00006a84 B foo
Change-Id: I3c8780888f46a6577ffd36bcea317997b4f84f6f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1692
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Adds lowlevel handling of DMAR tables for use by mainboards'
ACPI code. Not much automagic (yet).
Change-Id: Ia86e950dfcc5b9994202ec0e2f6d9a2912c74ad8
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We only want to add data once per device. Using the one in
chip_operations is not very usable anyway, as different
devices under the same chip directory would need to output
entirely different sets of data.
Change-Id: I96690c4c699667343ebef44a7f3de1f974cf6d6d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1492
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
The number read from the io-apic register represents the index of the
highest interrupt redirection entry, i.e. the number of interrupts
minus one.
Change-Id: I54c992e4ff400de24bb9fef5d82251078f92c588
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1624
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
HPET's min ticks (minimum time between events to avoid
losing interrupts) is chipset specific, so move it to
Kconfig.
Via also has a special base address, so move it as well.
Apart from these (and the base address was already #defined),
the table is very uniform.
Change-Id: I848a2e2b0b16021c7ee5ba99097fa6a5886c3286
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1562
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
This is in preparation for sharing interrupt handlers
between YABEL and x86emu.
Change-Id: Iff92c1d899b8ada20972731944341805a49b6326
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
pirq_routing_irqs assumed that only four links are available for PIRQ
routing, INTA to INTD. Some chipsets provide more, up to INTH.
When pirq_routing_irqs found a link number greater than 4 in the pirq table,
it would not assign that IRQ. This is a shame, as it limits the flexibility
of routing IRQs.
Make the maximum number of links a Kconfig variable, and modify the code to
respect it. This works beatifully on the VX900, which provides 8 routable
interrupts.
While we're at it, also refactor pirq_routing_irqs, and add some much
needed comments.
Rename pirq_routing_irqs to pirq_route_irqs to demistify the role of this
function.
The copyrights added were determined from git log filename.
Change-Id: I4b565315404c65b871406f616474e2cc9e6e013e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1482
Tested-by: build bot (Jenkins)
This patch aims to improve the microcode in CBFS handling that was
brought by the last patches from Stefan and the Chromium team.
Choices in Kconfig
- 1) Generate microcode from tree (default)
- 2) Include external microcode file
- 3) Do not put microcode in CBFS
The idea is to give the user full control over including non-free
blobs in the final ROM image.
MICROCODE_INCLUDE_PATH Kconfig variable is eliminated. Microcode
is handled by a special class, cpu_microcode, as such:
cpu_microcode-y += microcode_file.c
MICROCODE_IN_CBFS should, in the future, be eliminated. Right now it is
needed by intel microcode updating. Once all intel cpus are converted to
cbfs updating, this variable can go away.
These files are then compiled and assembled into a binary CBFS file.
The advantage of doing it this way versus the current method is that
1) The rule is CPU-agnostic
2) Gives user more control over if and how to include microcode blobs
3) The rules for building the microcode binary are kept in
src/cpu/Makefile.inc, and thus would not clobber the other makefiles,
which are already overloaded and very difficult to navigate.
Change-Id: I38d0c9851691aa112e93031860e94895857ebb76
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1245
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Don't derive the IRQ pin from the function number. Especially onboard
chipset devices don't follow that rule. Instead check and add all
fixed IRQ entries.
Change-Id: I46c88bad39104c1d9b4154f180f8b3c42df28262
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1461
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The current code does some argument manipulation to detect when a stage is being
added to cbfs. This same manipulation needs to be done when adding a payload.
Change-Id: Ief4c4a81446c9437923cbbb1ce3fa90729317587
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1451
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When we encounter an x86 exception, we print the problem address, dump the
registers and die. This may not be sufficient information for debug. Also
dump the memory around the problem instruction. This has proven useful in
identifying memory issues, and DRAM burst reordering problems.
Change-Id: I6411344e89f946e16d11217d7dbd73812c45d54c
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1454
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Adding ranges directly into coreboot memory table raised issues
as those methods bypassed the MTRR setup. Such regions are now
added as resources, so declare the functions again as static.
Change-Id: If78613da40eabc5c99c49dbe2d6047cb22a71b69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1415
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 042c1461fb.
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing NVS variable for PPCM will be used to
select a dynamic max P-state.
By itself this does not change existing behavior because
the NVS PPCM variable is initialized to zero.
PPCM can be tested by building and booting a modified BIOS
that sets gnvs->ppcm to a value greater than 1 and checking
from the OS that the P-state is limited to that value.
Change-Id: Ia7b3bbc6b84c1aa42349bb236abee5cc92486561
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EHCI debug allows to send message with 8 bytes length, but
we're only sending one byte in each transaction. Buffer up
to 8 bytes to speed up debug output.
Change-Id: I9dbb406833c4966c3afbd610e1b13a8fa3d62f39
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1357
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
This patch extends the current smbios api to allow changing mainboard
serial and version during coreboot runtime. This is helpful if you
have an EEPROM etc. to access these informations and want to add
some quirks for broken hardware revision for the linux kernel.
This could be done via DMI_MATCH marco.
Change-Id: I1924a56073084e965a23e47873d9f8542070423c
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1232
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
coreboot used to pass some information to u-boot in the coreboot table
and other information in a modified flat device tree. Since the FDT code
was never upstreamed and removed from our tree, u-boot was changed to
get the information it needs from the coreboot table alone. However,
in the process of this change only the vboot shared data structure was
passed on by coreboot, so when u-boot tried to update the ChromeOS
specific ACPI entries, it would accidently overwrite the vboot data.
This patch passes on the ChromeOS specific ACPI data structure instead
of the vboot shared data. Another change to u-boot will teach it how
to get to the vboot shared data from there.
Change-Id: Ifbb64eafc0d9967887b4cdeebf97d0c4ce019290
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1282
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This standared SMBIOS 0able describes the location and format
of the event log to the OS and applications. In this case the
pointer is a 32bit physical address pointer to the log in
memory mapped flash.
Look for SMBIOS type15 entry with 'dmidecode -t 15'
Handle 0x0004, DMI type 15, 23 bytes
System Event Log
Area Length: 4095 bytes
Header Start Offset: 0x0000
Header Length: 8 bytes
Data Start Offset: 0x0008
Access Method: Memory-mapped physical 32-bit address
Access Address: 0xFFB6F000
Status: Valid, Not Full
Change Token: 0x00000000
Header Format: OEM-specific
Supported Log Type Descriptors: 0
Change-Id: I1e7729e604000f197e26e69991a2867e869197a6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1314
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When microcode storage in CBFS is enabled, the make system is supposed
to generate the microcode blob and place it into the generated ROM
image as a CBFS component.
The microcode source representation does not change: it is still an
array of 32 bit constants. This new addition compiles the array into a
separate object file and then strips all sections but data.
The raw data section is then included into CBFS as a file named
'microcode_blob.bin' of type 0x53, which is assigned to microcode
storage.
Change-Id: I84ae040be52f520b106e3471c7e391e64d7847d9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1295
Tested-by: build bot (Jenkins)
This include file needs to be prevented from being included multiple
times.
Change-Id: I42e0cbe38d332b919f22e331eaf7a0251929e1dc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1293
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Code can easily make the mistake of using uninitialized
values or, in assembly, mistakenly dereferencing stack pointers
when an address is desired.
Set the stack to a non-zero value which is also (by testing)
a pointer which will crash coreboot if used. This poisoning
has uncovered at least one bug.
Change-Id: I4affb9a14b96611e8bf83cb82636e47913025a5d
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1221
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
This patch adds support for autogenerating the MPTABLE from
devicetree.cb. This is done by a write_smp_table() declared
weak in mpspec.c. If the mainboard doesn't provide it's own
function, this generic implementation is called.
Syntax in devicetree.cb:
ioapic_irq <APICID> <INTA|INTB|INTC|INTD> <INTPIN>
The ioapic_irq directive can be used in pci and pci_domain
devices. If there's no directive, the autogen code traverses
the tree back to the pci_domain and stops at the first device
which such a directive, and use that information to generate the
entry according to PCI IRQ routing rules.
Change-Id: I4df5b198e8430f939d477c14c798414e398a2027
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1138
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If a CPU was pre-allocated, cpu_path is not copied and thus
index would not be updated. This breaks cpu_index() and AMD
model_fxx is possibly broken without this patch.
Change-Id: I77483181cf0bca31423c655942c022bffab3c7ea
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1199
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
PCI Type 2 config was a strange and never-used config mechanism.
It is unlikely that in the 13 years of coreboot's existence that
type 2 was ever used; it just made life complicated for everyone.
It lived long enough in coreboot to be replaced by mmioconf.
Prior to making the device tree visible in romstage we want to
get rid of type2.
Delete two files we don't need any more (yay!).
Replace two functions with one: pci_config_default, which returns
a pointer to the default config method. At some future time this
may change to mmio but for now it is old type1 style.
Change-Id: Icc4ccf379a89bfca8be43f305b68ab45d88bf0ab
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1159
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
With this change it is possible to define serial number
and version of the mainboard. These informations are used
in SMBIOS tables.
Change-Id: I1634882270f6cb94e00aceb7832e7fd14adc186b
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-on: http://review.coreboot.org/1163
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The error message from romstage is annoying and misleading:
"Do not use global variables in romstage"
Because it can occur even when global variables are not used
in some circumstances, but also because it gives you only a rough
idea where to look. This change sucks but sucks less. We still don't
know which file the problem is in but at least we know if it is data
or bss.
Replace the error message with something that provides more information
and less guessing on the part of the script:
".bss is non-zero size in romstage which is not allowed -- global variable?"
or
".data is non-zero size in romstage which is not allowed -- global variable?"
To test: build coreboot as normal. It builds.
Add
char d[32];
to romstage.c and get the first error message; add
int x = 32;
to romstage.c and get the second.
Change-Id: I300ec05bdb4b30d7ef3f5112e6cc09b1fafe8263
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1160
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The wrapper for Trinity. Support S3. Parme is a example board.
Change-Id: Ib4f653b7562694177683e1e1ffdb27ea176aeaab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The current code for initializing AP cpus has several shortcomings:
- it assumes APIC IDs are sequential
- it uses only the BSP for determining the AP count, which is bad if
there's more than one physical CPU, and CPUs are of different type
Note that the new code call cpu->ops->init() in parallel, and therefore
some CPU code needs to be changed to address that. One example are old
Intel HT enabled CPUs which can't do microcode update in parallel.
Change-Id: Ic48a1ebab6a7c52aa76765f497268af09fa38c25
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Here's a quick demonstration on how to use it(tested on M4A785T-M).
(gdb) file ./build/cbfs/fallback/coreboot_ram.debug
Reading symbols from [...]/build/cbfs/fallback/coreboot_ram.debug...done.
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
_text () at src/arch/x86/lib/c_start.S:85
85 call hardwaremain
Change-Id: Ia49cbecc41deb061433bc39f5b81715da49edc98
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1134
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The constant value 0x100000000 is used in linker scripts to calculate
offsets from the end of 32-bit-addressed memory. There is nothing
wrong with it, but 32-bit versions of ld do the calculation wrong.
Change-Id: I4e27c6fd0c864b4d98f686588bf78c7aa48bcba8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1129
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Without that fix we have:
LINK cbfs/fallback/romstage_null.debug
build/generated/crt0.romstage.o: In function `ramtest':
romstage.c:(.rom.text+0x53f): undefined reference to `.Lhlt'
collect2: ld returned 1 exit status
make: *** [build/cbfs/"fallback"/romstage_null.debug] Error 1
On the M4A785T-M which doesn't have CONFIG_ROMCC.
Change-Id: I49eded1d18e996afe9441b85dae04ae30c760dd6
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Reviewed-on: http://review.coreboot.org/1101
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
- Add #define to allow the FADT PM Profile to be overridden.
- Change the location of the PMA_CNT_BLOCK_ADDRESS to match
current documentation.
- cst_cnt should be 0 if smi_cmd == 0
- add a couple of default access sizes.
- Add a couple of #define values for unsupported C2 & C3 entries.
- Add PM Profile override value into amd/persimmon platform.
This does not use the #defines in acpi.h so that the files that
include this don't all need to start including acpi.h.
Change-Id: Ib11ef8f9346d42fcf653fae6e2752d62a40a3094
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1055
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
It is just me or does anybody have the same build error without
this patch?
------
src/arch/x86/boot/acpigen.c: In function 'acpigen_write_empty_PTC':
src/arch/x86/boot/acpigen.c:347:3: error: unknown field 'resv'
specified in initializer
src/arch/x86/boot/acpigen.c:347:3: warning: missing braces around
initializer
src/arch/x86/boot/acpigen.c:347:3⚠️ (near initialization
for 'addr.<anonymous>')
-------
Anyway, I believe at least this will cause warnings.
"resv" is a member of a union, not of acpi_addr_t. So it should be
wrapped by a brace in the initializer.
Change-Id: I72624386816c987d5bb2d3a3a64c7c58eb9af389
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1056
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
clang does its own linking, incompatible to our
binutils-centric linker magic.
Change-Id: I243597adcb6bc3f7343c3431d7473610c327353d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/785
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When compiling coreboot with the latest ChromeOS toolchain, GCC
complains that some printk calls use %zu in connection with size_t
types since it resolves the typedefs to long unsigned int.
The problem is solved by using the GCC built-in __SIZE_TYPE__ if it
exists and define __SIZE_TYPE__ to long unsigned int otherwise.
Change-Id: I449c3d385b5633a05e57204704e981de6e017b86
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1040
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The bootblock.ld linkerscript is used by romstage. Name it
accordingly to avoid confusion.
Change-Id: I7ca9147bb821fe6f83224d170f5fe25654ef250f
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1031
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Cygwin is case insensitive, so bootblock.s and bootblock.S in the
same directory cause a build failure. This changes bootblock.S
to bootblock_inc.S, as it is generated from bootblock_inc.
crt0.S and crt0.S also had this problem. This changes crt0.S to
crt0.romstage.S.
Change-Id: I29d230a93b0743e34f11228f9034880ceaf7ab7b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1032
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Use the coreboot IASL for building SeaBIOS.
Change-Id: Ia6c802b090d53b7fbbc8ddb6edad3de6b822ff41
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1033
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Change source file modes from 755 to 644
The following files have been grepped for changes:
*.c
*.h
*Kconfig*
*Makefile*
Change-Id: I275f42ac7c4df894380d0492bca65c16a057376c
Signed-off-by: Alec Ari <neotheuser@ymail.com>
Reviewed-on: http://review.coreboot.org/1023
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Change-Id: I1ec7a7e54513671331ac12f08d5f59161b72b0fd
Example:
PSS: 1900MHz power 35000 control 0x1300 status 0x1300
PSS: 1600MHz power 28468 control 0x1000 status 0x1000
PSS: 1400MHz power 24291 control 0xe00 status 0xe00
PSS: 1200MHz power 20340 control 0xc00 status 0xc00
PSS: 1000MHz power 16569 control 0xa00 status 0xa00
PSS: 800MHz power 12937 control 0x800 status 0x800
PSS: 1900MHz power 35000 control 0x1300 status 0x1300
PSS: 1600MHz power 28468 control 0x1000 status 0x1000
PSS: 1400MHz power 24291 control 0xe00 status 0xe00
PSS: 1200MHz power 20340 control 0xc00 status 0xc00
PSS: 1000MHz power 16569 control 0xa00 status 0xa00
PSS: 800MHz power 12937 control 0x800 status 0x800
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/994
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The CBMEM_ID_RESUME_SCRATCH area is only used by Agesa code, on one
particular board (AMD Persimmon). Make the creation of that section
depending on Agesa so it does consume space on non-Agesa systems.
Change-Id: I2a1a4f76991ef936ea68cf75928b20b7ed132b84
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/992
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of the special case in the generic Makefile.inc,
use cbfs-files in the CPU directories.
Change-Id: I71d9c8dff906c9a516ac0dd09a315f8956075592
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/962
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
stages have special cbfstool syntax, which we need to support.
Change-Id: I119255246af818f010acfc7ec2091a6184e74eb3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/961
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This code fixes the sandybridge C state generation code to work with
the current version of the ACPI code generator.
Change-Id: I56ae1185dc0694c06976236523fdcbe5c1795b01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/950
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's used by Sandybridge specific C state generation code.
Change-Id: Ia6f1e14e748841a9646fd93d0a18f9e8f2a55e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/949
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... in order to unify the Sandybridge and Lenovo implementations
currently used in the tree.
- use acpi_addr_t in acpigen_write_register()
- use acpi_cstate_t for cstate tables (and fix up
the x60 and t60)
- drop cst_entry from acpigen.h
Change-Id: Icb87418d44d355f607c4a67300107b40f40b3b3f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/943
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
since it is used in CPU specific ACPI generation code
Change-Id: I2559658f43c89dc5b4dc8230dea8847d2802990c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/947
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
If compiling coreboot with ChromeOS support, two
more include files are required.
Change-Id: I7e042e250e4a89e7dd4bab58443824d503c3f709
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/931
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Added a union to identify the byte that was reserved in the
Generic Address Structure from ACPI 2.0 to ACPI 2.0b as the
Access Size byte for ACPI 2.0c to ACPI 5.0
- Added various #defines for use in the FADT
- Added a couple of comments for the #endifs
Change-Id: I294ddfd89fcb0ad88bb6e52d911f807d84671e82
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/930
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Move final build results under $(objcbfs).
Move intermediate files under $(objgenerated).
Remove use of sed -i.
Change-Id: Ie035a1544848b26514a197c340f470201065b8d5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/859
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
$(obj)/coreboot_ap -> $(objcbfs)/coreboot_ap.elf
It is really a ramstage for AP CPU and not a romstage, it is not
enabled for any mainboard by default, and it doesn't compile
even if enabled.
Change-Id: Ifb9c5cb6df65309660b000876cf6a9a3da9b6839
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/840
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit d4d5e4d3e1 contains #ifdef instead
of #if, making the FSB/serial bus selection for APIC always select serial
bus. The bug is harmless on most chipsets because the bit is often RO,
but it breaks at least on VIA K8T890.
Change-Id: I89c4855922199eca7f921c3e4eb500656544c8e5
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/921
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Final build results (.elf, .debug, .map) are to be placed under
directory $(objcbfs), the default is:
$(obj)/cbfs/$(CONFIG_CBFS_PREFIX)/
Intermediate build results (.o, .s, .S, .inc, .ld) that do not have
a clear one-to-one relation to a file under src/ are to be placed
under directory $(objgenerated), the default is:
$(obj)/generated
Also defines implicit rules for final build results:
.debug -> .elf and .map
.elf -> .bin
Change-Id: I448c6b7c9a952e54170df42091d7db438025a795
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/858
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
As cmos.layout parsing capabilities are already there in nvramtool,
use those than using build_opt_tbl.c. Add binary and header file
generation in nvramtool. Make appropriate changes to Makefile.inc.
Change-Id: Iaf3f5d4f51451aeb33c92800a0c895045f2388cf
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/898
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
1. Move the Stack to high memory.
2. Restore the MTRR before Coreboot jump to the wakeup vector.
Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
HEST feature starts from ACPI 4.0.
HEST is one of four kinds of tables of ACPI Platform Error
Interfaces (APEI). In Windows world, APEI is called Windows Hardware
Error Architecture (WHEA).
APEI consists of four separate tables:
1. Error Record Serialization Table (ERST)
2. BOOT Error Record Table (BERT)
3. Hardware Error Source Table (HEST)
4. Error Injection Table (EINJ)
All these 4 tables have the same header as FADT, MADT, etc. They are
pointed by RSDP.
For the HEST, it contains the error source. The types of them are
defined as
type description
1. Machine Check Exception (MCE)
2. Corrected Machine Check (CMC)
3. NMI Error
6. PCI Express Root Port AER
7. PCI Express Device AER
8. PCI Express Bridge AER
9. Generic Hardware Error Source
Error source types 3, 4, and 5 are reserved for legacy reasons and
must not be used.
Currently AMD board only provide part of "Machine Check
Exception (MCE)" & Corrected Machine Check (CMC)". we need to provide
the header of each error source. Other types of Error Sources is in
TODO list.
Only persimmon is tested. Linux can add HEST feature. The dmesg says,
ACPI: HEST 0000000066fe5010 00198 (v03 CORE COREBOOT 00000000 CORE 00000000)
......
HEST: Table parsing has been initialized.
No more message is got.
Windows can boot with this patch. Havent found a way to test it.
Change-Id: I447e7f57b8e8f0433a145a43d0710910afabf00f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/888
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Some places still hardcoded the address instead of using IO_APIC_ADDR.
Change-Id: I3941c1ff62972ce56a5bc466eab7134f901773d3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix regression after commit:
7dfe32c540
Only align 16-bit entry on platforms that really require it,
indicated by selecting SIPI_VECTOR_IN_ROM in CPU Kconfig.
Disable assertion test of AP_SIPI_VECTOR for platforms not
depending on this feature.
Build of romstage should be fixed to get the vector address from
bootblock build automatically.
Change-Id: Ide470833c0254df1a9ff708369ab1c095ccfb98d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/875
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function can be used outside of the normal CPU setup
Change-Id: I810c63b8aff868a6f69d5b992bea1cfae5a5996b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/868
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In ChromeOS we potentially have different payloads with
different versions. Since the user land tools get information
on which one of them is loaded, leave the string in smbios
empty so we can fill it out in the payload.
Also fill out system version number and serial number with
some constant values.
Change-Id: Id1fed5a54b511c730975fa83347452f1274b8504
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/867
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
ChromeOS uses two extensions to the coreboot table:
- ChromeOS specific GPIO description for onboard switches
- position of verified boot area in nvram
Change-Id: I8c389feec54c00faf2770aafbfd2223ac9da1362
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/866
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... and always include IP checksumming in romstage.
It's generally useful and our upcoming port needs it.
Change-Id: I248402d96a23e58354744e053b9d5cca6b74ad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/827
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some mainboards (most likely laptops) will need mainboard specific functions
called upon a resume from suspend.
Change-Id: If1518a4b016bba776643adaef0ae64ff49f57e51
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/852
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We changed our verified boot initialization to run from romstage,
as that allows faster boot times and does not add as much ChromeOS
specific code to generic files.
Change-Id: Id4164c26d524ea0ffce34467cf91379a19a4b2f6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The socket mPGA604 is for P4 Xeon which to my knowledge is always
HT-enabled. I assume the existing usage of car/cache_as_ram.inc
on socket_mPGA604, namely the Tyan S2735, as broken.
Existing car/cache_as_ram.inc has invalid SIPI vector and it does
not initialise AP CPU's to activate L2 cache.
Other mPGA604 boards are not affected, as they have not been
converted to CAR.
Change-Id: I7320589695c7f6a695b313a8d0b01b6b1cafbb04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/607
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The x86 memcpy() implementation did not mention its implicit output
registers ESI, EDI and ECX which might make this code miscompile when
the compiler uses the value of EDI for the return value *after* the 'rep
movsb' has completed. That would break the API of memcpy as this would
return 'dst+len' instead of 'dst'.
Fix this possible bug by removing the wrong comment and listing all
output registers as such (using dummy stack variables that get optimized
away).
Also the leading 'cld' is superflous as the ABI mandates the direction
flag to be cleared all the time when we're in C (see
<http://gcc.gnu.org/gcc-4.3/changes.html>) and we have no ASM call sites
that might require it to be cleared explicitly (SMM might come to mind,
but it clears the DF itself before passing control to the C part of the
SMI handler).
Last but not least fix the prototype to match the one from <string.h>.
Change-Id: I106422d41180c4ed876078cabb26b45e49f3fa93
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/836
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
For a hyper-threading processor, enabling cache requires that both the
BSP and AP CPU clear CR0.CD (Cache Disable) bit. For a Cache-As-Ram
implementation, partial multi-processor initialisation precedes
raminit and AP CPUs' 16bit entry must be run from ROM.
The AP CPU can only start execute real-mode code at a 4kB aligned
address below 1MB. The protected mode entry code for AP is identical
with the BSP code, which is already located at the top of bootblock.
This patch takes the simplest approach and aligns the bootblock
16 bit entry at highest possible 4kB boundary below 1MB.
The symbol ap_sipi_vector is tested to match CONFIG_AP_SIPI_VECTOR
used by the CAR code in romstage. Adress is not expected to ever
change, but if it does, link will fail.
Change-Id: I82e4edbf208c9ba863f51a64e50cd92871c528ef
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/454
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
After change it is more clear how romstage is linked twice and with
what scripts. Also with the change, it is easier to add some
object of static size that need to be re-compiled for the 2nd link.
One such object could be md5sum of executable.
Change-Id: Ib34d1876071a51345c5c7319a0ed937868817fd1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/803
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There were cases where output file was generated and modified within
a recipe. If make was interrupted, it could exit with an output file
that appears as up-to-date, but was generated with incomplete recipe.
The output file should be created only when successful, in an atomic
operation. There could be other places in the make system which
require a similar fix, this needs to be investigated further.
Change-Id: I25c8ee23577a460eace196fd28c23cc67aa72a9a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/830
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's not significantly faster, but easier to read and smaller.
Change-Id: Ibab0b478873912d67bf1f07743f628586353368a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/755
Reviewed-by: Mathias Krause <minipli@googlemail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I forgot to implement this the first time around.
It does not seem to cause noticeable problems but
in heavy suspend/resume testing I saw a suspicious
crash in the kernel when trying to bring one of the
CPUs back online.
Change-Id: I950ac260f251e2683693d9bd20a0dd5e041aa26e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/770
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
David Hendricks