[U-Boot] mpc85xx debug TLB entry
Scott Wood
scottwood at freescale.com
Thu Oct 11 17:21:07 CEST 2012
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
More information about the U-Boot
mailing list