2003-04-22 21:02:15 +02:00
|
|
|
/*
|
|
|
|
This software and ancillary information (herein called SOFTWARE )
|
|
|
|
called LinuxBIOS is made available under the terms described
|
|
|
|
here. The SOFTWARE has been approved for release with associated
|
|
|
|
LA-CC Number 00-34 . Unless otherwise indicated, this SOFTWARE has
|
|
|
|
been authored by an employee or employees of the University of
|
|
|
|
California, operator of the Los Alamos National Laboratory under
|
|
|
|
Contract No. W-7405-ENG-36 with the U.S. Department of Energy. The
|
|
|
|
U.S. Government has rights to use, reproduce, and distribute this
|
|
|
|
SOFTWARE. The public may copy, distribute, prepare derivative works
|
|
|
|
and publicly display this SOFTWARE without charge, provided that this
|
|
|
|
Notice and any statement of authorship are reproduced on all copies.
|
|
|
|
Neither the Government nor the University makes any warranty, express
|
|
|
|
or implied, or assumes any liability or responsibility for the use of
|
|
|
|
this SOFTWARE. If SOFTWARE is modified to produce derivative works,
|
|
|
|
such modified SOFTWARE should be clearly marked, so as not to confuse
|
|
|
|
it with the version available from LANL.
|
|
|
|
*/
|
|
|
|
/* Copyright 2000, Ron Minnich, Advanced Computing Lab, LANL
|
|
|
|
* rminnich@lanl.gov
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
2008-01-18 16:08:58 +01:00
|
|
|
* C Bootstrap code for the coreboot
|
2003-04-22 21:02:15 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <console/console.h>
|
|
|
|
#include <version.h>
|
2003-04-24 08:25:08 +02:00
|
|
|
#include <device/device.h>
|
|
|
|
#include <device/pci.h>
|
2003-07-19 06:28:22 +02:00
|
|
|
#include <delay.h>
|
2004-10-14 22:54:17 +02:00
|
|
|
#include <stdlib.h>
|
2010-02-22 07:09:43 +01:00
|
|
|
#include <reset.h>
|
2009-04-22 10:17:38 +02:00
|
|
|
#include <boot/tables.h>
|
2003-04-22 21:02:15 +02:00
|
|
|
#include <boot/elf.h>
|
2009-04-14 09:40:01 +02:00
|
|
|
#include <cbfs.h>
|
2012-06-13 01:29:32 +02:00
|
|
|
#include <lib.h>
|
2009-06-30 17:17:49 +02:00
|
|
|
#if CONFIG_HAVE_ACPI_RESUME
|
2009-04-13 19:57:44 +02:00
|
|
|
#include <arch/acpi.h>
|
2009-04-14 08:38:15 +02:00
|
|
|
#endif
|
2009-10-26 18:04:28 +01:00
|
|
|
#include <cbmem.h>
|
Implement GCC code coverage analysis
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
|
|
|
#include <coverage.h>
|
2011-11-04 20:31:58 +01:00
|
|
|
#include <timestamp.h>
|
2003-04-22 21:02:15 +02:00
|
|
|
|
2004-12-03 23:39:34 +01:00
|
|
|
/**
|
2009-10-26 18:04:28 +01:00
|
|
|
* @brief Main function of the RAM part of coreboot.
|
2004-12-03 23:39:34 +01:00
|
|
|
*
|
2010-04-27 08:56:47 +02:00
|
|
|
* Coreboot is divided into Pre-RAM part and RAM part.
|
|
|
|
*
|
2004-12-03 23:39:34 +01:00
|
|
|
* Device Enumeration:
|
2010-04-27 08:56:47 +02:00
|
|
|
* In the dev_enumerate() phase,
|
2004-12-03 23:39:34 +01:00
|
|
|
*/
|
2009-04-13 19:57:44 +02:00
|
|
|
|
2009-10-27 15:29:29 +01:00
|
|
|
void hardwaremain(int boot_complete);
|
|
|
|
|
2003-04-22 21:02:15 +02:00
|
|
|
void hardwaremain(int boot_complete)
|
|
|
|
{
|
|
|
|
struct lb_memory *lb_mem;
|
Extend CBFS to support arbitrary ROM source media.
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-22 11:57:56 +01:00
|
|
|
void *payload;
|
2012-10-16 00:23:20 +02:00
|
|
|
|
|
|
|
timestamp_stash(TS_START_RAMSTAGE);
|
2011-04-11 22:17:22 +02:00
|
|
|
post_code(POST_ENTRY_RAMSTAGE);
|
2004-05-13 22:39:07 +02:00
|
|
|
|
Implement GCC code coverage analysis
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2012-12-19 01:23:28 +01:00
|
|
|
#if CONFIG_COVERAGE
|
|
|
|
coverage_init();
|
|
|
|
#endif
|
|
|
|
|
2009-10-26 18:04:28 +01:00
|
|
|
/* console_init() MUST PRECEDE ALL printk()! */
|
2003-04-22 21:02:15 +02:00
|
|
|
console_init();
|
2010-04-27 08:56:47 +02:00
|
|
|
|
2011-04-11 22:17:22 +02:00
|
|
|
post_code(POST_CONSOLE_READY);
|
2005-07-06 19:17:41 +02:00
|
|
|
|
2010-04-27 08:56:47 +02:00
|
|
|
printk(BIOS_NOTICE, "coreboot-%s%s %s %s...\n",
|
2008-01-18 16:08:58 +01:00
|
|
|
coreboot_version, coreboot_extra_version, coreboot_build,
|
2004-12-03 23:39:34 +01:00
|
|
|
(boot_complete)?"rebooting":"booting");
|
2003-04-22 21:02:15 +02:00
|
|
|
|
2011-04-11 22:17:22 +02:00
|
|
|
post_code(POST_CONSOLE_BOOT_MSG);
|
2003-04-22 21:02:15 +02:00
|
|
|
|
|
|
|
/* If we have already booted attempt a hard reboot */
|
|
|
|
if (boot_complete) {
|
|
|
|
hard_reset();
|
|
|
|
}
|
2004-03-23 22:28:05 +01:00
|
|
|
|
2004-10-16 08:20:29 +02:00
|
|
|
/* FIXME: Is there a better way to handle this? */
|
2010-04-27 08:56:47 +02:00
|
|
|
init_timer();
|
2003-04-22 21:02:15 +02:00
|
|
|
|
2012-10-16 00:23:20 +02:00
|
|
|
timestamp_stash(TS_DEVICE_ENUMERATE);
|
2012-07-25 10:33:05 +02:00
|
|
|
|
|
|
|
/* Initialize chips early, they might disable unused devices. */
|
|
|
|
dev_initialize_chips();
|
|
|
|
|
2004-11-04 12:04:33 +01:00
|
|
|
/* Find the devices we don't have hard coded knowledge about. */
|
2003-04-22 21:02:15 +02:00
|
|
|
dev_enumerate();
|
2011-04-11 22:17:22 +02:00
|
|
|
post_code(POST_DEVICE_ENUMERATION_COMPLETE);
|
2011-11-04 20:31:58 +01:00
|
|
|
|
2012-10-16 00:23:20 +02:00
|
|
|
timestamp_stash(TS_DEVICE_CONFIGURE);
|
2004-11-04 12:04:33 +01:00
|
|
|
/* Now compute and assign the bus resources. */
|
2003-04-22 21:02:15 +02:00
|
|
|
dev_configure();
|
2011-04-11 22:17:22 +02:00
|
|
|
post_code(POST_DEVICE_CONFIGURATION_COMPLETE);
|
2011-11-04 20:31:58 +01:00
|
|
|
|
2012-10-16 00:23:20 +02:00
|
|
|
timestamp_stash(TS_DEVICE_ENABLE);
|
2004-11-04 12:04:33 +01:00
|
|
|
/* Now actually enable devices on the bus */
|
2003-04-22 21:02:15 +02:00
|
|
|
dev_enable();
|
2012-08-07 22:14:20 +02:00
|
|
|
post_code(POST_DEVICES_ENABLED);
|
2011-11-04 20:31:58 +01:00
|
|
|
|
2012-10-16 00:23:20 +02:00
|
|
|
timestamp_stash(TS_DEVICE_INITIALIZE);
|
2004-11-04 12:04:33 +01:00
|
|
|
/* And of course initialize devices on the bus */
|
2003-04-22 21:02:15 +02:00
|
|
|
dev_initialize();
|
2012-08-07 22:14:20 +02:00
|
|
|
post_code(POST_DEVICES_INITIALIZED);
|
2003-04-22 21:02:15 +02:00
|
|
|
|
2012-10-16 00:23:20 +02:00
|
|
|
timestamp_stash(TS_DEVICE_DONE);
|
2012-04-24 16:01:24 +02:00
|
|
|
|
2009-10-26 18:04:28 +01:00
|
|
|
cbmem_initialize();
|
2011-09-30 20:16:49 +02:00
|
|
|
#if CONFIG_CONSOLE_CBMEM
|
|
|
|
cbmemc_reinit();
|
2009-04-13 19:57:44 +02:00
|
|
|
#endif
|
2012-10-16 00:23:20 +02:00
|
|
|
timestamp_sync();
|
2012-10-15 22:41:56 +02:00
|
|
|
|
|
|
|
#if CONFIG_HAVE_ACPI_RESUME
|
|
|
|
suspend_resume();
|
|
|
|
post_code(0x8a);
|
|
|
|
#endif
|
|
|
|
|
2012-05-10 21:15:18 +02:00
|
|
|
timestamp_add_now(TS_CBMEM_POST);
|
|
|
|
|
|
|
|
if (cbmem_post_handling)
|
|
|
|
cbmem_post_handling();
|
|
|
|
|
2011-11-04 20:31:58 +01:00
|
|
|
timestamp_add_now(TS_WRITE_TABLES);
|
|
|
|
|
2004-10-14 22:54:17 +02:00
|
|
|
/* Now that we have collected all of our information
|
|
|
|
* write our configuration tables.
|
|
|
|
*/
|
|
|
|
lb_mem = write_tables();
|
2011-11-04 20:31:58 +01:00
|
|
|
|
|
|
|
timestamp_add_now(TS_LOAD_PAYLOAD);
|
2012-06-13 01:29:32 +02:00
|
|
|
|
Extend CBFS to support arbitrary ROM source media.
Summary:
Isolate CBFS underlying I/O to board/arch-specific implementations as
"media stream", to allow loading and booting romstage on non-x86.
CBFS functions now all take a new "media source" parameter; use
CBFS_DEFAULT_MEDIA if you simply want to load from main firmware.
API Changes:
cbfs_find => cbfs_get_file.
cbfs_find_file => cbfs_get_file_content.
cbfs_get_file => cbfs_get_file_content with correct type.
CBFS used to work only on memory-mapped ROM (all x86). For platforms like ARM,
the ROM may come from USB, UART, or SPI -- any serial devices and not available
for memory mapping.
To support these devices (and allowing CBFS to read from multiple source
at the same time), CBFS operations are now virtual-ized into "cbfs_media". To
simplify porting existing code, every media source must support both "reading
into pre-allocated memory (read)" and "read and return an allocated buffer
(map)". For devices without native memory-mapped ROM, "cbfs_simple_buffer*"
provides simple memory mapping simulation.
Every CBFS function now takes a cbfs_media* as parameter. CBFS_DEFAULT_MEDIA
is defined for CBFS functions to automatically initialize a per-board default
media (CBFS will internally calls init_default_cbfs_media). Also revised CBFS
function names relying on memory mapped backend (ex, "cbfs_find" => actually
loads files). Now we only have two getters:
struct cbfs_file *entry = cbfs_get_file(media, name);
void *data = cbfs_get_file_content(CBFS_DEFAULT_MEDIA, name, type);
Test results:
- Verified to work on x86/qemu.
- Compiles on ARM, and follow up commit will provide working SPI driver.
Change-Id: Iac911ded25a6f2feffbf3101a81364625bb07746
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2182
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-22 11:57:56 +01:00
|
|
|
payload = cbfs_load_payload(CBFS_DEFAULT_MEDIA,
|
|
|
|
CONFIG_CBFS_PREFIX "/payload");
|
2012-06-13 01:29:32 +02:00
|
|
|
if (! payload)
|
|
|
|
die("Could not find a payload\n");
|
|
|
|
|
|
|
|
selfboot(lb_mem, payload);
|
|
|
|
printk(BIOS_EMERG, "Boot failed");
|
2003-04-22 21:02:15 +02:00
|
|
|
}
|
|
|
|
|