I don't have software examples at hand, but I'll explain from a hardware / VMEbus level how slot ID works, which could be useful when implementing this. I hope functions for the Monarch role become a standard function in the various OSs. I don't think Vx or Lynx have it now.
There's DY4 Auto-ID, and VME64 Auto Slot ID. DY4 Auto-ID uses an IACK cycle on level 1 and counts off Sysclocks to determine relative slot position, same way the DARF64 and SCV64 interfaces perform it. VME64 Auto Slot ID is a more recent method in the VME64 spec that arranges for all participating slaves that need configuring to interrupt and be acknowledged and configured in a deterministic sequence on interrupt level 2 after a system reset.
Cards that participate in Auto Slot ID have configuration registers for VME base address and size and any other card-specific details they need that can be written to from the VMEbus, when they are enabled to do so. The registers start off non-responding.
In the VME64 Auto Slot ID method, all cards that want to be configured must start off by holding SYSFAIL asserted when SYSRESET negates. When they are ready to receive configuration writes from the VME into their VMEbus interface, they assert IRQ2 and release SYSFAIL. Since SYSFAIL is a shared line, this will result in SYSFAIL finally turning off when the slowest card is finally ready to be configured.
Once SYSFAIL turns off, it's up to software to continue the configuration process (being the bit of software to be written). Somewhere in the system there needs to be a card with knowledge of what cards should be present and how they need to be configured. This card's the Monarch. It might be an SBC in slot 1, or might be a network card in some other slot, it does not have to be the Syscon card. Meanwhile, all the cards that need configuring are sitting patiently with empty minds in single file on the IRQ2 line.
The Monarch will now run one (ONE!!) acknowledge cycle for IRQ2. It should not have been allowed to run any yet. Since there's an interrupt acknowledge daisy chain on the backplane, the physically first card interrupting on IRQ2 will respond with a vector (value 0xFE). At the same time, that card will enable it's configuration registers to respond to VME cycles in the Config space at offset zero. All other cards are still non-responding. The Monarch should now write a new base address for the config registers, to move it to a unique address in the config space. The Monarch might leave the card at it's new address partially set up and proceed with mapping in the remaining cards or might write all the config data needed to that card now.
If IRQ2 is still asserted, the Monarch now runs another IACK level 2 cycle, checks that the the vector is 0xFE (the Auto Slot ID value), then writes the config details to that card. The Monarch could also read fields from those config/status register to confirm that the expected cards are present and occuring in the expected order.
OK, for the Universe details:
It has fully automatic mode, wherein the Uni will immediately make
itself available to be configured in the Auto Slot ID process after
reset, in the above protocol. There's the semi-automatic mode, where it
asserts SYSFAIL but won't assert IRQ2 and release SYSFAIL until local
software has done whatever non-VME initialization and BIT needed; once
local software sets the AUTOID bit, then IRQ2 and SYSFAIL are switched
and the configuration process proceeds. The choice of mode is a hardware
configuration on the card and documented somewhere.
An SBC would likely not be configured for automatic. That way s/w could use semiautomatic, running BIT first, then letting itself participate in Auto Slot ID (by setting AUTOID) and seeing what data it's been given, then finally starting it's application. Or the card might just turn off Sysfail once it's up and doesn't need to be configured by anyone else. A dumb slave card would use automatic mode.
Acknowledging interrupts just once at a time: the Universe autonomously acknowledges VME interrupts if it's they are enabled, then interrupts the local CPU with the vector when it's got it. Check the interrupt driver for your card; it must not re-enable interrupts on IRQ2 as soon as it's got a vector,if the Auto Slot ID process isn't finished yet. What'll happen is the first card has been acknowledged and has enabled it's config registers to base zero in the CSR space, and now the Uni has raced ahead and acknowledged IRQ2 again, resulting in another card enabling itself into the CSR space at zero, before the first card's finshed (and still at that address). Data will get written to both cards, or the wrong card.
To access the VME CSR space via a Uni, you'll need to change the VAS bits in the PCI target image control reg that creates your outgoing window, to 101 (see the Uni manual for that reg definition).
Matt mentioned setting the Syscon bit; do not set this. Only slot 1 (no slot zero!) is allowed to provide system controller functions and it will figure out for itself when it's in slot 1 and whether to enable Syscon. If syscon is forced on in any other slot, the system will run erratically (you'll eventually get two masters on the bus at the same time).
A VMETRO card is very useful to seeing what's happening on the bus when developing this level of code!
Andy Fraser, DY 4 Systems
afraser@(3 characters, first one's a D) dot com
|
|
|
|