cache issues

I am not the uClinux expert but can tell you this: Try turning on the icache - that should be completely transparent to the sotware that is running. Adding dcache is *not* transparent.

The software that running must ensure that cache coherency is managed by: mallocing buffers as un-cachable, flushing the cache to external memory, or doing direct (cache-bypassed) IO reads and writes as necessary... I would imagine that the linux port & drivers already have taken care of this but one of the Microtronix guys can probably confirm it.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

I would imagine that the linux port & drivers already have taken care of this but one of the Microtronix guys can probably confirm it.[/b]

--- Quote End ---

confirmed. The port and drivers Microtronix provided have taken care of this.

thosburke, regarding the problem you run into, I recommend making a simple hello world program work first on the new core, before trying uClinux. I have had similar problems many times, most were proven no-software problems. Using a standalone small program, you can check if the flash, sdram, etc can be accessed ...

Regards,

wentao

Microtronix

I&#39;ve tried this already (trying to get anything to work with cache) and have never succeeded. I have a small monitor program that can run out of flash, internal ram/rom or sdram just fine. But, if I use a NIOS core with cache, nothing happens. By all outward appearances the CPU is dead. The monitor could fit 100% in icache, but since the core is dead, I can&#39;t try anything.

I&#39;ve tried both the standard and full cores, standard having only i-cache, and full having both i- and d-cache.

There must be something required to initialize the cache, or flush it or something on power-up (or hard cpu reset), but I&#39;ve yet to find out what the magic trick is.

Oh, and I&#39;m using release 1.01 of the NIOS2 core. Of course, that would be so easy to blame....

I&#39;d be happy for any advice.

Thanks,

TB

Anyway, if you reenable interrupts, the Dcache will give you trouble (there is a strange behaviour in 1.0 and 1.01 (should be fixed in 1.1).

Stefaan

As far as I know, the D-cache in Nios II 1.0.1 works fine (there was a bug in Nios II 1.0).

I did find a bug in the Nios II/f core regarding interrupts and writes to the ienable register that is fixed in Nios II 1.1.

This bug looks like a spurious interrupt. I&#39;m not familiar enough with the uClinux code to know what it does

in this case but it could be your problem.

I&#39;d recommend that you try a simple experiment to see if your problem is

with the D-cache or just the Nios II/f in general. Just edit your system.ptf file (make sure SOPC Builder isn&#39;t running)

and change always_bypass_dcache from "0" to "1". Now regenerate in SOPC Builder, recompile your software,

and try again. If you still have a problem, it isn&#39;t the D-cache because you just disabled it.

As for how to initialize the caches, I would hope the that the uClinux startup code at the reset address

takes care of this for you. You should see it executing initi instructions in a loop to clear out the I-cache

and initd instructions in a loop to clear out the D-cache.

BTW, when you say the CPU is dead, what exactly do you mean by dead? If you have the OCI debug built-in,

are you able to single-step or break the CPU? You could enable Signaltap II and look at signals to see what

the CPU is doing while it is dead. I&#39;d recommend looking at A_pc, A_valid, A_iw, and A_stall. The A_pc is the A-stage

word-aligned instruction address (multiply by four to get a byte address). The A_valid tells you if there is an

instruction in the A-stage. The A_iw tells you which instruction is present (32-bit instruction). The A_stall tells you

if the A-stage (and all other stages as well) are stalled.