From: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
To: Alex Thorlton <athorlton-sJ/iWh9BUns@public.gmane.org>
Cc: Linux EFI <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Matt Fleming
<matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>,
Russ Anderson <rja-sJ/iWh9BUns@public.gmane.org>
Subject: Re: [RFC] Best place/method to determine BIOS version?
Date: Tue, 10 Jun 2014 10:03:00 +0200 [thread overview]
Message-ID: <20140610080300.GA28607@pd.tnic> (raw)
In-Reply-To: <20140609200017.GD2700-sJ/iWh9BUns@public.gmane.org>
On Mon, Jun 09, 2014 at 03:00:17PM -0500, Alex Thorlton wrote:
> 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,
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.
--
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@suse.de>
To: Alex Thorlton <athorlton@sgi.com>
Cc: Linux EFI <linux-efi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Matt Fleming <matt@console-pimps.org>,
Russ Anderson <rja@sgi.com>
Subject: Re: [RFC] Best place/method to determine BIOS version?
Date: Tue, 10 Jun 2014 10:03:00 +0200 [thread overview]
Message-ID: <20140610080300.GA28607@pd.tnic> (raw)
In-Reply-To: <20140609200017.GD2700@sgi.com>
On Mon, Jun 09, 2014 at 03:00:17PM -0500, Alex Thorlton wrote:
> 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,
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.
--
next prev parent reply other threads:[~2014-06-10 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-09 20:00 [RFC] Best place/method to determine BIOS version? Alex Thorlton
2014-06-09 20:00 ` Alex Thorlton
[not found] ` <20140609200017.GD2700-sJ/iWh9BUns@public.gmane.org>
2014-06-10 8:03 ` Borislav Petkov [this message]
2014-06-10 8:03 ` Borislav Petkov
[not found] ` <20140610080300.GA28607-fF5Pk5pvG8Y@public.gmane.org>
2014-06-10 20:44 ` efi_call on SGI Borislav Petkov
2014-06-10 20:44 ` Borislav Petkov
[not found] ` <20140610204414.GB29302-fF5Pk5pvG8Y@public.gmane.org>
2014-06-11 17:32 ` Alex Thorlton
2014-06-11 17:32 ` Alex Thorlton
2014-06-11 8:55 ` [RFC] Best place/method to determine BIOS version? Matt Fleming
2014-06-11 8:55 ` Matt Fleming
2014-06-11 17:30 ` Alex Thorlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140610080300.GA28607@pd.tnic \
--to=bp-l3a5bk7wagm@public.gmane.org \
--cc=athorlton-sJ/iWh9BUns@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org \
--cc=rja-sJ/iWh9BUns@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.