Hi Folks,
I just wanted to point out to people that I posted changes to make the boot flow more flexible:
http://review.coreboot.org/3131 http://review.coreboot.org/3132 http://review.coreboot.org/3133 http://review.coreboot.org/3134 http://review.coreboot.org/3135 http://review.coreboot.org/3136 http://review.coreboot.org/3137 http://review.coreboot.org/3138 http://review.coreboot.org/3139
The reason for these changes stems from dependency requirements on newer machines that don't closely follow the device tree and pci device ordering. However, there are other benefits such as dynamically deciding to perform something at a given time during the boot sequence as well as not introducing board-specific calls throughout the common code. The patches provide usage examples by some of the core pieces of code.
There is something else I've been thinking about and working on is the ability to schedule work based on time. Ron had introduced a microsecond global timer. There is also a desire on my part to utilize this concept so that the boot flow isn't busy waiting on something that takes a long time. I have the timer scheduler written, but it requires global time source. On x86 this is quite complicated in that there appears to be quite a few (> 3?) implementations of the udelay() function. The timer scheduler would integrate into the boot state machine above by running the timers between states. Additionally, the concept of blocking state entry when timers are queued. That concept would provide a sequence point for not proceeding further than necessary until all work is drained.
I wanted to get people's thoughts on these concepts. I think I can push off the introduction of the timer scheduler by just delaying work using the boot state machine. However, I'm not sure what other people's needs are.
Thanks.
-Aaron
-
Aaron Durbin