• Locked Locked
  • Replies 9 replies
  • Subscribers 119 subscribers
  • Views 5530 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bootloader problem in ARM926ejs

F Girault
Parents
  • 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.
Reply
  • 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.
Children
No data