Detoke and the Openbios video console driver?

[Jd Lyons]

I’ve been trying to add graphics acceleration to Qume-PPC and have a few questions about how Open Bios deals with FCode option roms.

I noticed when I build Openbios, it creates a file called QEMU,VGA.bin. Is this file the video console driver for Openbios?

I’d like to replace it with an FCode option rom from one of the proprietary Video cards supported by the Mac OS, is this feasible?

What parts of Openbios would need to be changed to support proprietary FCode option roms from cards like the ATI,Rage 128 Pro?

Would I need to rewrite some part of Openbios to support the VGA?

The file QEMU,VGA doesn’t appear to be Tokenized, can Openbios deal with Tokenized option roms, or do I need to pass it a Detokenized Rom?

I noticed Fcode-Utils has a detoke tool, I’d like to use it to detoke FCode roms, but I’m not sure of it’s usage, do I need to remove the PCI Header from the FCode rom?

If so, how long is the header, is it a standard length, or does it vary from Rom to Rom?

Thanks,
JD

[Mark Cave-Ayland]

On 18/02/17 16:52, Jd Lyons wrote:
> I’ve been trying to add graphics acceleration to Qume-PPC and have a few questions about how Open Bios deals with FCode option roms.
>
> I noticed when I build Openbios, it creates a file called QEMU,VGA.bin. Is this file the video console driver for Openbios?

Yes, it is. It mostly does the low-level setup for the card (resolution,
PCI bus mapping) and then falls back to a set of internal console APIs
for handling the VGA console.
> I’d like to replace it with an FCode option rom from one of the proprietary Video cards supported by the Mac OS, is this feasible?

In theory yes, however I suspect you'd hit a couple of obstacles.
Firstly the QEMU,VGA.bin file isn't (yet) used by QEMU, i.e. it's not
mapped into the option ROM by QEMU so you'd need to do some work there.

Secondly I suspect that the driver has some code specific to
QEMU/OpenBIOS to it, i.e. it uses the Bochs VBE API to set the screen
size which won't be present on real hardware. And it could also be that
the proprietary FCode tries to call special registers that only exist on
the card itself.
> What parts of Openbios would need to be changed to support proprietary FCode option roms from cards like the ATI,Rage 128 Pro?
>
> Would I need to rewrite some part of Openbios to support the VGA?

I'd suggest that trying to boot a proprietary VGA FCode ROM is likely to
be long route to getting the emulation running. The good thing here is
that all video cards start up in a standard VGA mode regardless, so you
might as well use the in-built VGA FCode ROM for OpenBIOS and then let
the OS drivers enable the HW-specific parts of the card which they will
do as soon as they match the information found in the DT.
> The file QEMU,VGA doesn’t appear to be Tokenized, can Openbios deal with Tokenized option roms, or do I need to pass it a Detokenized Rom?

QEMU,VGA.bin is tokenised, i.e. tok is used to compile the
drivers/vga.fs driver into FCode. All FCode options ROMs must be
tokenized (almost compiled) as per the IEEE-1275 bindings.
> I noticed Fcode-Utils has a detoke tool, I’d like to use it to detoke FCode roms, but I’m not sure of it’s usage, do I need to remove the PCI Header from the FCode rom?
>
> If so, how long is the header, is it a standard length, or does it vary from Rom to Rom?

I'm not sure exactly, but if you do have an FCode ROM from a real card
then find a way to extract it via the serial port or other (Google is
your friend) and then you should be able to run it through "detok" in
order to see what the source looks like which will give you plenty of clues.

ATB,

Mark.

[Tarl Neustaedter]

On 2017-Feb-18 11:52 , Jd Lyons wrote:
> I noticed Fcode-Utils has a detoke tool, I’d like to use it to detoke FCode roms, but I’m not sure of it’s usage, do I need to remove the PCI Header from the FCode rom?
>
> If so, how long is the header, is it a standard length, or does it vary from Rom to Rom?

See section 9 of the 1275 PCI binding - one copy at
http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf . The
header is 0x1A bytes long.

Note, however, that the FCode doesn't necessarily start right after the
header, but will lie at the offset defined by bytes 2-3.