lkml.org 
[lkml]   [2013]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: BGRT Pointer in System RAM
On Mon, Jul 15, 2013 at 4:20 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Mon, Jul 15, 2013 at 04:08:13PM -0700, Andy Lutomirski wrote:
>> On Mon, Jul 15, 2013 at 4:04 PM, Josh Triplett <josh@joshtriplett.org> wrote:
>> > On Mon, Jul 15, 2013 at 01:28:36PM -0700, Andy Lutomirski wrote:
>> >>
>> >> Interesting. My BGRT says:
>> >>
>> >> [028h 0040 8] Image Address : 0D06801800000001
>> >>
>> >> If I reverse the high and low 32-bit dwords, then I get an address in
>> >> system RAM.
>> >
>> > Does that address in RAM start with a BMP header?
>>
>> No idea. I'd presumably have to modify the driver to find out --
>> otherwise something else will overwrite it.
>
> You could boot with a mem= command-line argument that reserves that
> memory.

I'll see what I can do.

>
>> > Because that would be *special*. I don't think it's worth trying to
>> > cope with that bug; better to just write off the BGRT as invalid if the
>> > BIOS can't get endianness right.
>> >
>> > In theory we could guess at that bug if the unmangled address points to
>> > a location in RAM starting with a BMP header. In practice, let's not; a
>> > missing BGRT is a purely cosmetic issue, and BIOS vendors can learn to
>> > get that one right if they want to see their logo during Linux boot.
>> > This won't break fastboot support, it just breaks fancy crossfades from
>> > the BIOS logo to a Linux desktop or splash.
>>
>> FWIW, the address that my BIOS gives is non-canonical. Maybe that's
>> good enough.
>
> What do you mean by "non-canonical".

Brainfart. I'm confusing physical and virtual addresses. More
usefully, the bogus address from my BIOS is too large -- it's way
above the highest e820 spot (and I'm pretty sure it exceeds the
maximum address that my CPU can address). Maybe that would be a
decent heuristic to use to avoid trying to follow the pointer.

>
>> > So, a "firmware bug" message in dmesg seems sufficent for that case. We
>> > do need to handle the case of a valid pointer into memory that e820
>> > calls system RAM, as well as the case of a valid pointer into memory
>> > reserved for the BIOS or similar, but not the case of an invalid
>> > pointer.
>>
>> Is the efi_bgrt code called early enough that data in system RAM will
>> still be there?
>
> In theory, it should always point to data in EFI's "reserved until after
> boot time" memory.
>
> - Josh Triplett


\
 
 \ /
  Last update: 2013-07-16 02:01    [W:0.061 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site