- Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
- S32M
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
- MCUXpresso Training Hub
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Knowledge Bases
- ARM Microcontrollers
- i.MX Processors
- Identification and Security
- Model-Based Design Toolbox (MBDT)
- QorIQ Processing Platforms
- S32 Automotive Processing Platform
- Wireless Connectivity
- CodeWarrior
- MCUXpresso Suite of Software and Tools
- MQX Software Solutions
-
- Home
- :
- QorIQ Processing Platforms
- :
- P-Series
- :
- Re: P2020 boot
P2020 boot
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
P2020 boot
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Booting from GPCM, local bus. Not completing boot, it hangs when I try to write the CCSRBAR register. In fact it hangs when I do any STW command.
Im looking at this on an ATE so I control the content of the RAM. The part goes to rest vector, I branch and write th MASx registers, run tlbwe and isynce. Next I try to set the CCSRBAR and that is when I have problems. This is after power on reset and so I should have all necessary permissions. I believe I'm missing something basic, an ideas?
ba 0xFFFFF000
lis r5, 0x0000
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5
lis r5, 0xe000
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xe000
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe 0,0,0
msync
isync
//////////////////////////////////
// relocate CCSRBAR at 0xe0000000
//////////////////////////////////
// read current value (forces all accesses to configuration space to complete)
lis r5, 0xff70
ori r5, r5, 0x0000
lwz r4, 0(r5)
isync
//Write the new value to CCSRBAR
lis r5, 0x000e
ori r5, r5, 0x0000
lis r4, 0xFF700000@ha
stw r5, 0xFF700000@l(r4)
nop
nop
......
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please double-check your TLB setup. You put 0 into MAS0, selecting TLB0. However, TLB0 does not support IPROT nor page sizes other than 4K, both of which you've requested in MAS1. Also, where did you set up the TLB entry pointing at 0xff700000?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Scott,
I'm realizing I'm not setting up the TLB correctly. I've modified code to this, but get the same results. I'm still missing something.
ba 0xFFFFF000
lis r5, 0x1001
ori r5, r5, 0x0000
mtspr 624, r5 //MAS0
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5 //MAS1
lis r5, 0xe000
ori r5, r5, 0x000a
mtspr 626, r5 //MAS2
lis r5, 0xe000
ori r5, r5, 0x003f
mtspr 627, r5 //MAS3
tlbwe 1,1,0 //TLB1
msync
isync
lis r5, 0x1002
ori r5, r5, 0x0000
mtspr 624, r5 // MAS0
lis r5, 0xC000
ori r5, r5, 0x0900
mtspr 625, r5 //MAS1
lis r5, 0xf000
ori r5, r5, 0x000a
mtspr 626, r5 //MAS2
lis r5, 0xf000
ori r5, r5, 0x003f
mtspr 627, r5 //MAS3
tlbwe 1,2,0 /TLB2 to set up eLBC and CCSR
msync
isync
//////////////////////////////////
// relocate CCSRBAR at 0xe0000000
//////////////////////////////////
// read current value (forces all accesses to configuration space to complete)
lis r5, 0xff70
ori r5, r5, 0x0000
lwz r4, 0(r5)
isync
//Write the new value to CCSRBAR
lis r5, 0x000e
ori r5, r5, 0x0000
lis r4, 0xFF700000@ha<mailto:0xFF700000@ha>
stw r5, 0xFF700000@l(r4<mailto:0xFF700000@l(r4>) //hangs up on this command
Tony
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The entry you're putting in ESEL 2 is overlapping the boot TLB entry, which is illegal. Not sure if that's what's causing your problem, though.
You shouldn't enable execute permission on CCSR or other I/O -- the guarded bit doesn't prevent speculative execution. This is very unlikely to be your problem, but it's something you should be aware of.
Why are you specifying operands to tlbwe? It doesn't take any on e500 -- MAS0 is used to identify the entry to write.
Are you sure that the stw is what hangs? What code is after the stw? Is there any chance your debugger is depending on the location of CCSR not changing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I change the tlbe2 to be 1MB so it shouldn't be overlapping anymore. And I dropped the operands for tlbwe. I know it is the stw command because if I replace with a nop it continues on. All I have after the stw right now is nop's for debug. I found that this also fails.
lis r7,0xff70
ori r7,r7,0000
lwz r4, 0(r7)
So not just writing to CCSBAR, but reading from CCSBAR. Somehow I must not be defining memory correctly.
Tony Kleman
Test Engineer
Integra Technologies LLC
3450 N. Rock Rd. bld 100
Wichita, KS 67226
316-630-6809 phone/fax
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So the first lwz doesn't hang but a second one does? What happens if you just do the store without an lwz first?
Just to be sure, when you adjusted the size of tlbe2, you adjusted the base address (in both MAS2 and MAS3) to 0xff700000, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I supposed this makes some sort of sense. FF70_0000 is not in the FFFF_F000 4k space defined in boot. But I'm supposed to write that address to define the CCSRBAR. Am I missing an indirect addressing somewhere?
Tony
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There shouldn't be anything required other than setting up the TLB entry.
Has your debug environment set up any LAWs, BTW? While CCSR normally takes precedence over LAWs, there is a note in the manual that says that undefined behavior can occur if a DDR LAW overlaps CCSR.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It never gets to the LAW section before hanging. I must be setting up the TLB wrong then if nothing else is required.
ba 0xFFFFF000
lis r5, 0x1001
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5
lis r5, 0xe000
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xe000
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe
isync
lis r5, 0x1002
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5
lis r5, 0xf000
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xf000
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe
isync
//////////////////////////////////
// relocate CCSRBAR at 0xe0000000
//////////////////////////////////
// read current value (forces all accesses to configuration space to complete)
lis r5, 0xff70
ori r5, r5, 0x0000
lwz r4, 0(r5) /// yes this is where it hangs
isync
//Write the new value to CCSRBAR
lis r5, 0x000e
ori r5, r5, 0x0000
lis r4, 0xFF700000@ha
stw r5, 0xFF700000@l(r4)
Tony Kleman
Test Engineer
Integra Technologies LLC
3450 N. Rock Rd. bld 100
Wichita, KS 67226
316-630-6809 phone/fax
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From a few comments back: "Just to be sure, when you adjusted the size of tlbe2, you adjusted the base address (in both MAS2 and MAS3) to 0xff700000, right?"
You changed the size of the entry to 1 MiB, but you left the base at 0xf0000000. So the entry covers from 0xf0000000 to 0xf00fffff, and nothing covers 0xff700000.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No I didn't. This is the code snippet I got from freescale
I get confused about the location of CCSRBAR. From the P2020 reference manual, but all code snippets I see is FF70_0000. I've tried FFE0.
2.2.4 CCSR Address Map
The full register address of any CCSR is comprised of the CCSR window base address, specified in
CCSRBAR (default address 0x0_FFE0_0000), plus the functional block base address, plus the specific
register's offset within that block.
4.3.1.1 Accessing Configuration, Control, and Status Registers
The configuration, control, and status registers are memory mapped. The set of configuration, control, and
status registers occupies a 1-Mbyte region of memory. Their location is programmable using the CCSR
base address register (CCSRBAR). The default base address for the configuration, control, and status
registers is 0xFFE0_0000 (CCSRBAR = 0x000F_FE00). CCSRBAR itself is part of the local access block
of CCSR memory, which begins at offset 0x0 from CCSRBAR. Because CCSRBAR is at offset 0x0 from
the beginning of the local access registers, CCSRBAR always points to itself. The contents of CCSRBAR
are broadcast internally in the P2020 to all functional units that need to be able to identify or create
configuration transactions.
// 1MB TLB1 entry 1: 0xE0000000 - 0xE00FFFFF; for CCSR cache inhibited
lis r5, 0x1001
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5
lis r5, 0xe000
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xe000
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe
msync
isync
// 256MB TLB1 entry 2 - Local Bus : 0xF0000000 - 0xFFFFFFFF
lis r5, 0x1002
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0900
mtspr 625, r5
lis r5, 0xf000
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xf000
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe
msync
isync
Tony Kleman
Test Engineer
Integra Technologies LLC
3450 N. Rock Rd. bld 100
Wichita, KS 67226
316-630-6809 phone/fax
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not sure what you mean by, "No I didn't." In the code snippet posted on Mar 15, 2013 10:51 AM, for the second TLB entry, please change SPR 626 from 0xf000000a to 0xff70000a, and SPR 627 from 0xf000003f to 0xff700005.
The default CCSRBAR on P2020 is 0xff700000. It is U-Boot that relocates it to 0xffe00000, but since you're running straight from the reset vector U-Boot isn't involved. What revision of what document do you see 0xffe00000 in? I see similar language in an older version of the P2020 reference manual, but it says 0xff700000.
Where did you get the code snippet from Freescale?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have changed to this. It no longer hangs up and I'm trying to determine if it is doing what I want. The manual I have is 03/2011
ba 0xFFFFF000
lis r5, 0x1001
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5
lis r5, 0xFF70
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xFF70
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe
isync
lis r5, 0x1002
ori r5, r5, 0x0000
mtspr 624, r5
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5
lis r5, 0xe000
ori r5, r5, 0x000a
mtspr 626, r5
lis r5, 0xe000
ori r5, r5, 0x003f
mtspr 627, r5
tlbwe
isync
//////////////////////////////////
// relocate CCSRBAR at 0xe0000000
//////////////////////////////////
// read current value (forces all accesses to configuration space to complete)
lis r5, 0xff70
ori r5, r5, 0x0000
lwz r4, 0(r5)
isync
//Write the new value to CCSRBAR
lis r5, 0x000e
ori r5, r5, 0x0000
lis r4, 0xFF700000@ha
stw r5, 0xFF700000@l(r4)
Tony Kleman
Test Engineer
Integra Technologies LLC
3450 N. Rock Rd. bld 100
Wichita, KS 67226
316-630-6809 phone/fax
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The latest P2020RM is Rev 2, dated 12/2012, and is available from our website. That said, the older version I was talking about was from 2009, so the error must have been introduced and then fixed.
Again, I recommend clearing the execute bits from MAS3 on these TLB entries -- you're not actually going to execute code from CCSR, and it leaves you open to speculative fetches that could have side effects. It's unlikely, but possible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Scott
It turns out I can do a lwz and stw as long as it is to the 4K boot space. I can do a mfspr and verify MASx are set correctly. It only hangs when I try to write to FF70_0000
Tony
scottwood
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So it was hanging on the lwz and not the stw in the previous code snippet? Can you show what the code looks like now?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm realizing I'm not setting up the TLB correctly. I've modified code to this, but get the same results. I'm still missing something.
ba 0xFFFFF000
lis r5, 0x1001
ori r5, r5, 0x0000
mtspr 624, r5 //MAS0
lis r5, 0xC000
ori r5, r5, 0x0500
mtspr 625, r5 //MAS1
lis r5, 0xe000
ori r5, r5, 0x000a
mtspr 626, r5 //MAS2
lis r5, 0xe000
ori r5, r5, 0x003f
mtspr 627, r5 //MAS3
tlbwe 1,1,0 //TLB1
msync
isync
lis r5, 0x1002
ori r5, r5, 0x0000
mtspr 624, r5 // MAS0
lis r5, 0xC000
ori r5, r5, 0x0900
mtspr 625, r5 //MAS1
lis r5, 0xf000
ori r5, r5, 0x000a
mtspr 626, r5 //MAS2
lis r5, 0xf000
ori r5, r5, 0x003f
mtspr 627, r5 //MAS3
tlbwe 1,2,0 /TLB2 to set up eLBC and CCSRBAR
msync
isync
//////////////////////////////////
// relocate CCSRBAR at 0xe0000000
//////////////////////////////////
// read current value (forces all accesses to configuration space to complete)
lis r5, 0xff70
ori r5, r5, 0x0000
lwz r4, 0(r5)
isync
//Write the new value to CCSRBAR
lis r5, 0x000e
ori r5, r5, 0x0000
lis r4, 0xFF700000@ha
stw r5, 0xFF700000@l(r4) //hangs up on this command
