Re: MVME3100 boot failure at "Trying to find CSR on VME"

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

On Nov 29, 2021, at 8:33 PM, Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> wrote:

On 11/28/21 9:12 PM, Peter Linardakis via Tech-talk wrote:

vmeTsi148 IRQ manager: looking for registers on VME...
Trying to find CSR on VME...
*********

Does anyone have any ideas why a certain backplane will cause this?

CSR in this context refers to the CSR address space, which
is a VME64 extension using the geographic address pins,
which won't be present in an older VME32 crate.

Still, this error shouldn't be fatal as the TSI148 driver
should fall back and print "Trying to find CRG on VME...".

https://github.com/RTEMS/rtems/blob/e945e3fc4d6a6a74789c9a348120ec7d06e19231/bsps/powerpc/shared/vme/vmeTsi148.c#L1715

Since the CPU on this backplane apparently hangs before printing that “CRG” message, my guess is that either the VME system controller isn’t generating a BERR signal if/when nothing responds to the I/O cycle after some suitable timeout interval (I assume from the probe operation in the call at line 1717), or maybe that the backplane has a problem with its BERR* signal line not working properly (is it terminated properly?). If the CPU doesn’t see a falling edge on either the BERR or DTACK signal it will hang waiting for a data from the read cycle which never completes. If this CPU *is* the VME system controller the code should have enabled a cycle timeout, but going back to what Heinz was talking about you need to make sure that the SCON is properly enabled and that the CPU is in slot 0.

- Andrew

-- 

Complexity comes for free, simplicity you have to work for.