mpc85xx debug TLB entry
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? Why is the debug TLB 256K? Why is it not aligned to 256K? How do you know that MAS2_I is correct (it should be cacheable in the loaded-by-spl case)?
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.
-Scott
Quoted 3 lines · Scott Wood
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.
Quoted 1 line
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.
Quoted 2 lines
How do you know that
MAS2_Iis 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.
Quoted 6 lines
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?
The proper solution would be to create temp Debug TLB for CONFIG_SYS_RAMBOOT after resizing current TLB to 4K. Please suggest.
Regards,
Prabhakar
Quoted 11 lines · Prabhakar Kushwaha
Quoted 4 lines · Scott Wood
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.
Quoted 7 lines
Quoted 1 line
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 for0x11001000but 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?
Quoted 7 lines
Quoted 2 lines
How do you know that
MAS2_Iis correct (it should be cacheable in the loaded-by-spl case)?I set it as
MAS2_Ibecause same is done while creating AS1 TLB entries forCONFIG_SYS_MONITOR_BASEduringCONFIG_SYS_RAMBOOT.Quoted 1 line
Quoted 6 lines
Quoted 5 lines
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_Ior 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.
Quoted 3 lines
The proper solution would be to create temp Debug TLB for
CONFIG_SYS_RAMBOOTafter 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
Quoted 37 lines · Scott Wood
Quoted 11 lines · Prabhakar Kushwaha
Quoted 4 lines · Scott Wood
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.Quoted 7 lines
Quoted 1 line
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 for0x11001000but 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?
Quoted 12 lines
Quoted 2 lines
How do you know that
MAS2_Iis correct (it should be cacheable in the loaded-by-spl case)?I set it as
MAS2_Ibecause same is done while creating AS1 TLB entries forCONFIG_SYS_MONITOR_BASEduringCONFIG_SYS_RAMBOOT.Quoted 6 lines
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.
Quoted 4 lines
Quoted 1 line
is the root cause
MAS2_Ior 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.
On p2020, the debug tlb is entry 2. The entry we're running out of (in my current patchset) is entry 8. These entries are for the same virtual address (which as you note is illegal). When we do a tlbsx to find out which entry to shrink, it's returning the bitwise OR of the two entry numbers, and we end up writing a new entry 10 without removing the old entry 8.
Then we go through the TLB removing entries which are neither 2 nor
10. After 8 is removed, we end up executing the wrong code -- we take a fault with SRR0=0xf8f81288 that only makes sense if it's really executing code at 0xf8ff1288.
TLB entry 2 is 256K at 0xf8f80000, and TLB entry 10 is 4K at 0xf8f81000 (both identity mapped). The only entry that points to physical addres 0xf8ff1288 is entry 12, which is 256K at 0xf8fc0000 (identity mapped).
While all this is totally illegal and strange things are allowed to happen as a result, I do find it odd that having just entry 2 and 10 causes worse behavior than having 2, 8, and 10. The only difference between entries 2 and 8 is that entry 8 is guarded and entry 2 is not (both are cache inhibited).
Quoted 7 lines
Quoted 3 lines
The proper solution would be to create temp Debug TLB for
CONFIG_SYS_RAMBOOTafter 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.
I'll move it as part of my patchset, but I'll need you to verify that debugging still works. I won't be basing this on RAMBOOT -- until we shrink the entry we're running from and remove other entries, we shouldn't add anything else to the TLB under any boot scenario. Plus the file is messy enough as is without putting the debug TLB stuff in two different places.
I'll also reduce the debug mapping to 4K, so it doesn't conflict with the 4K page we're running out of.
-Scott
Quoted 3 lines · Scott Wood
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.
Quoted 1 line
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.
Quoted 2 lines
How do you know that
MAS2_Iis 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.
Quoted 6 lines
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?
The proper solution would be to create temp Debug TLB for CONFIG_SYS_RAMBOOT after resizing current TLB to 4K. Please suggest.
Regards,
Prabhakar