[coreboot] coreboot work

[Aaron Durbin]

Hi Folks,

Some of you may know I have lots of ideas floating around in my head
for technical changes within coreboot. I'd like to layout many of
those ideas so that 1. it's written down 2. people can discuss the
merit. I plan on pursuing each of these changes, but I am not sure in
what way (personal playground?). Many of these proposed may be
x86-centric at first glance, but I feel that is reflective of the
current code base. Solving some of the generic/infrastructure issues
inherently will impact x86 systems. Also note that some of these ideas
aren't fully fleshed out, however I believe the underlying problems
still need to be addressed in some form.

Availability Features/Subsystems

There is currently quite a bit of code using macro guards around code
based on __PRE_RAM__, for example, to imply what stage a compilation
unit is being compiled for. While some of these heuristics may have
been true in the past it's definitely not true any longer --
especially with the introduction of coreboot supporting some of the
ARM SoC's. However, here is also a runtime component to feature
availability -- not just static or compile time.

Kyösti Mälkki has started to address the compile-time component:
http://review.coreboot.org/#/c/5410/  I think we should take it
further by having notions of "has devicetree", for example. The
runtime notion of availability of features is also important. Trying
to unify romstage (see below) will rely on having common points that
can be used to piggy back infrastructure changes. To that end a
construct of "mode" seems logical. The mode of the system would
include current stage as well as features (read: flags). During the
process of booting flags would be turned on triggering action. For
example, after main memory is available that flag would be flipped and
action could thus be taken (setting up cbmem, e.g.). The notion of "is
this boot a resume boot?" comes to mind as well.

On an ABI change front, I think it's important to pass this
information on the next corresponding change (romstage -> ramstage,
e.g.). x86's bootblock would not have such a notion since it currently
has no memory to work with. Passing information directly to the next
stage will provide direct dissemination of previous knowledge (e.g.
where is cbmem?).

Taming the Wild West of Romstage

Many people who have ventured into making changes that impact romstage
may know that there isn't a consistent framework/path. On x86, the
entry point is typically some assembly code that sets up cache-as-ram
then calls into a chipset specific C code. Memory is trained, cbmem is
brought up, exit back to assembly, cache-as-ram is torn down, then
call back into C code to locate and load ramstage. All of that
typically happens within the confines of a chipset. That means when
needing to make changes to APIs and/or assumptions in the
infrastructure the task is very high-touch affecting quite many
boards. On the other side of the spectrum the ARM SoCs have their own
romstage paths that sit entirely in C code. Thus, I think it's
important to solidify on a consistent API for booting through romstage
like we have for ramstage. It wouldn't be like ramstage's
hardwaremain.c, but it would provide a set of functions that should be
called/implemented.  Extending that concept further, the same
constructs could be employed on more forgiving architectures'
bootblock code.

Q: What about such and such? It doesn't do things like that.
A: I think we need to start conforming boards/chipsets into using the
common infrastructure. It should provide consistency as well easier
development cost in the long run for code changes.

x86-specific Romstage Changes

The above changes to romstage flow could be quite a big change for
each chipset transitioning over. However, there's a lot of duplication
w.r.t. setting up MTRRs and obtaining the stack location after
cache-as-ram is torn down. A set of common functions should be
introduced to manage the MTRRs and choosing stack location. This
approach is utilized in the haswell and baytrail code although the
code is essentially duplicated. Either through C code or some common
assembler the new stack would be processed after tearing down
cache-as-ram to initialize the new MTRR values and enable caching.

What makes this work even more worthwhile is the carrot dangling in
front of us at this point. Utilizing Ron Minnich's paging work
(http://review.coreboot.org/5354) we can get rid of CAR_GLOBAL. The
objects placed in CAR_GLOBAL currently would just live in the BSS
section. Just before tearing down cache-as-ram that region would be
copied into memory and page tables would be set up to map the address
space occupied by cache-as-ram to point to memory. All other physical
regions are identity mapped. The implication is that cache-as-ram is
not a first class citizen that always needs to be thought about.

However, that does require that x86 systems that utilize cache-as-ram
need tp set up cbmem, but that's not too bad because that assumption
was already being carried with some of the romstage unification.
Removing CAR_GLOBAL should allow for having a richer (or maybe not as
clumsy) APIs within the core infrastructure. Currently, x86 is holding
other architectures back in this regard.

x86 Assumptions

It's not surprising that there are some x86-isms that have crept into
the core components/libraries. One of the main issues that has been
talked about as of late is the access pattern and APIs surrounding
CBFS access patterns. The good news on that front is that there is a
GSoC proposal to attack that problem. To take that one step further
the medium on which CBFS resides can be used for other purposes aside
from CBFS. ChromeOS devices very much use this: memory training data,
event log, and verified boot. The regions patch
(http://review.coreboot.org/5394), as implemented, is a first-pass at
not just rectifying CBFS access patterns but also providing an
abstraction to the underlying medium into a single interface. That
allowed for a unified way to access the SPI flash. One of the nicer
things the regions support allows is to easily ship in-memory CBFS
updates as well as have the ability to carve out subregions while
still utilizing the underlying medium-access implementation.

Path Forward

I plan on working on the above things with a few boards. I have
haswell and baytrail boards. I should be getting some cubie
paraphernalia this week to have both an x86 and arm environment. Yes,
some of the proposals are somewhat soft and fluffy so there will be
some exploration involved, but most of these things are quite doable
in a small amount of time. Stealing Patrick's word, the hard part will
be "dragging" other systems forward.

Thanks for your time.

-Aaron