Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Firstly a disclaimer: I'm completely new at this stuff so apologies if I ask stooopid things.
I have an EFI application in mind that requires me to run some realtime code periodically.
I was thinking of setting up a EFI driver of some sort that executes the code when the APIC is triggered.
However I recently read that EFI drivers have no timer support??!? (Supports polling but that's not realtime enough I don't think...)
My question is: What's the best way of getting this periodic, realtime code running under EFI? Also, can I actually run realtime code under EFI (I need it to be pretty much clock-perfect) or am I going to loose clock cycles to all the other EFI stuff going on?
Please keep in mind that I have pretty much zero EFI knowledge (other than what I've been reading on the WIKI and other sites).
Any advice would be great!
depletionmode wrote:My question is: What's the best way of getting this periodic, realtime code running under EFI?
UEFI is intended for OS boot loaders (where an OS has it's own, much better drivers). There are provisions for some utilities, but these provisions only really exist for simple utilities intended for system maintenance (e.g. things like utilities to create/delete partitions, set/change boot options, etc).
If you hope that UEFI is a full fledged real time OS, then you're badly mistaken. It's not real time. It's not an OS. It was never intended to be used for either purpose. Basically, it's the wrong tool for the job for many many reasons.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Brendan wrote:
If you hope that UEFI is a full fledged real time OS, then you're badly mistaken. It's not real time. It's not an OS. It was never intended to be used for either purpose. Basically, it's the wrong tool for the job for many many reasons.
Gotcha. Maybe I'll go down the OS root for my project.
So are there any good tutorials or is there any good literature on how to pass off to my code (as an OS) from EFI?
Am I able to stay in protected mode or do I need to switch back to real mode and do the switch myself?
Or I'll just use GRUB from EFI to get me started...
Brendan wrote:
If you hope that UEFI is a full fledged real time OS, then you're badly mistaken. It's not real time. It's not an OS. It was never intended to be used for either purpose. Basically, it's the wrong tool for the job for many many reasons.
Gotcha. Maybe I'll go down the OS root for my project.
So are there any good tutorials or is there any good literature on how to pass off to my code (as an OS) from EFI?
depletionmode wrote:Am I able to stay in protected mode or do I need to switch back to real mode and do the switch myself?
There are 2 types of UEFI for 80x86: 32-bit (protected mode without paging) and 64-bit (long mode with everything identity mapped). Almost all 80x86 computers use 64-bit UEFI - only a few old Apple machines used 32-bit, and Microsoft has never supported 32-bit UEFI (and have no plans to support 32-bit UEFI in future). UEFI doesn't use real mode at all and there's never any sane reason to switch to real mode (it's not like you can use BIOS functions in real mode because it's a UEFI system and there is no BIOS or BIOS functions).
This means that it's very likely that your boot loader will be started in long mode and stay in long mode while it's using UEFI. For a 32-bit OS you'd have a 64-bit boot loader that uses UEFI to load everything, then switches to 32-bit protected mode to start the OS after it has finished with UEFI.
depletionmode wrote:Or I'll just use GRUB from EFI to get me started...
That might be easier, maybe.
It takes a long time to write an OS though; and if you only really want to write one application then it might make a lot more sense to find a suitable existing OS and write the application for that. For example, you might be able to avoid many years of work just by using something like QNX or RTLinux.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
