What exacly does EFI handle? From what I get from the EFI site, I gather that it is some form of interface between BIOS and the OS that holds data and availible system calls.
What does this mean? where does this come in to play to us developers?
Judging by the context, I can _guess_ that this would be used to interact between the actual firmware (such as the DOS bios calls from the old days)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Firmware" means machine code that can't be modified, typically because it is burned into a ROM. BIOS is firmware. EFI is a new architecture that *replaces* or supersedes BIOS. The 64-bit Itanium servers from HP, for instance (at least, all those I know of) have EFI.
For these machines, a new architecture is a must, as there IS no 16-bit real mode, and hence no BIOS on those machines.
There is also a 32-bit EFI spec, although I haven't seen if it has been adopted by any hardware manufacturers or not. It also differs from BIOS in that the "bootstrap" code has to meet special considerations, as do the early stages of the OS Loader- among others, the handoff occurs in protect mode, and *none* of the BIOS services exist.
It's probably not something you need to deal with right at the moment, but if the goal is to research what's out there in these early stages, this is definitely out there, and it is in use.
rbk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Developers could be affected several ways: the most likely is the need for an EFI OS Loader. If it does enough of the work itself, then when it tells EFI the OS is loaded, the rest of the OS can stay the same, and never use EFI again.
But something like JOSH and the existing NeOS code uses firmware services. So for these, they would have to use the EFI services instead.
IA64 machines are pricey, and its unlikely you'll be wanting to go after them this early in the game. Its more of an FYI thing.
rbk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see, however, what says that EFI doesn't progress past the bounds of IBM and migrate to less costly machines. It would be good to have a way for the bootstrap to detect this.
For instance, in gentoo linux, to start with the very basic install, you must first work at a very low level (with about 20 pages of instructions). The first major step is to bootstrap. I _think_ there is something in this that detects all the system aspects.
Although, this may be good for future development, but probably wont be needed as of yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The bottom line is you can't run your bootstrap code on an EFI box. You need a separate EFI-compliant OS Loader. They're radically different, so it's going to be an entirely new piece of code- you're not going to find much value in "tweaking" your existing one somehow.
It also means that you have to watch the design of the rest of the OS (post "bootstrap"). For instance, none of those Int xx BIOS calls are going to work. Neither is any real mode code.
For a modern OS, this only means that you have to have a well-defined point at which both "bootstrap" (I have to admit I prefer the old IPL [Initial Program Load] phrase- a "bootstrap" was a piece of metal [jumper if you will] you put on a disk drive when you wanted it to be the IPL source) methods are "complete" so the rest of the OS code is common.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What exacly does EFI handle? From what I get from the EFI site, I gather that it is some form of interface between BIOS and the OS that holds data and availible system calls.
What does this mean? where does this come in to play to us developers?
Judging by the context, I can _guess_ that this would be used to interact between the actual firmware (such as the DOS bios calls from the old days)
"Firmware" means machine code that can't be modified, typically because it is burned into a ROM. BIOS is firmware. EFI is a new architecture that *replaces* or supersedes BIOS. The 64-bit Itanium servers from HP, for instance (at least, all those I know of) have EFI.
For these machines, a new architecture is a must, as there IS no 16-bit real mode, and hence no BIOS on those machines.
There is also a 32-bit EFI spec, although I haven't seen if it has been adopted by any hardware manufacturers or not. It also differs from BIOS in that the "bootstrap" code has to meet special considerations, as do the early stages of the OS Loader- among others, the handoff occurs in protect mode, and *none* of the BIOS services exist.
It's probably not something you need to deal with right at the moment, but if the goal is to research what's out there in these early stages, this is definitely out there, and it is in use.
rbk
Developers could be affected several ways: the most likely is the need for an EFI OS Loader. If it does enough of the work itself, then when it tells EFI the OS is loaded, the rest of the OS can stay the same, and never use EFI again.
But something like JOSH and the existing NeOS code uses firmware services. So for these, they would have to use the EFI services instead.
IA64 machines are pricey, and its unlikely you'll be wanting to go after them this early in the game. Its more of an FYI thing.
rbk
I see, however, what says that EFI doesn't progress past the bounds of IBM and migrate to less costly machines. It would be good to have a way for the bootstrap to detect this.
For instance, in gentoo linux, to start with the very basic install, you must first work at a very low level (with about 20 pages of instructions). The first major step is to bootstrap. I _think_ there is something in this that detects all the system aspects.
Although, this may be good for future development, but probably wont be needed as of yet.
The bottom line is you can't run your bootstrap code on an EFI box. You need a separate EFI-compliant OS Loader. They're radically different, so it's going to be an entirely new piece of code- you're not going to find much value in "tweaking" your existing one somehow.
It also means that you have to watch the design of the rest of the OS (post "bootstrap"). For instance, none of those Int xx BIOS calls are going to work. Neither is any real mode code.
For a modern OS, this only means that you have to have a well-defined point at which both "bootstrap" (I have to admit I prefer the old IPL [Initial Program Load] phrase- a "bootstrap" was a piece of metal [jumper if you will] you put on a disk drive when you wanted it to be the IPL source) methods are "complete" so the rest of the OS code is common.