cache issues

[Altera_Forum]

We've managed to get uClinux to run on the custom HW board we are testing, and have also established a 100bT connection to the board, done remote login off a LAN etc. Everything seems to be progressing nicely. We're doing all of this with no JTAG UART because we want to ensure that these designs can be recreated using the free web-based Quartus tools, which require that the JTAG port be utilzed to allow the NIOS to run continuously as opposed to time-limited.  

 However, we can only get NIOS2 + uClinux to work together if we use the smallest NIOS2 core, i.e. the one with no cache.  As soon as we try the full-sized core with I and D caches, nothing works. The CPU doesn't boot at all.  We rebuild the kernel after recompiling the NIOS core, but get zilch.  Does anyone have any ideas on how we can get a cache version of NIOS to wake-up? Is there somethingn special we have to do to enable it to work? If so, it isn't obvious to us.  Many thanks!

[Altera_Forum]

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.

[Altera_Forum]

<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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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.