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