• Locked Locked
  • Replies 9 replies
  • Subscribers 119 subscribers
  • Views 5637 views
  • Users 0 members are here
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