Best place/method to determine BIOS version?

Hi guys,

We recently ran into/corrected a bug in our BIOS that was exposed by the recent updates to the way that the EFI code maps in memory during boot. Discussion here:

http://comments.gmane.org/gmane.linux.kernel/1638074

Anyways, we now need to find a way to determine the BIOS version before efi_apply_memmap_quirks is called, so that we know whether or not the BIOS we're running requires the quirk. We have a function in one of our EFI runtime services that provides this information, but I'm having a lot of trouble calling this function early enough in boot.

It seems that all the necessary function pointers are available well before efi_apply_memmap_quirks is called, but when trying to use efi_call_phys6 to call our function, I always hit a kernel paging error.

I think the problem is that I really need to be doing this at a point where I can directly use physical addressing (the function pointer that we have stored in efi.uv_systab contains the physical address of our function) - at least that's the idea I get from our BIOS guys, but I really don't know what I'm talking about here :)

Can anybody help me with how early in boot I need to make this call, and possibly with an appropriate location to stick the code in?

Any advice is greatly appreciated. Thanks!

- Alex

Why not use DMI instead of EFI for getting the BIOS version? I see dmi_scan_machine() called earlier than efi_apply_memmap_quirks() in setup_arch()...?

Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Btw,

while we're at it, I see uv_bios_call is sometimes done with preemption disabled around it and sometimes it is not (at least I don't see it)...

In any case, if SGI uses the EFI pagetable now too, you probably would want to do the efi calls like the rest of x86 does them - see the 64-bit version of efi_call_virt() in arch/x86/include/asm/efi.h for an example what I mean.

Now, you could either copy that macro or you could accomodate it to serve everyone's needs - depends on what you'd prefer.

I'm just saying - I had stumbled across this while the debugging session was going on and wanted to point that out but it wasn't too important at the time so...

HTH.

Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Thanks, Boris. I'll take a look at that. I'm not sure why we would've chosen to do things differently there; wouldn't have been around for that, but I'll see if we can fix things up so that we're doing everything the way that everyone else is.

- Alex

Can't you use either early_ioremap() or ioremap() (depending on when you want to access the physical address), perhaps coupled with efi_call_phys()?

Matt Fleming, Intel Open Source Technology Center

I had actually tried that exact approach, but I think the problem is that I need to remap both the function code, and the data that it needs to access, and the pointers get clobbered in that process. The pointers work fine in direct physical mode, and they work fine after being mapped into the EFI page table in virtual mode, but I think there's some magic in there that helps fix them up when set_virtual_address_map is called, which isn't getting done when I try to remap manually.

I'll look into this approach a bit more to be absolutely sure that it won't work, but I hadn't had any luck so far.

- Alex