-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Dec 23, 2006, at 16:13, Vincent wrote:

> According to Michael Lorenz:
>
>>>> Hmm, so you r display does provide EDID data after all. I didn't 
>>>> see any EDID stuff in your dmesg output but since the default mode 
>>>> used by radeonfb is the same as what your display reports that 
>>>> doesn't matter for now.
>>> It is supposed to do so?
>> Yes. And at least on my iBook it works just fine. To my surprise I 
>> might add.
>
> Well, there is obviously something more seriously wrong.

Not so obvious. Radeonfb can get EDID data only via i2c, the Xorg 
driver can also get them from the video BIOS.

>>> I think Xorg scans all the PCI bus, detects overlaps, and decides to 
>>> map the video BIOS in a hole.
>> Maybe - when X is up you can have a look with pcictl if there's 
>> something else than 0x00000000 in the ROM BAR - somehow I doubt it. 
>> In fact I think there's no dedicated video BIOS ROM and video BIOS is 
>> part of the main BIOS.
>
> No, there is nothing else, because I precisely dumped the BIOS under X.
>
> "Expansion ROM Base Address: 0x00000000"
>
> Anyhow, a ROM BAR should be ROM itself, no?

If it isn't mapped that usually means it's not used.

>> What you could do is:
>> - - find a safe address range for the ROM BAR ( usually you'll need 
>> 64kB or 128kB )
>> - - use pcitweak to set the address and enable the ROM
>> - - write a little program that mmap()s the ROM via /dev/mem ( just 
>> open /dev/mem for reading, use the address you picked as offset for 
>> mmap() ) and see what's there. If you get SIGBUS, SIGSEGV or bogus 
>> data ( like all 0x00000000 or 0xffffffff ) then there's likely no 
>> ROM.
>
> Somehow, X seems to find something when launch, so I guess there is a 
> piece of ROM somewhere. I'll try to tinker the way you indicated.

Yes, it calls the video BIOS. Radeonfb attempts to find some parameter 
table in the ROM. ( and xorg will attempt to do that as well )

>> Hmm, maybe it makes sense to have radeonfb look at the 'traditional' 
>> physical address of the video BIOS and cross fingers.
>
> Which is?

usually 0x000c0000 or 0x000c8000

>>> I've not tested CRT output yet, will do that now.
>> That would at least tell us if radeonfb doesn't feed the panel the 
>> right way or if there's something more fundamental wrong.
>
> The CRT output does not work either. At least my TV screen stays blank.

Not sure if radeonfb supports TV output at all. I doubt it does.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRY2yAspnzkX8Yg2nAQLZIQf/Q9Fh9vUjF+5K9u1e70BbU6W/NbqOeYf1
hN8PVymT42Q6l1GR53pYH6X2RKi7m2H0R29QtMY0QaOMsjMU+CM/MTpNVwYhU4Sy
Y7670sjhqzlsRGvc8MVG1ZvvZlygXgkbu2qIKaSj+tEzia9xvkSy/+gFTT7AnBs0
AulYF9kWiOGTRuZ66qxRvO2uPcQ5LbTUVY1ZcJVBpp7Eg61EBZKG4UyXAuUZZZko
KtED0iHixDMe27GJQEotC2aXLCLK24fiWcfdnuf+rJ3EmK8YapgTw2awyuw2gcuf
035DbLquCj05b7iUcUja01O9kGU4BqFSwTX+/iPNRRjvSIwwuWUuIg==
=QvoH
-----END PGP SIGNATURE-----