Prometheus, OpenPCI, AHI

[pipper]

Hi,

I recently got interested in the Hese's Firebird A3000 daughterboard. I installed the Firestorm firmware and prometheus.library. I got a S3Virge and Voodoo3 card running as RTG card using P96 (3.3.3). I read about a Radeon driver also being available for the Prometheus/OpenPCI framework, but apparently it was pulled because of copyright claims and never resurfaced. Does anyone have updates on this?

I attempted to get a Realtek8139 card running, and the driver seems to load and do something after I added the "DMASize=512kb" tooltype to the Prometheus monitor driver. Unfortunately, it doesn't really work for networking. Something somehow gets "stuck" and no real sustainable networking seems to work.

I also dabbled in trying to get a SbLive! PCI Audiocard going, but no luck so far. Playing a test sound in the AHI prefs just causes the card to produce some form of horrible squeal.

This lead me to a rabbit hole of "how hard can it be?", so I scoured the interwebs for sources...
I eventually found out that AHI was open sourced almost 20 years ago and its sources have lived on at https://sourceforge.net/projects/arp2/
The AHI sources are part of a very large repository that seems to contain lots of Martin Bloms (creator of AHI) source.
I took the liberty to move just the AHI part over to GitHub: https://github.com/mheyer32/AHI
preserving history, credits and licensing.

I also started working on make this pile of code compile with Bebbo's GCC toolchain, which was really not hard to do. The hardest parts was to make various tools that generate the documentation (.guide .doc etc) compile and work on the host machine.

Now to my real questions. I am now able to modify compile & test the AHI driver, in particular the emu10kx one. The way it is written is that it'll use the opencpi.library to talk to various PCI bridgeboards. Internally, openpci.library just forwards most calls to prometheus.library.

I found the source of openpci.library on GitHub: https://github.com/jeperk/OpenPCI
But it seems to be incomplete. It doesn't contain any source to talk to any bridge board other than the prometheus. I read that, again, Mediator support had been removed for legal reasons, but I don't know why all the other backends are missing.

The OpenPCI repo contains the Prometheus SDK (i.e. headers), but no Prometheus source code. I have found no traces of the actual Prometheus code anywhere. Didn't Prometheus go "Open Source" a decade ago? (I have been absent from the Amiga scene back then, so forgive my ignorance of the whole PCI landscape around the Amiga). Without it, it'll be hard o know for sure what the prometheus.library does and its hard to inspect it for bugs.

Back to the SbLive... I have been looking at the source and trying to understand how it works. My current hunch is that the buggy behavior might stem from either
a) not placing data that the card needs to access into PCI memory
b) programming pagetable pointers or registers with wrong values due to big/little endian conversion issues.

The big/little endian issue is a real head scratcher for me. The OpenPCI documentation states:

WARNING PCI read/write !!!
When you read or write things in PCI I/O, Mem or DMA memory think
ALWAYS the CPU side is in Big Endian format. Even if it's not the case
(like for X86 CPU). It's the only way to have portable driver under any
type of CPU. For that use ALWAYS swap macro of the MorphOS Team included by
libraries/openpci.h.

This macro are :
SWAPWORD(unsigned short value):
return swaped 16bits value (Big Endian <-> Little Endian conversion)
SWAPLONG(unsigned long value):
return swaped 32bits value (Big Endian <-> Little Endian conversion)

- If the PCI/AGP card you work on use Big Endian byte format redefine
SWAPWORD and SWAPLONG after #include <lirbaries/openpci.h> like that :
#undef SWAPLONG
#undef SWAPWORD
#define SWAPLONG(x) (x)
#define SWAPWORD(x) (x)

When you make a driver use ALWAYS this function : pci_inb/w/l()/pci_outb/w/l()

- NEVER use direct hardware access for read/write in I/O, Mem addr of the PCI card.
It's the same rules for pci_to_hostcpy(),host_to_pcicpy(),pci_to_pcicpy():
You want to copy a memory block from Host memory to DMA memory, I/O or Mem space
use host_to_pcicpy(). You want to copy a memory block from PCI DMA memory,
I/O or Mem space use pci_to_hostcpy(). You want to copy a memory block from PCI
DMA memory, I/O or Mem space to DMA memory, I/O or Mem space use pci_to_pcicpy().

This is confusing, but from looking at examples and the existing SbLive driver code, it seems to assume that the OpenPCI function always expect BE data and will convert to LE if necessary.
There are a few places in the driver, though, where the code does not go through these functions and instead does the BE-LE conversion on the spot. In particular the code to write the EMU10KX page table. Superficially this might look correct, but then I read a Prometheus document stating that the Prometheus hardware will auto-convert BE to LE and back, so the software would not have to do _any_ conversion, turning the above mentioned pagetable writes into wrong values!
I changed the code accordingly, but so far had no luck... Still only getting a squeal out of the card.

Another piece of code tried to translate addresses _inside_ a PCI allocation from virtual to physical (PCI) addresses. It is correct to assume that a linear range of virtual addresses maps to non-linear fragmented physical addresses. But again, the openpci/prometheus documentation are lacking information if querying an address _inside_ an allocation will work. It seems it does not.

Is there any more in-depth information on prometheus and openpci? Is the source for prometheus.library available anywhere? Is there any documentation describing the EMU10KX registers?

Thanks in advance for sharing your knowledge!

[Hedeon]

Prometheus went open source on HW, not SW more than a decade ago.

And I did some work on the SW here based on earlier work from Tobias Seiler:

https://github.com/Sakura-IT/Prometheus

[pipper]

That is awesome! Is this a reimplementation of the Prometheus.library then?
It’s also cool to see the Prometheus.card and the chip P96 drivers!
The good thing is that I was able to confirm that the library should be able to translate addresses inside a PCI allocation just fine. Looks like the mapping is as simple as subtracting the ZorroIII base address - I had feared there was some complex page based mapping going on :-)

I’m still dubious about the hardware BE/LE conversion. Do you have a definite answer if this is implemented in the firestorm FW?

[Hedeon]

Not totally sure. I think the config space is LE and all the rest is BE. As I seem to write normal to any PCI address and use swap to configure, like in

https://github.com/Sakura-IT/PowerPC...ster/libinit.c

I think Toni knows more as he has the HW programmed into WinUAE.

[Toni Wilen]

Prometheus emulation in UAE: PCI config space is not swapped, PCI IO and memory is always hardware endian swapped. Address is not changed (some other PCI bridges also do address "XOR" operation)

[pipper]

So, as long as I’m not writing to config space, no writes to PCI memory need to be swapped?
I wonder, though, how the driver can transparently handle this when it needs to write to PCI memory directly. OpenPCI does not expose this PCI bridge behavior and it’s documentation encourages to always do the conversion when not going through it’s pci_outX() functions.
In case of the SbLive the driver needs to manage pagetable entries that point to PCI memory addresses. The pagetable itself lives in PCI memory and it currently gets manipulated by directly writing to the pagetable (and converting each write to LE - which should be wrong on the Prometheus)

[pipper]

I'm confused.

https://wiki.osdev.org/PCI

states:

PCI devices are inherently little-endian, meaning all multiple byte fields have the least significant values at the lower addresses. This requires a big-endian processor, such as a Power PC, to perform the proper byte-swapping of data read from or written to the PCI device, including any accesses to the Configuration Address Space.

I do see prometheus.library source accessing the config stuff via byte swaps, though...

[pipper]

This is getting more and more confusing.
It looks like access to IO space is not getting byte swapped.

I confirmed this with the SbLive's WC register:

#define WC			0x10		/* Wall Clock register				*/
#define WC_SAMPLECOUNTER_MASK	0x03FFFFC0	/* Sample periods elapsed since reset		*/
#define WC_SAMPLECOUNTER	0x14060010
#define WC_CURRENTCHANNEL	0x0000003F	/* Channel [0..63] currently being serviced	*/
						/* NOTE: Each channel takes 1/64th of a sample	*/
						/* period to be serviced.			*/

The values returned make only sense when byte-swapping after the read.

[Krashan]

Originally Posted by pipper

This is getting more and more confusing.
It looks like access to IO space is not getting byte swapped.

Would be funny if it turns out that different CPLD firmware forks have different byteswap behaviour...

[Hedeon]

Originally Posted by pipper

It looks like access to IO space is not getting byte swapped.
The values returned make only sense when byte-swapping after the read.

Yeah, It looks like that. I think that everything from 0x1fc00000 to 0x20000000 on the Firestorm/Firebird is not swapped. So that is config0, config1 and I/O space. At the very least everything looks LE in this area :-)

[Toni Wilen]

I'd say "not enough information" without including result of long read, 2x word reads and 4x byte reads from same addresses.

[Hedeon]

Originally Posted by Toni Wilen

I'd say "not enough information" without including result of long read, 2x word reads and 4x byte reads from same addresses.

You don't have Firestorm/Firebird in UAE, right? Only the original Prometheus Firmware?

As the address map got changed http://www.e3b.de/prometheus/prometheus_V05.txt

[Toni Wilen]

Originally Posted by Hedeon

You don't have Firestorm/Firebird in UAE, right? Only the original Prometheus Firmware?

As the address map got changed http://www.e3b.de/prometheus/prometheus_V05.txt

I do have some PCI board but I never used it to emulate PCI boards. Emulation is almost always done by examining how existing software works. Documentation is usually wrong anyway

Does Firestorm/Firebird have any existing software? I don't emulate hardware that does not have any software.

[Hedeon]

Originally Posted by Toni Wilen

Does Firestorm/Firebird have any existing software? I don't emulate hardware that does not have any software.

It brought the Prometheus more in-line with the Mediator. So PCI to PCI DMA is now possible (Using gfx card memory; So RTL8139 and EMU10K1 is now possible through OpenPCI). Also you can add more bridges now to the Prometheus (e.g. a PCIe bridge). However, no software yet for that :-)

[pipper]

I wouldn’t say there is no software. There’s Prometheus.card to hook up existing .chip drivers for P96 with PCI graphics cards (supporting Voodoo3+, Permedia2 and S3Virge).
There are RTL8029 and RTL8139 network drivers and there’s AHI drivers for PCI sound cards (Emu10kx based).