Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jul 2003 11:29:03 +0930
From:      Greg 'groggy' Lehey <grog@FreeBSD.org>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        freebsd-mobile@freebsd.org
Subject:   Re: Mapping Video BIOS?
Message-ID:  <20030727015903.GJ45069@wantadilla.lemis.com>
In-Reply-To: <20030726.194750.28168388.imp@bsdimp.com>
References:  <20030727002138.GD45069@wantadilla.lemis.com> <20030726.184443.70908660.imp@bsdimp.com> <20030727010938.GF45069@wantadilla.lemis.com> <20030726.194750.28168388.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--aznLbwQ42o7LEaqN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Saturday, 26 July 2003 at 19:47:50 -0600, M. Warner Losh wrote:
> In message: <20030727010938.GF45069@wantadilla.lemis.com>
>             "Greg 'groggy' Lehey" <grog@freebsd.org> writes:
>> On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote:
>>> In message: <20030727002138.GD45069@wantadilla.lemis.com>
>>>             "Greg 'groggy' Lehey" <grog@FreeBSD.org> writes:
>>>> I had also expected that you could shed some light on the BIOS mapping
>>>> issue.  Since my last message I've become pretty sure that it must be
>>>> something to do with the chip set setup.  Is it possible that we're
>>>> not mapping the entire area 0xc0000 to 0xfffff?
>>>
>>> I'm not sure what you mean by this question.  Since OLDCARD works, and
>>> requires read/write access to that physical memory range, I doubt that
>>> it is unmapped.
>>
>> I'm not sure at what level.  I suspect that something in the chipset
>> is turning off that area of memory, or mapping something else to it.
>> The dump from Microsoft shows that there's another BIOS at 0xcf000,
>> but what I have mapped in memory shows only 0xff up to address
>> 0xd0000, where I find another BIOS signature:
>>
>> 0x28377fe0:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
>> 0x28377ff0:     0xffffffff      0xffffffff      0xffffffff      0xffffffff
>> 0x28378000:     0xe80caa55      0x4ecb14c8      0x0000033b      0x00000000
>> 0x28378010:     0x00000000      0x00200000      0x00600040      0x90c08b2e
>> 0x28378020:     0x49444e55      0x0000ea16      0x0c9d0201      0xad100800
>
> Typically, there are a number of different ROM sections.  The orm
> driver searches for these things out.  Does it report anything

Presuming that it's the ROM driver, I get this in the dmesg I posted:

pnpbios: Bad PnP BIOS data checksum

That's pretty much the same problem reported by the X server.

Where would I go from there?

Greg
--
See complete headers for address and phone numbers

--aznLbwQ42o7LEaqN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE/IzHnIubykFB6QiMRAo3KAKCF2YvuYqoD0U8jTWnGaTU6LjClSACeMxl3
NiHo1WVau3q+01MuEb8Ako4=
=bgb0
-----END PGP SIGNATURE-----

--aznLbwQ42o7LEaqN--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030727015903.GJ45069>