Sonnet 7200 PCI programming

[Hedeon]

So I got this Sonnet 7200 PCI card laying around….

First of all, I like to tinker with the software and the hardware side of Amigas. I know the discussion about this topic has tended to be in the direction of people questioning WHY you would want this as it would be slow etc etc. but that’s not the point. For me, it’s part of the hobby and I do it because I CAN do it.

Anyway, the short version of the problem is: There does not seem to be code execution from the PPC on the Sonnet side.

The long version:

1) The card is recognized by de mediator (A3000Di version with the 3.3V rail)
2) The PCI library I used (9.7?) normally goes into an infinite loop on allocation of PCI memory, I fixed that.
3) I set up de EUMB parameters using the PCI configuration registers. The EUMB is an extended configuration block in PCI memory.
4) I tell the card to setup this EUMB using the PCI command register bit 1 (Memory space). This works and a 4096kb block is created in PCI memory.
5) Inside the EUMB I then set up the outbound translation window location and size. I point it to PCI DMA memory, which is memory on the Voodoo in this case.
6) The outbound translation window is needed to execute code in PCI memory (or local memory, but I expect the Sonnet cannot access local Amiga memory due to limitations of the DMA of the mediator) instead of Sonnet memory.
7) With above method I tell the Sonnet card to translate any address from 0xFFF00000 (plus 1MB) to the outbound translation window in PCI memory.
8) I copy a simple PPC code piece to, let’s say, outbound translation window location+$100 (which is, as stated above, inside Voodoo memory).
9) The $100 offset is the CPU reset vector of the PPC. Normally, this is at 0xFFF00100. As the sonnet card has no real memory here, the CPU is halted (already during power up of the card)
10) Then I tell the card to start up the PPC CPU again. This is done by setting bit 2 of the PCI command register (Bus master bit).
11) It now should execute code at 0xFFF00100 which is translated to the PCI memory address where the short PPC code resides, but I don’t see anything happening. The code should manipulate some memory at outbound translation window location +$4C04 (0xFFF04C04 which is translated to PCI memory).

Am I making some wrong assumption here?
A. I assume the card does not have any firmware on it which is executed at power up so the PPC CPU should be at 0xFFF00100
B. I assume the Mediator has no limitations on access of PCI memory or bus mastering
C. The Sonnet card has 3x16MB EDO on it. Here, there seems to be discussion about it should be FPM. On the other hand, above method should work without any memory on the Sonnet.
D. I assume the Mediator can let the Sonnet card access the memory on the Voodoo

Any help?

PS. On point 2 (the infinite loop). What the PCI library does is write al 1’s to the PCI memory registers on every PCI card. The PCI cards respond in setting a mask regarding the length of the PCI memory. The PCI library then tries to find a place for this block inside the PCI memory space. The Sonnet card has an inbound translation window (LMBAR) which is programmed differently. So writing al 1’s to this register gives an invalid response back which isn’t correctly handled by the PCI library.






[FILES]

PrmLibs.lha 26 January 2023:
prometheus.library 4.3
Prometheus.card 7.600
3dfxVoodoo3.chip 7.16
3DLabsPermedia2.chip 7.17

SonnetLibrary.lha 24 October 2021:
powerpc.library 17.13b (no Prometheus support)
powerpc.library 17.14
sources & extras (Aminet upload)

[strim]

First, unfortunately I have to admit that I know nothing about Sonnet programming. However, I am pretty sure that Elbox's PCI library can't handle Sonnet in its current state. I suggest you program Mediator directly, skipping PCI library entirely.

Check out the NetBSD driver:
http://nxr.netbsd.org/xref/src/sys/a.../pci/empbreg.h
http://nxr.netbsd.org/xref/src/sys/a...iga/pci/em4k.c

Mediator 3000 should work exactly the same as 4000. From this driver source it should be fairly easy to deduce how to program the Mediator. If you have any questions regarding operation of Mediator, don't hesitate to ask (I wrote this driver).

Regarding DMA to Amiga space, I suspect the same. Elbox's site states that Mediator can do "DMA to A4000 motherboard space", but I never got that to work (so I doubt Mediator can work as Zorro bus master).

Note that from Amiga CPU point of view, PCI address space is not linear either, but accessed through a window in Z3 memory space. This might pose some problems too. However you are programming the Sonnet, you should always think in terms of PCI addresses, not Amiga addresses. And if you are accessing this location from Amiga side, you have to program the Mediator's window position correctly first. NetBSD driver for Mediator 4000 does not do it at all (just conveniently limits the available PCI address space to the size of a window). I am not sure if Elbox's PCI library ever does it. However, you can see an example of this in Mediator 1200 driver code (where window is very small, so I had to implement changing the position).

See:
http://nxr.netbsd.org/xref/src/sys/a...iga/pci/empb.c function empb_switch_window.

Also, I am in no way associated with Elbox and don't have access to any official documentation. So I guess we can further reverse engineer Mediator to our hearts content.

[Hedeon]

Thank you for your reply. I will look into the NetBSD source.

Sonnet programming is really about knowing how to program the TSi107 (or MCP107) chipset.

The current knowledge I have regarding PCI address space: The current window is set to 512MB in Z3 space (with a jumper) and is setup using the MMU (I think) from 0x60000000 to 0x80000000. Most PCI memory is set up to be in the 0x60000000 to 0x80000000 range by the Mediator except for ROMs like the Voodoo ROM space which is going to the 0x40000000 to 0x60000000 range, I think (could be wrong here, I’m at work). Second jumper on mediator is set to ROM space before Config space (as is obvious from the above).

The mediator itself (through the PCI library) sets up a memory range in the unused VooDoo GFX memory which can be addressed from the Amiga. Currently it is 3 MB located around 0x6D000000. I use this memory for access. The question is of course, can the Sonnet access this space through the Mediator (without translation/certain MMU setup).

Regarding bus mastering: There is a third (unused) jumper on the Mediator noted as Master and according to the Mediator documentation it has to be changed when using a SharkPPC, but I’m not sure what it does (it doesn’t fix my problem anyway).

As maybe obvious from the above, I'm not too versed in MMU programming (yet) which I think is needed to set up PCI memory space correctly?

Thanks for the suggestions; I’ll come back here when I have further questions. I like a good puzzle, but I’m not certain if there is a solution :-)

[Hedeon]

As a PS: The only thing the PCI library is used for is to initiate the PCI memory range which is automatically done when opening the library, but maybe there lies the problem. As I don't have the SDK for the PCI library the rest of the programming is done using the PCI memory config space.

[strim]

Originally Posted by Hedeon

The current knowledge I have regarding PCI address space: The current window is set to 512MB in Z3 space (with a jumper) and is setup using the MMU (I think) from 0x60000000 to 0x80000000.

Whether this location is a window address or a mapping done by a MMU, you can check easily by comparing output of ShowConfig and pciinfo. If the memory address space of memory board (the 512MB one) as shown in ShowConfig overlaps with memory addresses given by pciinfo, then MMU is not used. If the MMU is used, then board address in ShowConfig and memory addresses outputted by pciinfo do not overlap.

There's a setting somewhere in ENV that enables/disables MMU usage. I think in your situation, using MMU mappings would only further complicate the matters.

If I remember correctly, by default, in no-MMU mode, pci.library never changes the window position, it just sets the position to the same PCI address as the address of Zorro memory board on Amiga side. So that the driver accessing let's say 0x60000000 on Amiga side hits the same address on PCI side.

The mediator itself (through the PCI library) sets up a memory range in the unused VooDoo GFX memory which can be addressed from the Amiga. Currently it is 3 MB located around 0x6D000000. I use this memory for access. The question is of course, can the Sonnet access this space through the Mediator (without translation/certain MMU setup).

You need to check what's really programmed in the BAR register of Voodoo card. It will tell you the address on PCI side of a bridge. I'm not sure if pciinfo outputs address after translation, or the true PCI address set in BAR. Anyway, this will be the address to use when programming Sonnet.

As maybe obvious from the above, I'm not too versed in MMU programming (yet) which I think is needed to set up PCI memory space correctly?

Not necessarily, you can avoid using MMU at all. There's a window into PCI address space and no amount of programming gonna change that. Using MMU to translate addresses only creates an illusion of linear address space. And if you are doing such low level programming, having this additional level of abstraction can additionally complicate things.

Thanks for the suggestions; I’ll come back here when I have further questions. I like a good puzzle, but I’m not certain if there is a solution :-)

Considering that SharkPPC never surfaced, there might be hardware problems we don't know about.

As I don't have the SDK for the PCI library

It is only available under super restrictive non disclosure agreement (we wouldn't be able to have this talk if either one of us had the access to official SDK). It's kinda difficult to interact with the library, without any kind of documentation. That's why for the purpose of your work, I suggest dumping it entirely and write the necessary parts yourself.

[alexh]

These cards cannot be used on a Mediator because they don't support PCI MultiMaster

[Hedeon]

@alexh:

Could you expand a little on it? Is it also the reason for the extra jumper which should make the Sonnet the busmaster (but which apparently doesn't work).

Would've guessed that there would be some hardware limiting factor. Learned a lot about PCI and the mediator, though.

PS:

Is it the same for a 3.3V modified Prometheus PCI card?

[strim]

Originally Posted by Hedeon

@alexh:

Could you expand a little on it? Is it also the reason for the extra jumper which should make the Sonnet the busmaster (but which apparently doesn't work).

I am not completely sure what alexh means here. As far as I know, any PCI device can be a bus master in Mediator, however only on PCI side of the bridge. Perhaps because due to windowed design, PCI devices don't have any access to Amiga memory space anyway.

Perhaps alexh is referring to lack of ability to enslave the Amiga bus. Maybe master jumper does just that? Or maybe if this jumper is set, then Amiga can only be a target in bus master transaction? I.e. loses ability to be a master.

PS:

Is it the same for a 3.3V modified Prometheus PCI card?

Prometheus with default CPLD cores is even worse in this aspect (does not support bus mastering at all). I heard Michael Boehmer developed alternative CPLD firmware that would support bus mastering between PCI cards (though not to Amiga, just as in Mediator).

[crasbe]

What you really want do experiment with is the Prometheus-Board with the Firestorm firmware by Michael Boehmer. If you ask him kindly, he'll upgrade the board.

The Prometheus does support alternative busmasters and MastaTabs (from a1k) got the Sonnet 7200 working with a little output on the serial interface.

I'll send you their mailadresses per PM

[Hedeon]

Thanks crasbe :-)

[Hedeon]

@Strim:

Programming the Mediator directly resulted in the same result. I manually activated PCI memory in the Zorro space, did the BARs on the Voodoo, copied the PPC code to a part in the Voodoo PCI memory...etc.. essentially it's like in the first post from here on.

So I guess Alexh has a point.

[strim]

Argh. But why should it matter for the Sonnet? If it is the only master on the PCI side of the bridge anyway?

Technical explanation of what does "master" jumper on Mediator do would be nice. I wonder if anyone besides Elbox knows. Did you experiment with it?

BTW. Could you share your code on GitHub or something... ?

[Hedeon]

Never would have guessed it from reading the MCP107 documentation, but setting the Watchpoint control register up correctly did the trick.

[Hedeon]

Thanks for the help so far, all. Access to CONFIG_ADDR and CONFIG_DAT from the PPC side works so writing some initialization code as we speak. Setting up the memory on the Sonnet side etc.

[strim]

Very cool! Any chance you to share this knowledge?

[Hedeon]

Looking at the way Mastatabs got it to work on the Prometheus (With 3.3V and Firestorm) and cross referring it to the TSi/MCP107 manual it seemed you need to set WP_TRIG0 and WP_TRIG1 in the WP_CONTROL register to negate HRESET (According chapter 16.4).

You do it immediately after setting the bus master bit (Step 10 in the original post)

Regarding sources: I have to admit I can only read C, not really write it. All the stuff up to now is in assembly. And it's a hack job to get results very quickly: it assumes some paramaters which are only valid for my current system.

I tend to clean it up in the near future :-)

[Hedeon]

So in short:

0) I set up the second BAR of the Voodoo to point to PCI memory space of the mediator
1) I set up de EUMB parameters using the PCI configuration registers. The EUMB is an extended configuration block in PCI memory.
2) I tell the card to setup this EUMB using the PCI command register bit 1 (Memory space). A 4096kb block is created in PCI memory
3) Inside the EUMB I then set up the outbound translation window location and size. I point it to a place set inside the memory as set in step 0, which is Voodoo memory
4) The outbound translation window is needed to execute code in PCI memory (or local memory, but I expect the Sonnet cannot access local Amiga memory due to limitations of the DMA of the mediator) instead of Sonnet memory.
5) With above method I tell the Sonnet card to translate any address from 0xFFF00000 (plus 1MB) to the outbound translation window in PCI memory.
6) I copy a simple PPC code piece to outbound translation window location+$100 (which is, as stated above, inside Voodoo memory).
7) The $100 offset is the CPU reset vector of the PPC. Normally, this is at 0xFFF00100. As the sonnet card has no real memory here, the CPU is halted (already during power up of the card)
8) Then I tell the card to start up the PPC CPU again. This is done by setting bit 2 of the PCI command register (Bus master bit) and by setting WP_TRIG0 and WP_TRIG1 in the WP_CONTROL register to negate HRESET
9) It now executes code at 0xFFF00100 which is translated to the PCI memory address where the PPC code resides.
10) The PPC code (for now) invalidates the BATs. Makes a part of the PCI memory cache-inhibited and guarded and initializes the EUMB in this part of the PCI memory through the EUMBBAR register (using CONFIG_ADDR and CONFIG_DAT). This is an extended copy from the one set up in step 2, but this one is accessed by the PPC instead of the 68k processor and has more configuration registers.

Next step is to set up the memory on the Sonnet, and translate it to PCI memory (using the inbound transation window) so the Amiga can access the memory of the Sonnet through PCI memory. Then we are in business. Application is of course limited due to the DMA limitations of the PPC towards the Amiga hardware.

And then I'll clean up the code and place it on Github if needed. For now the 68k side is 250 bytes and the PPC side is 150 bytes (that's what I meant with hack).

[strim]

Looks awesome and opens a few interesting possibilities.

Regarding limitations of DMA, I think that master jumper on Mediator is something to investigate. I would guess, it makes some part of normal Amiga address space visible within PCI address space, so that the bus master transactions from PCI bus can be translated into Amiga bus requests.

I wonder if TSI110 has similar functionality and could work in master mode on a shared bus too. Both TSI110 and MPC7448 are still produced, makes me want to design a PCI card with them. Sounds like complicated and completely uneconomical but lots of fun. Too bad I have so many other projects open now.

[Hedeon]

It's fun to have a project on the Amiga, especially when there's progression (on a side note, there are rumours that the ultimateppc team has made a working prototype).

I have to admit, I've been looking already at the warphw.library docs, but let's not get overexcited now :-P.

The TSi110 User Manual doesn't seem to be available on the net, btw.

[strim]

Originally Posted by Hedeon

but let's not get overexcited now :-P

Yeah, I know, I know

The TSi110 User Manual doesn't seem to be available on the net, btw.

PM sent.