Unified Extensible Firmware Interface (UEFI) Example

[Gunther]

HSE,

Are you just following the subject, or building some UEFI application?

Both. The subject is important if UEFI applications are planned. With Intel's design decision, we've now the whole thing on our hands. There are alternatives,
but they are still in their early stages.

[HSE]

 

[Gunther]

HSE,

what is your goal? Do you just want to fix errors in Efi.inc?

[HSE]

Gunther,

what is your goal? Do you just want to fix errors in Efi.inc?

Combine here and here.

So far, I don't found any small UEFI OS, all are from BIOS era, wich now begin to fade (and my PC don't run legacy BIOS  ). If you know some small UEFI OS, I will preciate that data.

First point is to prove that big simulations can run without any OS in UEFI machines. That can not be dificult because ObjAsm have optimized functions, then need very few things from OS for calculations.     

Second point is to test if this simulations can run faster than inside Win OS.

[jj2007]

Second point is to test if this simulations can run faster than inside Win OS.

Yeah, Windows slows down everything. Oh, wait: task manager says cpu use is 2%, with 80+ processes running. How could an application run faster in another OS, if 98% of the cpu are available? What's the theory behind the assumption that, for example, Linux runs your stuff faster than Windows? Just curious

P.S.: There is a wealth of evidence here.

[johnsa]

I specifically built the UEFI stuff for just this reason.. for my personal OS project work. I had a small toy-OS running on a bunch of PCs, even working on an x86 mac pro.

I can tell you a few things, you'd be surprised at how little difference running that bare metal actually makes over Windows 10. As a test I wrote a distance-marching software renderer, running from my bare long-mode UEFI OS vs. Windows showed about a 10% performance gain.

To even get that took a lot of work making a set of drivers of AMD and NVidia gfx cards, not actually mode-setting, I relied on UEFI graphics to set the mode, but what you need to do is ensure you have the framebuffer memory configured as write-combining in the MTRRs and or PAT, and even more importantly, using UEFI PCI tools you can see that when you run under Windows the video card is set to maximum transfer rate via PCIe config but not from clean boot. It took a bunch of digging in the little docs that are available as well as pinging some of the guys from the Noveau driver project to find the right PCI BAR config regs to get  that setup. With that in place, you can software fill 1920x1080x32bit framebuffer and actually get it to the GPU at well over 1000 fps (as a baseline).

I went on to write an HD Audio driver so I had some sound playing too.. it was all good fun.. but at the end of the day.. I'm not sure it's worth it for 10% (If Windows slowed the code down by 30+ percent.. then yeah). I'll share the code for the bits of it if you like, just PM me.

[HSE]

Hi JJ!

How could an application run faster in another OS, if 98% of the cpu are available?

100%

What's the theory behind the assumption that, for example, Linux runs your stuff faster than Windows? Just curious

Linux is also a big OS.

For calculations you only could need micro OS (because apparently UEFI is more complete than BIOS). I think you need a micro OS at least to distribute process between cores and hyperthreads, and perhaps some memory management to prevent multiple access to some locations.

Regards, HSE.

[HSE]

for my personal OS project work. I had a small toy-OS running on a bunch of PCs

That is the idea, something specific.

I can tell you a few things, you'd be surprised at how little difference running that bare metal actually makes over Windows 10. As a test I wrote a distance-marching software renderer, running from my bare long-mode UEFI OS vs. Windows showed about a 10% performance gain.

That is a question to answer. For sure depends on hardware.

To even get that took a lot of work making a set of drivers of AMD and NVidia gfx cards..
I went on to write an HD Audio driver so I had some sound playing too..

That is what can be eliminated for calculations!

I'll share the code for the bits of it if you like, just PM me.

Thanks. Just learning now, but some questions will arise in the way.

[HSE]

Hi !

I'm writing:

Code Select Expand

  mov rax, pBootServices
  invoke [rax].EFI_BOOT_SERVICES.LocateProtocol, ADDR EFI_MP_SERVICES_PROTOCOL_GUID, NULL, ADDR MpProtocol


and ObjConv say assemble is:

Code Select Expand

        mov     rcx, qword ptr [pBootServices]          ; 0A08 _ 48: 8B. 0D, 00000000(rel)
        lea     rcx, ptr [EFI_MP_SERVICES_PROTOCOL_GUID]; 0A0F _ 48: 8D. 0D, 00000000(rel)
        xor     edx, edx                                ; 0A16 _ 33. D2
        lea     r8, ptr [rsp+30H]                       ; 0A18 _ 4C: 8D. 44 24, 30
        call    qword ptr [rcx+140H]                    ; 0A1D _ FF. 91, 00000140


but must be:

Code Select Expand

        mov     rax, pBootServices                      <---
        lea     rcx, ptr [EFI_MP_SERVICES_PROTOCOL_GUID]; 0A0F _ 48: 8D. 0D, 00000000(rel)
        xor     edx, edx                                ; 0A16 _ 33. D2
        lea     r8, ptr [rsp+30H]                       ; 0A18 _ 4C: 8D. 44 24, 30
        call    qword ptr [rax+140H]                    <---


I don't know if is a UASM problem or a bad method definition:

Code Select Expand

STDFUNC LocateProtocol, <voidarg>, Protocol:PTR EFI_GUID, Registration:PTR, ppInterface:PTR


Thanks in advance, HSE

[johnsa]

That doesn't look right, I'll check it out.

[HSE]

That was if MpProcotol is an structure, if MpProtocol is a qword then everything is correct (but anyway is a pointer  )