Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color
On Tue, 31 May 2016 11:54:54 +0100 Ben Hutchingswrote: > 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
On Tue, May 31, 2016 at 6:22 PM, Ben Hutchingswrote: > 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
On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote: > On Mon, May 30, 2016 at 9:50 PM, Ben Hutchingswrote: > > 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
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
On Mon, May 30, 2016 at 9:50 PM, Ben Hutchingswrote: > 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
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
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
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
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
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