'nough said. It was broken since 2006.
Change-Id: I312ac07eee65d6bb8567851dd38064c7f51b3bd2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2062
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This just imports a header. We may wish to modify the i2c interface
and/or unify it with the smbus interface we currently have.
Change-Id: I314f3aef62be936456c6c3e164a3db2c473b8792
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
GNU CC coverage needs free() and it's highly desirable to leave
the code as genuine as possible.
Change-Id: I4c821b9d211ef7a8e7168dc5e3116730693999c6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2051
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The SB800 and Hudson now support adding the IMC ROM which runs from the same
chip as coreboot. When the IMC is running, write or erase commands sent to
the spi bus will fail, and the IMC will die. To fix this, we send a request
to the IMC to stop fetching from the SPI rom while we write to it. This
process (in one form or another) is required for writes to the SPI bus while
the IMC is running.
Because the IMC can take up to 500ms to respond every time we claim the
bus, this patch tries to keep the number of times we need to do that to a
minimum. We only need to claim the bus on writes, and using a counter for
the semaphore allows us to call in once to claim the bus at the beginning
of a number of transactions and it will stay claimed until we release it
at the end of the transactions.
Claim() - takes up to 500ms hit
claim() - no delay
erase()
release()
claim() - no delay
write()
release()
Release()
Change-Id: I4e003c5122a2ed47abce57ab8b92dee6aa4713ed
Signed-off-by: Martin Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1976
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
and disable IO mapped UARTs on ARMV7 per default
Change-Id: I712c4677cbc8519323970556718f9bb6327d83c8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2021
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
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)
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>
Set_boot_successful depends on CMOS parts that non-PC80
platforms do not have. For now, make the current path
depend on CONFIG_PC80_SYSTEM, and make the alternative
empty.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I68cf63367c8054d09a7a22303e7c04fb35ad0153
Reviewed-on: http://review.coreboot.org/1954
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.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)
Add an init() function to the chip_operations which will be called
before bus enumeration. This allows to disable unused devices before
they get enumerated.
Change-Id: I63dd9cbfc7b5995ccafb7bf7a81dc71fc67906a0
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1623
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
In principle this isn't necessary. However there's a byte (or several)
outside the first 14 bytes that are part of the RTC, and require
locking (century/altCentury).
Since their location is mostly unknown, guard writes properly.
Change-Id: I847cd4efa92722e8504d29feaf7dbfa5c5244b4e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1868
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Using global variables with the TSEG is a bad idea because
they are not relocated properly right now. Instead make
the variables static and add accessor functions for the
rest of SMM to use.
At the same time drop the tcg/smi1 pointers as they are
not setup or ever used. (the debug output is added back
in a subsequent commit)
Change-Id: If0b2d47df4e482ead71bf713c1ef748da840073b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1764
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>
Several small improvements of the stack checking code:
- move the CPU0 stack check right before jumping to the payload
and out of hardwaremain (that file is too crowded anyways)
- fix prototype in lib.h
- print size of used stack
- use checkstack function both on CPU0 and CPU1-x
- print amount of stack used per core
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Test: Boot coreboot on Link, see the following output:
...
CPU1: stack: 00156000 - 00157000, lowest used address 00156c68,
stack used: 920 bytes
CPU2: stack: 00155000 - 00156000, lowest used address 00155c68,
stack used: 920 bytes
CPU3: stack: 00154000 - 00155000, lowest used address 00154c68,
stack used: 920 bytes
...
Jumping to boot code at 1110008
CPU0: stack: 00157000 - 00158000, lowest used address 00157af8,
stack used: 1288 bytes
Change-Id: I7b83eeee0186559a0a62daa12e3f7782990fd2df
Reviewed-on: http://review.coreboot.org/1787
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In hardwaremain() we can't add timestamps before we actually
reinitialized the cbmem area. Hence we kept the timestamps in
an array and added them later. This is ugly and intrusive and
helped hiding a bug that prevented any timestamps to be logged
in hardwaremain() when coming out of an S3 resume.
The problem is solved by moving the logic to keep a few timestamps
around into the timestamp code. This also gets rid of a lot of ugly
ifdefs in hardwaremain.c
Change-Id: I945fc4c77e990f620c18cbd054ccd87e746706ef
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1785
Tested-by: build bot (Jenkins)
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)
If the event log is stored in flash that is not memory
mapped then it must use the SPI controller to read from
the flash device instead of relying on memory accesses.
In addition a new CBMEM ID is added to keep an resident
copy of the ELOG around if needed. The use of CBMEM for
this is guarded by a new CONFIG_ELOG_CBMEM config option.
This CBMEM buffer is created and filled late in the process
when the SMBIOS table is being created because CBMEM is
not functional when ELOG is first initialized.
The downside to using CBMEM is that events added via the
SMI handler at runtime are not reflected in the CBMEM copy
because I don't want to let the SMM handler write to memory
outside the TSEG region.
In reality the only time we add runtime events is at kernel
shutdown so the impact is limited.
Test:
1) Test with CONFIG_ELOG_CBMEM enabled to ensure the event
log is operational and SMBIOS points to address in CBMEM.
The test should involve at least on reboot to ensure that the
kernel is able to write events as well.
> mosys -l smbios info log | grep ^address
address | 0xacedd000
> mosys eventlog list
0 | 2012-10-10 14:02:46 | Log area cleared | 4096
1 | 2012-10-10 14:02:46 | System boot | 478
2 | 2012-10-10 14:02:46 | System Reset
3 | 2012-10-10 14:03:33 | Kernel Event | Clean Shutdown
4 | 2012-10-10 14:03:34 | System boot | 479
5 | 2012-10-10 14:03:34 | System Reset
2) Test with CONFIG_ELOG_CBMEM disabled to ensure the event
log is operational and SMBIOS points to memory mapped flash.
The test should involve at least on reboot to ensure that the
kernel is able to write events as well.
> mosys -l smbios info log | grep ^address
address | 0xffbf0000
> mosys eventlog list
0 | 2012-10-10 14:33:17 | Log area cleared | 4096
1 | 2012-10-10 14:33:18 | System boot | 480
2 | 2012-10-10 14:33:18 | System Reset
3 | 2012-10-10 14:33:35 | Kernel Event | Clean Shutdown
4 | 2012-10-10 14:33:36 | System boot | 481
5 | 2012-10-10 14:33:36 | System Reset
Change-Id: I87755d5291ce209c1e647792227c433dc966615d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1776
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Fix handling of 5-byte Fast Read command in the ICH SPI
driver. This fix is ported from the U-boot driver.
- Allow CONFIG_SPI_FLASH_NO_FAST_READ to be overridden by
defining a name for the bool in Kconfig and removing the
forced select in southbridge config
- Fix use of CONFIG_SPI_FLASH_NO_FAST_READ in SPI drivers
to use #if instead of #ifdef
- Relocate flash functions in SMM so they are usable.
This really only needs to happen for read function pointer
since it uses a global function rather than a static one from
the chip, but it is good to ensure the rest are set up
correctly as well.
Change-Id: Ic1bb0764cb111f96dd8a389d83b39fe8f5e72fbd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1775
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Applied function attribute to function definition to avoid 'conflicting type' warning.
Function declaration is in src/include/cpu.h
void secondary_cpu_init(unsigned int cpu_index)__attribute__((regparm(0)));
But function definition in lapic_cpu_init.c is missing the "__attribute__" part.
Change-Id: Idb7cd00fda5a2d486893f9866920929c685d266e
Signed-off-by: Han Shen <shenhan@google.com>
Reviewed-on: http://review.coreboot.org/1784
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
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>
src/include/timestamp.h is an interface describing timestamp storage
in coreboot. Exporting this interface is complicated by inclusion of
tsc.h which is needed only for the API and is not used in structure
definitions. Including this dependency only when needed fixes the
problem.
Change-Id: Ie6b1460b1dab0f5b5781cb5a9fa89a1a52aa9f17
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1753
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
These events were initially for Chrome EC but they can be
applied to any EC.
Change-Id: I0eba9dbe8bde506e7f9ce18c7793399d40e6ab3b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1746
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
http://netbsd.gw.com/cgi-bin/man-cgi?date++NetBSD-current
The NetBSD manual tells us the date in NetBSD doesn't take any flags
to enable or disable padding in the format.
By default, date pads numeric fields with zeroes. This will convert the
number to octal one. So add "0x" to convert it to BCD directly.
Change-Id: Icd44312acf01b8232f1da1fbaa70630d09007b40
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1804
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Read out the post code from the previous boot and
log it if the code is not one of the expected values.
Test:
1) interrupt the boot of the system, this is easiest
with warm reset button when servo is attached
2) check the event log with mosys
65 | 2012-09-09 12:32:11 | Last post code in previous boot | 0x9d
Change-Id: Id418f4c0cf005a3e97b8c63de67cb9a09bc57384
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
We are seeing ME disabled and ME error events on some devices
and this extended info can help with debug.
Also fix a potential issue where if the log does manage to get
completely full it will never try to shrink it because the only
call to shrink the log happens after a successful event write.
Add a check at elog init time to shrink the log size.
Change-Id: Ib81dc231f6a004b341900374e6c07962cc292031
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1739
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code that attempts to use the opmenu needs to have a special
case for write enable now that it is handled as an atomic prefix
and not as a standalone opcode.
To test, ensure that runtime SPI write via ELOG is successful by
checking the event log for a kernel shutdown reason code:
5 | 2012-08-27 11:09:48 | Kernel Event | Clean Shutdown
6 | 2012-08-27 11:09:50 | System boot | 26
7 | 2012-08-27 11:09:50 | System Reset
Change-Id: I527638ef3e2a5ab100192c5be6e6b3b40916295a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1710
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Check the RTC on boot after RTC battery failure and ensure
that the reported build date matches what is reported:
> grep ^rtc /proc/driver/rtc
rtc_time : 01:00:21
rtc_date : 2012-08-16
Change-Id: If23f436796754c68ae6244ef7633ff4fa0a93603
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1709
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
(elog portion, support in EC code pending)
- Use a new EC command to read the last post code
from the previous boot
- If the post code is not well-known final boot
or resume code then log it
Change-Id: Id6249e9a182243eb87c777edd56f48de72125e77
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1703
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Right now we only had a post code for "All devices enabled" which
was emitted at the wrong time (after the device initialize stage
rather than the device enable stage)
Change-Id: Iee82bff020de844c7095703f8d6521953003032c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1693
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
Compose the name from Kconfig strings instead.
As the field is for debug print use only, a minor change in the output
should do no harm. The strings no longer include word "Mainboard".
Change-Id: Ifd24f408271eb5a5d1a08a317512ef00cb537ee2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1635
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The constant field "name" in chip_operations is common to multiple
different devices within a chip and cannot reflect the actual device
as found on the platform.
The intention is that a driver sets dev->name as part of the device
enumeration sequence with the detected hardware type and revision.
The field is for debug print use only.
Change-Id: Ib7bf90ba3c618ad0cb715d80d6a937ceaae0adcf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1634
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This adds proper support for turbo and super-low-frequency modes.
Calculation of the p-states has been rewritten and moved into an
extra file speedstep.c so it can be used for non-acpi stuff like
EMTTM table generation.
It has been tested with a Core2Duo T9400 (Penryn) and a Core Duo T2300
(Yonah) processor.
Change-Id: I5f7104fc921ba67d85794254f11d486b6688ecec
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1658
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We had only some MSR definitions in there, which are used in speedstep
related code. I think speedstep.h is the better and less confusing place
for these.
Change-Id: I1eddea72c1e2d3b2f651468b08b3c6f88b713149
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1655
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)
Disallow tracing while in SMM.
Change-Id: Icde17629bb06a615cc48f017fd0cd1f7b720e62d
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/1503
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
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>
These declarations were never or no longer used.
Change-Id: Icdbfc0838d5021ea02ab031b643b3fe6361b39b4
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1489
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Factor CPU allocation out of AMD northbridge codes. As CPU topology
information is required for generation of certain ACPI tables, make
this code globally available.
For AMDK8 and AMDFAM10 northbridge, there is a possible case of
BSP CPU with lapicid!=0. We do not want to leave the lapic 0 from
devicetree unused, so always use that node for BSP CPU.
Change-Id: I8b1e73ed5b20b314f71dfd69a7b781ac05aea120
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1418
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Take a copy of BSP CPU's TOP_MEM and TOP_MEM2 MSRs to be distributed
to AP CPUs and factor out the debugging info from setup_uma_memory().
Change-Id: I1acb4eaa3fe118aee223df1ebff997289f5d3a56
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1387
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The CPU can arbitrarily reorder calls to rdtsc, significantly
reducing the precision of timing using the CPUs time stamp counter.
Unfortunately the method of synchronizing rdtsc is different
on AMD and Intel CPUs. There is a generic method, using the cpuid
instruction, but that uses up a lot of registers, and is very slow.
Hence, use the correct lfence/mfence instructions (for CPUs that
we know support it)
Change-Id: I17ecb48d283f38f23148c13159aceda704c64ea5
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1422
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
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)
Dropping mainboard's chip.h broke execution of the mainboard's enable
function and the addition of mainboard specific smbios tables.
The former was fixed by Kyosti in http://review.coreboot.org/1374
This patch fixes the breakage in static.c and also backs out a small
portion of Kyosti's patch (because it's not needed anymore)
Change-Id: I6fdea9cbb8c6041663bd36f68f1cae4b435c1f9b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1421
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The function is a noop for all but amd/serengeti_cheetah.
Change-Id: I09e2e710aa964c2f31e35fcea4f14856cc1e1dca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1184
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Some mainboards have really nice capabilities for posting, beyond
simple POST cards. Further, some can not use a POST card. This
change defines a weak symbol (mainboard_post) that can be overridden
by a real mainboard_post function.
If, for example, you'd like to do something fancy before the payload starts,
you can add this to mainboard.c:
void mainboard_post(u8 value)
{
switch(value){
case POST_TIME_TO_PARTY: some_fancy_lights();
break;
}
}
Maybe the post function should be an entry in the device. We're beginning to over-use
weak symbols.
BUG=None
TEST=Build and boot a google chromebook. Observe that it still works. Use it to drive
some pretty lights.
Change-Id: I3512d2ec34a66c747287191851c3f68b6a7cc1b2
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1397
Tested-by: build bot (Jenkins)
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>
Commit 188e3c2ff0 dropped mainboard
out of the static device tree. This left dev_root->chip_ops unset,
and mainboard_ops.enable_dev() was no longer called.
Change-Id: I6d447c8049a66041b8bb36ec9aac3e7e0d20a99b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1374
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If the CMOS is cleared or someone writes some random date/time
on purpose, the CMOS date register has a invalid date. This will
hurts some OS, like Windows 7, which hangs at MS logo forever.
When we detect that, we need to write a reasonable date in CMOS.
Alexandru Gagniuc:
Hmm, it would be interesting to use the date the coreboot image
was built and set that as the default date. At least until time
travel is invented.
Change-Id: Ic1c7a2d60e711265686441c77bdf7891a7efb42e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1389
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
UMA region can be determined at any time after the amount
of RAM is known and before the uma_resource() call.
Change-Id: I2a0bf2d3cad55ee70e889c88846f962b7faa0c7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1379
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reserved memory resources will get removed from memory table at
the end of write_coreboot_table(),
Change-Id: I02711b4be4f25054bd3361295d8d4dc996b2eb3e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1372
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@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>
Hide some details of the resource allocator from rest of the world.
These should come in handy when fixing some aspects of MTRR setup.
Change-Id: I8acad98f25e56cd8bae64fb52539d81ce94f9c73
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1367
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Recent changes in EC/Vboot/U-boot have completely broken
the logging of developer and recovery modes.
Recovery mode may not be in VBNV, so if that is zero and
yet we are in recovery mode then assume it is there because
the button/key was pressed.
Since there may not be any actual developer mode switch
we look if option rom is loaded and the system is not
in recovery mode and consider that as developer mode.
Change-Id: I70104877b24de477217e1ff5b3a019aef22343ec
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will log if the ME is disabled or has an error.
1) disable ME via EC console: gpioset PCH_HDA_SDO 1
2) boot the device
3) read eventlog with "mosys eventlog list"
71 | 2012-07-13 10:10:55 | Management Engine | Disabled
Change-Id: I9f6ee452d2aea76e6a5ea2cd50a50ff36245692a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1345
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>
The linux kernel contains an SMI driver that was written by
me (Duncan) and upstreamed a couple years ago called GSMI.
This driver will format a parameter buffer and pass pointers
to this parameter buffer to the SMI handler. It uses this to
generate events for kernel shutdown reasons: Clean, Panic, Oops,
etc.
This function expects to be passed pointers into the SMM state
save area that correspond to the prameter buffer and the return
code, which are typically EAX and EBX.
The format of the parameter buffer is defined in the kernel
driver so we implement the same interface here in order to be
compatible.
GSMI_CMD_HANDSHAKE: this is an early call that it does to try
and detect what kind of BIOS is running.
GSMI_CMD_SET_EVENT_LOG: this contains a parameter buffer that
has event type and data. The kernel-specific events are
translated here and raw events are passed through as well which
allows any run-time event to be added for testing.
GSMI_CMD_CLEAR_EVENT_LOG: this command clears the event log.
First the gsmi driver must be enabled in the kernel with
CONFIG_GOOGLE_GSMI and then events can be added via sysfs
and events are automatically generated for various kernel
shutdown reasons.
These can be seen in the event log as the 'Kernel Event' type:
169 | 2012-06-23 15:03:04 | Kernl Event | Clean Shutdown
181 | 2012-06-23 16:26:32 | Kernl Event | Oops
181 | 2012-06-23 16:26:32 | Kernl Event | Panic
Change-Id: Ic0a3916401f0d9811e4aa8b2c560657dccc920c1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1316
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function is exported so it can be used in other
places that need similar relocation due to TSEG.
Change-Id: I68b78ca32d58d1a414965404e38d71977c3da347
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1310
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
This maintains a 32bit monotonically increasing boot counter
that is stored in CMOS and logged on every non-S3 boot when
the event log is initialized.
In CMOS the count is prefixed with a 16bit signature and
appended with a 16bit checksum.
This counter is incremented in sandybridge early_init which is
called by romstage. It is incremented early in order notice
when reboots happen after memory init.
The counter is then logged when ELOG is initialized and will
store the boot count as part of a 'System boot; event.
Reboot a few times and look for 'System boot' events in the
event log and check that they are increasing. Also verify
that the counter does NOT increase when resuming from S3.
171 | 2012-06-23 16:02:55 | System boot | 285
176 | 2012-06-23 16:26:00 | System boot | 286
182 | 2012-06-23 16:27:04 | System boot | 287
189 | 2012-06-23 16:31:10 | System boot | 288
Change-Id: I23faeafcf155edfd10aa6882598b3883575f8a33
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1315
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
There are enough differences that it is worth defining the
proper map for the sandybridge/ivybridge CPUs. The state
save map was not being addressed properly for TSEG and
needs to use the right offset instead of pointing in ASEG.
To do this properly add a required southbridge export to
return the TSEG base and use that where appropriate.
Change-Id: Idad153ed6c07d2633cb3d53eddd433a3df490834
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1309
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is based around the SMBIOS event log specification but
expanded with OEM event types to support more specific and
relevant system events.
It requires flash storage and a minimum 4K block (or flash block
size) that should be allocated in the FMAP.
A copy of the event log is maintained in memory for convenience
and speed and the in-memory copy is written to flash at specific
points.
The log is automatically shunk when it reaches a configurable
full threshold in order to not get stuck with a full log that
needs OS help to clear.
ELOG implements the specification published here:
http://code.google.com/p/firmware-event-log/wiki/FirmwareEventLogDesign
And is similar to what we use in other firmware at Google.
This implementation does not support double-buffered flash
regions. This is done because speed is valued over the log
reliability and it keeps the code simpler for the first version.
This is a large commit and by itself it just provides a new
driver that is made available to coreboot. Without additional
patches it is not very useful, but the end result is an event
log that will contain entries like this:
171 | 2012-06-23 16:02:55 | System boot | 285
172 | 2012-06-23 16:02:55 | EC Event | Power Button
173 | 2012-06-23 16:02:55 | SUS Power Fail
174 | 2012-06-23 16:02:55 | System Reset
175 | 2012-06-23 16:02:55 | ACPI Wake | S5
Change-Id: I985524c67f525c8a268eccbd856c1a4c2a426889
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Previous patches implemented stack overflow checking for the APs.
This patch builds on the BSP stack poisoning patch to implement
stack overflow checking for the BSP, and also prints out maximum
stack usage. It reveals that our 32K stack is ridiculously oversized,
especially now that the lzma decoder doesn't use a giant 16K on-stack
array.
Break the stack checking out into a separate function, which
we will later use for the APs.
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8
To test failure, change the DEADBEEF stack poison value in c_start.S
to something else. Then we should get an error like this:
Stack overrun on BSP.Increase stack from current 32768 bytes
CPU0: stack from 00180000 to 00188000:Lowest stack address 00180000
Separate the act of loading from the act of starting the payload. This
allows us better error management and reporting of stack use. Now we
see:
CPU0: stack from 00180000 to 00188000:Lowest stack address 00187ad8
Tested for both success and failure on Link. At the same time, feel free
to carefully check my manipulation of _estack.
Change-Id: Ibb09738b15ec6a5510ac81e45dd82756bfa5aac2
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1286
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When CONFIG_MICROCODE_IN_CBFS is enabled, find the microcode blob in
CBFS and pass it to intel_update_microcode() instead of using the
compiled in array.
CBFS accesses in pre-RAM and 'normal' environments are provided
through different API.
Change-Id: I35c1480edf87e550a7b88c4aadf079cf3ff86b5d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1296
Tested-by: build bot (Jenkins)
This lets the SPI driver and the LPC driver know about HM70 and NM70.
Change-Id: Id2f1e0e5586a2f7200b2d24785df3f2be890da98
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1300
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The oxpcie ramstage code calls uartmem_init after the PCI memory
allocation, but hte function was static and didn't have a prototype.
Change-Id: Iabc1a3d248aeaed29aaaa22504defac97c572326
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/1285
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
ELOG reads from RTC to build timestamp structure,
the resulting timestamp is decoded when printing events.
Change-Id: If26552074f18de5095b967b875a0ac1d815a5b31
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1302
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Since coreboot is running very short, we don't free memory.
Hence, drop (dummy) free()
Change-Id: I6e2737f07c6b9f73ebfad7d124b97a57cb7454a3
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1274
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We don't ever free memory in coreboot, hence drop spi_flash_free() and
spi_free_slave()
Change-Id: I0ca3f78574ceb4516e7d33c06ab1a58abfb3b0ec
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1273
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
VGA is this part-legacy thing that can cause trouble...
For this, introduce device_t->disable(dev) method, in which a driver
can take care to deregister the device if necessary.
Change-Id: I3fecec07f402e530458b79eda30b2c274101fefa
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1251
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
MTRR setup code can detect this and mark it as UC/WT/WC as suitable
for the specific hardware.
Change-Id: Ib7a3d450fc7c19e3ca72767dfb350412dd35c971
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1214
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Use of the uma_memory_base and _size variables is very scattered.
Implementation of setup_uma_memory() will appear in each northbridge.
It should be possible to do this setup entirely in northbridge
code and get rid of the globals in a follow-up.
Change-Id: I07ccd98c55a6bcaa8294ad9704b88d7afb341456
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Like ram_resource(), but reserved and not cacheable.
Switch all AMD northbridges to use this one.
Change-Id: I88515c6a0f59f80fd8607c390d0d4a2a35d805f2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1203
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
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>
CACHE_ROM_SIZE default is ROM_SIZE, the Flash device size set
in menuconfig. This fixes a case where 8 MB SPI flash MTRR setup
would not cover the bottom 4 MB when ramstage is decompressed.
Verify CACHE_ROM_SIZE is power of two.
One may set CACHE_ROM_SIZE==0 to disable this cache.
Change-Id: Ib2b4ea528a092b96ff954894e60406d64f250783
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1146
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
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>
Early HT-enabled CPUs do not serialize microcode updates within a core.
Solve this by running microcode updates on the thread with the smallest
lapic ID of a core only.
Also set MTRRs once per core only.
Change-Id: I6a3cc9ecec2d8e0caed29605a9b19ec35a817620
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1142
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remove all the repeated sections of code in cbtypes.h and place it
in a common location. Add include dir in vendor code's Makefile.
Change-Id: Ida92c2a7a88e9520b84b0dcbbf37cd5c9f63f798
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/912
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Requirements:
- must be in ramstage (locking flash while executing code from there
might not work)
- must be after cbmem is reinitialized (so the mrc cache copy of the
current run can be found)
Change-Id: I8028fb073349ce2b027ef5f8397dc1a1b8b31c02
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1002
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This driver is taken from u-boot and adapted to match
coreboot. It still contains some hacks and is ICH specific
at places.
Change-Id: I97dd8096f7db3b62f8f4f4e4d08bdee10d88f689
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/997
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change is taken from Linux. It allows to check for Kconfig
definitions in the preprocessor and source code using the same
idiom.
Long term plan is to remove our Kconfig hack to #define values to 0,
and this helps.
This includes a tiny modification to the macros to fix romcc support.
Change-Id: I0fddbea8c8ca215cf226acf39cb329b0ba0445a5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1005
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Many PCI devices share the very same driver despite having different
PCI device IDs, which causes a lot of copy and paste of driver
definitions.
This change introduces a way to specify the array of acceptable
device IDs in a single driver entry. As an example the Intel
{Sandy|Ivy} Bridge SATA driver is being modified to use a single
driver structure for all different SATA controller flavors, a few
more Ivy Bridge IDs are being added as well.
BUG=none
TEST=manual
. modified coreboot brought up an Ivy Bridge platform all the
way to Linux login screen.
Change-Id: I761c5611b93ef946053783f7a755e6c456dd6991
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/982
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
rename from mainboard_apm_cnt to mainboard_smi_apmc to match the function
naming scheme of the other handlers. Add prototype for mainboard_smi_sleep
(mainboard specific S3 sleep handlers in SMM) that is required by Sandybridge.
Change-Id: Ib479397e460e33772d90d9d41dba267e4e7e3008
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/933
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to use the generic microcode update code in the bootblock, cpu/cpu.h
needs ROMCC guards. Also, delete the unused struct device declaration and move
the struct bus declaration to where it's used.
Change-Id: I0cc731c555593946e931a680ec93994932530599
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/932
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is no reason for this to be a top level directory.
Some stuff from lib/ should also be moved to drivers/
Change-Id: I3c2d2e127f7215eadead029cfc7442c22b26814a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/939
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- add GPLv2 + copyright header after talking to Ron
- "bits" in struct microcode served no real purpose but
getting its address taken. Hence drop it
- use asm volatile instead of __asm__ volatile
- drop superfluous wrmsr (that seems to be harmless but
is still wrong) in read_microcode_rev
- use u32 instead of unsigned int where appropriate
- make code usable both in bootblock and in ramstage
- drop ROMCC style print_debug statements
- drop microcode update copy in Sandybridge bootblock
Change-Id: Iec4d5c7bfac210194caf577e8d72446e6dfb4b86
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/928
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of opaque numbers like (1<<29), use
symbols like CR0_NoWriteThrough.
Change-Id: Id845e087fb472cfaf5f71beaf37fbf0d407880b5
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/833
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Add a memalign function and have malloc use it. Also,
change the default alignment for malloc to u64-aligned.
Change-Id: I0788637008f5cb5ac801d8bbdc430ca992c98e81
Signed-off-by: Ron Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/887
Tested-by: build bot (Jenkins)
Reviewed-by: Mathias Krause <minipli@googlemail.com>
Stefan Reinauer