PCI Stack - new development, and call for feedback

[Thomas Richter]

There is a little something I prepared... the new P96 voodoo driver is based on OpenPCI, but unfortunately nobody cares about the (full) version of OpenPCI with mediator support anymore, so we need something. It also not ideal that it is only a wrapper around propietary and (often) undocumented third party libraries, so something needs to be done to clean up in PCI land a little bit. So, I considered, why not offering an API-compatible openPCI library that talks directly to the hardware instead of going through third party libraries?

The attachment is a start, and more a discussion basis. It is an openPCI compatible library that talks directly to the A4000 mediator boards. The API implementation should be pretty complete, including reading the config area, finding boards, reserving cards, reading and writing bytes and allocating interrupts. Needless to say, as this talks to the hardware directly, the Elbox pci.library can go, it is no longer needed. The voodoo driver provided last week runs fine on it (of course, that does not mean that the thing is bug free, but it's a start). What it does not yet offer is the option to reserve DMA bounce buffers on the graphics card because there is still a knot in my brain how to organize this best and what a suitable architecture could be. The current one is... not so great, and suffers from a chicken and egg problem.

There is a also a little bonus: This library implementation not only configures the PCI boards, it also announces them to the expansion.library such that tools like ShowConfig list them, through a dummy vendor ID and a product ID that identifies the type of the resource. The PCI product and vendor ID I could not fit into the ConfigDev structure directly (simply because the PCI product is two bytes, not one as in AmigaOs), but you can still find it there in the serial number information. The vendorID is still in the process of being allocated, but the product ID is taken from the following list:

Generic_Bridge EQU 0 ;a PCI bridgeGeneric_PCIConfig EQU 1 ;a PCI config areaGeneric_PCIMem EQU 2 ;a PCI memory areaGeneric_PCIMemReg EQU 3 ;a PCI memory mapped register setGeneric_PCIIO EQU 4 ;a PCI IO mapped regionGeneric_PCIRom EQU 5 ;a PCI expansion ROM

Now, what is the advantage of having this information in expansion? It means that the system no longer needs to build the MMU tables for the entire 512MB (or so) of expansion area reserved by the PCI bridge, but only the areas that are actually populated, which is (typically) less. Thus, if openpci.library is loaded upfront SetPatch (e.g. by making it resident with LoadModule), it will speed up your boot process.

What can you do?

*) The obvious. Testing. This thing is of course another step and a a milestone towards a larger goal, namely having a cleaned up PCI integration of the system.
*) Discussion. Is there anything I miss, I need to integrate (potentially, many things at this stage). Clearly, there should be support for additional PCI bridges. This will take time (and hardware, and testers).
*) Should this possibly also include an emulation layer for other pci-driver libraries or can we settle with OpenPCI as a good common ground for PCI hardware support?

Again, note that this is the beginning, and thus many things are open for discussion. This is mainly posted here to "trigger interest", not so much to provide a product. (But, alas, it already works for the voodoo. Maybe it works for something else, too).

[Wrangler]

This sounds great! I'll test and report back over the weekend. Can I check that your intention is for this to support Mediators, Altera-based Prometheus and Xilinx-based Prometheus cards? I'm asking as I think we need any new solution to have as broad a base as possible. (Yes, I know there is Grex as well but how many of those actually exist...)

[Mr-Z]

Too bad I don't have an Amiga with a PCI busboard anymore, but this is a great initiative

[jasonsbeer]

This may be relevant to the discussion.

https://github.com/jasonsbeer/AmigaPCI/

[Thomas Richter]

Originally Posted by jasonsbeer

This may be relevant to the discussion.https://github.com/jasonsbeer/AmigaPCI/

Yes, Jason, thank you. I was already attempting to contact you, and I was made aware of this project. Is there anything I can do for you? Is the PCI bridge you are going to use related to the Prometheus board? Then, hopefully, there is nothing extra for me to do, but I do not know.

[Thomas Richter]

Originally Posted by Wrangler

This sounds great! I'll test and report back over the weekend. Can I check that your intention is for this to support Mediators, Altera-based Prometheus and Xilinx-based Prometheus cards? I'm asking as I think we need any new solution to have as broad a base as possible. (Yes, I know there is Grex as well but how many of those actually exist...)

That is the idea, yes. But this will possibly take a while.

[jasonsbeer]

Originally Posted by Thomas Richter

Yes, Jason, thank you. I was already attempting to contact you, and I was made aware of this project. Is there anything I can do for you? Is the PCI bridge you are going to use related to the Prometheus board? Then, hopefully, there is nothing extra for me to do, but I do not know.

Hi Thomas - Sending PM now.

[grelbfarlk]

Originally Posted by jasonsbeer

This may be relevant to the discussion.https://github.com/jasonsbeer/AmigaPCI/

This looks great too, btw.

As far as the openpci.library, the current initiative is to try openpci versions of drivers on the Mediator, is that the short of it?

[Thomas Richter]

That is the current status - or to be precise, the current status is A4000 mediators only. This will hopefully change, the plan is to support more PCI bridges, but this will take a while.

[Wrangler]

I'm trying to test out openpci.library and getting stuck. I'm probably doing something dumb:

• A4000D with Mediator and Voodoo3
• Removed pci.library from libs:, added openpci.library. Removed old Voodoo.card, added new Voodoo.card from the other thread
• Copied old Voodoo monitor file. Board type left unchanged as 'Voodoo'
• In Picasso96Mode, I've attached to the 'Voodoo' board
• But testing one of the screenmodes doesn't work - it switches out from native Amiga display but then the monitor says no signal

It's possible the problem is with SwitchControl on my Ratte monitor switch? Or have I missed a set-up step?

BTW this is with 2.X of P96. Is v3.X required?

[Thomas Richter]

For the voodoo driver, you need indeed a v3. Screen-Dragging is only available for these later versions. Other than that, you are changing too many things at once. First, update P96. Then install the classical OpenPCI version from the source quoted in the driver, keeping the original pci.library. Then try to change to the new openpci.library.

[specfreak]

This could be quite interesting. I've just got my A1200T out of 'storage' and it all worked fine with my BPPC 060@50Mhz/603e@240MHz, then in a week or so it just stopped working :-(. So I sent off my A1200 mobo for recapping and it was confirmed the BPPC is foobar'ed. The mobo is fine although I do get Vertical Lines on my Micronik Scandex scandoubler (via External DB25).

I have a Mediator SX with Voodoo 3/3000 16MB, Sound and Ethernet cards.

So once I get something up and running I might try this out, although you mention its geared towards A4000s at the moment.

I'm just getting back into miggy setup, so will have to explore which Accelerator to get.
Likely a PiStorm 32 Lite or TF1260 or TF1232. So it's gonna be interesting getting my PCI cards backup and running if any of these lack MMU? Booting on stock A1200 moaned about MMU presence.

[Thomas Richter]

Originally Posted by specfreak

I have a Mediator SX with Voodoo 3/3000 16MB, Sound and Ethernet cards.

Note that at the moment the mediators for the A1200 are not yet supported, but I'm on it. There is some prototype code for them already I wrote this weekend, but it is too early to say. So please stay tuned.

Originally Posted by specfreak

So it's gonna be interesting getting my PCI cards backup and running if any of these lack MMU? Booting on stock A1200 moaned about MMU presence.

The A1200 mediators suffer from a 4MB or 8MB address window. Thus, without an MMU, only a fraction of the card address space will be available. If you need more, and want to have a larger address space available, you will need a MMU.

[Wrangler]

Originally Posted by Thomas Richter

For the voodoo driver, you need indeed a v3. Screen-Dragging is only available for these later versions. Other than that, you are changing too many things at once. First, update P96. Then install the classical OpenPCI version from the source quoted in the driver, keeping the original pci.library. Then try to change to the new openpci.library.

OK, updated to P96 v3.4.1. With the new Voodoo.card from the other thread, the "classic" openpci.library and elbox pci.library everything is fine - Voodoo card can switch into an RTG modes. But swapping openpci.library to the version in this thread and going back into P96 Settings to test video modes gives a black (but not "blacker than black") screen, which implies to me that the monitor is getting sync pulses but nothing else.

[Thomas Richter]

Which kind of mediator is that? Only the A4000 mediators are supported at this moment.

[ncafferkey]

This is a great initiative. I was thinking recently about what a pity it is that PCI software is so fragmented on Amiga.

However, IMHO it would be better to use the Prometheus API (i.e. write a prometheus.library for the Mediator hardware). These are my reasons:

1. prometheus.library has a much more Amiga-like API. As much as I appreciated the idea of a unified Amiga PCI API that OpenPCI offered, AFAIK it basically copied the Linux PCI API. While copying a Linux/Unix API might be useful for porting certain software, it's no advantage here as no Linux PCI-based driver is anywhere near just a recompile to get an Amiga port.
2. Work could be saved by not having to support Prometheus hardware in your new library, as the original prometheus.library could be used instead.
3. You'd get immediate support for new network drivers on Mediator hardware: I have five suitable network drivers that already support prometheus.library (two wired and three wireless).
4. From the little I've read about it, Prometheus hardware seems to be much more open than Mediator, so it seems a good fit to use its API.
5. prometheus.library has a function to register a driver that's using a PCI card - useful for avoiding conflicts and informing users.

BTW, I have a GRex, so I might be able to help if supporting that becomes a goal.

[pipper]

For GRex, we’d need any available SDK and or documentation (and later testing) There used to be a GRex backend in OpenPCI, but it’s not in the open source anymore.

[Wrangler]

Originally Posted by Thomas Richter

Which kind of mediator is that? Only the A4000 mediators are supported at this moment.

A4000D Mediator - see post 10

[ncafferkey]

Originally Posted by pipper

For GRex, we’d need any available SDK and or documentation (and later testing)

I have that too

[pipper]

If you can, please zone it :-)