GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/src/include/bootstate.h

203 lines
6.1 KiB
C
Raw Normal View History

ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2013 Google, Inc.
*
* 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.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef BOOTSTATE_H
#define BOOTSTATE_H
bootstate: don't use header in romstage code Change-Id: I0c2943bb0889552dc384d8efb5226cd6982a4d81 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/6663 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-08-14 19:23:41 +02:00
#if !defined(__SMM__) && !defined(__PRE_RAM__)
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
#include <string.h>
bootstate: use structure pointers for scheduling callbacks The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-16 23:30:09 +01:00
#include <stdlib.h>
#include <stddef.h>
#include <stdint.h>
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
/* Control debugging of the boot state machine. */
#define BOOT_STATE_DEBUG 0
/*
* The boot state machine provides a mechanism for calls to be made through-
* out the main boot process. The boot process is separated into discrete
* states. Upon a state's entry and exit and callbacks can be made. For
* example:
*
* Enter State
* +
* |
* V
* +-----------------+
* | Entry callbacks |
* +-----------------+
* | State Actions |
* +-----------------+
* | Exit callbacks |
* +-------+---------+
* |
* V
* Next State
*
* Below is the current flow from top to bottom:
*
* start
* |
* BS_PRE_DEVICE
* |
* BS_DEV_INIT_CHIPS
* |
* BS_DEV_ENUMERATE
* |
* BS_DEV_RESOURCES
* |
* BS_DEV_ENABLE
* |
* BS_DEV_INIT
* |
* BS_POST_DEVICE
* |
* BS_OS_RESUME_CHECK -------- BS_OS_RESUME
* | |
* BS_WRITE_TABLES os handoff
* |
* BS_PAYLOAD_LOAD
* |
* BS_PAYLOAD_BOOT
* |
* payload run
*
* Brief description of states:
* BS_PRE_DEVICE - before any device tree actions take place
* BS_DEV_INIT_CHIPS - init all chips in device tree
* BS_DEV_ENUMERATE - device tree probing
* BS_DEV_RESOURCES - device tree resource allocation and assignment
* BS_DEV_ENABLE - device tree enabling/disabling of devices
* BS_DEV_INIT - device tree device initialization
* BS_POST_DEVICE - all device tree actions performed
* BS_OS_RESUME_CHECK - check for OS resume
* BS_OS_RESUME - resume to OS
* BS_WRITE_TABLES - write coreboot tables
* BS_PAYLOAD_LOAD - Load payload into memory
* BS_PAYLOAD_BOOT - Boot to payload
*/
typedef enum {
BS_PRE_DEVICE,
BS_DEV_INIT_CHIPS,
BS_DEV_ENUMERATE,
BS_DEV_RESOURCES,
BS_DEV_ENABLE,
BS_DEV_INIT,
BS_POST_DEVICE,
acpi: split resume check and actual resume code It's helpful to provide a distinct state that affirmatively describes that OS resume will occur. The previous code included the check and the actual resuming in one function. Because of this grouping one had to annotate the innards of the ACPI resume path to perform specific actions before OS resume. By providing a distinct state in the boot state machine the necessary actions can be scheduled accordingly without modifying the ACPI code. Change-Id: I8b00aacaf820cbfbb21cb851c422a143371878bd Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3134 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-25 05:33:08 +02:00
BS_OS_RESUME_CHECK,
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
BS_OS_RESUME,
BS_WRITE_TABLES,
BS_PAYLOAD_LOAD,
BS_PAYLOAD_BOOT,
} boot_state_t;
/* The boot_state_sequence_t describes when a callback is to be made. It is
* called either before a state is entered or when a state is exited. */
typedef enum {
BS_ON_ENTRY,
BS_ON_EXIT
} boot_state_sequence_t;
struct boot_state_callback {
void *arg;
void (*callback)(void *arg);
/* For use internal to the boot state machine. */
struct boot_state_callback *next;
#if BOOT_STATE_DEBUG
const char *location;
#endif
};
#if BOOT_STATE_DEBUG
#define BOOT_STATE_CALLBACK_LOC __FILE__ ":" STRINGIFY(__LINE__)
#define BOOT_STATE_CALLBACK_INIT_DEBUG .location = BOOT_STATE_CALLBACK_LOC,
#define INIT_BOOT_STATE_CALLBACK_DEBUG(bscb_) \
bscb_->location = BOOT_STATE_CALLBACK_LOC;
#else
#define BOOT_STATE_CALLBACK_INIT_DEBUG
#define INIT_BOOT_STATE_CALLBACK_DEBUG(bscb_)
#endif
#define BOOT_STATE_CALLBACK_INIT(func_, arg_) \
{ \
.arg = arg_, \
.callback = func_, \
.next = NULL, \
BOOT_STATE_CALLBACK_INIT_DEBUG \
}
#define BOOT_STATE_CALLBACK(name_, func_, arg_) \
struct boot_state_callback name_ = BOOT_STATE_CALLBACK_INIT(func_, arg_)
/* Initialize an allocated boot_state_callback. */
#define INIT_BOOT_STATE_CALLBACK(bscb_, func_, arg_) \
INIT_BOOT_STATE_CALLBACK_DEBUG(bscb_) \
bscb_->callback = func_; \
bscb_->arg = arg_
/* The following 2 functions schedule a callback to be called on entry/exit
include: Fix spelling Change-Id: Iadc813bc8208278996b2b1aa20cfb156ec06fac9 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3755 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10 05:46:01 +02:00
* to a given state. Note that there are no ordering guarantees between the
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
* individual callbacks on a given state. 0 is returned on success < 0 on
* error. */
int boot_state_sched_on_entry(struct boot_state_callback *bscb,
boot_state_t state);
int boot_state_sched_on_exit(struct boot_state_callback *bscb,
boot_state_t state);
bootstate: use structure pointers for scheduling callbacks The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-16 23:30:09 +01:00
/* Schedule an array of entries of size num. */
struct boot_state_init_entry;
void boot_state_sched_entries(struct boot_state_init_entry *entries,
size_t num);
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
boot state: add ability to block state transitions In order to properly sequence the boot state machine it's important that outside code can block the transition from one state to the next. When timers are not involved there's no reason for any of the existing code to block a state transition. However, if there is a timer callback that needs to complete by a certain point in the boot sequence it is necessary to place a block for the given state. To that end, 4 new functions are added to provide the API for blocking a state. 1. boot_state_block(boot_state_t state, boot_state_sequence_t seq); 2. boot_state_unblock(boot_state_t state, boot_state_sequence_t seq); 3. boot_state_current_block(void); 4. boot_state_current_unblock(void); Change-Id: Ieb37050ff652fd85a6b1e0e2f81a1a2807bab8e0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3204 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-06 17:50:19 +02:00
/* Block/Unblock the (state, seq) pair from transitioning. Returns 0 on
* success < 0 when the phase of the (state,seq) has already ran. */
int boot_state_block(boot_state_t state, boot_state_sequence_t seq);
int boot_state_unblock(boot_state_t state, boot_state_sequence_t seq);
/* Block/Unblock current state phase from transitioning. */
void boot_state_current_block(void);
void boot_state_current_unblock(void);
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
/* Entry into the boot state machine. */
Rename hardwaremain() to main() ... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-10 01:30:06 +02:00
void main(void);
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
boot state: schedule static callbacks Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 23:12:52 +02:00
/* In order to schedule boot state callbacks at compile-time specify the
* entries in an array using the BOOT_STATE_INIT_ENTRIES and
* BOOT_STATE_INIT_ENTRY macros below. */
struct boot_state_init_entry {
boot_state_t state;
boot_state_sequence_t when;
struct boot_state_callback bscb;
};
#define BOOT_STATE_INIT_ATTR __attribute__ ((used,section (".bs_init")))
bootstate: use structure pointers for scheduling callbacks The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-16 23:30:09 +01:00
#define BOOT_STATE_INIT_ENTRY(state_, when_, func_, arg_) \
static struct boot_state_init_entry func_ ##_## state_ ##_## when_ = \
{ \
.state = state_, \
.when = when_, \
.bscb = BOOT_STATE_CALLBACK_INIT(func_, arg_), \
}; \
static struct boot_state_init_entry * \
bsie_ ## func_ ##_## state_ ##_## when_ BOOT_STATE_INIT_ATTR = \
& func_ ##_## state_ ##_## when_;
boot state: schedule static callbacks Many of the boot state callbacks can be scheduled at compile time. Therefore, provide a way for a compilation unit to inform the boot state machine when its callbacks should be called. Each C module can export the callbacks and their scheduling requirements without changing the shared boot flow code. Change-Id: Ibc4cea4bd5ad45b2149c2d4aa91cbea652ed93ed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3133 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 23:12:52 +02:00
bootstate: don't use header in romstage code Change-Id: I0c2943bb0889552dc384d8efb5226cd6982a4d81 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/6663 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-08-14 19:23:41 +02:00
#endif
ramstage: introduce boot state machine The boot flow currently has a fixed ordering. The ordering is dictated by the device tree and on x86 the PCI device ordering for when actions are performed. Many of the new machines and configurations have dependencies that do not follow the device ordering. In order to be more flexible the concept of a boot state machine is introduced. At the boundaries (entry and exit) of each state there is opportunity to run callbacks. This ability allows one to schedule actions to be performed without adding board-specific code to the shared boot flow. Change-Id: I757f406c97445f6d9b69c003bb9610b16b132aa6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3132 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-24 22:14:01 +02:00
#endif /* BOOTSTATE_H */