Al Boldi wrote:
So, what made OLPC switch from LinuxBIOS to OFW, and why can't the two projects be merged?
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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. - Jim
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?)
How much intelligence is actually needed to abstract the hardware enough for any system to be initialized? C is obviously not useful for an embedded system that could just write a table of registers into hardware.
I guess it's the old code reuse idea.
Perhaps I just reinvented OpenFirmware? And the v3 dts.
//Peter
On 04/05/07 04:31 +0200, Peter Stuge 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?)
How much intelligence is actually needed to abstract the hardware enough for any system to be initialized? C is obviously not useful for an embedded system that could just write a table of registers into hardware.
I guess it's the old code reuse idea.
Perhaps I just reinvented OpenFirmware? And the v3 dts.
ding!
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.
There's no clear answer yet.
ron
On Thu, May 03, 2007 at 09:01:05PM -0600, Jordan Crouse wrote:
Perhaps I just reinvented OpenFirmware? And the v3 dts.
ding!
=)
On Thu, May 03, 2007 at 08:17:57PM -0700, ron minnich wrote:
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.
Yep.
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.
Yes, but it's still register writes. The functions are just more complex.. Hm. VHDL could work.
I'm thinking out loud while rebalancing the high level design tree. Sorry about the noise.
A netlist and BOM is really all that is needed, right? It would indeed be awesome to generate a BIOS that way.
It's not a BIOS anymore. It's hardware init with an OS starter; the HIOS. Remember where you heard it first. ;)
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.
There would be high level SPD functions.
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.
Oh yes, it's overkill but it's the best HAL I know.
And, as Jordan pointed out, things can fall apart when some of these constants change.
Yes, for that macro thing to work only chip constants would be constant. :)
There's no clear answer yet.
Nope, but it sure is an interesting problem.
//Peter
Jim Gettys wrote:
Al Boldi wrote:
So, what made OLPC switch from LinuxBIOS to OFW, and why can't the two projects be merged?
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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.
I suppose this was done by relying on the ACPI tables?
And, wouldn't it make sense for LinuxBIOS and OFW to join forces?
Thanks!
-- Al
* Al Boldi a1426z@gawab.com [070504 06:38]:
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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.
I suppose this was done by relying on the ACPI tables?
No, no ACPI involved. ACPI is far too slow and broken to do the task. It's a mixture between the Open Firmware device tree and FCode. Reinvented poorly.
And, wouldn't it make sense for LinuxBIOS and OFW to join forces?
Definitely. This is already happening - There is a GSoC project (going to be done by Jens Freimann) to get a better integration between OFW and LB done.
Stefan
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [070504 06:38]:
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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.
I suppose this was done by relying on the ACPI tables?
No, no ACPI involved.
Not even the init tables ACPI depends on?
ACPI is far too slow and broken to do the task. It's a mixture between the Open Firmware device tree and FCode. Reinvented poorly.
You mean ACPI was reinvented poorly?
And, wouldn't it make sense for LinuxBIOS and OFW to join forces?
Definitely. This is already happening - There is a GSoC project (going to be done by Jens Freimann) to get a better integration between OFW and LB done.
I was more thinking of merging the projects; or is there an advantage of keeping them separate?
Thanks!
-- Al
* Al Boldi a1426z@gawab.com [070504 14:02]:
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [070504 06:38]:
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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.
I suppose this was done by relying on the ACPI tables?
No, no ACPI involved.
Not even the init tables ACPI depends on?
What init tables?
No, OLPC uses no ACPI.
Definitely. This is already happening - There is a GSoC project (going to be done by Jens Freimann) to get a better integration between OFW and LB done.
I was more thinking of merging the projects; or is there an advantage of keeping them separate?
This is like merging the Linux kernel and glibc. They're doing different stuff.
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [070504 14:02]:
Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [070504 06:38]:
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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.
I suppose this was done by relying on the ACPI tables?
No, no ACPI involved.
Not even the init tables ACPI depends on?
What init tables?
I think they are called something like DST...
You know, the one part in any legacy BIOS.
No, OLPC uses no ACPI.
So they probably have their own tables?
Definitely. This is already happening - There is a GSoC project (going to be done by Jens Freimann) to get a better integration between OFW and LB done.
I was more thinking of merging the projects; or is there an advantage of keeping them separate?
This is like merging the Linux kernel and glibc. They're doing different stuff.
But, I thought OFW is a BIOS replacement and more. No? Does OLPC still depend on LinuxBIOS? Or on some other BIOS. The picture isn't clear.
Thanks!
-- Al
On Fri, May 04, 2007 at 03:02:32PM +0300, Al Boldi wrote:
ACPI is far too slow and broken to do the task. It's a mixture between the Open Firmware device tree and FCode. Reinvented poorly.
You mean ACPI was reinvented poorly?
Yes, I'm pretty sure that's what Stefan meant ;)
And, wouldn't it make sense for LinuxBIOS and OFW to join forces?
Definitely. This is already happening - There is a GSoC project (going to be done by Jens Freimann) to get a better integration between OFW and LB done.
I was more thinking of merging the projects; or is there an advantage of keeping them separate?
I doubt that you'll be able to or want to _merge_ them. They're totally different with different design, different programming language etc. etc.
What is very well possible, though, is to improve interoperability, and to use good ideas and concepts from OFW to enhance LinuxBIOS, and vice versa.
Even code sharing might be possible to a certain degree (the licenses are compatible, IIRC), but completely _merging_ the projects is not realistic, IMO.
Uwe.
Uwe Hermann wrote:
On Fri, May 04, 2007 at 03:02:32PM +0300, Al Boldi wrote:
I was more thinking of merging the projects; or is there an advantage of keeping them separate?
I doubt that you'll be able to or want to _merge_ them. They're totally different with different design, different programming language etc. etc.
What is very well possible, though, is to improve interoperability, and to use good ideas and concepts from OFW to enhance LinuxBIOS, and vice versa.
Even code sharing might be possible to a certain degree (the licenses are compatible, IIRC), but completely _merging_ the projects is not realistic, IMO.
It sounds to me that OFW is a pluggable Firmware Framework, which means that it is LinuxBIOS and more.
What can LinuxBIOS do OFW can't?
Thanks!
-- Al
* Al Boldi a1426z@gawab.com [070504 16:08]:
It sounds to me that OFW is a pluggable Firmware Framework, which means that it is LinuxBIOS and more.
What can LinuxBIOS do OFW can't?
Hypertransport setup and memory init on K8. It could be done, but it would be a lot harder.
On Fri, 2007-05-04 at 10:01 +0200, Stefan Reinauer wrote:
- Al Boldi a1426z@gawab.com [070504 06:38]:
Mitch wrote a fast path resume from RAM for the OLPC Geode hardware. 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.
I suppose this was done by relying on the ACPI tables?
No, no ACPI involved. ACPI is far too slow and broken to do the task.
Yes, no ACPI, and when we did have ACPI, it was clearly too slow for our needs. Without even doing significant performance work, the system now resumes from RAM in about 160ms, and Jordan believes the hardware will let us do about 63ms. Gotta get the B3 build done before we'll have time to do any serious performance work.
It's a mixture between the Open Firmware device tree and FCode. Reinvented poorly.
I don't think this is what Mitch did. However, it is quite Geode/OLPC specific. As I said, it's a fixed configuration system, with known hardware; very different than most systems. - Jim
And, wouldn't it make sense for LinuxBIOS and OFW to join forces?
Definitely. This is already happening - There is a GSoC project (going to be done by Jens Freimann) to get a better integration between OFW and LB done.
Stefan
* Jim Gettys jg@laptop.org [070504 18:51]:
It's a mixture between the Open Firmware device tree and FCode. Reinvented poorly.
I don't think this is what Mitch did. However, it is quite Geode/OLPC specific. As I said, it's a fixed configuration system, with known hardware; very different than most systems.
Oh, sorry, that was not what I intended to say. I was referring to ACPI. Mitch's work is great, no doubt!
Stefan
On Fri, May 04, 2007 at 12:51:14PM -0400, Jim Gettys wrote:
the system now resumes from RAM in about 160ms
I get really angry when I think about contemporary laptops.
Maybe there's actually a good product to be found somewhere in Asia?
I can only hope that OLPC will help educate not only children in developing countries but also sadly misinformed professionals all over the world so that they will stop buying junk and demand higher quality when they understand what modern hardware can do.
Dell will still sell $500 toys of course, but perhaps a $4000 model will actually be better than the toy then.
Will stop now before I get too cynical.
//Peter
-
Al Boldi -
Jim Gettys -
Jordan Crouse -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Uwe Hermann