[U-Boot] mpc85xx debug TLB entry

[Scott Wood <scottwood@freescale.com>]

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