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: 17 Mar 2003 15:00:14 +0800 [thread overview]
Message-ID: <1047883995.1234.7.camel@localhost.localdomain> (raw)
In-Reply-To: <20030317040051.35768.qmail@web14911.mail.yahoo.com>
On Mon, 2003-03-17 at 12:00, Jon Smirl wrote:
> --- Antonino Daplas <adaplas@pol.net> wrote:
> > > > 3. write to PCI config space of secondary
> > controller the address you
> > > > want it to appear (ie C000:0000). Can I use
> > other addresses?
> >
> > I checked the PCI 2.2 specs, and it doesn't have
> > this capability. It
> > will give you the address of the expansion ROM, but
> > you still have to
> > manually copy the ROM and place it in any of the
> > expansion areas.
> > Unfortunately for VGA controllers, it's always
> > C000:0000.
>
> You can very definitely move the ROMs to where ever
> you want that isn't occupied by something else. I have
> written code that does it. Also, the system BIOS must
> be moving the ROMs in order to sort things out so that
> they don't all appear on top of each other.
>
You're talking about other device's expansion ROM's. VGA ROM's,
especially for the x86, are an exception and has to be always mapped at
c000:0000.
> You don't even need to move the ROM. Just enable it
> and read it's address form PCI space. The system BIOS
> will have sorted the addresses out so that they don't
> overlap. PCI config Region 6 is always the ROM see
> include/linux/pci.h
>
> > 1. COOO:0000 will be write protected by the BIOS
> > upon initialization of
> > the first VGA controller. This will prevent copying
> > of the succeeding
> > ROMS into that segment (unless you have a BIOS that
> > supports read-write
> > shadow ROM's).
>
> How is C000 write protected? I'm pretty sure that the
> ATI ROM are writing to C000.
It is. C000 is write enabled by the BIOS before init. Then it calls
the INIT procedure, which adjusts the initialization size before
returning. Afterwards, the BIOS write-protects the block equivalent to
the initialization size. Suceeding ROM's will then be mapped after this
block.
Remember, ROM's are supposed to be read-only, so even if they are
shadowed, the BIOS write protects it.
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 7:03 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 [this message]
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
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=1047883995.1234.7.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).