[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] Booting Lubuntu 16.04 on qemu-system-ppc produces errors
From: |
Andrew Randrianasulu |
Subject: |
Re: [Qemu-ppc] Booting Lubuntu 16.04 on qemu-system-ppc produces errors |
Date: |
Wed, 10 Jul 2019 06:40:35 +0300 |
User-agent: |
KMail/1.9.10 |
В сообщении от 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
>