Re: [microblaze-uclinux] The one cycle access to LMB

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Alejandro,

alucero@xxxxxxxxx wrote:

>>Apart from the existing code in mach_early_init, which copies the
>>interrupt vectors, there should be no other accesses into LMB.
> 
> Ok. I'm a bit confused. I have two bram controllers at my mhs file, one an opb 
> interface controller and the other is the LMB interface controller. The 
> addresses for the OPB controller are 0x0 to 0x00001fff, meanwhile the 
> addresses for LMB are 0x20000000-0x20001fff. I was using the LMB addresess to 
> copy the irq routine (just the irq entry at entry.S, not specific irq devices 
> routines since what I want is to measure the worst interrupt latency case).
> However, I have seen that the addresses you use to copy the interrupt and 
> exception table is the 0x0, in my case the OPB bram controller address. 
> Is that right? Is there a conflict in my configuration file?

As you are seeing, this stuff currently assumes the "default" microblaze
setup of each port of a BRAM going to the ILMB and DLMB, mapped to the
same address space (0x00 upwards).

If I understand, you have a BRAM block attached at one port to the ILMB,
from 0x2000000 upwards, and one port attached to OPB mapped at 0x000000?

This is not going to work well, because MicroBlaze always branches to
e.g. 0x10 on an interrupt.  in your architecture, 0x10 will cause an OPB
fetch (not LMB), and will be slower than it needs to be.

You would probably be better to reverse this mapping, so the LMB
interface maps 0x000 upwards, and OPB 0x2000000.

But, since you cannot write data over the ILMB, you will then have to
change the code in machine.c where it sets up the interrupt vectors etc,
to add the 0x2000000 offfset to force these write accesses out over the
OPB bus - basically just line 144 of
arch/microblaze/platform/uclinux-auto/machine.c will become

dst = (unsigned int *) 0x20000000;

> I attach my mhs file.

Hmm, I don't see it here?

>>If you are using XMD/MDM, try setting a HW write breakpoint at one of
>>the corrupted addresses, and set the kernel running.  You might be able
>>to trap the offending instruction this way.
> 
> 
> Ohh. I did not know the XMD had this option. GREAT!

Yes - make sure you have HW debug support enabled in the MicroBlaze ,and
at least one write data breakpoint support (set by default).

Then in XMD, once you are connected:

% watch w <addr>

will set a hardware write watchpoint at that address.  Then, let the
kernel run, it should trap when something tries to clobber that address.

see XMD's "help breakpoint" for more.

> I want to release my work the next weeks, and I think it could be interesting 
> for the microblaze comunity ... real time?.

It will be interesting to see what sort of latency/jitter improvements
you get from running the basic IRQ  stuff out of BRAM.

Cheers,

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/