Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #54224 > unrolled thread

Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

Back to article view | Back to linux.debian.kernel

Contents

  Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color Mathieu Malaterre <malat@debian.org> - 2016-05-30 18:50 +0200
    Bug#825840: Acknowledgement (linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color) Mathieu Malaterre <malat@debian.org> - 2016-05-30 19:00 +0200
      Bug#825840: Acknowledgement (linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color) Mathieu Malaterre <malat@debian.org> - 2016-05-30 19:10 +0200
    Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color Ben Hutchings <ben@decadent.org.uk> - 2016-05-31 18:30 +0200
      Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color Mathieu Malaterre <malat@debian.org> - 2016-05-31 18:40 +0200
    Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color Milan Kupcevic <milan@debian.org> - 2016-05-31 20:20 +0200
    Processed: localechooser: image display inverts red and blue color owner@bugs.debian.org (Debian Bug Tracking System) - 2016-09-02 21:10 +0200
    Processed: Re: Bug#825840: localechooser: image display inverts  red and blue color owner@bugs.debian.org (Debian Bug Tracking System) - 2016-09-06 02:40 +0200
    Processed: offb/ATY,RockHopper: inverts red and blue in bterm owner@bugs.debian.org (Debian Bug Tracking System) - 2016-09-14 10:00 +0200

#54224 — Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Multipart message — attachments visible in raw view] — view raw

Package: linux-image-4.5.0-2-powerpc
Version: 4.5.4-1

During Debian installation the background color is inverted on PPC system.
At least on my Mac Mini G4, the default background color shows up as red
from begining to start (only the last screen turn blue).

Looking at the module loaded during the installation I can see radeonfb,
which I suspect is the one responsible for handling of `/dev/fb0`.

After installation I tried reproducing this color inversion without any
luck so far.

It is non-trivial to `rmmod radeon`, so instead I used (and rebooted):

$ cat /etc/modprobe.d/radeon.conf
blacklist radeon

However upon reboot `/dev/fb0` is already setup. But neither radeonfb nor
radeon module seems to be loaded (using lsmod) but lspci output is rather
confusing [*].

I can also see:

$ cat /proc/fb
0 OFfb ATY,RockHo

Playing with the virtual screen with a red and blue color and `fim`, all
images looks weird, I could not figure out if there was something special
to setup so that I can display a red or blue image in `fim`.

Lastly, I can run `dmesg` and the color looks right (error messages are
displayed in red, timestamp in green).

I'd like to keep this bug open until I find what is going on with this
color inversion on PPC/ATI.


$ lspci  -s 0000:00:10.0 -vvx
0000:00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] RV280 [Radeon 9200] (rev 01) (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RV280 [Radeon 9200]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 255 (2000ns min), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 48
Region 0: Memory at 98000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at 0400 [size=256]
Region 2: Memory at 90000000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at 90020000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel modules: radeonfb, radeon
00: 02 10 62 59 07 00 b0 02 01 00 00 03 08 ff 00 00
10: 08 00 00 98 01 04 00 00 00 00 00 90 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 62 59
30: 00 00 02 90 58 00 00 00 00 00 00 00 ff 01 08 00

[toc] | [next] | [standalone]

#54227 — Bug#825840: Acknowledgement (linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color)

As a side note, inserting the radeonfb module gives me:

[   96.551486] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[   96.551526] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem
0x98000000-0x9fffffff pref]
[   96.551531] radeonfb (0000:00:10.0): cannot request region 0.
[   96.551545] radeonfb: probe of 0000:00:10.0 failed with error -16

[toc] | [prev] | [next] | [standalone]

#54228 — Bug#825840: Acknowledgement (linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color)

Some actual progress. The trick was to prevent Open Firmware to
provide the framebuffer for us (??does that even make sense??).

Before;

[    0.740726] Using unsupported 800x600 ATY,RockHopper2_A at
9c008000, depth=8, pitch=1024
[    0.750458] Console: switching to colour frame buffer device 100x37
[    0.759850] fb0: Open Firmware frame buffer device on
/pci@f0000000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0

Change:

#  echo 'append="nomodeset video=offb:off"' >> /etc/yaboot.conf
# reboot

At this point should have nothing associated with framebuffer. Then
simply `modprobe radeonfb`:

[   86.282273] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[   86.483645] radeonfb 0000:00:10.0: Invalid PCI ROM header
signature: expecting 0xaa55, got 0x0000
[   86.483671] radeonfb (0000:00:10.0): Invalid ROM signature 0 should be 0xaa55
[   86.483681] radeonfb: Retrieved PLL infos from Open Firmware
[   86.483690] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=190.00
Mhz, System=250.00 MHz
[   86.483700] radeonfb: PLL min 12000 max 35000
[   86.582586] i2c i2c-7: unable to read EDID block.
[   86.734169] i2c i2c-7: unable to read EDID block.
[   86.885653] i2c i2c-7: unable to read EDID block.
[   87.115918] radeonfb: Monitor 1 type CRT found
[   87.115932] radeonfb: EDID probed
[   87.115938] radeonfb: Monitor 2 type CRT found
[   87.115943] radeonfb: EDID probed
[   87.128299] Console: switching to colour frame buffer device 210x65
[   87.144004] radeonfb (0000:00:10.0): ATI Radeon 5962 "Yb"


Turns out: everything works as expected ! `fim` happily display a nice
red or blue bmp image. dmesg output is still very nicely coloured.

Maybe the issue is directly in d-i where PPC is setup with a different
layout for some reason.

[toc] | [prev] | [next] | [standalone]

#54247

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote:
> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Control: reassign src:linux 4.5.4-1
> > Control: tag -1 help
> > 
> > On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
> > > Package: linux-image-4.5.0-2-powerpc
> > > Version: 4.5.4-1
> > > 
> > > During Debian installation the background color is inverted on PPC system.
> > > At least on my Mac Mini G4, the default background color shows up as red
> > > from begining to start (only the last screen turn blue).
> > > 
> > > Looking at the module loaded during the installation I can see radeonfb,
> > > which I suspect is the one responsible for handling of `/dev/fb0`.
> > > 
> > > After installation I tried reproducing this color inversion without any
> > > luck so far.
> > > 
> > > It is non-trivial to `rmmod radeon`, so instead I used (and rebooted):
> > > 
> > > $ cat /etc/modprobe.d/radeon.conf
> > > blacklist radeon
> > > 
> > > However upon reboot `/dev/fb0` is already setup.
> > 
> > Of course, because there is no character-based display mode on Power
> > Macs (in general).
> > 
> > > But neither radeonfb nor
> > > radeon module seems to be loaded (using lsmod) but lspci output is rather
> > > confusing [*].
> > 
> > lspci lists all kernel modules that match a particular PCI device's ID,
> > and separately whether any kernel driver is currently bound to the
> > device.
> > 
> > > I can also see:
> > > 
> > > $ cat /proc/fb
> > > 0 OFfb ATY,RockHo
> > 
> > As I would expect, the generic Open Firmware framebuffer driver is
> > behind /dev/fb0.  If a hardware-specific driver is loaded, that will
> > take over from it.
> 
> Thank you ! Ok now I understand. d-i tried to modprobe `radeonfb` but
> fails since framebuffer is already taken by Open Firmare, as can be
> seen in the dmesg log:
[...]

That's *not* what I thought was happening.  I was expecting radeonfb to
do something like this (in the radeon DRM driver):
https://sources.debian.net/src/linux/4.5.4-1/drivers/gpu/drm/radeon/radeon_drv.c/?hl=336#L336
and maybe to query offb about the existing framebuffer properties first.

So the problem is simpler: offb gets the palette or pixel format wrong
and loading radeonfb afterwards doesn't help because it doesn't take
over from offb.

On the installed system, the radeon driver is auto-loaded (although it
will still fail initialisation if the firmware is missing, except for
old ATI chips).  It can take over from offb and (presumably) gets the
colours right.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.

[toc] | [prev] | [next] | [standalone]

#54248

On Tue, May 31, 2016 at 6:22 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote:
>> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> > Control: reassign src:linux 4.5.4-1
>> > Control: tag -1 help
>> >
>> > On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
>> > > Package: linux-image-4.5.0-2-powerpc
>> > > Version: 4.5.4-1
>> > >
>> > > During Debian installation the background color is inverted on PPC system.
>> > > At least on my Mac Mini G4, the default background color shows up as red
>> > > from begining to start (only the last screen turn blue).
>> > >
>> > > Looking at the module loaded during the installation I can see radeonfb,
>> > > which I suspect is the one responsible for handling of `/dev/fb0`.
>> > >
>> > > After installation I tried reproducing this color inversion without any
>> > > luck so far.
>> > >
>> > > It is non-trivial to `rmmod radeon`, so instead I used (and rebooted):
>> > >
>> > > $ cat /etc/modprobe.d/radeon.conf
>> > > blacklist radeon
>> > >
>> > > However upon reboot `/dev/fb0` is already setup.
>> >
>> > Of course, because there is no character-based display mode on Power
>> > Macs (in general).
>> >
>> > > But neither radeonfb nor
>> > > radeon module seems to be loaded (using lsmod) but lspci output is rather
>> > > confusing [*].
>> >
>> > lspci lists all kernel modules that match a particular PCI device's ID,
>> > and separately whether any kernel driver is currently bound to the
>> > device.
>> >
>> > > I can also see:
>> > >
>> > > $ cat /proc/fb
>> > > 0 OFfb ATY,RockHo
>> >
>> > As I would expect, the generic Open Firmware framebuffer driver is
>> > behind /dev/fb0.  If a hardware-specific driver is loaded, that will
>> > take over from it.
>>
>> Thank you ! Ok now I understand. d-i tried to modprobe `radeonfb` but
>> fails since framebuffer is already taken by Open Firmare, as can be
>> seen in the dmesg log:
> [...]
>
> That's *not* what I thought was happening.  I was expecting radeonfb to
> do something like this (in the radeon DRM driver):
> https://sources.debian.net/src/linux/4.5.4-1/drivers/gpu/drm/radeon/radeon_drv.c/?hl=336#L336
> and maybe to query offb about the existing framebuffer properties first.
>
> So the problem is simpler: offb gets the palette or pixel format wrong
> and loading radeonfb afterwards doesn't help because it doesn't take
> over from offb.

Ok.

Too bad offb is built into the kernel (not as module):

$ grep FB_OF /boot/config-4.5.0-2-powerpc
CONFIG_FB_OF=y

I'll see if I can reuse any of the existing hack [*] for my Mac Mini G4.

[*]
$ grep -i hack drivers/video/fbdev/offb.c
/* Supported palette hacks */
/* Definitions used by the Avivo palette hack */
static void offb_init_palette_hacks(struct fb_info *info, struct
device_node *dp,
offb_init_palette_hacks(info, dp, name, address);
/* Hack for when BootX is passing us */
* a display (just not the palette hacks).

[toc] | [prev] | [next] | [standalone]

#54249

[Multipart message — attachments visible in raw view] — view raw

On Tue, 31 May 2016 11:54:54 +0100 Ben Hutchings <ben@decadent.org.uk>
wrote:
> On Tue, 2016-05-31 at 07:23 +0200, Geert Stappers wrote:

[...]

> > I don't know what PowerPC hardware is available these days.
> [...]
> 
> Looking at who's participating in OpenPOWER, I think it's mostly
> servers now. (There are still low-end PowerPC chips going into
> embedded systems, but I don't believe Debian has ever supported them.
> We require Open Firmware.) It looks like a lot of those are custom-
> made for large HPC and cloud customers, but Tyan has some that are
> generally available, like this:
> http://www.tyan.com/campaign/openpower/
> 
> There are some PowerPC systems available for remote use by developers:
> http://developers.openpowerfoundation.org/explore
> 


This Tyan development reference platform offer looks interesting.

And still, the most appealing option for an individual Free software
developer to put their hands on a fully functional big-endian machine is
to get a PowerPC Mac, YDL PowerStation or Pegasos II from ebay and
install Debian on it.

IBM Power machines are mostly out of reach to individuals, price-wise
and formal-customer-agreement-requirement-wise.

Milan

[toc] | [prev] | [next] | [standalone]

#55005 — Processed: localechooser: image display inverts red and blue color

Processing control commands:

> reassign -1 localechooser 2.68
Bug #825840 [src:linux] 0 OFfb ATY,RockHo: image display inverts red and blue color
Bug reassigned from package 'src:linux' to 'localechooser'.
No longer marked as found in versions linux/4.5.4-1.
Ignoring request to alter fixed versions of bug #825840 to the same values previously set
Bug #825840 [localechooser] 0 OFfb ATY,RockHo: image display inverts red and blue color
Marked as found in versions localechooser/2.68.
> retitle -1 localechooser: image display inverts red and blue color
Bug #825840 [localechooser] 0 OFfb ATY,RockHo: image display inverts red and blue color
Changed Bug title to 'localechooser: image display inverts red and blue color' from '0 OFfb ATY,RockHo: image display inverts red and blue color'.

-- 
825840: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825840
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#55028 — Processed: Re: Bug#825840: localechooser: image display inverts red and blue color

Processing control commands:

> reassign -1 linux
Bug #825840 [bogl-bterm] bterm: inverts red and blue in localechooser
Bug reassigned from package 'bogl-bterm' to 'linux'.
No longer marked as found in versions bogl/0.1.18-4 and bogl/0.1.18-11.
Ignoring request to alter fixed versions of bug #825840 to the same values previously set

-- 
825840: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825840
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#55097 — Processed: offb/ATY,RockHopper: inverts red and blue in bterm

Processing control commands:

> retitle -1 offb/ATY,RockHopper: inverts red and blue in bterm
Bug #825840 [linux] bterm: inverts red and blue in localechooser
Changed Bug title to 'offb/ATY,RockHopper: inverts red and blue in bterm' from 'bterm: inverts red and blue in localechooser'.
> tags -1 - patch
Bug #825840 [linux] offb/ATY,RockHopper: inverts red and blue in bterm
Removed tag(s) patch.
> tags -1 + confirmed upstream
Bug #825840 [linux] offb/ATY,RockHopper: inverts red and blue in bterm
Added tag(s) confirmed and upstream.
> forwarded -1 http://www.spinics.net/lists/linux-fbdev/msg21179.html
Bug #825840 [linux] offb/ATY,RockHopper: inverts red and blue in bterm
Set Bug forwarded-to-address to 'http://www.spinics.net/lists/linux-fbdev/msg21179.html'.

-- 
825840: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825840
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web