[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] ATY 'NDRV'
From: |
BALATON Zoltan |
Subject: |
Re: [Qemu-ppc] ATY 'NDRV' |
Date: |
Fri, 19 Jul 2019 16:43:33 +0200 (CEST) |
User-agent: |
Alpine 2.21.9999 (BSF 287 2018-06-16) |
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