Subject: Re: The radeon framebuffer device panics init (on i386)
To: Vincent <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 12/23/2006 17:47:30
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----