Yestereday Jordan wrotee
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.
------------------
From Martin
Too right. This is one of those ideas which is thrown off kind of light-heartedly but is actually crucual.
(a) Of all the posts here, I'd guess that more than half (to my inexpert and untutored eye) are about initiialising this processor/RAM chunk/other piece of hardware or that one.
(b) My young (12-year-old) friend is leaning to program in that variety of C that's around now, what's its name can't remember? but anyway, he's written < Hello Word > of course, and it starts with more than a page of <inits> before we get down to the couple of lines of code which actually put "Hello World" in a nice little box on the screen :
(c) Even when I was writing in Borland C all those years ago, the same was true (only not quite as badly as it is now, since we didn't have a huge variety of components to deal with.).
------
So, yes, of course we should have a separate, small macro langage for initialising chunks of hardware, it would only take half an hour to learn it; and yes, every component manufacturer should agree on this same maro language and simply make available the necessary sequence of macros for every piece of hardware they make, so the prgram writers can just slam it into the front of any chunk of software they're constructing.
I know that to somo extent this happens already, but I don't think it goes nearly far enough, to judge by the sequences of posts I see here discussing how to use one peice of hardware or another?
---- What should happen ---- it seems to my ancient mind --- is that the programmer should merely write a series of in a form such as :
processor=xxxxx primaryRAM= yyyyy videochip=zzzzz etc etc
--- and so forth, for whatever components are known to have the need to be handled,
-- and the COMPILER then automatically inserts the necessary sequence(s) of macros known to be needed to "initialise" xxxxx, yyyyy and zzzzz, whatever they are?
Could this not work? What are the possible snags?
Of course everybody would have to agree upon, and learn, and then use, the same macro language, but I don't see that as insuperable? OK, it's another piece of stuff to learn, but we have to do that all the time, and this particular piece would save a whole lot of other learning.
Maybe we should ask old Linus to put it together?
Cheers, Martin
On Fri, May 04, 2007 at 10:01:49AM +0100, MARTIN WOODHOUSE wrote:
processor=xxxxx primaryRAM= yyyyy videochip=zzzzz etc etc
[..]
Could this not work?
Yes. This macro principle is actually already used in the current version of LinuxBIOS v2 and the tools and language have been improved a lot for the next version. (new syntax but same good concept) What I was rambling about yesterday was what kind of code the macro language generates, for performance reasons.
We still have more code than just register writes, and that will probably continue to be the case for systems supporting dynamic configuration.
What are the possible snags?
Mainly two things;
* Dynamic hardware configurations Optional CPU, RAM or expansion slots need to be detected at startup and initialized only if they are filled with something.
* Mainboard vendor configurations There's not a single standard way for a mainboard vendor to connect all the hardware together on the board. The initializing software in most cases needs to know some hardware design detail or other.
//Peter
On 5/4/07, MARTIN WOODHOUSE hokusai@btinternet.com wrote:
---- What should happen ---- it seems to my ancient mind --- is that the programmer should merely write a series of in a form such as :
processor=xxxxx primaryRAM= yyyyy videochip=zzzzz etc etc
--- and so forth, for whatever components are known to have the need to be handled,
speaking of reinvention ... this is LinuxBIOS V1 :-)
But ...
The primaryRAM idea won't work. RAM can move around, be at different CPUs, and so on. It's totally dynamic. The timing is dynamic. The bugs are dynamic. The videochip idea won't work either. Yes, this problem seems that simple but, no, it's not nearly that simple. Dealing with this complexity is what has driven LinuxBIOS to its current complex form.
The best you can do, for real hardware, is to give the code some hints. This set of hints then turns into a sea of conditionals at runtime: you may or may not have all the CPUs, memory may only be on one CPU, the video may be on CPU 0 or CPU 1 (as in Sun ultra 40), and so on. Some parts have bugs, so you have to build in the workarounds. Some mainboards have bugs-by-design, so you may have all the chips you want, but you still need to fit in those mainboard bugs. And on and on ...
And that's why, there is a V2. Because around 2002 or so the hardware got very complex, and much more work needed to be done at runtime, and the structure of functions and the order in which they were called got pretty messy.
As to this OFW and LinuxBIOS discussion: LinuxBIOS is designed to load an OS from FLASH, no more and no less. To the maximum extent possible, LinuxBIOS avoids drivers, file systems, network protocol stacks, web servers, icons, GUIs, video displays, and so on. There is a reason for this: I have seen, over the years, that BIOSes tend to do a poor job of supporting hardware; conversely, OSes like Linux do a very good job. Hence the original design goal of LinuxBIOS: to facilitate placing a Linux image in FLASH, and using Linux as the BIOS. Hence the name.
In fact, in the early days, we did not consider what we now call "LinuxBIOS" as separate from a Linux kernel. The payload was always Linux. The only thing that required the seperation, eventually, was the small FLASH sizes and the Linux kernel bloat.
OFW is also an OS, really like Linux in a way. In fact, OFW is much more like Linux than it is like LinuxBIOS. It has drivers, file systems, console interaction, network protocol drivers and stacks (and now, even an 802.11 stack and OFW supplicant), a simple GUI, icons, interrupt support (in some versions), etc. etc. Some implementations have had threads and/or processes. OFW seems to really want that console interaction -- the standard fallback is an 'ok' prompt. In many situations, however, console interaction is impossible, which has been an issue with clusters I have built based on OFW-based systems (i.e. SPARCs).
That's one reason that LinuxBIOS is <32K, and OFW is 32K*10 -- even on a trivial platform like OLPC. OFW does a lot more. The extra capability of OFW makes it very powerful, and that is both a strength and a weakness.
There are two things that OFW does that I am uncomfortable with. The first and most important is, as mentioned: it has lots of drivers. If you are planning to run, e.g., OFW AND Linux on new hardware, you now have doubled the task of writing drivers: you get to write BOTH Linux and OFW drivers. Now, people tell me all the time that drivers are easy. Generally, these are people who are either really good at writing drivers, or who have never had to wring the last almost-never-happen bugs out of a driver. It is true that the first iteration of a driver is pretty easy. What makes them miserable is managing all the corner cases and hardware bugs and only-happens-once-in-100 million iterations bugs. So, for example, one of my OLPC units will still not talk to ANY of my flash sticks ... from OFW. From Linux, these flash sticks work fine -- and always have. They worked fine when we used Linux-As-Bootloader. Yep, this can be fixed, but it does point out the issues that come up with supporting two different operating systems on one piece of hardware. Each one has to work, and they have to interact and work together. It's more than twice as complex, because of those interactions, as Jordan alluded to in a recent note.
The drivers require support, but the support team for OFW is probably 1/1000 the size of the support team for Linux, and, I guess, has about 1/1000 the money to do the work -- I think this is an optimistic estimate. So, which group will fix bugs faster, and be more current on hardware? I think I can guess. That's why I like Linux as the BIOS. It gets back to support.
I don't believe that OFW will ever have the level of support that Linux has. It is an OS, but it is not the OS people run; it just boots an OS. That distinction is guaranteed to put OFW behind Linux in the queue for support money and people. And, further pressure applies, because the chipset vendors are making it very clear to third-party vendors that their BIOS support teams should be writing EFI drivers, not OFW or other BIOS drivers. Whatever time and money the hardware vendors have for driver writing breaks down something like this: 1. boot support for traditional BIOS / EFI driver 2. Windows drivers 3. Linux (maybe) drivers (you can tell by the quality of some of these drivers ... )
I've seen this directly. We talked to one company, who told us they'd be showing us some really neat cluster hardware "as soon as we have finished up our EFI drivers". Yes, they are writing EFI drivers from scratch, although they have existing Linux drivers. Why not boot Linux from FLASH? An interesting question. It would require some chipset vendor support, I suppose. :-)
I talked to someone yesterday who built a small OS for an infiniband appliance. They actually got it to go. They also swore that the next time, their firmware was going to be simple: "Load Linux from flash and go -- let Linux do it". That's been our rallying cry from the beginning -- let Linux do it.
One might ask, instead of merging LinuxBIOS and OFW, why not merge Linux and OFW? After all, we have shown that we can boot Linux from FLASH, and it can be fast. Linux has great driver support. Linux has a huge support team, and support from many corporations. So why not subsume OFW into a Linux module? I think this could work, for people who really want OFW, and makes more sense than merging LinuxBIOS and OFW.
I think, for the future, where small 512KiB flash parts exist, the LinuxBIOS+OFW combo makes sense, for those who need OFW capabilities. And, as we have seen, on a sufficiently simple platform such as OLPC, OFW can do a great job without LinuxBIOS. I could post the OLPC startup code, I guess, but it's really a loop something like this:
for(i = 0; i < COUNT; i++) wrmsr(table[i].msr, table[i].value);
Done. It's a tad more than that, but not by much. Few platforms are this simple. It's also quite possible that the OFW guys will get motivated to support K8 -- you never can tell, and the OFW people are very smart people.
But, even if OFW ran on everything LinuxBIOS ran on, the OFW problem remains. OFW is a small OS, but it is an OS. If OFW is to boot an OS, such as Linux, then it will need the platform drivers. Let's suppose that OFW is ported to a mainboard such as the MS9185. It would have to support a lot of devices, and they would all have to be written. From what I can see, a given OFW port to a platform is far more complex than a LinuxBIOS port, due to the driver issues.
Were OFW to grow, it would require the level of support required of any OS. It will never get that level of support, period. I actually find that regrettable. OFW would have been a far better path to take than EFI. I have never understood the decision, given the existence of OFW, for the creation of EFI (well, actually, I do understand it, and that's almost worse than not understanding it ... ). But that decision has been made, and we are not going to be able to reverse it.
We might suppose that a company or companies would step forward to support and use OFW instead of EFI. The question is, how much support should a company put into an OS which is merely there to boot another OS? Or, to put it another way, given two choices: 1. use Linux in FLASH to load OS from disk 2. use OFW in FLASH to load OS from disk which one makes more sense, economically, including costs of support, documentation, and training? I've talked to a number of companies on this issue. Last summer, I offered one company OFW; the company knew what it was, and the response was immediate and negative; "No OFW. Put Linux in there. Our people know what it is, we don't have to train them on it".
My second concern is that OFW also makes what I think is a mistake, in that it supports callbacks into OFW. BIOS callbacks made sense in the 1970s. They even made sense into the 1980s. But as of the 1990s, when NetBSD on SPARC came out, one of the big NetBSD improvements over SunOS was to REMOVE the OFW callbacks for console I/O, i.e. to reduce the use of OFW callbacks. I am not convinced callbacks make sense any more. We have seen on many thousands of platforms that we don't need them.
BIOS callbacks complicate OSes in situations such as SMP -- you have to make sure the BIOS itself is SMP-safe, or you have to do nasty things in the OS to support the non-SMP-safe BIOS. I've seen systems with BIOS callbacks that were not SMP-safe (early EFI machines) and debugging them was quite hard. It would be nice to use the use of BIOS callbacks decline, rather than increase. The latest OFW patches to the kernel institutionalize the BIOS callbacks used on OLPC. I wish that had not happened.
BIOS callbacks also complicate virtualization (think Xen and friends). A privileged OS (domain 0 in Xen) can make those OFW calls, but how do you manage domain 1 and up OFW calls? It is surely a Simple Matter of Programming, but do we really need to add this complexity to what is already a pretty complex world? I would rather not.
Of course, the "guest domains" can just figure out they can not callback to OFW, and get the information some other way. But if an OS can get what it needs without a callback, why add a callback? Why add something to an OS when you can do without it?
So, by all means, LinuxBIOS can be bundled with OFW. I think it can be a useful combination, for situations where there is not much FLASH memory. That situation is becoming less and less common, but it still exists .
While I think OFW as a payload makes sense in some situations, I don't see much value in a codebase merge. LinuxBIOS with OFW is useful. LinuxBIOS without OFW is useful. So, we need to be able to make OFW optional. That "optional" nature makes a strong case for OFW as a payload.
At the same time, I believe that as the FLASH sizes grow to 2 Mbytes and beyond, putting Linux in FLASH will be the preferred option for many situations. That mode is already common in the non-x86 embedded space. It's probably the fastest way to boot Linux. And, from my measurements, Linux is a very fast bootloader -- on processors running at 2 Ghz, it's the fastest by far. So for people who really want OFW, maybe an OFW kernel module or OFW shell makes sense, running as part of Linux. If OFW were integrated into Linux, the driver issue would disappear.
Long term, however, I can not see the need for anything as complex as EFI or OFW when one can boot Linux directly, and have Linux boot Linux. At the FOSDEM conference a number of speakers showed Linux booting in well under a second -- this on a rather slow ARM. There's no fundamental reason that we can't boot Linux quickly and use it as either our embedded OS or bootloader.
To put it another way, the "LinuxBIOS or OFW" issue is the wrong way to look at the problem, in my view. LinuxBIOS and OFW work quite nicely together, as we have seen. It's an OFW or Linux issue. Which one would you rather interact with at boot time? I think, in some cases, the answer is "OFW", and in other cases, the answer is "Linux" or "Filo" or something else. Increasingly, however, I think the x86 world will follow the path of the non-x86 world, and the answer will, increasingly, be Linux -as- BIOS, which means Linux in FLASH.
thanks
ron
Very good explanation about LinuxBIOS and Linux Kernel.
Some ideas about future FW: 1. LinuxBIOS only need to do basic things like mem and basic init like HT, and basic PCI resources allocation 2. leave other thing to tiny linux kernel. 3. Thanks to Eric for kexec. and it make linux boot linux happen.
For EFI, they could do first step too. Only use EFI PEI and very slim pci resources allocation.
OFW, do the first step? That will need bunch of code for HT and Mem init. We don't need to reinvent that for x86.
Legacy BIOS: we can use that for step 1, and we could slim Etherboot and tiny kernel on flash on MB or PCI addon card. like Etherboot replace option rom on addon/onboard nic. or put the kernel on IDE flash or HDD.
So left work: 1. for LinuxBIOS: need to make the ACPI to more complete to support Nvidia chipset, and we need ACPI to do the thing instead of SMI, and hot plug things.... 2. kexec interface, so we can load other OS, and some new OS may be loaded via EFI, so may produce one EFI layer to be used by kexec. or just another simulate interface for EFI in kexec. 3. work on Kernel, So tiny kernel could be small and boot more faster for payload. ---- that would be great for embed solution.
YH
On Fri, May 04, 2007 at 11:29:04AM -0700, yhlu wrote:
Very good explanation about LinuxBIOS and Linux Kernel.
I agree. Thanks Ron!
Some ideas about future FW:
- LinuxBIOS only need to do basic things like mem and basic init
like HT, and basic PCI resources allocation 2. leave other thing to tiny linux kernel. 3. Thanks to Eric for kexec. and it make linux boot linux happen.
I like it. Just sucks that flash isn't growing in size sooner.
Does anyone know how much flash is in the MacBooks with EFI btw?
So left work:
- for LinuxBIOS: need to make the ACPI to more complete to support
Nvidia chipset, and we need ACPI to do the thing instead of SMI, and hot plug things....
This ACPI situation.. Is ACPI _really_ what anyone needs?
I expect a $4000 laptop to resume as fast as, if not faster than, the OLPC $100 machine. Seems that will be impossible with ACPI. What do the power management people think about this?
ACPI is needed for the short term, but what about the slightly longer term?
//Peter
On 5/4/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
I expect a $4000 laptop to resume as fast as, if not faster than, the OLPC $100 machine. Seems that will be impossible with ACPI. What do the power management people think about this?
You could check linux supend to mem or disk feature. but for LinuxBIOS+TinyKernel, you still need to go through it to get access to HD.
ACPI is needed for the short term, but what about the slightly longer term?
Still need some byte-code to do sth in FW to support different OS. such as PCI device hot plug. the ACPI AML could be used. maybe some day we can get good byte-code than AML.
YH
ron minnich wrote:
As to this OFW and LinuxBIOS discussion: LinuxBIOS is designed to load an OS from FLASH, no more and no less. To the maximum extent possible, LinuxBIOS avoids drivers, file systems, network protocol stacks, web servers, icons, GUIs, video displays, and so on. There is a reason for this: I have seen, over the years, that BIOSes tend to do a poor job of supporting hardware; conversely, OSes like Linux do a very good job. Hence the original design goal of LinuxBIOS: to facilitate placing a Linux image in FLASH, and using Linux as the BIOS. Hence the name.
In fact, in the early days, we did not consider what we now call "LinuxBIOS" as separate from a Linux kernel. The payload was always Linux. The only thing that required the seperation, eventually, was the small FLASH sizes and the Linux kernel bloat.
OFW is also an OS, really like Linux in a way. In fact, OFW is much more like Linux than it is like LinuxBIOS. It has drivers, file systems, console interaction, network protocol drivers and stacks (and now, even an 802.11 stack and OFW supplicant), a simple GUI, icons, interrupt support (in some versions), etc. etc. Some implementations have had threads and/or processes. OFW seems to really want that console interaction -- the standard fallback is an 'ok' prompt. In many situations, however, console interaction is impossible, which has been an issue with clusters I have built based on OFW-based systems (i.e. SPARCs).
That's one reason that LinuxBIOS is <32K, and OFW is 32K*10 -- even on a trivial platform like OLPC. OFW does a lot more. The extra capability of OFW makes it very powerful, and that is both a strength and a weakness.
There are two things that OFW does that I am uncomfortable with. The first and most important is, as mentioned: it has lots of drivers. If you are planning to run, e.g., OFW AND Linux on new hardware, you now have doubled the task of writing drivers: you get to write BOTH Linux and OFW drivers. Now, people tell me all the time that drivers are easy. Generally, these are people who are either really good at writing drivers, or who have never had to wring the last almost-never-happen bugs out of a driver. It is true that the first iteration of a driver is pretty easy. What makes them miserable is managing all the corner cases and hardware bugs and only-happens-once-in-100 million iterations bugs. So, for example, one of my OLPC units will still not talk to ANY of my flash sticks ... from OFW. From Linux, these flash sticks work fine -- and always have. They worked fine when we used Linux-As-Bootloader. Yep, this can be fixed, but it does point out the issues that come up with supporting two different operating systems on one piece of hardware. Each one has to work, and they have to interact and work together. It's more than twice as complex, because of those interactions, as Jordan alluded to in a recent note.
The drivers require support, but the support team for OFW is probably 1/1000 the size of the support team for Linux, and, I guess, has about 1/1000 the money to do the work -- I think this is an optimistic estimate. So, which group will fix bugs faster, and be more current on hardware? I think I can guess. That's why I like Linux as the BIOS. It gets back to support.
I don't believe that OFW will ever have the level of support that Linux has. It is an OS, but it is not the OS people run; it just boots an OS. That distinction is guaranteed to put OFW behind Linux in the queue for support money and people. And, further pressure applies, because the chipset vendors are making it very clear to third-party vendors that their BIOS support teams should be writing EFI drivers, not OFW or other BIOS drivers. Whatever time and money the hardware vendors have for driver writing breaks down something like this:
- boot support for traditional BIOS / EFI driver
- Windows drivers
- Linux (maybe) drivers (you can tell by the quality of some of these
drivers ... )
I've seen this directly. We talked to one company, who told us they'd be showing us some really neat cluster hardware "as soon as we have finished up our EFI drivers". Yes, they are writing EFI drivers from scratch, although they have existing Linux drivers. Why not boot Linux from FLASH? An interesting question. It would require some chipset vendor support, I suppose. :-)
I talked to someone yesterday who built a small OS for an infiniband appliance. They actually got it to go. They also swore that the next time, their firmware was going to be simple: "Load Linux from flash and go -- let Linux do it". That's been our rallying cry from the beginning -- let Linux do it.
One might ask, instead of merging LinuxBIOS and OFW, why not merge Linux and OFW? After all, we have shown that we can boot Linux from FLASH, and it can be fast. Linux has great driver support. Linux has a huge support team, and support from many corporations. So why not subsume OFW into a Linux module? I think this could work, for people who really want OFW, and makes more sense than merging LinuxBIOS and OFW.
I think, for the future, where small 512KiB flash parts exist, the LinuxBIOS+OFW combo makes sense, for those who need OFW capabilities. And, as we have seen, on a sufficiently simple platform such as OLPC, OFW can do a great job without LinuxBIOS. I could post the OLPC startup code, I guess, but it's really a loop something like this:
for(i = 0; i < COUNT; i++) wrmsr(table[i].msr, table[i].value);
Done. It's a tad more than that, but not by much. Few platforms are this simple. It's also quite possible that the OFW guys will get motivated to support K8 -- you never can tell, and the OFW people are very smart people.
But, even if OFW ran on everything LinuxBIOS ran on, the OFW problem remains. OFW is a small OS, but it is an OS. If OFW is to boot an OS, such as Linux, then it will need the platform drivers. Let's suppose that OFW is ported to a mainboard such as the MS9185. It would have to support a lot of devices, and they would all have to be written. From what I can see, a given OFW port to a platform is far more complex than a LinuxBIOS port, due to the driver issues.
Were OFW to grow, it would require the level of support required of any OS. It will never get that level of support, period. I actually find that regrettable. OFW would have been a far better path to take than EFI. I have never understood the decision, given the existence of OFW, for the creation of EFI (well, actually, I do understand it, and that's almost worse than not understanding it ... ). But that decision has been made, and we are not going to be able to reverse it.
We might suppose that a company or companies would step forward to support and use OFW instead of EFI. The question is, how much support should a company put into an OS which is merely there to boot another OS? Or, to put it another way, given two choices:
- use Linux in FLASH to load OS from disk
- use OFW in FLASH to load OS from disk
which one makes more sense, economically, including costs of support, documentation, and training? I've talked to a number of companies on this issue. Last summer, I offered one company OFW; the company knew what it was, and the response was immediate and negative; "No OFW. Put Linux in there. Our people know what it is, we don't have to train them on it".
My second concern is that OFW also makes what I think is a mistake, in that it supports callbacks into OFW. BIOS callbacks made sense in the 1970s. They even made sense into the 1980s. But as of the 1990s, when NetBSD on SPARC came out, one of the big NetBSD improvements over SunOS was to REMOVE the OFW callbacks for console I/O, i.e. to reduce the use of OFW callbacks. I am not convinced callbacks make sense any more. We have seen on many thousands of platforms that we don't need them.
BIOS callbacks complicate OSes in situations such as SMP -- you have to make sure the BIOS itself is SMP-safe, or you have to do nasty things in the OS to support the non-SMP-safe BIOS. I've seen systems with BIOS callbacks that were not SMP-safe (early EFI machines) and debugging them was quite hard. It would be nice to use the use of BIOS callbacks decline, rather than increase. The latest OFW patches to the kernel institutionalize the BIOS callbacks used on OLPC. I wish that had not happened.
BIOS callbacks also complicate virtualization (think Xen and friends). A privileged OS (domain 0 in Xen) can make those OFW calls, but how do you manage domain 1 and up OFW calls? It is surely a Simple Matter of Programming, but do we really need to add this complexity to what is already a pretty complex world? I would rather not.
Of course, the "guest domains" can just figure out they can not callback to OFW, and get the information some other way. But if an OS can get what it needs without a callback, why add a callback? Why add something to an OS when you can do without it?
So, by all means, LinuxBIOS can be bundled with OFW. I think it can be a useful combination, for situations where there is not much FLASH memory. That situation is becoming less and less common, but it still exists .
While I think OFW as a payload makes sense in some situations, I don't see much value in a codebase merge. LinuxBIOS with OFW is useful. LinuxBIOS without OFW is useful. So, we need to be able to make OFW optional. That "optional" nature makes a strong case for OFW as a payload.
At the same time, I believe that as the FLASH sizes grow to 2 Mbytes and beyond, putting Linux in FLASH will be the preferred option for many situations. That mode is already common in the non-x86 embedded space. It's probably the fastest way to boot Linux. And, from my measurements, Linux is a very fast bootloader -- on processors running at 2 Ghz, it's the fastest by far. So for people who really want OFW, maybe an OFW kernel module or OFW shell makes sense, running as part of Linux. If OFW were integrated into Linux, the driver issue would disappear.
Long term, however, I can not see the need for anything as complex as EFI or OFW when one can boot Linux directly, and have Linux boot Linux. At the FOSDEM conference a number of speakers showed Linux booting in well under a second -- this on a rather slow ARM. There's no fundamental reason that we can't boot Linux quickly and use it as either our embedded OS or bootloader.
To put it another way, the "LinuxBIOS or OFW" issue is the wrong way to look at the problem, in my view. LinuxBIOS and OFW work quite nicely together, as we have seen. It's an OFW or Linux issue. Which one would you rather interact with at boot time? I think, in some cases, the answer is "OFW", and in other cases, the answer is "Linux" or "Filo" or something else. Increasingly, however, I think the x86 world will follow the path of the non-x86 world, and the answer will, increasingly, be Linux -as- BIOS, which means Linux in FLASH.
Thanks for this 200+ line explanation. I did read it all, which probably means that you were rather concise.
Now, if I read you correctly, you are implying that OFW has overhead that isn't needed to just boot another OS. And LinuxBIOS is a mini BIOS that is tagged onto Linux to leverage its driver pool. Your point is taken. But there is one point you didn't mention:
OFW is pluggable, which means that it is easily extensible.
1. OFW in itself does not do anything other than provide a framework for pluggable firmware. Knowing how big this empty framework is, defines its overhead. Do you know how big it is?
2. OFW provides services via plugins. These plugins can be anything, even a linux kernel, provided it's adapted to conform to the OFW api. This means OFW can easily leverage the linux driver pool without providing any drivers itself.
3. OFW can easily host a Hypervisor as a plugin as well.
4. OFW can also relegate low level BIOS operations to a LinuxBIOS plugin, again provided LinuxBIOS is adapted to conform to the OFW api. But, as the OLPC project has shown, they chose to implement this from scratch as it was probably much easier that way. Which makes me think that we can learn something from this, and adjust LinuxBIOS to merge with OFW, while still allowing LinuxBIOS to act in a standalone manner, using a stripped OFW host, for cases where full OFW overhead is too big.
Thanks!
-- Al
On 5/4/07, Al Boldi a1426z@gawab.com wrote:
Now, if I read you correctly, you are implying that OFW has overhead that isn't needed to just boot another OS.
You did not read me correctly at all. Sorry, I guess I was not clear. OFW has overhead that it MUST HAVE to boot another OS. That's its job. LinuxBIOS does not have that overhead; LinuxBIOS counts on the in-FLASH payload, which it loads from FLASH to memory, and that payload is what boots another OS.
What I said was, that OFW has this very powerful ability to control devices, file systems, web servers, GUIs, network protocol stacks, remote file systems, and so on. That is at once its great strength and great weakness. It is a strength, since it has so much capability. It is a weakness because, to function, it has to have all the drivers written for it that Linux, or Windows, or EFI, has. it can not reuse exiting drivers from, e.g., Linux. And, sadly, due to short-sighted decisions by a number of vendors, nobody is going to develop new drivers for OFW. Any new drivers developed by vendors will be for: BIOS, Windows, Linux, and EFI, in that order.
Maybe OFW can start using EFI drivers, but at that point, what's the reason for OFW to exist?
And LinuxBIOS is a mini BIOS that is tagged onto Linux to leverage its driver pool. Your point is taken. But there is one point you didn't mention:
OFW is pluggable, which means that it is easily extensible.
That really has no importance or bearing on the discussion that I can see. I am not sure how it helps. The whole point is that OFW is already doing a lot, and having it do more is tough, due to the driver issue.
- OFW in itself does not do anything other than provide a framework for
pluggable firmware. Knowing how big this empty framework is, defines its overhead. Do you know how big it is?
you'll have to tell me :-)
- OFW provides services via plugins. These plugins can be anything, even a
linux kernel, provided it's adapted to conform to the OFW api. This means OFW can easily leverage the linux driver pool without providing any drivers itself.
yes, in other words, you can strip all the drivers out of OFW, until there is nothing left; then, you can add all the capability that linuxbios has into OFW, so that OFW can run on any hardware; then, you have OFW do nothing but load a Linux kernel from FLASH.
At that point, you will have done a lot of work so that OFW can do what LinuxBIOS does now, while removing everything from OFW that makes it OFW. I am not sure what the point of such an activity would be, but you can try it.
- OFW can easily host a Hypervisor as a plugin as well.
which would be good for?
- OFW can also relegate low level BIOS operations to a LinuxBIOS plugin,
again provided LinuxBIOS is adapted to conform to the OFW api. But, as the OLPC project has shown, they chose to implement this from scratch as it was probably much easier that way. Which makes me think that we can learn something from this, and adjust LinuxBIOS to merge with OFW, while still allowing LinuxBIOS to act in a standalone manner, using a stripped OFW host, for cases where full OFW overhead is too big.
well, give it a try, I guess, and let us know how it works out. I think you need to start trying to implement some of this stuff, I am not sure further discussion is all that useful.
thanks
ron
OLPC will boot Windows? because the customer want it as a backup.
http://biz.yahoo.com/ap/070504/hundred_dollar_laptop.html?.v=2
they will use old legacy BIOS like AMD using in 5x15?
YH
* yhlu yinghailu@gmail.com [070507 20:08]:
OLPC will boot Windows? because the customer want it as a backup.
http://biz.yahoo.com/ap/070504/hundred_dollar_laptop.html?.v=2
they will use old legacy BIOS like AMD using in 5x15?
They could sure use LinuxBIOS after GSoC is done. Microsoft, are you reading this?
or boot windows via OFW in OLPC?
YH
* yhlu yinghailu@gmail.com [070507 21:10]:
or boot windows via OFW in OLPC?
Indeed. Microsoft has code to do this, they did it on PPC before.
On 07.05.2007 21:22, Stefan Reinauer wrote:
- yhlu yinghailu@gmail.com [070507 21:10]:
or boot windows via OFW in OLPC?
Indeed. Microsoft has code to do this, they did it on PPC before.
No, they use a conventional PC BIOS on the OLPC to boot Windows.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070508 00:12]:
Indeed. Microsoft has code to do this, they did it on PPC before.
No, they use a conventional PC BIOS on the OLPC to boot Windows.
Any idea which one?
On 08.05.2007 01:24, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070508 00:12]:
Indeed. Microsoft has code to do this, they did it on PPC before.
No, they use a conventional PC BIOS on the OLPC to boot Windows.
Any idea which one?
Not really, but the early A-Test revisions of OLPC had an Insyde PC BIOS.
Regards, Carl-Daniel
On 5/7/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 08.05.2007 01:24, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070508 00:12]:
Indeed. Microsoft has code to do this, they did it on PPC before.
No, they use a conventional PC BIOS on the OLPC to boot Windows.
Any idea which one?
Not really, but the early A-Test revisions of OLPC had an Insyde PC BIOS.
which was time-bombed. So, this process, if it uses a proprietary bios, has cost someone money.
ron
* ron minnich rminnich@gmail.com [070508 01:42]:
Not really, but the early A-Test revisions of OLPC had an Insyde PC BIOS.
which was time-bombed. So, this process, if it uses a proprietary bios, has cost someone money.
So their 3$ offer probably won't make it below 6$? 100% overdraw for not using LinuxBIOS? ;-)
-
Al Boldi -
Carl-Daniel Hailfinger -
MARTIN WOODHOUSE -
Peter Stuge -
ron minnich -
Stefan Reinauer -
yhlu