On 5/3/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Thu, May 03, 2007 at 05:55:39PM -0400, Jim Gettys wrote:
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware.
The fastest path is obviously attractive also in LinuxBIOS.
Once you've done that, you find that you've done just about everything to initialize the hardware in the first place; so that code is now used both at boot time and at suspend from RAM time.
This is an interesting observation.
Perhaps all chip init would best be written in some macro language? (one specific for the task?)
We've talked about this. It only really works on OLPC because OLPC is so incredibly simple. Add an opteron of the type that stefan used to port to -- variable number of CPUs, 31 PCI busses, etc. etc. -- and it's a bit harder.
Also, let's pretend that someday there is an OLPC with SPD. The problem starts to get ugly again as you add back in SMBUS support, etc. etc. -- all that stuff that linuxbios can do pretty well.
I also still believe, having watched how things played out, that I want linux as my bios. Nothing in what I have seen on OLPC changes my belief, and some things that have happened on OLPC strongly confirm it.
Again, the OLPC code can be found at openbios.org, it's pretty trivial, and works mainly because the OLPC hardware has hardcoded dram timing, etc. etc. And, as Jordan pointed out, things can fall apart when some of these constants change.
Heh. Accusing a Geode as being "simple" is a false accusation.... Rather...
As Ron points out, with the exception of SD and USB (at fixed locations), the XO-1 is a *fixed configuration* system.
There are additional complications. Since fast resume is *so* important to us, we are sometimes going to initialize hardware in OFW early in resume, so that Linux PM will not have to start the process and then wait (or wait as long) to be able to complete hardware re-initialization of that particular device.
Mark Foster described (at the Power management summit a year ago) a more general scheme for paralleling initialization using tables and data structures. Something like that might be adaptable enough for more complex systems: but that isn't what's been implemented here; we haven't needed to do so. Regards, - Jim