Arm Community
Site
Search
User
Site
Search
User
Groups
Arm Research
DesignStart
Education Hub
Graphics and Gaming
High Performance Computing
Innovation
Multimedia
Open Source Software and Platforms
Physical
Processors
Security
System
Software Tools
TrustZone for Armv8-M
中文社区
Blog
Announcements
Artificial Intelligence
Automotive
Healthcare
HPC
Infrastructure
Innovation
Internet of Things
Machine Learning
Mobile
Smart Homes
Wearables
Forums
All developer forums
IP Product forums
Tool & Software forums
Pelion IoT Platform
Support
Open a support case
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Developer Community
Tools and Software
Software Tools
Jump...
Cancel
Software Tools
Arm Development Studio forum
Bootloader problem in ARM926ejs
Tools, Software and IDEs blog
Forums
Videos & Files
Help
Jump...
Cancel
New
Replies
9 replies
Subscribers
127 subscribers
Views
3515 views
Users
0 members are here
Related
Bootloader problem in ARM926ejs
Offline
F Girault
over 7 years ago
Parents
Offline
F Girault
over 7 years ago
Note: This was originally posted on 25th June 2011 at
http://forums.arm.com
Hi scott,
Thx for your reply.
The abort exception I get is a Data Abort exception so I located the offending instruction by looking at the address pointed by (R14-8).
It was a write access to a peripheral register.
I did some additional checks today, and I discovered that my MMU table is not always mapped as I expect it to be.
I fill up a table by giving
[size], [logical address], [physical address], [attributes]
in an MMU table, and I was told only to be careful that the TTB base address should be 16kB aligned, and the page addresses 4kB aligned, but after MMU table initialization, I took a pick at the entries in the TTB and Coarse TTB, and it is not always what I was expecting (for example, the entries concerning the stack memory do not appear in the TTB but it should point to an entry in the CTTB - but I have to double check that).
In any case, even if all my entries are there in the table, I also discovered that sections with size > 1MB have to be 1MB aligned.
Since I was not aware of that before, that might have lead to some problem (ill review the memory-map at first so that this kind of problem cant occur).
Concerning flushing the D cache, yes until now the caches were ON.
But today I tried to put the attributes "NCNB" on the Application Code destination area, but I still got the same problem.
The weirdest thing is that changing the Read-Only attribute of the code section to Read-Write seems to solve the issue (at least I could reproduce the issue by putting the code back to Read-Only).
What is weird is that this attribute applies to a memory area that is not the one where the offending abort exception seems to occur.
Also the peripheral registers are somewhere between 0x43F00000 - 0x7000000 and the code section is between 0x81400000 - 0x81800000 in RAM. It should be unrelated.
But it might not be so weird if the TTB and CTTB are wrongly set.
Still that does not explain why I dont get any trouble when running from the debugger.
I will investigate more, and post back the results.
The truth should be in there....
PS: Please note that I modified the first post's boot sequence, I had inverted a few things. Now it reflects well what the boot sequence is doing. There is no access to the stacks in MMU initialization.
Cancel
Up
0
Down
Reply
Cancel
Reply
Offline
F Girault
over 7 years ago
Note: This was originally posted on 25th June 2011 at
http://forums.arm.com
Hi scott,
Thx for your reply.
The abort exception I get is a Data Abort exception so I located the offending instruction by looking at the address pointed by (R14-8).
It was a write access to a peripheral register.
I did some additional checks today, and I discovered that my MMU table is not always mapped as I expect it to be.
I fill up a table by giving
[size], [logical address], [physical address], [attributes]
in an MMU table, and I was told only to be careful that the TTB base address should be 16kB aligned, and the page addresses 4kB aligned, but after MMU table initialization, I took a pick at the entries in the TTB and Coarse TTB, and it is not always what I was expecting (for example, the entries concerning the stack memory do not appear in the TTB but it should point to an entry in the CTTB - but I have to double check that).
In any case, even if all my entries are there in the table, I also discovered that sections with size > 1MB have to be 1MB aligned.
Since I was not aware of that before, that might have lead to some problem (ill review the memory-map at first so that this kind of problem cant occur).
Concerning flushing the D cache, yes until now the caches were ON.
But today I tried to put the attributes "NCNB" on the Application Code destination area, but I still got the same problem.
The weirdest thing is that changing the Read-Only attribute of the code section to Read-Write seems to solve the issue (at least I could reproduce the issue by putting the code back to Read-Only).
What is weird is that this attribute applies to a memory area that is not the one where the offending abort exception seems to occur.
Also the peripheral registers are somewhere between 0x43F00000 - 0x7000000 and the code section is between 0x81400000 - 0x81800000 in RAM. It should be unrelated.
But it might not be so weird if the TTB and CTTB are wrongly set.
Still that does not explain why I dont get any trouble when running from the debugger.
I will investigate more, and post back the results.
The truth should be in there....
PS: Please note that I modified the first post's boot sequence, I had inverted a few things. Now it reflects well what the boot sequence is doing. There is no access to the stacks in MMU initialization.
Cancel
Up
0
Down
Reply
Cancel
Children
No data
More questions in this forum
By title
By date
By reply count
By view count
By most asked
By votes
By quality
Descending
Ascending
All recent questions
Unread questions
Questions you've participated in
Questions you've asked
Unanswered questions
Answered questions
Questions with suggested answers
Questions with no replies
Not Answered
DS52020.0 connection to Musca-A/B boards not working
0
Arm Development Studio
Musca-A
33
views
0
replies
Started
3 hours ago
by
Daniel Oliveira
Suggested Answer
Positioning a function in a Position Independent Executable for ARMV8
0
1656
views
3
replies
Latest
7 days ago
by
Stephen Theobald
Answered
Link a pure binary file to image with scatter file
0
1620
views
3
replies
Latest
7 days ago
by
Ronan Synnott
Answered
Failed to read contents of Internal RAM L1-I_DATA in ARM DS
0
Arm Development Studio
Cache
Debug and Trace Services Layer (DTSL)
4202
views
23
replies
Latest
20 days ago
by
Boon Khai
Suggested Answer
DS-5 connect fail when cortex-r5 is in lock-step mode
0
3873
views
10
replies
Latest
27 days ago
by
Stuart Hirons
>
View all questions in Arm Development Studio forum