[U-Boot] tlb15_entry is set wrong in the 4K code when the MPC8572DS boots from nand flash

[Scott Wood]

On Thu, 2014-02-13 at 17:22 +0100, Y fan wrote:
> Hello,
> 
> 
> >I don't know what you mean by "the fifth bit of the tlb1_entry 15
> value".
> 
> 
> From the file CodeWarrior version10.x.pdf (see in the attatchment),
> the fifth bit of the TLB1_entry indicates the AS.
> 
> 
> >What makes you say it's 256M?  Are you dumping the TLB from some
> debugger?  Are you sure you're dumping it at the right time?  Don't
> rely
> on breakpoints.
> 
> 
> 
> And from my debug software, the TLB1_entry 15 is L2MMU_CAM15 =
> 0x900003ca1c080000fff00000fff00001. So according to the CodeWarrior
> version10.x.pdf, I think the size of TLB1_entry 15 is 256Mbyte.
> 
Where is the code executing when you see that?

I'm surprised CodeWarrior doesn't give a user-friendly display of that
data...

The "Encoded page size" of 9 (256M) doesn't seem to match the "Mask" of
0b0000001111 (1M).  Normally this sort of contradiction would make me
think of overlapping TLB entries, but I think that only makes sense as
an explanation if this were a tlbsx-equivalent rather than a
tlbre-equivalent.  My next suspicion is that something's wrong with the
debugger. :-P

FWIW, I built MPC8572DS_NAND and disassembled create_init_ram_area, and
the value it loads into TLB1 is 0xc0001500 which is TS=1, 1MiB size:

Dump of assembler code for function create_init_ram_area:
   0xfff00b40 <+0>:	lis     r6,4111
   0xfff00b44 <+4>:	ori     r6,r6,0
   0xfff00b48 <+8>:	lis     r6,4111
   0xfff00b4c <+12>:	ori     r6,r6,0
   0xfff00b50 <+16>:	mtspr   624,r6
   0xfff00b54 <+20>:	lis     r6,-16384
   0xfff00b58 <+24>:	ori     r6,r6,5376
   0xfff00b5c <+28>:	mtspr   625,r6
   0xfff00b60 <+32>:	lis     r6,-16
   0xfff00b64 <+36>:	ori     r6,r6,10
   0xfff00b68 <+40>:	mtspr   626,r6
   0xfff00b6c <+44>:	lis     r6,-16
   0xfff00b70 <+48>:	ori     r6,r6,21
   0xfff00b74 <+52>:	mtspr   627,r6
   0xfff00b78 <+56>:	lis     r6,0
   0xfff00b7c <+60>:	ori     r6,r6,0
   0xfff00b80 <+64>:	mtzpr   r6
   0xfff00b84 <+68>:	isync
   0xfff00b88 <+72>:	sync    
   0xfff00b8c <+76>:	tlbld   r0
   0xfff00b90 <+80>:	isync
   0xfff00b94 <+84>:	lis     r6,4110
   0xfff00b98 <+88>:	ori     r6,r6,0
   0xfff00b9c <+92>:	mtspr   624,r6
   0xfff00ba0 <+96>:	lis     r6,-16384
   0xfff00ba4 <+100>:	ori     r6,r6,4608
   0xfff00ba8 <+104>:	mtspr   625,r6
   0xfff00bac <+108>:	lis     r6,-48
   0xfff00bb0 <+112>:	ori     r6,r6,0
   0xfff00bb4 <+116>:	mtspr   626,r6
   0xfff00bb8 <+120>:	lis     r6,-48
   0xfff00bbc <+124>:	ori     r6,r6,21
   0xfff00bc0 <+128>:	mtspr   627,r6
   0xfff00bc4 <+132>:	lis     r6,0
   0xfff00bc8 <+136>:	ori     r6,r6,0
   0xfff00bcc <+140>:	mtzpr   r6
   0xfff00bd0 <+144>:	isync
   0xfff00bd4 <+148>:	sync    
   0xfff00bd8 <+152>:	tlbld   r0
   0xfff00bdc <+156>:	isync

> >What actual functional problem are you seeing?  Are you getting a TLB
> exception?  If so, at what line of code, trying to access what
> address?
>
> I think the problem is when the code wants to access the  memory
> address where the CCSRBAR is located, it will get the wrong values. So
> it can't get the correct baud rate for the serial port and can't
> initialize the correct size of L2SRAM.For example, the function
> cpu_init_f in start.S can initial the L2 SRAM, but it gets the wrong
> L2SRAM size from the memory. 

Could you show the actual value expected versus read, and what specific
virtual address it was read from?  Do other CCSR registers look wrong?

Can you try reading out the TLB entries in software and writing them to
memory that the debugger can read?

> I didn't get a TLB exception.
> 
> 
> I know in the nand_spl there's no relocation of the CCSRBAR, but why in
> the cpu_init_early_f  there's a tlb1_entry 1 is set for CCSRBAR from
> rpn=0xff700000 to epn=0xffe00000. Now I think it's why I can't get the
> correct value when accessing the memory region where CCSRBAR is
> located.
> 
There's no relocation of the physical address of CCSR, but we always use
U-Boot's preferred virtual address when mapping and accessing it.  Why
do you think this is a problem?  What does it have to do with the early
TLB entries written with create_tlb1_entry in start.S?
> 
> I want to know how big the u-boot-nand.bin file after compiling? My
> file is about 572 Kbyte.

That sounds about right.
> 
-Scott