On 10/11/2012 04:01:27 AM, Prabhakar Kushwaha wrote:
On 10/11/2012 05:51 AM, Scott Wood wrote:
I'm debugging some SPL changes and am still having a hard time
following the initial TLB flow. We seem to be creating an entry in
AS0 -- how is that not conflicting with the TLB entry we're running
from?
The behaviour of overlapping TLB entries is undefined for e500v2
processor.
Luckily it is working for P1010RDB, P1020RDB, P2020RDB-PC and
BSC9131RDB.
Why is the debug TLB 256K? Why is it not aligned to 256K?
Temp TLB is created because label "nexti" resize the current TLB
to 4K. So create one for debugging with CONFIG_SYS_MONITOR_BASE.
Although we are creating TLB entry for 0x11001000 but actual TLB
entry is created with 0x11000000,256K aligned. Same is verified from
debugger.
You shouldn't rely on the hardware to ignore the lower bits of the
address.
Why does it need to be 256K?
How do you know that MAS2_I is correct (it should be cacheable in
the loaded-by-spl case)?
I set it as MAS2_I because same is done while creating AS1 TLB
entries for CONFIG_SYS_MONITOR_BASE during CONFIG_SYS_RAMBOOT.
I'm trying to get the p2020rdb-pca SPL payload to run out of L2
SRAM, and I see weird TLB behavior causing a hang if I don't comment
out the debug TLB.
is the root cause MAS2_I or 256K TLB entries created?
It's not MAS2_I, as it happens even when I have all the other SRAM
mappings cache inhibited. I don't know what the root cause is.
The proper solution would be to create temp Debug TLB for
CONFIG_SYS_RAMBOOT after resizing current TLB to 4K.
Please suggest.
I suggest you do so. :-)
In the meantime, I'll remove it for RAMBOOT/SPL as it's broken.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
