Re: [Qemu-ppc] ATY 'NDRV'

[BALATON Zoltan]

Hello,

On Fri, 19 Jul 2019, Jd Lyons wrote:
> > On Jul 19, 2019, at 7:51 AM, Jd Lyons <address@hidden> wrote:
> >
> > In order for the rom based or disk based ATI ‘NDRV’ to load for the Rage128, 
> > the name string needs to match in name space.
> >
> > I.E. ATY,Rage128Pd as the name property rather than just ATY.

Yes, I've noticed this as well when I've seen the string in both FCode and 
NDRV and this is what the FCode sets in the device tree. There may be 
other device tree properties it looks at such as ATY.Status which seems to 
tell what the FCode has done but I don't know what its bits mean. The 
FCode seems to set bits in it after some operations. I guess if we could 
run the FCode we would have a better chance to get the NDRV working than 
just trying to figure out what it may need. The FCode also reads EDID info 
and programs some regs of the card so the NDRV probably expects that and 
does not fully init the card so likely it won't work without the FCode. 
(For clocking and memory stuff this may not matter as these are ignored in 
QEMU as it does not have to care about that to have picture but if the 
FCode checks results and expect to get some values to say it was 
successful some changes may be needed. Also if the NDRV expects the FCode 
to select a mode and program the card accordingly then it won't work 
unless we do the same and maybe add the right params in the device tree 
for the NDRV.)

> > Unfortunately this doesn’t get us much further as far as booting the Mac OS.
> >
> > Can your emulated Rage128 change screen modes or bit depth under Linux or the 
> > MorphOS?

Sure it can, have you tried? However it may be wrong and could have bugs 
and definitely has missing features. On Linux with rage128fb kernel driver 
only 8 bit mode works, 16 bpp has no colors and in 24-32 bpp modes there's 
no picture (even if it can switch to that mode) because of some mismatch 
between frame buffer and CRT Controller depth/pitch. I'm not sure this is 
because a bug in Linux driver or some missing emulation but I've checked 
the registers and it seems to program the CRTC in a way that's consistent 
with the display but may be wrong for the mode so either I don't 
understand what's happening or the Linux driver is buggy (older Linux 
version may be less buggy or have different bugs). This could be verified 
by trying on real hardware but I don't have any to try. If someone with a 
real hardware tests an image and can tell what it does on real hardware we 
can use the same image to replicate that on emulation.

> Some observation that I’m not sure is useful:
>
> OS X never maps the vram and is unable to load the graphics server in any mode 
> other than 8 bits color.
>
> The last thing we see in a successful graphics boot in the system log before 
> the window server loads is:
>
> ATY: vram [8100000:01000000]
>
> or
>
> QEMU,VGA: vram {81000000:01000000]

If you see QEMU,VGA then it's likely wrong. Probably OSX tries to use the 
NDRV that OpenBIOS unconditionally patches in for every VGA device (while 
OSX has its own drivers it may try to use compatibility mode sometimes). I 
think this QEMU,VGA hack should be removed from OpenBIOS and the NDRV 
should be passed from QEMU as card ROM instead which another hack in 
OpenBIOS already puts in device-tree as NDRV. This needs a change to QEMU 
to allow setting the card ROM so we can have different ROM on ppc than 
other targets (but that will be needed for ati-vga as well or to support 
proper FCode ROMs eventually so it's worth doing). If that's done the 
whole QEMU,VGA patching and downloading via FW_CFG could be dropped from 
OpenBIOS as it's not needed any more and then it would not break ati-vga 
with it. (Actually the FCode part is also currently run separately as 
another hack so fixing FCode ROM support would be the best way to clean 
this up in OpenBIOS.) Until then you probably should always use -prom-env 
'vga-ndrv?=false' with ati-vga and maybe also pass the NDRV as card ROM 
with QEMU romfile option to make sure it's not trying to program the 
ati-vga with the QEMU,VGA driver, which may work (as ati-vga supports 
Bochs VBE for compatibility with QEMU firmwares and also internally for 
switching modes) but then you're not testing ati emulation and a proper 
ati driver will probably find the card in unexpected state after this. But 
if MacOS and OSX ATI drivers expect the card to be in the state the FCode 
puts it then you'll either need to fix OpenBIOS to be able to run the 
FCode or reimplement what it does as another hack in OpenBIOS and replace 
the hack in vga_config_cb that runs vga-driver-fcode without checking it 
would do the right thing or make sure it runs the right FCode for the 
card.

> I also noted in qemu-system-i386 under Windows XP SP3 graphics mode was 
> stuck at 4 bit color and unable to change the screen resolution with our 
> emulated rage128. I also had to use a Rage128 vbios or XP couldn’t get 
> to the desktop. Sadly I was only able to find one Rage128 vbios to test, 
> but I did test many Rage128 drivers in XP.

Be sure to use the right ROM. Read about different Rage, Rage 128, Rage 
Pro and Rage 128 Pro models on my page at 
https://osdn.net/projects/qmiga/wiki/SubprojectAti and note that the above 
4 are all different GPUs despite named confusingly similar so it's easy to 
pick the wrong ROM which is not supposed to work with the card we're 
trying to emulate. However on x86 it may not depend on the ROM as much as 
it does on ppc so maybe the latest sea vgabios ROM with Rage128Pro support 
would be enough there. You can get it from: 
https://git.kraxel.org/cgit/seabios/tree/vgabios-ati.bin?h=ati and it has 
to be copied to the pc-bios dir replacing the vgabios-ati.bin there, 
specifying it via romfile does not work. But it may need a real ROM 
because some drivers read tables from ROM to get some data which may be 
missing from other ROMs.

> That brings me around to the point of ‘NDRV’s, there are several for the 
> Rage128 GPU, we’ve only been testing the “Rage128Pd” as that is the one 
> in the FCode ROM we were trying to debug.

The Rage128Pro matches the emulated card so that's the only one supposed 
to work. Rage128 (not Pro) NDRVs probably won't work fully. Only drivers 
that work with real Rage128Pro found in PowerMacs are expected to work but 
not yet fully as there are a lot of missing emulation yet. If you tested 
with anything else then that may be because of a mismatch between ROM/NDRV 
and not because of missing emulation (although missing emulation is pretty 
much expected at this point even with the right drivers).

> Two key points:
>
> 1. If our emulated Rage128 can not change screen resolutions or bit 
> depth yet, then there is not much point in loading ‘NDRV’s, as they are 
> never going to work.

It's never going to work if we don't load NDRVs to try what they do and 
implement that in emulation to make it work. That's the point of trying to 
load drivers to test emulation even if it's known not working yet. The 
current emulation implements resolution and depth switch for the CRTC part 
of the card. It only implements CRTC at the moment. If the driver thinks 
the display is not connected to the CRTC but tries to program different 
registers (e.g. there are a set for FlatPanel support and there maybe 
secondary CRTC on the card) then it's possible it won't work. But the only 
way to find it is to enable register tracing and look up the regs in docs 
and see what the driver does and then find out why it does not work. I 
don't know an easier way, if anyone does please let me know.

> 2. There are quite a few Rage128 GPU’s and we need to narrow down which 
> one we are emulating to a specific revision. Otherwise we are shooting 
> blind as to which ‘NDRV’ to use.

Yes, that's what I've tried to explain on my Qmiga page and also said 
above and thought it was clear so you did not have to come to the same 
conclusion the hard way. We are narrowing down the emulated chips to just 
these two (in qemu/hw/display/ati.c):

ati_model_aliases[] = {
    { "rage128p", PCI_DEVICE_ID_ATI_RAGE128_PF },
    { "rv100", PCI_DEVICE_ID_ATI_RADEON_QY },
};

where the corresponding PCI IDs are (in qemu/hw/display/ati_int.h):

#define PCI_VENDOR_ID_ATI 0x1002
/* Rage128 Pro GL */
#define PCI_DEVICE_ID_ATI_RAGE128_PF 0x5046
/* Radeon RV100 (VE) */
#define PCI_DEVICE_ID_ATI_RADEON_QY 0x5159

(The 1002:5159 is also sometimes called Radeon 7000 or M6 but RV100 is 
usually the most specific name of the GPU.)

As the warning in the beginning of ati.c says the emulation is currently 
very incomplete so a lot of stuff is not working. Therefore it's not 
expected to work yet with any random ATI driver. The point of thesting 
with these is to find out what features are needed and would need to be 
implemented next. For example a lot of these drivers would want to use 
more advanced programming modes such as memory buffers which are not yet 
supported. So if a driver tries to set up a memory buffer then put 
commands there in the hope that the card will get it then currently 
nothing will happen as these are not implemented yet. Again the way to 
find this is to look at register traces and docs. Otherwise you won't know 
why it does not work.

Regards,
BALATON Zoltan