Re: [Qemu-ppc] Booting Lubuntu 16.04 on qemu-system-ppc produces errors

[Andrew Randrianasulu]

В сообщении от Tuesday 09 July 2019 19:27:30 BALATON Zoltan написал(а):
> On Tue, 9 Jul 2019, Andrew Randrianasulu wrote:
> > (gdb) run qemu-system-ppc -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> > /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display 
> > sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 
> > -device ES1370
> > Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc qemu-system-ppc 
> > -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> > /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display 
> > sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 
> > -device ES1370
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > [New Thread 0xf560cb40 (LWP 19193)]
> > qemu-system-ppc: qemu-system-ppc: Could not open 'qemu-system-ppc': No such 
> > file or directory
> > [Thread 0xf560cb40 (LWP 19193) exited]
> > [Inferior 1 (process 19189) exited with code 01]
> > (gdb) run  -M mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> > /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display 
> > sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 
> > -device ES1370
> > Starting program: /dev/shm/qemu/ppc-softmmu/qemu-system-ppc -M 
> > mac99,via=pmu -L ../queue-vga/pc-bios -cdrom 
> > /mnt/sdb1/PPC-img/lubuntu-16.04-desktop-powerpc.iso -m 512  -display 
> > sdl,gl=on -vga std -d guest_errors,unimp -boot d -cpu G4 -g 1024x768x24 
> > -device ES1370
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > [New Thread 0xf560cb40 (LWP 19200)]
> > [New Thread 0xf4c1ab40 (LWP 19201)]
> > [New Thread 0xec1b7b40 (LWP 19202)]
> > [New Thread 0xc5962b40 (LWP 19204)]
> > [Thread 0xf4c1ab40 (LWP 19201) exited]
> > [New Thread 0xf4c1ab40 (LWP 19219)]
> >
> > Thread 4 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0xec1b7b40 (LWP 19202)]
> > 0xf290e844 in code_gen_buffer ()
> > (gdb) bt full
> > #0  0xffffffff in code_gen_buffer ()
> > #1  0x567054ee in cpu_exec (itb=<optimized out>, cpu=<optimized out>) at 
> > /dev/shm/qemu/accel/tcg/cpu-exec.c:173
> 
> This seems to crash in TCG which I don't know how to debug and looks not 
> related to any of my patches. Hopefully someone on the list can help. I 
> wonder if this is related to recent AltiVec optimisations that went on for 
> the last two releases. Maybe you could try earlier release (4.0.0 and 
> 3.1.0) and if that works could try to bisect (although since there were 
> some bugs in previous versions things might fail differently or not work 
> with those versions so this may make bisecting difficult).

I think this is one of those 32-bit only crashes, because I booted same iso 
with 64-bit qemu without crash ...
Will try bisect later.

> 
> >>> this booted up to (corrupted colors, but this was using fbdev X driver) 
> >>> LXde desktop.
> >>
> >> The corrupted colors are because some mismatch with frame buffer
> >> endianness. This iso uses 15 bpp mode. Reverting commit a38127414
> >> (ati-vga: Fix frame buffer endianness for big endian target) fixes this
> >> but that breaks MorphOS Rage128 driver so one of these is probably wrong
> >> (and Linux, or OpenBIOS if it uses open firmware console is more likely to
> >> be wrong here).
> >
> > Colors are fine with -vga std, but probably just any other card on 
> > different endiannes host/gues combination will give some fanky color
> 
> QEMU vga device has some assumptions about endianness and sets frame 
> buffer to big endian if emulating big endian machine:
> 
> https://git.qemu.org/?p=qemu.git;a=blob;f=hw/display/vga.c;h=910a23c12ef720a0cd9b14ce2b81e3c300015508;hb=HEAD#l2224
> 
> I don't know why is that but this is wrong for ati-vga which is always 
> little endian (like PCI devices in general, unless accessing frame buffer 
> over a big endian aperture window) so this is what commit a38127414 
> overrides for ati-vga but leaves VGA behaviour unchanged as I don't know 
> why was that added and if correct or not (but if Linux has same 
> assumptions only being tested on QEMU it might work but not sure it works 
> on real hardware).
> 
> > I  booted same Lubuntu and swicthed it via xorg.conf to 24 bpp - 
> > transparancy (?) becomes intensive blue and offset all other colors..
> 
> If guest puts image in big endian to frame buffer but it's really little 
> endian then all colors will be off in all direct color depths other than 8 
> bit which stores only one byte per pixel and uses indexed color so there 
> won't be endianness problem. So this is not surprising after finding that 
> 15 bpp is also wrong. Then 32 and 24 bpps would likely have same problem.
> 
> > Note, if you want to have r128 driver in LiveCD you better to update it 
> > (sudo apt update), and then choose r128-hwe
> > (it will require new xorg-core, so make sure toadd input-evdev, because 
> > removing old xserver will remove drivers too).
> >
> > Unfortunately, none of tested 8, 16, 24 bpp X variations (with r128 driver 
> > and UseFBDev option, and acceleration ON)
> > resulted in image on screen. X and some fxce programs started up (via 
> > startx), but screen was black, not even cursor was  visible :/
> 
> No idea why but instead of trying to update and fix this image I'd rather 
> test with something known to work on real hardware to avoid chasing bugs 
> in guest code.
> 
> >> Or maybe they access the frame buffer differently as the
> >> card has support for big-endian aperture which may not be emulated
> >> correctly yet. I think this should be checked on a real PowerMac3,1 to see
> >> which of these isos actually work on real hardware to make sure we're
> >> testing with correct guest code.
> >
> > Unfortunately, I have no real ppc machine :/
> 
> Again hope someone on the list might have a PowerMac3,1 and some time to 
> test these isos to know which one works and which has also problem on real 
> hardware. I've found hints that Debian (and so distros based on it) may 
> have problems:
> 
> https://wiki.debian.org/PowerPC/FAQ#How_do_I_get_graphics_working.3F
> 
> and the bug referenced for Rage128 specifically mentions Rage 128 PRO Mac 
> and PC versions so there could also be bugs in guest code which makes it 
> difficult to test emulation with that.

I'll try to set up emulated ppc machine with earlier (XAA-supporting) 
X-server/r128 driver, XAA was less buggy for me on i386
so may be it will work better for emulated ppc too?

I asked on russian linux website if anyone has Mac PPC and/or r128 card to 
test.. Two users might have x86 version of card, 
but so far they recommended me to find used (PCI) card somewhere ....

> 
> Regards,
> BALATON Zoltan
>