* BALATON Zoltan (bala...@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 / dgilb...@redhat.com / Manchester, UK
