Re: X on old (non-x86) Linux guests

[Dr. David Alan Gilbert]

* BALATON Zoltan (balaton@eik.bme.hu) wrote:
> Hello,
> 
> On Mon, 26 Apr 2021, Dr. David Alan Gilbert wrote:
> >  Over the weekend I got a Red Hat 6.x (not RHEL!) for Alpha booting
> > under QEMU which was pretty neat.  But I failed to find a succesful
> > combination to get X working; has anyone any suggestions?
> 
> Adding Andrew who has experimented with old X framebuffer so he may remember
> something more but that was on x86.
> 
> >  That distro was from around 2000; the challenge is since we don't have
> > VESA on non-x86, we can't change mode that way, so generic XF86_SVGA
> > doesn't want to play with any of the devices.
> > 
> >  I also tried the ati device, but the accelerated mach64 driver
> > didn't recognise that ID.
> 
> The ati-vga partially emulates an ATI Rage128 Pro so it won't work with
> mach64 driver that is older and while functionally similar has different
> registers. You probably need to load aty128fb and then set a mode with fbset
> then may need to edit X conf but I forgot which option was neded, something
> about UseFb or similar so it won't try to change mode itself but use the
> already set Linux FB because otherwise it did not detect the card properly
> but I don'r remember the details so may be wrong. Also some 2D accel is
> emulated so may work without disabling it but I think has some bugs so it
> may have glitches.
> 
> >  Has anyone found any combo that works?
> > I suspect using one of the existing devices, lying about PCI ID, and
> > then turning off all accelerations might have a chance but I've not got
> > that far.
> 
> Changing the PCI ID may not help as these ATI chips have different registers
> so only compatible with the right drivers. I've tried to use current ati-vga
> with a Mac ROM that expects mach64 but it did not work.
> 
> It may help to add -trace enable="ati*" and maybe also enable some debug
> defines in ati_int.h to see if it accesses the card at all but with the
> right driver that works with Rage128Pro it should produce some picture at
> least in fb console and we could run X with it on x86 before.

Thanks.

> More info on ati-vga is here:
> https://osdn.net/projects/qmiga/wiki/SubprojectAti
> 
> By the way, last time I've experimented with it I've found that mouse
> pointer getting out of sync and jumping around is probably a result of mouse
> acceleration on the host is not taken into account when tracking guest
> pointer position. Is that possible and is there a way to fix it?

That's actually really tricky; on modern guests we recommend using a
usb-tablet emulation rather than a mouse; there's no logical
relationship between the deltas sent by a mouse and the amount which a
guest moves a pointer by.  Many OSs have mouse acceleration and other 
behaviours that are non-linear - also if you lose a mous event somewhere
then you get a slip.

Some notes on this weekends playing; I still haven't actually got X
going though.

My initial boot was:

./alpha-softmmu/qemu-system-alpha -m 512M -kernel ~/alpha/generic.kernel   -vga 
none -cpu ev67-alpha-cpu -smp 1  -append 'console=ttyS0 root=/dev/hda'  -serial 
stdio -drive if=ide,file=/home/dg/alpha/redhat-6.2-alpha.iso
That should be the kernel from
http://archive.download.redhat.com/pub/redhat/linux/6.2/en/os/alpha/kernels/
and the iso from 
http://archive.download.redhat.com/pub/redhat/linux/6.2/en/iso/alpha/

Then moving up to being able to do an install with:
./alpha-softmmu/qemu-system-alpha -m 512M -kernel ~/alpha/generic.kernel    
-cpu ev67-alpha-cpu -smp 1  -append 'root=/dev/hdb' -drive 
if=ide,file=./alpha-main.qcow2 -drive 
if=ide,file=/home/dg/alpha/redhat-6.2-alpha.iso

Note that kernel doesn't match the one installed, so you can't load
modules.
Later I installed the SMP kernel rpm, copied that out (via tar to
a blank image disk) and booted using:

./alpha-softmmu/qemu-system-alpha -m 512M -kernel 
~/alpha/extract/boot/vmlinux-2.2.14-6.0smp    -cpu ev67-alpha-cpu -smp 4  
-append 'root=/dev/hda2' -drive if=ide,file=./alpha-main.qcow2 -drive 
if=ide,file=/home/dg/alpha/redhat-6.2-alpha.iso -device ati-vga -nic 
user,model=tulip

and that's actually pretty neat, 4 cores of alpha and 512MB RAM; it's
pretty fast; only takes about an hour to rebuild X!

Other SCSI adapters are all disliked:
DC390: 1 adapters found
scsi0 : Tekram DC390/AM53C974 V2.0d 1998/12/25
scsi : 1 host.
Unable to handle kernel paging request at virtual address 0000000000000004
swapper(1): Oops -1
--
ncr53c810 - cache test failed
-
sym53c8xx: at PCI bus 0, device 2, function 0
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c895a detected
sym53c895a-0: rev=0x00, base=0x9020000, io_port=0xb000, irq=28
sym53c895a-0: NCR clock is 0KHz, 0KHz
sym53c895a-0: ID 7, Fast-40, Parity Checking
sym53c895a-0: on-chip RAM at 0x9022000
sym53c895a-0: restart (scsi reset).
sym53c895a-0: handling phase mismatch from SCRIPTS.
sym53c895a-0: Downloading SCSI SCRIPTS.
sym53c895a-0: unexpected disconnect
sym53c895a-0: unexpected disconnect

---
The only fb built into that kernel was TGA; the ATY fb it has in that
kernel source doesn't have overlapping PCI IDs with the ones we
currently emualted (and it oops'd on load).

The 'ati' and 'cirrus' drivers in vga256 X server both
had chunks of X86 asm (not just in blits) so wouldn't build.
The 'r128' driver did build with some hackery; and with:

Section "Device"
  Identifier "svgahack"
  ...
  Chipset "r128"
  ChipID 0x5245
  Option "NoAccel"
  Option "SWCursor"
  VideoRam 4096
EndSection

actually changes resolution - but then falls over with a stream of
machine checks;  I'm wondering if something isn't happy with the Alpha's
IOMMU/mapping - maybe that also explains all the SCSI controllers being
unhappy as well.
(Or maybe it's the build hacks I had to do to r128 to get it to
build...)

So I think the only other thing there is to move to a newer kernel
with a fb driver that has a better chance.

(My real alpha has a 3dfx 3000 in as I remember, and that was from the
end of '97)

Dave


> Regards,
> BALATON Zoltan
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK