* X on old (non-x86) Linux guests @ 2021-04-26 10:01 Dr. David Alan Gilbert 2021-04-26 13:48 ` Thomas Huth ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: Dr. David Alan Gilbert @ 2021-04-26 10:01 UTC (permalink / raw) To: qemu-devel, richard.henderson, balaton, kraxel Hi, 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? 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. 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. [Alpha took a bit of a fight; none of the SCSI controllers were happy, but the CMD646 worked well enough to install off a CD image from a -kernel passed in ] Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 10:01 X on old (non-x86) Linux guests Dr. David Alan Gilbert @ 2021-04-26 13:48 ` Thomas Huth 2021-04-26 14:14 ` Dr. David Alan Gilbert 2021-04-26 14:04 ` Laurent Vivier ` (2 subsequent siblings) 3 siblings, 1 reply; 15+ messages in thread From: Thomas Huth @ 2021-04-26 13:48 UTC (permalink / raw) To: Dr. David Alan Gilbert, qemu-devel, richard.henderson, balaton, kraxel, Thomas Huth On 26/04/2021 12.01, Dr. David Alan Gilbert wrote: > Hi, > 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? > > 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. > > Has anyone found any combo that works? Not sure if it is of any help, but IIRC the advent calendar image #4 from the 2014 edition also uses an ancient Red Hat image with X, and it still seems to be working with recent versions of QEMU: https://www.qemu-advent-calendar.org/2014/#day-4 Maybe you could copy the config from that image? Thomas ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 13:48 ` Thomas Huth @ 2021-04-26 14:14 ` Dr. David Alan Gilbert 0 siblings, 0 replies; 15+ messages in thread From: Dr. David Alan Gilbert @ 2021-04-26 14:14 UTC (permalink / raw) To: Thomas Huth; +Cc: Thomas Huth, kraxel, richard.henderson, qemu-devel * Thomas Huth (th.huth@posteo.de) wrote: > On 26/04/2021 12.01, Dr. David Alan Gilbert wrote: > > Hi, > > 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? > > > > 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. > > > > Has anyone found any combo that works? > > Not sure if it is of any help, but IIRC the advent calendar image #4 from > the 2014 edition also uses an ancient Red Hat image with X, and it still > seems to be working with recent versions of QEMU: > > https://www.qemu-advent-calendar.org/2014/#day-4 > > Maybe you could copy the config from that image? That's using the VESA driver, which we generally don't have on non-x86. Dave > Thomas > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 10:01 X on old (non-x86) Linux guests Dr. David Alan Gilbert 2021-04-26 13:48 ` Thomas Huth @ 2021-04-26 14:04 ` Laurent Vivier 2021-04-26 14:18 ` Dr. David Alan Gilbert 2021-04-26 15:26 ` BALATON Zoltan 2021-04-26 15:53 ` Gerd Hoffmann 3 siblings, 1 reply; 15+ messages in thread From: Laurent Vivier @ 2021-04-26 14:04 UTC (permalink / raw) To: Dr. David Alan Gilbert, qemu-devel, richard.henderson, balaton, kraxel On 26/04/2021 12:01, Dr. David Alan Gilbert wrote: > Hi, > 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? > > 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. > > 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. > > [Alpha took a bit of a fight; none of the SCSI controllers were > happy, but the CMD646 worked well enough to install off a CD image > from a -kernel passed in ] > Did you try to use kernel framebuffer with X fbdev driver? Thanks, Laurent ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 14:04 ` Laurent Vivier @ 2021-04-26 14:18 ` Dr. David Alan Gilbert 2021-04-26 14:54 ` Laurent Vivier 0 siblings, 1 reply; 15+ messages in thread From: Dr. David Alan Gilbert @ 2021-04-26 14:18 UTC (permalink / raw) To: Laurent Vivier; +Cc: kraxel, richard.henderson, qemu-devel * Laurent Vivier (lvivier@redhat.com) wrote: > On 26/04/2021 12:01, Dr. David Alan Gilbert wrote: > > Hi, > > 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? > > > > 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. > > > > 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. > > > > [Alpha took a bit of a fight; none of the SCSI controllers were > > happy, but the CMD646 worked well enough to install off a CD image > > from a -kernel passed in ] > > > > Did you try to use kernel framebuffer with X fbdev driver? I hadn't, but how do I get it into fb mode - vga=ask doesn't work, so again I don't think I can get into graphics. Dave > Thanks, > Laurent -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 14:18 ` Dr. David Alan Gilbert @ 2021-04-26 14:54 ` Laurent Vivier 0 siblings, 0 replies; 15+ messages in thread From: Laurent Vivier @ 2021-04-26 14:54 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: kraxel, richard.henderson, qemu-devel On 26/04/2021 16:18, Dr. David Alan Gilbert wrote: > * Laurent Vivier (lvivier@redhat.com) wrote: >> On 26/04/2021 12:01, Dr. David Alan Gilbert wrote: >>> Hi, >>> 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? >>> >>> 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. >>> >>> 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. >>> >>> [Alpha took a bit of a fight; none of the SCSI controllers were >>> happy, but the CMD646 worked well enough to install off a CD image >>> from a -kernel passed in ] >>> >> >> Did you try to use kernel framebuffer with X fbdev driver? > > I hadn't, but how do I get it into fb mode - vga=ask doesn't work, so > again I don't think I can get into graphics. In kernel 2.2, it seems to be "video=[FB]", perhaps video=atyfb ? thanks, Laurent ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 10:01 X on old (non-x86) Linux guests Dr. David Alan Gilbert 2021-04-26 13:48 ` Thomas Huth 2021-04-26 14:04 ` Laurent Vivier @ 2021-04-26 15:26 ` BALATON Zoltan 2021-04-28 1:19 ` Andrew Randrianasulu 2021-05-04 11:07 ` Dr. David Alan Gilbert 2021-04-26 15:53 ` Gerd Hoffmann 3 siblings, 2 replies; 15+ messages in thread From: BALATON Zoltan @ 2021-04-26 15:26 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: Andrew Randrianasulu, richard.henderson, qemu-devel, kraxel 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. 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? Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 15:26 ` BALATON Zoltan @ 2021-04-28 1:19 ` Andrew Randrianasulu 2021-04-28 1:37 ` Andrew Randrianasulu 2021-05-04 11:07 ` Dr. David Alan Gilbert 1 sibling, 1 reply; 15+ messages in thread From: Andrew Randrianasulu @ 2021-04-28 1:19 UTC (permalink / raw) To: BALATON Zoltan Cc: kraxel, richard.henderson, Dr. David Alan Gilbert, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3386 bytes --] On Monday, April 26, 2021, 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. Sorry, I still away from my desktop (with notes/logs), not sure when return.. I do not think I tried something that old.. Kernel 2.2 i guess, before any attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx attempted to use that (as it tries by default in much newer distros) I tried Last debian for alpha, (5.0.x?) on qemu, it had bugs in cirrusfb in 2.6.26 Kernel so i compiled like 2.6.32.last inside emulated system.. This made fb works, But still there was no X for me... (can't recall exact error - May be even sigabort or sigbus - but do not count on my memory on this... /) Notes i used for launching qemu - https://virtuallyfun.com/wordpress/2014/02/19/alpha-linux-on-qemu/ But Sadly pre-compressed disk image from that post really gone (it uses funny error Page telling you to use login/password, yet file can't be downloaded...) > 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. > > More info on ati-vga is here: https://osdn.net/projects/qmig > a/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? > > Regards, > BALATON Zoltan > [-- Attachment #2: Type: text/html, Size: 4450 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-28 1:19 ` Andrew Randrianasulu @ 2021-04-28 1:37 ` Andrew Randrianasulu 2021-04-28 12:04 ` BALATON Zoltan 0 siblings, 1 reply; 15+ messages in thread From: Andrew Randrianasulu @ 2021-04-28 1:37 UTC (permalink / raw) To: BALATON Zoltan Cc: kraxel, richard.henderson, Dr. David Alan Gilbert, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3753 bytes --] On Wednesday, April 28, 2021, Andrew Randrianasulu <randrianasulu@gmail.com> wrote: > > > On Monday, April 26, 2021, 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. > > > > Sorry, I still away from my desktop (with notes/logs), not sure when > return.. > I do not think I tried something that old.. Kernel 2.2 i guess, before any > attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx > attempted to use that (as it tries by default in much newer distros) > > I tried Last debian for alpha, (5.0.x?) on qemu, it had bugs in cirrusfb > in 2.6.26 Kernel so i compiled like 2.6.32.last inside emulated system.. > This made fb works, But still there was no X for me... (can't recall exact > error - May be even sigabort or sigbus - but do not count on my memory on > this... /) > > Notes i used for launching qemu - > https://virtuallyfun.com/wordpress/2014/02/19/alpha-linux-on-qemu/ > But Sadly pre-compressed disk image from that post really gone (it uses > funny error Page telling you to use login/password, yet file can't be > downloaded...) > Upd: https://web.archive.org/web/20191021110430/https://vpsland.superglobalmegacorp.com/old/install/linux/DecAlpha/alpha-linux.7z This May give you kernel/initrd/disk image.. > > >> 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. >> >> More info on ati-vga is here: https://osdn.net/projects/qmig >> a/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? >> >> Regards, >> BALATON Zoltan >> > [-- Attachment #2: Type: text/html, Size: 5261 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-28 1:37 ` Andrew Randrianasulu @ 2021-04-28 12:04 ` BALATON Zoltan 2021-04-28 13:18 ` Andrew Randrianasulu 2021-04-28 13:44 ` Dr. David Alan Gilbert 0 siblings, 2 replies; 15+ messages in thread From: BALATON Zoltan @ 2021-04-28 12:04 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: kraxel, richard.henderson, Andrew Randrianasulu, qemu-devel On Wed, 28 Apr 2021, Andrew Randrianasulu wrote: > On Wednesday, April 28, 2021, Andrew Randrianasulu <randrianasulu@gmail.com> > wrote: >> On Monday, April 26, 2021, BALATON Zoltan <balaton@eik.bme.hu> wrote: >>> 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. >> >> >> >> Sorry, I still away from my desktop (with notes/logs), not sure when >> return.. >> I do not think I tried something that old.. Kernel 2.2 i guess, before any >> attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx >> attempted to use that (as it tries by default in much newer distros) Maybe it would work better with newer RedHat than 6.0? I think I've seen images up to at least 7.1 that supported alpha but I don't know how to boot them. I could get kernel and installer running with -kernel -initrd but did not find the CD on the defailt CMD646 controller (seems to only have driver for one SCSI controller) so I'm not sure how to try this. Trying to just boot from the CD without -kernel -initrd it just stops after displaying "Hello" in top left but that could be something about alpha firmware I don't know how to use. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-28 12:04 ` BALATON Zoltan @ 2021-04-28 13:18 ` Andrew Randrianasulu 2021-04-28 13:44 ` Dr. David Alan Gilbert 1 sibling, 0 replies; 15+ messages in thread From: Andrew Randrianasulu @ 2021-04-28 13:18 UTC (permalink / raw) To: BALATON Zoltan Cc: kraxel, richard.henderson, Dr. David Alan Gilbert, qemu-devel [-- Attachment #1: Type: text/plain, Size: 2025 bytes --] On Wednesday, April 28, 2021, BALATON Zoltan <balaton@eik.bme.hu> wrote: > On Wed, 28 Apr 2021, Andrew Randrianasulu wrote: > >> On Wednesday, April 28, 2021, Andrew Randrianasulu < >> randrianasulu@gmail.com> >> wrote: >> >>> On Monday, April 26, 2021, BALATON Zoltan <balaton@eik.bme.hu> wrote: >>> >>>> 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. >>>> >>> >>> >>> >>> Sorry, I still away from my desktop (with notes/logs), not sure when >>> return.. >>> I do not think I tried something that old.. Kernel 2.2 i guess, before >>> any >>> attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx >>> attempted to use that (as it tries by default in much newer distros) >>> >> > Maybe it would work better with newer RedHat than 6.0? I think I've seen > images up to at least 7.1 that supported alpha but I don't know how to boot > them. I could get kernel and installer running with -kernel -initrd but did > not find the CD on the defailt CMD646 controller (seems to only have driver > for one SCSI controller) so I'm not sure how to try this. Trying to just > boot from the CD without -kernel -initrd it just stops after displaying > "Hello" in top left but that could be something about alpha firmware I > don't know how to use. I think alpha firmware is incomplete, not like real Alpha firmware.. I found you can try to install rh 7.1 on alpha from Hard drive or network (ftp/http) https://web.archive.org/web/20011120235248/http://www.redhat.com/docs/manuals/linux/RHL-7.1-Manual/alpha-install-guide/s1-guimode-sel-method.html But this requires network boot disk... Not sure from where you can get it... > > Regards, > BALATON Zoltan > [-- Attachment #2: Type: text/html, Size: 3183 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-28 12:04 ` BALATON Zoltan 2021-04-28 13:18 ` Andrew Randrianasulu @ 2021-04-28 13:44 ` Dr. David Alan Gilbert 2021-04-29 1:07 ` BALATON Zoltan 1 sibling, 1 reply; 15+ messages in thread From: Dr. David Alan Gilbert @ 2021-04-28 13:44 UTC (permalink / raw) To: BALATON Zoltan Cc: kraxel, richard.henderson, Andrew Randrianasulu, qemu-devel * BALATON Zoltan (balaton@eik.bme.hu) wrote: > On Wed, 28 Apr 2021, Andrew Randrianasulu wrote: > > On Wednesday, April 28, 2021, Andrew Randrianasulu <randrianasulu@gmail.com> > > wrote: > > > On Monday, April 26, 2021, BALATON Zoltan <balaton@eik.bme.hu> wrote: > > > > 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. > > > > > > > > > > > > Sorry, I still away from my desktop (with notes/logs), not sure when > > > return.. > > > I do not think I tried something that old.. Kernel 2.2 i guess, before any > > > attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx > > > attempted to use that (as it tries by default in much newer distros) > > Maybe it would work better with newer RedHat than 6.0? I think I've seen > images up to at least 7.1 that supported alpha but I don't know how to boot > them. I could get kernel and installer running with -kernel -initrd but did > not find the CD on the defailt CMD646 controller (seems to only have driver > for one SCSI controller) so I'm not sure how to try this. Trying to just > boot from the CD without -kernel -initrd it just stops after displaying > "Hello" in top left but that could be something about alpha firmware I don't > know how to use. I ended up using -kernel/-initrd and passed the cdrom as an image to hdb rather than with -cdrom; as you say the cmd646 didn't like the cdrom. (Where I'm pretty sure my real Alpha does have a CDROM connected to it's cmd646). And none of the SCSI controllers would work. I'll make some notes on my command line this weekend and post them next week; I'll try the X suggestions as well. Dave > Regards, > BALATON Zoltan > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-28 13:44 ` Dr. David Alan Gilbert @ 2021-04-29 1:07 ` BALATON Zoltan 0 siblings, 0 replies; 15+ messages in thread From: BALATON Zoltan @ 2021-04-29 1:07 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: kraxel, richard.henderson, Andrew Randrianasulu, qemu-devel On Wed, 28 Apr 2021, Dr. David Alan Gilbert wrote: > * BALATON Zoltan (balaton@eik.bme.hu) wrote: >> On Wed, 28 Apr 2021, Andrew Randrianasulu wrote: >>> On Wednesday, April 28, 2021, Andrew Randrianasulu <randrianasulu@gmail.com> >>> wrote: >>>> On Monday, April 26, 2021, BALATON Zoltan <balaton@eik.bme.hu> wrote: >>>>> 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. >>>> >>>> >>>> >>>> Sorry, I still away from my desktop (with notes/logs), not sure when >>>> return.. >>>> I do not think I tried something that old.. Kernel 2.2 i guess, before any >>>> attempt at r128 drm Kernel module was written (in 2.4?) and so before ddx >>>> attempted to use that (as it tries by default in much newer distros) >> >> Maybe it would work better with newer RedHat than 6.0? I think I've seen >> images up to at least 7.1 that supported alpha but I don't know how to boot >> them. I could get kernel and installer running with -kernel -initrd but did >> not find the CD on the defailt CMD646 controller (seems to only have driver >> for one SCSI controller) so I'm not sure how to try this. Trying to just >> boot from the CD without -kernel -initrd it just stops after displaying >> "Hello" in top left but that could be something about alpha firmware I don't >> know how to use. > > I ended up using -kernel/-initrd and passed the cdrom as an image to hdb > rather than with -cdrom; as you say the cmd646 didn't like the cdrom. > (Where I'm pretty sure my real Alpha does have a CDROM connected to it's > cmd646). And none of the SCSI controllers would work. Passing the iso as HD did not work with 7.1 iso as that does not seem to be hybrid or the kernel said no partition found. > I'll make some notes on my command line this weekend and post them next > week; I'll try the X suggestions as well. It looks like RedHat versions before 7.1 don't have any fb drivers (not sure those existed on kernel 2.2), the 7.1 iso has kernel 2.4 but only seems to have radeonfb and r128 drm driver which may not work as it probably wants to use 3D or other features we don't emulate yet. If you can't compile a kernel with aty128fb you may try the provided radeonfb with -device ati-vga,model=rv100 but not sure if that will load or work. If you can get picture with that then X using fb driver may work. Not sure if the X r128 driver would work with -device ati-vga but I'm quite sure a radeon driver will not work yet even if you set model to rv100 as those drivers usually want to use memory queues that we don't emulate yet. It also seems there was once a 7.2 iso available from Compaq but could not find a place that still has it so don't know if that would be any better. Maybe you can try other distros too to see if those have more fb drivers. Regards, BALATON Zoltan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 15:26 ` BALATON Zoltan 2021-04-28 1:19 ` Andrew Randrianasulu @ 2021-05-04 11:07 ` Dr. David Alan Gilbert 1 sibling, 0 replies; 15+ messages in thread From: Dr. David Alan Gilbert @ 2021-05-04 11:07 UTC (permalink / raw) To: BALATON Zoltan Cc: Andrew Randrianasulu, richard.henderson, qemu-devel, kraxel * 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: X on old (non-x86) Linux guests 2021-04-26 10:01 X on old (non-x86) Linux guests Dr. David Alan Gilbert ` (2 preceding siblings ...) 2021-04-26 15:26 ` BALATON Zoltan @ 2021-04-26 15:53 ` Gerd Hoffmann 3 siblings, 0 replies; 15+ messages in thread From: Gerd Hoffmann @ 2021-04-26 15:53 UTC (permalink / raw) To: Dr. David Alan Gilbert; +Cc: richard.henderson, qemu-devel On Mon, Apr 26, 2021 at 11:01:26AM +0100, Dr. David Alan Gilbert wrote: > Hi, > 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? > > 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. Well, one trick is to run the vgabios in x86emu. This is what the xorg vesa driver still does today on non-x86 archs (which includes x86_64). I suspect Red Has 6.x is to old for that one though. When was it released exactly? I would guess late 90-ies ... If the vesa path fails the best bet would probably be a driver for the cirrus. There is a cirrusfb driver in the kernel which could be combined with the fbdev xserver, not sure when cirrusfb was merged and whenever redhat enabled the driver though. Also not sure whenever there is an working xfree86 cirrus driver. > I also tried the ati device, but the accelerated mach64 driver > didn't recognise that ID. The virtual ati cards are probably too new. HTH, Gerd ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-05-04 11:09 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-26 10:01 X on old (non-x86) Linux guests Dr. David Alan Gilbert 2021-04-26 13:48 ` Thomas Huth 2021-04-26 14:14 ` Dr. David Alan Gilbert 2021-04-26 14:04 ` Laurent Vivier 2021-04-26 14:18 ` Dr. David Alan Gilbert 2021-04-26 14:54 ` Laurent Vivier 2021-04-26 15:26 ` BALATON Zoltan 2021-04-28 1:19 ` Andrew Randrianasulu 2021-04-28 1:37 ` Andrew Randrianasulu 2021-04-28 12:04 ` BALATON Zoltan 2021-04-28 13:18 ` Andrew Randrianasulu 2021-04-28 13:44 ` Dr. David Alan Gilbert 2021-04-29 1:07 ` BALATON Zoltan 2021-05-04 11:07 ` Dr. David Alan Gilbert 2021-04-26 15:53 ` Gerd Hoffmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.