[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Odd Microblaze behavior
Richard Klosinski wrote:
> Here is the code and small disassembly
> 4 int a;
> 6 a = 33;
> 0x2dc <main+16>: addik r3, r0, 33 // 0x21
> - 0x2e0 <main+20>: swi r3, r19, 28
> 7 a = 33;
> - 0x2e4 <main+24>: addik r3, r0, 33 // 0x21
> - 0x2e8 <main+28>: swi r3, r19, 28
OK, so the assembly looks reasonable, but in this instance you seem to
have omitted the "volatile" keyword on the variable 'a'?
> As I step through main+16 and stop at main+20, r3 = 0x2fd, NOT 33. Stopping
> at main+28, r3 = 0x21. The only registers that are changing are r3 and rpc.
That's odd. What debugging mechanism are you using? XMD + MDM over
JTAG? XMD + xmdstub over serial?
Can you fully describe a small self-contained test case that I can try
here (and we can give to Xilinx EDK guys to test)?
> This behavior happens all through my code, making it impossible to boot my
> ucLinux from flash, as I cannot run code out of bram. I relocated my flash
> code to upper memory, and I was able to erase and program flash w/o a
There's something else going on here - this should just "work". For
example the "jboot" bootloader in the mbvanilla_net target does exactly
these kinds of operations, executing from BRAM, writing and erasing
flash devices etc, and it works fine (in my experience).
Could it be something like your code not conforming to the timings
expected by the flash devices? When running from BRAM on fixed 2 cycle
bus latency, maybe it's too fast for the flash, but when executing from
external ram perhaps the bus fetch delays are opening the timing window
up a bit? Far-fetched I know, but the behaviour you describe is pretty
> BEGIN lmb_bram_if_cntlr
> PARAMETER INSTANCE = i_lmb_bram_if_cntlr
> PARAMETER HW_VER = 1.00.b
> PARAMETER C_MASK = 0x80000000
> PARAMETER C_BASEADDR = 0x00000000
> PARAMETER C_HIGHADDR = 0x00001FFF
> BUS_INTERFACE SLMB = i_lmb_v10
> BUS_INTERFACE BRAM_PORT = conn_1
probably insignificant, but I never set the C_MASK parameter directly
here - it seems safer to let platgen work it out.
> Note that the cache is only for the sdram, as the bram runs at opb speeds,
> and does not need to be cached.
yes - just wanted to be sure.
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/