Tracking down radeonfb failure (was: [iBook 2.2] Blank screen, no X - kernel issue?)
Hi,
this is crossposted as I'm not sure where to put this.
The referenced posting to debian-powerpc hasn't seen a reply yet.
Nikolaus Schulz wrote:
> With a fresh Sarge install from d-i RC1 on my iBook 2.2, I cannot get X
> to work.
Perhaps I should have mentioned that there is an installation report
(Bug #266472) available at [1].
To be more verbose and make this posting a little bit more
self-contained: the affected machine is an iBook G3, 800MHz Combo, with
a Radeon Mobility M7 (7500 LW) graphics chip.
> Using the plain default kernel 2.6.7-5 gives a blank console.
Note that the backlight is working, but nothing more.
> Adding video=ofonly makes the console work, but startx again blanks
> the screen.
> Some people wrote that the Open Firmware framebuffer driver (aka ofonly)
> breaks X, so that's not very surprising. But radeonfb seems to be
> broken, too, and I've found nobody experiencing the same behaviour :-(
>
> Using kernel 2.4.26, there's no need to specify boot parameters for
> the console, but X still doesn't function...
In fact kernel 2.4.26 falls back to offb, too. This can be seen in the
dmesg, I just missed it.
[...]
> Rather than posting all potentially relevant configs and logs, I've put
> the dmesg, XF86Config-4 and, if possible, XFree86.logs for the kernels
> 2.6.7 and 2.4.26 on a website:
>
> http://www.math.fu-berlin.de/~nschulz/linux/trouble/ibook/
Okay, I have further investigated the problem. Looks like a serious
one...
Apparently radeonfb fails to retrieve necessary display info.
Once again searching the lists, I finally found two postings describing
similar problems, see [2]: "DualHead-hack for iBook breaks radeonfb" and
[3]: "Powerbook 15" 1Ghz radeonfb/XFree86 woes".
In fact I once had applied the Dual-Head hack -- but the mainboard has
been replaced by Apple with a new one after it broke completely...
This was a case for the "iBook Logic Board Repair Extension Program" [4].
Just like Michael Klein reported in [2], EDID information seems to be
missing. (Never heard of EDID before...)
ibook$ ls -1 /proc/device-tree/pci@f0000000/ATY,BeeParent@10/ATY,Bee_A/
AAPL,gray-page
address
character-set
compatible
depth
device_type
display-type
height
iso6429-1983-colors
linebytes
linux,phandle
name
width
I have made a tarball of the directory tree below /proc/device-tree/ and
uploaded it to my site given above.
In addition I gathered the dmesg output running kernel 2.6.7 with
CONFIG_FB_RADEON_DEBUG enabled and uploaded it, too.
For the record, and to put some meat onto this posting, here a snippet
from dmesg.
The XFree86 logs are probably irrelevant with offb running, right?
In any case, I've uploaded everything.
,----[ dmesg of 2.6.7 with CONFIG_FB_RADEON_DEBUG ]
| PCI: Probing PCI hardware
| Registering openpic with sysfs...
| radeonfb_pci_register BEGIN
| PCI: Enabling device 0000:00:10.0 (0086 -> 0087)
| aper_base: 98000000 MC_FB_LOC to: 9bff9800, MC_AGP_LOC to: ffffa000
| radeonfb: probed DDR SGRAM 32768k videoram
| radeonfb: mapped 16384k videoram
| radeonfb: Invalid ROM signature 0 should be 0xaa55
| radeonfb: Retreived PLL infos from Open Firmware
| radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=180.00 Mhz, System=180.00 MHz
| Starting monitor auto detection...
| radeonfb: I2C (port 1) ... not found
| radeonfb: I2C (port 2) ... not found
| radeonfb: I2C (port 3) ... not found
| radeonfb: I2C (port 4) ... not found
| radeon_probe_OF_head
| head: ATY,Bee_A (letter: A, head_no: 0)
| analyzing OF properties...
| display-type: LCD
| radeon_probe_OF_head
| head: ATY,Bee_A (letter: A, head_no: 1)
| radeonfb: I2C (port 3) ... not found
| radeonfb: I2C (port 4) ... not found
| radeonfb: Monitor 1 type LCD found
| radeonfb: Monitor 2 type no found
| Guessing panel info...
| radeonfb: Assuming panel size 8x1
| radeonfb: Power Management enabled for Mobility chipsets
| Registered "ati" backlight controller, level: 15/15
| radeonfb: ATI Radeon LW DDR SGRAM 32 MB
| radeonfb_pci_register END
`----
The finding in [5] regarding [3] and [2] is the same here:
macos-shell$ ioreg -l | grep EDID
| | | | "EDIDerr" = <f615>
| | | | "EDIDerr" = <f615>
macos-shell$
Looking into kernel-source-2.6.7/drivers/video/aty/radeon_monitor.c, I
found the following, BTW:
,----[ radeon_monitor.c lines 825-833 ]
| RTRACE("Guessing panel info...\n");
| if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
| u32 tmp = INREG(FP_HORZ_STRETCH) & HORZ_PANEL_SIZE;
| rinfo->panel_info.xres = ((tmp >> HORZ_PANEL_SHIFT) + 1) * 8;
| tmp = INREG(FP_VERT_STRETCH) & VERT_PANEL_SIZE;
| rinfo->panel_info.yres = (tmp >> VERT_PANEL_SHIFT) + 1;
| }
| if (rinfo->panel_info.xres == 0 || rinfo->panel_info.yres == 0) {
| printk(KERN_WARNING "radeonfb: Can't find panel size, going back to CRT\n");
`----
I'd say this looks plain wrong, the second "if" will never be triggered.
This is the source of the weird "Assuming panel size 8x1" message in
dmesg. --
As Michael Klein wrote in [5], he fixed his problems by hardcoding the
EDID values into radeonfb.c. I hope there is another way!?
Nikolaus
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266472
[2] http://lists.debian.org/debian-powerpc/2003/08/msg00199.html
[3] http://lists.debian.org/debian-powerpc/2003/08/msg00398.html
[4] http://www.apple.com/support/ibook/faq/
[5] http://lists.debian.org/debian-powerpc/2003/08/msg00489.html
Reply to: