H Aaron, On Wed, Apr 2, 2014 at 1:30 PM, Aaron Durbin <[email protected]> wrote: > 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?). >
This sounds good. Since CBFS and coreboot stage loading is basicly elf based, we could support standard argument passing, for example: --cbmem 0x<cbmem_address>. This would allow different architectures pass some specific data as well as generic or common data. Could this be useful for a payload that accepts command line options. Is this a good idea? > 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. > All great points. I agree with the needs that you have identified. I think that we should have an unstable development branch where this work is done. I expect that there could be a lot of breakage with these changes. We should still use gerrit and jenkins to maintain the process and inform us of the general health of the branch. Marc -- http://se-eng.com -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
