On Mon, 2016-05-30 at 19:06 +0200, Mathieu Malaterre wrote: > 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`: [...] > 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. It sounds like offb has an incorrect view of what order the RGB components are stored in memory in the framebuffer set up by Open Firmware. When radeonfb is loaded, it take over this framebuffer and accept the incorrect description that offb gave it (I think). If you disable offb, radeonfb won't know anything about the Open Firmware framebuffer. It will create a fresh framebuffer and set the screen mode itself, so they are consistent. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer
Attachment:
signature.asc
Description: This is a digitally signed message part