question for the release.S u-boot code

[hv]

in this section of code:

"Coming here, we know the cpu has one TLB mapping in TLB1[0] which maps 0xfffff000-0xffffffff one-to-one.  We set up a second mapping that maps addr 1:1 for 64M, and then we jump to addr"

lis r10,(MAS0_TBLSEL(1)|MAS0_ESEL(0))@h

mtspr SPRN_MAS0,r10

does it look like it's setting up entry 0 in TLB1 for the 1:1 mapping?  But isn't entry 0 in TLB1 already used for the 4KB boot page (0xfffff000-0xffffffff)?

thanks!

[scottwood]

Yes, the boot mapping is in TLB1[0] -- but the spin table code is no longer executing from that TLB entry.  Beginning at __bootpg_addr it is executing from TLB1[1] which maps the same address in the alternate space (MAS1[TS] is set).

[hv]

The instruction “rfi” at the end of release.S is going to jump to this 1:1 64MB mapping. Can I run my code in this alternate space?

question for the release.S u-boot code

reply from Scott Wood<http://jiveon.jivesoftware.com/mpss/c/pQA/PDcDAA/t.1nd/7-hqasTVT3C-cZBFquTXtQ/h1/eqhG5v9o4WV1pCmWaB03cUjBPgRj-2F3GoJUaXSZ409bSdP5biIGukMJCDP2RcupmsPmgsYXI6jS0m1mNZQcP1yOyvoqXPJhZYDmN8R-2F7Wf2U-3D> in QorIQ Processors - View the full discussion<http://jiveon.jivesoftware.com/mpss/c/pQA/PDcDAA/t.1nd/7-hqasTVT3C-cZBFquTXtQ/h2/eqhG5v9o4WV1pCmWaB03cUjBPgRj-2F3GoJUaXSZ409bRoZ2SYle7BNfbHw3tg5nT3tBP3nZLDJYxHBKPIunet1Ukn1AwO1R70H7lvCrVxfl0-3D>

[scottwood]

Yes, you can run code from the mapping that is created -- see the decription in ePAPR of the Secondary Initial Mapped Area (SIMA).  However, you will probably want to replace the mapping in order to access beyond that 64M region.

The 64M mapping is not in the alternate space.  It's the 4K mapping in TLB1[1] that is in the alternate space (so that it doesn't conflict with the 64M mapping).

[hv]

While running in this 64M mapping, I set up CCSR for core 1 as follows:

mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(1);

mas1 = MAS1_VALID | MAS1_TID(0) | MAS1_TS | MAS1_TSIZE(BOOKE_PAGESZ_1M);

mas2 = FSL_BOOKE_MAS2(0xFE000000, MAS2_I|MAS2_G);

mas3 = FSL_BOOKE_MAS3(0xFE000000, 0, MAS3_SW|MAS3_SR);

mas7 = FSL_BOOKE_MAS7(0xFE000000);

write_tlb(mas0, mas1, mas2, mas3, mas7);

when the code runs, while trying to read the PID, the code had an exception.

PC: 0x000001C0

SRR0: 0x00007D24

DEAR: 0xFE040090

MAS0: 0x00000001

MAS1: 0x80000000

MAS2: 0xFE040000

MAS3: 0x00000000

It seemed to me that I didn’t set up the TLB for CCSR correctly then. But I don’t know what I did wrong.

And what’s at 0x1C0?

Thanks!

question for the release.S u-boot code

reply from Scott Wood<http://jiveon.jivesoftware.com/mpss/c/pQA/PDcDAA/t.1nj/D6e2uObWSB6OreXSenf_BQ/h1/eqhG5v9o4WV1pCmWaB03cUjBPgRj-2F3GoJUaXSZ409bSdP5biIGukMJCDP2RcupmsPmgsYXI6jS0m1mNZQcP1yOyvoqXPJhZYDmN8R-2F7Wf2U-3D> in QorIQ Processors - View the full discussion<http://jiveon.jivesoftware.com/mpss/c/pQA/PDcDAA/t.1nj/D6e2uObWSB6OreXSenf_BQ/h2/eqhG5v9o4WV1pCmWaB03cUjBPgRj-2F3GoJUaXSZ409bRTVbR62AlK2x0jKLXgsbN2BgUW3UNlXisE6xqqgdtOUX9N2VmCSPQ-2Ftl8QSkf1FO8-3D>

[scottwood]

Again, on OS entry you are not running in the alternate space, so don't set MAS1_TS.  Only the spin table code itself runs in the alternate space.

[hv]

I’m still unsure if I set up the MMU mapping for the CCSR correct. Following the CCSR mapping, I ran the following code:

mr r12, r3 // after this r12=xFE040090 which is where the I want to read the process ID for the core (in this case, it’s core 1)

lwz r12,0(r12) // r12 after this shows 0xFFFFFFFF

is that because I didn’t set up the CCSR correctly so it couldn’t read what’s there?

Thanks!

[scottwood]

What is the physical address of CCSR on your board?  What chip is it?

[hv]

It’s RDB P2041. I think the physical address is 0xFF700000 but I use 0xFE000000 because that’s where u-boot moved it to.

This is how I set up the mapping for CCSR:

mas0 = MAS0_TLBSEL(1) | MAS0_ESEL(1);

mas1 = MAS1_VALID | MAS1_TID(0) | MAS1_TSIZE(BOOKE_PAGESZ_16M);

mas2 = FSL_BOOKE_MAS2(CCSRBAR, MAS2_I|MAS2_G);

mas3 = FSL_BOOKE_MAS3(CCSRBAR, 0, MAS3_SW|MAS3_SR);

mas7 = FSL_BOOKE_MAS7(CCSRBAR);

[scottwood]

U-Boot on P2041, unless you've changed it, moves the CCSR physical address to 0xf_fe00_0000, not 0x0_fe00_0000.

[hv]

It’s working now that I use 0x0_FE00_0000 for core 1!

But I have this question:

When displaying memory from u-boot

CCSRBAR high is 0x0000000f

CCSRBAR low is 0xfe000000

But our software on core 0 is using just the 32-bit effective address is 0xFE000000 and it worked on core 0. Why?

Thanks!

[scottwood]

Do you mean when you use 0xf_fe00_0000?

The effective address is 0xfe00_0000 (it's a 32-bit core so you can't have an effective address of 0xf_fe00_0000).  The physical address is not equal to the effective address.

[hv]

We’re seeing TFTP timed out when running TFTP to load files to the T1040. Through Wireshark, we can see TFTP kept trying to send Data Packet Block 1 and there were acknowledgement for Block 1. Do you know what the issue is?

Thanks!

[scottwood]

That is a completely unrelated question; please make a new post for it, and provide more details (e.g. what sort of ethernet interface you're using).  I'm probably not the right person to answer that question.

[hv]

I will do that. Thank you very much for all your help!!!