[coreboot-gerrit] Change in coreboot[master]: Documentation: Add design doc on revising our stages

[Patrick Georgi (Code Review)]

Patrick Georgi has uploaded a new change for review. ( https://review.coreboot.org/19266 )

Change subject: Documentation: Add design doc on revising our stages
......................................................................

Documentation: Add design doc on revising our stages

Change-Id: Ie25a2dc5cc45064cd69f8a0641eabfe8159ac08e
Signed-off-by: Patrick Georgi <pgeorgi at chromium.org>
---
A Documentation/technotes/2017-04-reconsidering-ramstage.md
1 file changed, 76 insertions(+), 0 deletions(-)


  git pull ssh://review.coreboot.org:29418/coreboot refs/changes/66/19266/1

diff --git a/Documentation/technotes/2017-04-reconsidering-ramstage.md b/Documentation/technotes/2017-04-reconsidering-ramstage.md
new file mode 100644
index 0000000..28fbf7c
--- /dev/null
+++ b/Documentation/technotes/2017-04-reconsidering-ramstage.md
@@ -0,0 +1,76 @@
+Reconsidering ramstage
+======================
+Initially the ramstage was added to coreboot to bring the system into a state
+where Linux can take over, because some initialization wasn't done by Linux
+itself.
+
+Over time, it grew to provide a more-and-more complete booted environment, and
+there were discussions over many of these features and where exactly to draw
+the boundaries.
+
+One - admittedly rather aggressive - proposal to deal with it is to remove
+ramstage altogether. Since many payloads expect the setup that ramstage
+offers, it could be moved to libpayload, so that payloads can choose to pick
+the ramstage services they need "a la carte", and for payloads that can't make
+use of that for one reason or another, a simple intermediate payload should be
+feasible that builds a ramstage-alike from the libpayload pieces and then
+loads the real payload.
+
+The goal of this effort is to provide a clearer boundary for coreboot's
+responsibility, namely getting RAM initialized and executing the next stage;
+provide more flexibility for embedded tasks by allowing developers to pick and
+choose the features they need without heaping more and more Kconfig options
+into coreboot; enable more complex scenarios, such as parallel initialization
+of hardware, without burdening coreboot with that complexity.
+
+libpayload would act as repository for common late-stage initialization
+code, which might make it easier to reuse for other projects as well.
+
+End result
+----------
+The end result is a coreboot build that ends with romstage, directly loading
+the payload into the newly available RAM, eliminating one of the
+synchronizations points in our boot process that every coreboot-based firmware
+project needs to design around (eg. when implementing multithreading or when
+passing data around between stages).
+
+How to get there
+----------------
+The following steps might serve as guidelines how to make such an effort work.
+
+### Allowing loading payload from romstage
+Instead of loading the ramstage at the end of romstage, optionally allow
+directly loading the payload. If it's capable of its own initialization, we
+could bypass the entire ramstage stage.
+There are reports that such an approach works for Linux-as-payload, and it's
+feasible that a Tianocore payload could be made to work with little effort,
+too.
+The goal here is first, to add an option that makes romstage load the payload
+and test that.
+
+After that, all ramstage handling in the build system
+(building, linking, adding) could depend on this option being disabled.
+
+### Make libpayload part of the coreboot build
+Prepare libpayload to be linkable into ramstage. This should also eliminate
+some code duplication.
+
+### Move components over to libpayload
+x86emu, used for VGA init on some devices, should be an example of a
+well-isolated component that can be moved out of coreboot and into libpayload.
+Since ramstage still calls it from there, nothing changes for current
+payloads.
+Wash, rinse, repeat with more components.
+
+### Move ramstage into a payload
+When (most) everything is brought over, create a stub payload that executes
+the code added to libpayload in the same way it's now run from ramstage.
+Some of this can probably be done in little steps, shaving off components off
+the end of ramstage, moving them into the payload (that is used by default).
+
+Once done, this payload could be built by default if the Kconfig option for
+"no-ramstage" that was introduced in the beginning is not set.
+
+### Adapt payloads
+While ramstage is ported into libpayload, external payloads could start to
+make use of libpayload incrementally.

-- 
To view, visit https://review.coreboot.org/19266
To unsubscribe, visit https://review.coreboot.org/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie25a2dc5cc45064cd69f8a0641eabfe8159ac08e
Gerrit-PatchSet: 1
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Owner: Patrick Georgi <pgeorgi at google.com>