Subject: Re: The radeon framebuffer device panics init (on i386)
To: Vincent <>
From: Michael Lorenz <>
List: tech-kern
Date: 12/23/2006 17:47:30
Hash: SHA1


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
Version: GnuPG v1.2.4 (Darwin)