GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/console/post.c

159 lines
3.4 KiB
C
Raw Normal View History

Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
/*
* This file is part of the coreboot project.
remove trailing whitespace Change-Id: Ib91889a374515d36a2b12b53aeb12b6ea6e22732 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/364 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2011-10-31 20:56:45 +01:00
*
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
* Copyright (C) 2003 Eric Biederman
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; version 2 of
* the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <arch/io.h>
src/console/post.c: Sanitize headers from preprocessor abuse Continuing on from the rational given in: a173a62 Remove guarding #includes by CONFIG_FOO combinations Change-Id: I524713b21684f6fa99355614a1ab38aee9975790 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6091 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <gaumless@gmail.com>
2014-06-21 13:42:25 +02:00
#include <elog.h>
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
#include <console/console.h>
src/console/post.c: Sanitize headers from preprocessor abuse Continuing on from the rational given in: a173a62 Remove guarding #includes by CONFIG_FOO combinations Change-Id: I524713b21684f6fa99355614a1ab38aee9975790 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6091 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <gaumless@gmail.com>
2014-06-21 13:42:25 +02:00
#include <device/device.h>
Add support for storing POST codes in CMOS 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>
2012-09-10 04:09:56 +02:00
#include <pc80/mc146818rtc.h>
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
#include <smp/spinlock.h>
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
/* Write POST information */
Add a capability for mainboard-specific posting. 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)
2012-08-03 20:20:57 +02:00
/* someday romcc will be gone. */
#ifndef __ROMCC__
/* Some mainboards have very nice features beyond just a simple display.
* They can override this function.
*/
void __attribute__((weak)) mainboard_post(uint8_t value)
{
}
#else
/* This just keeps the number of #ifs to a minimum */
#define mainboard_post(x)
#endif
Add support for storing POST codes in CMOS 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>
2012-09-10 04:09:56 +02:00
#if CONFIG_CMOS_POST
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
DECLARE_SPIN_LOCK(cmos_post_lock)
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
#if !defined(__PRE_RAM__)
void cmos_post_log(void)
{
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
u8 code = 0;
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#if CONFIG_CMOS_POST_EXTRA
u32 extra = 0;
#endif
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
spin_lock(&cmos_post_lock);
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
/* Get post code from other bank */
switch (cmos_read(CMOS_POST_BANK_OFFSET)) {
case CMOS_POST_BANK_0_MAGIC:
code = cmos_read(CMOS_POST_BANK_1_OFFSET);
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#if CONFIG_CMOS_POST_EXTRA
extra = cmos_read32(CMOS_POST_BANK_1_EXTRA);
#endif
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
break;
case CMOS_POST_BANK_1_MAGIC:
code = cmos_read(CMOS_POST_BANK_0_OFFSET);
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#if CONFIG_CMOS_POST_EXTRA
extra = cmos_read32(CMOS_POST_BANK_0_EXTRA);
#endif
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
break;
}
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
spin_unlock(&cmos_post_lock);
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
/* Check last post code in previous boot against normal list */
switch (code) {
case POST_OS_BOOT:
case POST_OS_RESUME:
case POST_ENTER_ELF_BOOT:
case 0:
break;
default:
printk(BIOS_WARNING, "POST: Unexpected post code "
"in previous boot: 0x%02x\n", code);
#if CONFIG_ELOG
elog_add_event_word(ELOG_TYPE_LAST_POST_CODE, code);
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#if CONFIG_CMOS_POST_EXTRA
if (extra)
elog_add_event_dword(ELOG_TYPE_POST_EXTRA, extra);
#endif
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
#endif
}
}
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#if CONFIG_CMOS_POST_EXTRA
void post_log_extra(u32 value)
{
spin_lock(&cmos_post_lock);
switch (cmos_read(CMOS_POST_BANK_OFFSET)) {
case CMOS_POST_BANK_0_MAGIC:
cmos_write32(CMOS_POST_BANK_0_EXTRA, value);
break;
case CMOS_POST_BANK_1_MAGIC:
cmos_write32(CMOS_POST_BANK_1_EXTRA, value);
break;
}
spin_unlock(&cmos_post_lock);
}
Log device path into CMOS during probe stages One of the most common hangs during coreboot execution is during ramstage device init steps. Currently there are a set of (somewhat misleading) post codes during this phase which give some indication as to where execution stopped, but it provides no information on what device was actually being initialized at that point. This uses the new CMOS "extra" log banks to store the encoded device path of the device that is about to be touched by coreboot. This way if the system hangs when talking to the device there will be some indication where to investigate next. interrupted boot with reset button and gathered the eventlog after several test runs: 26 | 2013-06-10 10:32:48 | System boot | 120 27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize 28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0 29 | 2013-06-10 10:32:48 | Reset Button 30 | 2013-06-10 10:32:48 | System Reset Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58105 Reviewed-on: http://review.coreboot.org/4230 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:34:20 +02:00
void post_log_path(struct device *dev)
{
if (dev) {
/* Encode path into lower 3 bytes */
u32 path = dev_path_encode(dev);
/* Upper byte contains the log type */
path |= CMOS_POST_EXTRA_DEV_PATH << 24;
post_log_extra(path);
}
}
void post_log_clear(void)
{
post_log_extra(0);
}
Extend CMOS POST code logging to store extra data This can be used to indicate sub-state within a POST code range which can assist in debugging BIOS hangs. For example this can be used to indicate which device is about to be initialized so if the system hangs while talking to that device it can be identified. Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58104 Reviewed-on: http://review.coreboot.org/4229 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-10 19:21:41 +02:00
#endif /* CONFIG_CMOS_POST_EXTRA */
Log unexpected post code from the previous boot 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>
2012-09-10 04:14:45 +02:00
#endif /* !__PRE_RAM__ */
Add support for storing POST codes in CMOS 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>
2012-09-10 04:09:56 +02:00
static void cmos_post_code(u8 value)
{
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
spin_lock(&cmos_post_lock);
Add support for storing POST codes in CMOS 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>
2012-09-10 04:09:56 +02:00
switch (cmos_read(CMOS_POST_BANK_OFFSET)) {
case CMOS_POST_BANK_0_MAGIC:
cmos_write(value, CMOS_POST_BANK_0_OFFSET);
break;
case CMOS_POST_BANK_1_MAGIC:
cmos_write(value, CMOS_POST_BANK_1_OFFSET);
break;
}
cmos post: Guard with spinlock The CMOS post code storage mechanism does back-to-back CMOS reads and writes that may be interleaved during CPU bringup, leading to corruption of the log or of other parts of CMOS. Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58102 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4227 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-10 18:53:33 +02:00
spin_unlock(&cmos_post_lock);
Add support for storing POST codes in CMOS 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>
2012-09-10 04:09:56 +02:00
}
#endif /* CONFIG_CMOS_POST */
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
void post_code(uint8_t value)
{
more ifdef -> if fixes Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6536 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2011-04-21 22:45:45 +02:00
#if !CONFIG_NO_POST
#if CONFIG_CONSOLE_POST
misc: Drop print_ implementation from non-romcc boards Because we had no stack on romcc boards, we had a separate, not as powerful clone of printk: print_*. Back in the day, like more than half a decade ago, we migrated a lot of boards to printk, but we never cleaned up the existing code to be consistent. Instead, we worked around the problem with a very messy console.h (nowadays the mess is hidden in romstage_console.c and early_print.h) This patch cleans up the generic code pieces to use printk() on all non-ROMCC boards. Our two remaining ROMCC boards are fixed up in this commit: bifferos/bifferboard and dmp/vortex86ex. Change-Id: I16676eeabe5c892c8e3c9f3c0cd3bae2e8fd74b6 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/8115 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Andrew Wu <arw@dmp.com.tw> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-01-05 22:12:38 +01:00
printk(BIOS_EMERG, "POST: 0x%02x\n", value);
Add support for storing POST codes in CMOS 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>
2012-09-10 04:09:56 +02:00
#endif
#if CONFIG_CMOS_POST
cmos_post_code(value);
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
#endif
Make POST device configurable. Change-Id: If92b50ab3888518228d2d3b76f5c50c4aef968dd Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/4561 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-03-11 16:36:21 +01:00
#if CONFIG_POST_IO
outb(value, CONFIG_POST_IO_PORT);
Make POST codes written to IO port optional This adds more configurability to POST codes. The current assumption is that POST codes should be written to an IO port (e.g. LPC) if POST codes are enabled. This changes the assumption so that POST codes can be written to the serial console without being written to an IO port. This enables POST codes by default using "default y" to avoid changing current behavior. Change-Id: I3db91c358ccb1557096983c4d07f70b2e872c4b3 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/1685 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2012-11-05 21:34:09 +01:00
#endif
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
#endif
Add a capability for mainboard-specific posting. 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)
2012-08-03 20:20:57 +02:00
mainboard_post(value);
Printing coreboot debug messages on VGA console is pretty much useless, since initializing VGA happens pretty much as the last thing before starting the payload. Hence, drop VGA console support, as we did in coreboot v3. - Drop VGA and BTEXT console support. Console is meant to be debugging only, and by the time graphics comes up 99% of the risky stuff has already happened. Note: This patch does not remove hardware init but only the actual output functionality. The ragexl driver needs some extra love, but that's for another day - factor out die() and post() - drop some leftover RAMBASE < 0x100000 checks. Signed-off-by: Stefan Reinauer <stepan@coreboot.org> Acked-by: QingPei Wang<wangqingpei@gmail.com> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6111 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-22 09:09:50 +01:00
}