MCF54454 with branch cache hangs my flexbus?

[AndyDaytona]

Hi,

I am having trouble with sporadic reads to unmapped flexbus memory causing

the processor to hang until the bus monitor kicks it going again.

The accesses seem to come from the branch cache, something like

move.l #1000,a2

...

lea sdram_label,a2

jsr (a2)

will still have caused a flexbus access at address 1000.

Turning the branch cache off comes with a 10% performance decrease which is no good.

I can extend an auto acknowledging chipselect to cover flexbus memory, what if a2 would point to

internal peripheral space?

Does anyone know if I am right about this? If so, can instruction prefetch disturb the internal peripherals?

best regards

Andy

[jkmahan]

Does it still happen if you do a flush on the branch cache?

[AndyDaytona]

If I flush the branch cache in the kernel thread dispatcher, the problem seems to disappear (or happen so seldom

I cannot detect it, although I cannot detect it directly by stepping thru code, and I cannot get any bus error to detect this so I

cannot trace exactly what happens, it has taken almost two weeks to find this problem as I initially assumed that it was a code bug.)

from my disassembly I have this generated by gcc

loop:

jsr (a3)

jsr (a2)

addq.l #4,sp

bra loop

a3 points to the semaphore wait command

a2 points to something that executes every time I get a semaphore signal.

The pop is for the semaphore wait, but has been deferred.

When this code executes there seem to be a flexbus read at the address pointed to by a2 in another thread!

If I put just a trapf between the jsr instructions the problem goes away.

I have  a memory mapped external peripheral (a DSP) and if a2 for some reason would point to its memory,

it would be really bad.

[jkmahan]

Sounds similar to a problem I tracked down a couple of years ago when I worked for FSL doing the V4 Linux BSP.   

[AndyDaytona]

That sounds very interesting, did you manage to pinpoint how to avoid the problem?

I also noticed now that disabling the branch cache in cacr did not solve the problem.

I also managed to induce false reads to the ATA FIFO, hanging the DMA handler, using this

problem which proves that it is not isolated to the flexbus, I think.

This only leaves avoiding the instruction combinations creating this state altogether as an option.

[jkmahan]

The big issue was that I was changing the the MMU mappings and not flushing the branch cache at the same time I was flushing the other caches.  So there was stale data in the branch cache.

[AndyDaytona]

Ok, unfortunately, we do not use the MMU, so that shouldn't be it.