From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Radeon issue on x86
Date: Wed, 18 Feb 2004 11:33:00 +1100 [thread overview]
Message-ID: <1077064380.1076.76.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402171553250.2154@home.osdl.org>
> I can't help you on that one. You'd have to figure the "which chip is the
> primary" out on yourself, although you are likely to be able to figure it
> out by just following the trace of who has the legacy area mapped (ie who
> has the 0xA0000 - 0xCFFFF IO region enabled).
>
> On PCI bridges, that _should_ be visible by checking which bridge has
> "VGASnoop" on (and if none, default to the VGA device closest to the
> root). But I don't know - I've never tried to do this myself. I assume
> XFree86 must have some strange code to do this.
Hrm... I'm not sure how all of this works. Somebody suggested just
picking the VGA card that has IO enabled at boot (so basically
adding a quirk to x86 that "remembers" the pci_dev of whatever
VGA card had IO enabled during first PCI probe).
> There is no exact format. It's allowed to look pretty much any way it
> wants, although you're _supposed_ to have the marker 0x55, 0xAA in the
> first two bytes. That's how the system BIOS historically figures out that
> there is an extension ROM there somewhere.
Ok.
> The rule is, I think, that the primary video ROM should be at address
> 0xC0000. There might be alternate ROM start points at 2kB boundaries (in
> the whole 0xC0000 .. 0xFFFFF range).
>
> Oh, and byte 2 should have the "length indicator", which is the size of
> the ROM in 512-byte blocks, while "byte 3" is actually the first
> instruction to be run at initialization. So if you want to verify more,
> you should be able to disassemble "start+3" into a valid instruction, and
> "start+2" should have a sensible value, but especially that "rom length" I
> don't know how accurate it is.
I think I'll keep my current loop... so far it worked fine... (just
check for the signature). I may be able to check ATI specific signatures
in there, I don't know if it's worth the pain...
> The reason I say "should be" is that I would not be totally surprised if a
> video ROM that is embedded with the system ROM might not skip that part,
> since the system ROM "knows" that it is there regardless of signature.
>
> I just checked my EVO rom, and I notice that it _does_ have the signature
> 0xAA55 at 0xC0000, and the byte 0x80 at byte offset 2 (implying 65536
> bytes, which should be correct). So that's likely to be the right thing to
> check.
Maybe I should actually do more sanity checking on the values I read
from the BIOS, and based on that, try everything again the "other"
way... Hrm... it's all pretty nasty, I don't even have an x86 box
with a radeon to play with yet ;)
> > I currently copied a search routine from XFree but it does very little
> > verifications in there, I'm a bit paranoid about picking the wrong
> > thing...
> >
> > What do you suggest ?
>
> Does the above match what XFree86 does?
It just does a loop looking for the aa55 signature.
Ben.
next prev parent reply other threads:[~2004-02-18 0:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-17 3:51 Linux 2.6.3-rc4 Linus Torvalds
2004-02-17 6:19 ` Felix Seeger
2004-02-17 8:54 ` Martin Diehl
2004-02-17 9:27 ` Martin Diehl
2004-02-17 15:39 ` Bartlomiej Zolnierkiewicz
2004-02-17 16:21 ` Linux 2.6.3-rc4 (compile stats) John Cherry
2004-02-17 18:45 ` Linux 2.6.3-rc4 GCS
2004-02-17 19:09 ` Linus Torvalds
2004-02-17 20:05 ` Adrian Bunk
2004-02-17 20:16 ` Linus Torvalds
2004-02-17 22:59 ` Adrian Bunk
2004-02-17 23:11 ` Linus Torvalds
2004-02-17 23:37 ` Radeon issue on x86 Benjamin Herrenschmidt
2004-02-18 0:17 ` Linus Torvalds
2004-02-18 0:33 ` Benjamin Herrenschmidt [this message]
2004-02-18 0:00 ` Linux 2.6.3-rc4 Adrian Bunk
2004-02-18 1:28 ` Roman Zippel
2004-02-18 0:39 ` Roman Zippel
2004-02-18 1:06 ` Roman Zippel
2004-02-18 2:45 ` Roman Zippel
2004-02-18 2:58 ` Linus Torvalds
2004-02-18 0:15 ` Roman Zippel
2004-02-18 0:21 ` GCS
2004-02-17 18:56 ` Jonathan Brown
2004-02-17 19:06 ` Linus Torvalds
2004-02-18 10:18 ` Andreas Happe
2004-02-18 4:06 ` Stephen Rothwell
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=1077064380.1076.76.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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.