From: Antonino Daplas <adaplas@pol.net>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
James Simmons <jsimmons@infradead.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Reading the EDID block for x86 machines
Date: 18 Mar 2003 06:29:56 +0800 [thread overview]
Message-ID: <1047940105.3693.40.camel@localhost.localdomain> (raw)
In-Reply-To: <20030317220215.49788.qmail@web14902.mail.yahoo.com>
On Tue, 2003-03-18 at 06:02, Jon Smirl wrote:
> The VBIOS should be position independent code and it
> will run at any 64K boundary. The PC bus spec simply
> says the video BIOS defaults to C000, it is not a
> requirement that it be located there. For example if
> you look at the aty128fb driver's find ROM routine
> your will notice that it is searching a broad address
> space for the ROM.
>
> I'm still not convinced that the memory at C000 is
> really hardware write protected, I think it is just
> RAM with a copy of the ROM in it. For example if I
> turn off BIOS shadowing my system will not boot. When
> debugging this I spent some time tracing into the ATI
> ROM and I was pretty sure that they are dependent on
> begin copied into RAM before begin run.
The PC-compatible specific set of steps for the system POST code
when handling each expansion ROM are:
1. Map and enable the expansion ROM to an unoccupied area of the
memory address space.
2. Find the proper image in the ROM and copy it from ROM into the
compatibility area of RAM (typically 0C0000h to 0DFFFFhh) using the
number of bytes specified by Initialization Size.
3. Disable the Expansion ROM Base Address register.
4. Leave the RAM area writable and call the INIT function.
5. Use the byte at offset 02h (which may have been modified) to
determine how much memory is used at runtime.
Before system boot, the POST code must make the RAM area containing
expansion ROM code read-only.
POST code must handle VGA devices with expansion ROMs in a special
way. The VGA device's expansion BIOS must be copied to 0C0000h.
VGA devices can be identified by examining the Class Code field in
the device's Configuration Space.
-- pg. 210 PCI Local Bus Specification Revision 2.2 December 18, 1998
>
> Do you have a DOS floppy around? Just boot into DOS,
> start debug and see if you can change C000:0.
Yes, it's unchangeable.
Tony
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
next prev parent reply other threads:[~2003-03-17 22:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-11 12:49 Reading the EDID block for x86 machines Antonino Daplas
2003-03-11 15:49 ` James Simmons
2003-03-11 20:07 ` Antonino Daplas
2003-03-11 21:33 ` Antonino Daplas
2003-03-11 21:47 ` Antonino Daplas
2003-03-11 22:05 ` Jon Smirl
2003-03-11 22:33 ` Antonino Daplas
2003-03-11 22:54 ` Jon Smirl
2003-03-11 23:02 ` Antonino Daplas
2003-03-11 23:42 ` Jon Smirl
2003-03-12 17:38 ` Antonino Daplas
2003-03-12 18:16 ` Jon Smirl
2003-03-12 22:38 ` Antonino Daplas
2003-03-12 23:36 ` Jon Smirl
2003-03-12 23:47 ` Jon Smirl
2003-03-13 6:50 ` Geert Uytterhoeven
2003-03-13 15:42 ` Jon Smirl
2003-03-16 23:00 ` Antonino Daplas
2003-03-17 4:00 ` Jon Smirl
2003-03-17 7:00 ` Antonino Daplas
2003-03-17 19:33 ` Jon Smirl
2003-03-17 21:38 ` Antonino Daplas
2003-03-17 22:02 ` Jon Smirl
2003-03-17 22:29 ` Antonino Daplas [this message]
2003-03-17 23:41 ` Jon Smirl
2003-03-18 9:06 ` Geert Uytterhoeven
2003-03-18 10:00 ` Antonino Daplas
2003-03-18 17:07 ` Jon Smirl
2003-03-19 5:15 ` Antonino Daplas
2003-03-19 6:07 ` Jon Smirl
2003-03-18 0:00 ` Jon Smirl
2003-03-11 23:54 ` Jon Smirl
2003-03-12 12:10 ` Ville Syrjälä
2003-03-12 17:38 ` Antonino Daplas
2003-03-12 18:47 ` Ville Syrjälä
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=1047940105.3693.40.camel@localhost.localdomain \
--to=adaplas@pol.net \
--cc=geert@linux-m68k.org \
--cc=jonsmirl@yahoo.com \
--cc=jsimmons@infradead.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).