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