X on old (non-x86) Linux guests

X on old (non-x86) Linux guests

[Dr. David Alan Gilbert]

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

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

[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

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

[Dr. David Alan Gilbert]

* 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

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

[Laurent Vivier]

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

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

[Dr. David Alan Gilbert]

* 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

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

[Laurent Vivier]

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

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

[BALATON Zoltan]

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

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

[Andrew Randrianasulu]

[-- 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 --]

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

[Andrew Randrianasulu]

[-- 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 --]

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

[BALATON Zoltan]

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

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

[Andrew Randrianasulu]

[-- 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 --]

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

[Dr. David Alan Gilbert]

* 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

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

[BALATON Zoltan]

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

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

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

[Gerd Hoffmann]

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