Subject: Re: The radeon framebuffer device panics init (on i386)
To: Vincent <firstname.lastname@example.org>
From: Michael Lorenz <email@example.com>
Date: 12/23/2006 15:21:12
-----BEGIN PGP SIGNED MESSAGE-----
On Dec 23, 2006, at 05:18, Vincent wrote:
> Michael Lorenz =E9crit :
>> Hmm, so you r display does provide EDID data after all. I didn't see=20=
>> any EDID stuff in your dmesg output but since the default mode used=20=
>> by radeonfb is the same as what your display reports that doesn't=20
>> matter for now.
> It is supposed to do so?
Yes. And at least on my iBook it works just fine. To my surprise I=20
>> Xorg apparently manages to get data out of the BIOS - probably by=20
>> calling it which we can't really do in a supposedly=20
>> machine-independent driver ( the same thing works just fine on my=20
>> iBook for instance ) - to do this we'd have to split up the driver=20
>> into machine dependent parts.
> I think Xorg scans all the PCI bus, detects overlaps, and decides to=20=
> map the video BIOS in a hole.
Maybe - when X is up you can have a look with pcictl if there's=20
something else than 0x00000000 in the ROM BAR - somehow I doubt it. In=20=
fact I think there's no dedicated video BIOS ROM and video BIOS is part=20=
of the main BIOS.
> That we can't do at start, because the attach process do not keep=20
> track of the (yet) allocated PCI addresses and range, as far as I=20
> know. Which is a pity.
Well, that's not entirely true:
- - on most architectures that's the firmware's job ( be it a PCI BIOS,=20=
OpenFirmware or whatever )
- - on other architectures NetBSD does that all itself ( mostly embedded=20=
- - on most architectures there's code to fix mistakes made by the=20
firmware ( like overlaps, missing bus numbers, wrong IRQs, set up=20
devices the firmware 'forgot', etc. )
What you could do is:
- - find a safe address range for the ROM BAR ( usually you'll need 64kB=20=
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=20=
/dev/mem for reading, use the address you picked as offset for mmap() )=20=
and see what's there. If you get SIGBUS, SIGSEGV or bogus data ( like=20
all 0x00000000 or 0xffffffff ) then there's likely no ROM.
Hmm, maybe it makes sense to have radeonfb look at the 'traditional'=20
physical address of the video BIOS and cross fingers.
>> Does CRT output work with radeonfb? A halfway modern monitor might=20
>> give some hints how exactly frequencies are screwed up ( like=20
>> doubled, completely off or whatever - might be interesting since all=20=
>> clocks are generated from one reference clock and ATI did pull some=20=
>> stunts with that in the past with some mach64 using ~14.7MHz, others=20=
>> ~29.4MHz )
> 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=20
right way or if there's something more fundamental wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----