[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] System hangs with I-cache enabled

I am using microblaze 4.00.a and opb_ddr 2.00.b with EDK 8.1.01i.
I traced the problem to the Sln_retry signal from the opb_ddr. The problem occurs when this signal is asserted and the OPB arbiter schedules a different master (in this case the EMAC) on the next transaction. The opb_ddr must keep some internal state which causes it to latch up when presented with a different address. I was able to work around this problem by converting Sln_retry into Sln_toutSup. This probably decreases performance slightly, but who needs performance when you do not have functionality? A remaining question is why the 2 OPB masters built into the microblaze do not trigger this problem.
I was not able to get mch_opb_ddr 1.00.b working--is it compatible with the XUP board? If so, how should I set it up? I tried setting up the DDR interface and parameters to match the opb_ddr, but when I debugged the design with XMD, all my memory transfers seemed to wrap around into the LMB address space. 

Alex


On Tue, 18 Apr 2006, John Williams wrote:


Hi Alex,

Alex Krasnov wrote:


I have built the uclinux kernel from the latest source and am running it
on the XUP board using the reference design with caches enabled.
Whenever I enable the I-cache in the kernel, the system hangs after a
short period (at most a few minutes). In particular, an almost certain
way to hang it is to do an NFS transfer, though the problem occurs even
with NFS disabled. XMD reports that the pipeline is stalled at a random
PC. The problem occurs consistently regardless of other hardware or
kernel features.


Are you using the mch_opb_ddr memory controller, by any chance?

And what version  / service pack of EDK?

There was a bug in the mch_opb_ddr core, in EDK7.1, and I am not sure if
it has been completely resolved.  It caused pipeline stalls like that
you describe.

Also, there was a bug in the MicroBlaze v4.00.a core, around the same
time, whereby partial cache invalidate operations would cause problems
when the MCH (CacheLink) channels were used.

You can see the legacy of this bug in
linux-2.4.x/include/asm-microblaze/pgalloc.h, around line 116 - if the
FSL caches are enabled, all cache flush operations do the entire cache,
not just the necessary range.


Before I go on a lengthy debugging journey, I would like to know whether
this is a known problem or whether there is a simple explanation. The
only possible explanation I see is that the I-cache is inconsistent with
main memory; however, this seems unlikely since the kernel flushes the
I-cache when necessary. Also, I added full flushes in several places,
including in the scheduler. Adding printfs to the scheduler seemed to
help, so perhaps there is a race condition. I can provide additional
information or debug output if necessary.


Cache inconsistency in single processor systems is really only an issue
if you have some peripheral doing DMA - but, in currently that's just
the ethernet MAC, and that driver is stable and well tested / used.

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/