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

[Milan Kupcevic]

On Tue, 31 May 2016 11:54:54 +0100 Ben Hutchings 
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



signature.asc
Description: OpenPGP digital signature

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

[Mathieu Malaterre]

On Tue, May 31, 2016 at 6:22 PM, Ben Hutchings  wrote:
> On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote:
>> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings  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).

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

[Ben Hutchings]

On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote:
> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings  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.

signature.asc
Description: This is a digitally signed message part

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

[Geert Stappers]

On Tue, May 31, 2016 at 05:34:24PM +0200, Mathieu Malaterre wrote:
> [...]
> Maybe the palette is setup backward for powerpc.

FWIW that triggered here: big endian vs litte endian

Now shared that thought with you


HTH
Geert Stappers
-- 
Leven en laten leven

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

[Mathieu Malaterre]

On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings  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:

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

One way to double check if color inversion happen using `radeonfb` is
simply to type at boot: command line:

install32 nomodeset video=offb:off

(instead of the default `install32`).

At least I know where too look now. Maybe the palette is setup
backward for powerpc.

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

[Lennart Sorensen]

On Tue, May 31, 2016 at 07:23:38AM +0200, Geert Stappers wrote:
> I had fun with PowerPC Macintosh. Something about eight years ago.
> Maybe ten years ago.
> 
> Ben is right where he wrote "no-one is likely to help with PowerPC"

Actually I think there are people who help with PowerPC.  I think it is
more accurate that you wouldn't get much help with PowerMacs anymore,
since they are just so obsolete.  IBM pseries and freescale boards on
the other hand are quite actively in use.

> I would have wrote "be aware that you might on your own", now doing so.
> 
> I don't know what PowerPC hardware is available these days.  But those who
> want to spend time on PowerPC software should go there way.  Remember that
> Linus Torvalds started on is own.

Powerpc in general works fine.  Graphical desktops on them on the other
hand is rarely used by anyone at this point it seems.

-- 
Len Sorensen

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

[Ben Hutchings]

On Tue, 2016-05-31 at 07:23 +0200, Geert Stappers wrote:
> On Mon, May 30, 2016 at 08:50:46PM +0100, Ben Hutchings wrote:
> > On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
> [ ... ]
> > > 
> > > I'd like to keep this bug open until I find what is going on with this
> > > color inversion on PPC/ATI.
> > [...]
> > 
> > I'm sorry, but no-one is likely to help with this. The Linux port to
> > Power Macs is no longer actively developed and no-one on the Debian
> > kernel team looks after them.
> 
> I had fun with PowerPC Macintosh. Something about eight years ago.
> Maybe ten years ago.
> 
> Ben is right where he wrote "no-one is likely to help with PowerPC"
> 
> I would have wrote "be aware that you might on your own", now doing so.
> 
> 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

Ben.

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



signature.asc
Description: This is a digitally signed message part

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

[Geert Stappers]

On Mon, May 30, 2016 at 08:50:46PM +0100, Ben Hutchings wrote:
> On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote:
[ ... ]
> > 
> > I'd like to keep this bug open until I find what is going on with this
> > color inversion on PPC/ATI.
> [...]
> 
> I'm sorry, but no-one is likely to help with this. The Linux port to
> Power Macs is no longer actively developed and no-one on the Debian
> kernel team looks after them.

I had fun with PowerPC Macintosh. Something about eight years ago.
Maybe ten years ago.

Ben is right where he wrote "no-one is likely to help with PowerPC"

I would have wrote "be aware that you might on your own", now doing so.

I don't know what PowerPC hardware is available these days.  But those who
want to spend time on PowerPC software should go there way.  Remember that
Linus Torvalds started on is own.


Groeten
Geert Stappers
-- 
Leven en laten leven

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

[Ben Hutchings]

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.

> 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.
[...]

I'm sorry, but no-one is likely to help with this.  The Linux port to
Power Macs is no longer actively developed and no-one on the Debian
kernel team looks after them.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


signature.asc
Description: This is a digitally signed message part

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

[Mathieu Malaterre]

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 :00:10.0 -vvx
: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- SERR- 
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