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>
- preprocessor macros should not use defined(CONFIG_*) but
just CONFIG_*
- drop AMD CPU model 14XXX config variable use. Those do not exist.
- skip some delays on Sandybridge systems
- Count how long we're waiting for each AP to stop
- Skip speedstep specific CPU entries
Change-Id: I13db384ba4e28acbe7f0f8c9cd169954b39f167d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/871
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
cache as ram does not usually cache the ram before it is up. Hence,
if romstage.c backs up resume memory, the involved memcpy is always
uncached. This makes resume very slow.
On Sandybridge we copy the memory later, after enabling caching, and
that allows us to resume in as little as 250ms.
Change-Id: I31a71ad4468679d39880cf9a8c4e497bb7addf8f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/872
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>
Traditionally coreboot's SMM handler runs in ASEG (0xa0000),
"behind" the graphics memory. This approach has two issues:
- It limits the possible size of the SMM handler (and the
number of CPUs supported in a system)
- It's not considered a supported path anymore in newer CPUs.
Change-Id: I9f2877e46873ab2ea8f1157ead4bc644a50be19e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Acked-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/842
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
From wikipedia:
Intel Turbo Boost is a technology implemented by Intel in certain
versions of their Nehalem- and Sandy Bridge-based CPUs, including Core
i5 and Core i7 that enables the processor to run above its base
operating frequency via dynamic control of the CPU's "clock rate".
It is activated when the operating system requests the highest
performance state of the processor.
Change-Id: I166ead7c219083006c2b05859eb18749c6fbe832
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/844
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add support for type 41 smbios tables (to be used by board
specific smbios handlers)
Change-Id: Id6af5e4b1f5c5c78c63759d24fdc7cf8537ae5e6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/843
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
... and drop duplicate definition in via/epia-n code.
Change-Id: Id79daaaa35c4d412c8c1f621a3638d129681d331
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/820
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This affects the algorithm when determining when to
transform a range into a larger range with a hole.
It is needed when for when I switch on an 8MB TSEG
and cause the memory maps to go crazy.
Also add header defines for the SMRR.
Change-Id: I1a06ccc28ef139cc79f655a8b19fd3533aca0401
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds a number of timestamps in ramstage and romstage
so we can figure out where execution time goes.
Change-Id: Iea17c08774e623fc1ca3fa4505b70523ba4cbf01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/749
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
and initialize the TPM on S3 resume
This patch integrates the TPM driver and runs TPM resume upon an ACPI S3
resume without including any other parts of vboot.
We could link against vboot_fw.a but it is compiled with u-boot's CFLAGS
(that are incompatible with coreboot's) and it does a lot more than we
want it to do.
Change-Id: I000d4322ef313e931e23c56defaa17e3a4d7f8cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cbmem console structure and car global data are put in their own section,
with the cbmem console coming after the global data. These areas are linked
to be where CAR is available and at the very bottom of the stack.
There is one shortcoming of this change:
The section created by this change needs to be stripped out by the Makefile
since leaving it in confuses cbfstool when it installs the stage in the image.
I would like to make the tools link those symbols at the right location but
leave allocation of that space out of the ELF.
Change-Id: Iccfb99b128d59c5b7d6164796d21ba46d2a674e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/727
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use an int in CAR global data to store whether or not the OXPCIE serial card
is actually there. Also, time out if the card doesn't show up quickly enough,
don't continue initialization if it's not there, and don't make the
initialization routine default to a card if none is found.
Change-Id: I9c72d3abc6ee2867b77ab2f2180e6f01f647af8c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/728
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These are guarded by individual Kconfig entries. The deprecated
CONFIG_PCIE_TUNING defines have been removed in favor of using specific
config options.
This is the generic half, there is board-specific pieces
still to come that tune before and after ASPM is enabled.
Change-Id: I3fe46282eada67629e9eeeed07e487dff54f2729
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/735
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
We need to provide u-boot access to several different CBMEM
sections. To do that, a common coreboot table structure is used,
just different tags match different coreboot table sections.
Also, the code is added to export CBMEM console and MRC cache
addresses through the same mechanism.
Change-Id: I63adb67093b8b50ee61b0deb0b56ebb2c4856895
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/724
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change exports the timestamp table pointer through coreboot
table to make it possible for u-boot to add timestamps to the
table.
Inclusion of cbmem.h allows to drop external declarations in
coreboot_table.c.
Change-Id: Ia070198cee7a6ffdaeece03d9d15bd91e033b6d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add CBMEM type for the console buffer section.
Change-Id: I02757c06d71e46af77b02b90b0e6018a37b62406
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/720
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The CBMEM console driver saves console output in a CBMEM area, which
then is made available to Linux applications for perusing.
There are some system limitations which need to be worked around
to achieve this goal:
- some console traffic is generated before DRAM is initialized,
leave alone CBMEM initialized.
- after the RAM based stage starts, a lot of traffic is generated
before CBMEM is initialized.
As a result, the console log lives in three different places -
the bottom of the cache as RAM space, the CBMEM buffer (where it
is expected to be) and a static buffer used early in the RAM
stage.
When execution starts (in the cache as RAM mode), the console
buffer is allocated at the bottom of the cache as RAM memory
address range. Once DRAM is initialized, the CBMEM structure is
initialized, and then the console buffer contents are copied from
the bottom of the cache as RAM space into the CBMEM area right
before the cache as RAM mode is disabled. The
src/lib/cbmem_console.c:cbmemc_reinit() takes care of the
copying.
At this point the cache as RAM memory is about to be disabled,
but the ROM stage is still going generating console output. To
make sure this output is not lost, cbmemc_reinit() saves the new
buffer address at a fixed location (0x600 was chosen for this),
and the actual "printing" function checks to see if the RAM is
already initialized (the stack is in RAM), and if so, gets the
console buffer pointer from this location instead of using the
cache as RAM address.
When the RAM stage starts, a static buffer is used to store the
console output, as the CBMEM buffer location is not known. Then,
when CBMEM is reinitialized, cbmemc_reinit() again takes care of
the copying.
In case the allocated buffers are not large enough, the excessive
data is dropped, and the copying routine adds some text to the
output buffer to indicate that there has been data lost and how
many characters were dropped.
Change-Id: I8c126e31db6cb2141f7f4f97c5047f39a8db44fc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change adds 128K to the memory amount set aside for CBMEM in
case the CBMEM console is enabled (to keep the CBMEM 128K byte
aligned). The console buffer size is being set to 64K, which is
enough to accommodate the most verbose coreboot console and
u-boot console.
Change-Id: If583013dfb210de5028d69577675095c6fe2f3ab
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/725
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These get used later for saving/restoring the MRC scrambler
seed values on each boot.
Change-Id: I6e23f17649bea6d22c4b279ed8d0e5cb6c0885e7
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/717
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds code to initialize the time stamp collection
facility in coreboot. It adds a table in the CBMEM section, which
provides the base timer reading value (all other readings are
offsets of this one) and an array of timestamp id/timestamp value
pairs.
Just two values are being added now, this will have to be used
more extensively and also integrated into payloads to provide more
comprehensive boot process time measurements.
Also, since the CBMEM area could already contain a section (from the
previous run, before reset), when processing a section addition
request we should check if a section already exists and return its
address, if so.
Change-Id: I7ed9f5c400bc5432f228348b41fd19a67c36d533
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/713
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
We want to be able to share data between different phases of firmware
(rom stage/ram stage/payload). Coreboot CBMEM seems an appropriate
location for this data, but normally it is not initialized
until coreboot reaches the ram stage.
This change initializes the CBMEM while still in rom stage in
case CONFIG_EARLY_CBMEM_INIT is set.
Note that there is a discrepancy in how coreboot determines the
size of DRAM at rom and ram stages, get_top_of_ram() is used at
rom stage and is not defined for all platforms. Those platforms
will have to define this function should they enable the
CONFIG_EARLY_CBMEM_INIT flag.
Change-Id: I81691d45e28de59496fb227f2cca4e8c15ece717
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/711
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I3f3585f15265aa1377f72ba23accf1adb08cb8ac
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: http://review.coreboot.org/806
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
clang doesn't know about the side effect, so we have to tell it
that it's okay not to care about the result.
Change-Id: Ib11890bff6779e36cf09c178d224695ea16a8ae8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/783
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since cbfs_core.h provides a macro that uses ntohl, make sure ntohl is available by
including byteorder.h
Change-Id: I9ab8cb51bd680e861b28d5130d09547bb9ab3b1f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/709
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
