• Locked Locked
  • Replies 3 replies
  • Subscribers 120 subscribers
  • Views 4588 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

Running TrustZone

Andreas Lauber
Note: This was originally posted on 4th January 2013 at http://forums.arm.com

Hallo,

I'm trying to run the TrustZone example from DS-5. And it's working with the RTSM-VE-A9x4. But this is just a simulation, isn't it. Because I do not have to power up DSTREAM and my board.
So I tried some more to run the example on the Xilinx Zynq board which has a ARM Cortex A9 DualCore.

BUT: If I'm using "Debug Cortex_A9_0 via DSTREAM/RVI" from Xilinx-Zynq-7000 EEP ZC702 its not working anymore. I used the connection with a hello world program before so it's defiantly the right connection. I also added

add-symbol-file "${workspace_loc:/TrustZone/normal.axf}" N:0

in execute debugger commands like it is in the RTSM version.
Nevertheless I get the following error if I want to debug the software on the ARM.

ERROR(CMD16-TAD11-NAL22):
! Failed to load "TrustZone-versatile.axf"
! Failed to write 4.872 bytes to address S:0x80000000
! General error on memory or register access.

I know the example was written for versatile express, but its also just a Cortex A9. So where is the difference? What did I forgot to change? I would be happy about some ideas.
  • Arm Employee Badge
    Note: This was originally posted on 5th January 2013 at http://forums.arm.com

    Your problem is that the two boards probably have different memory maps.  So the Versatile has RAM at 0x80000000, I'm guessing the Xilinx board has it somewhere else.
    The example will be making assumptions about where things like RAM are, for example to allocate stack memory.  As the two boards are different it's falling over (looks like while trying to load)
    When you're working with apps, the OS hides the differences between systems (true for ARM, x86, etc...).  But when you have bare metal code you'll need to do some level of porting when moving code from one board to another.  At the most basic, re-link to match the address of memory.
    The example you're using is quiet simple.  So I suspect it wouldn't take too much effort to port.  Probably just need to change the scatter files and re-link.
  • Note: This was originally posted on 7th January 2013 at http://forums.arm.com

    Hey ttfn,

    thanks for your help. I know moved the software to the OCM and it looked like it's going to work.
    I could also run the code in the secure mode.
    But unfortunately as soon as I'm swithing in the non-secure mode the software crashs. As far as I see its because the regin of the non-secure software is still marked as secure. So for example I copied the code with the scatter file to 0x18000 and its there but if I have a look at the memory it says S:0x18000. This means I cannot access it from normal world.

    So here comes the question: How can I make the memory from 0x18000 to 0x30000 as non-secure. I don't see any point in the scatter files and startup files.
    But I guess there has to be a way...

    Thx
  • Arm Employee Badge
    Note: This was originally posted on 8th January 2013 at http://forums.arm.com

    You need to modify the scatter files so that secure code/data is in secure memory, and non-secure code/data is in non-secure memory.

    Most the boards I have worked with have some permanently secure memory, and some memory which is run-time configurable as secure/non-secure.  With the default being secure, and controlled by a TrustZone Protection Controller (TZPC) or TrustZone Address Space Controller (TZASC) or a couple of cases some custom logic in the interconnect.  I don't know what the part you're using does.

    From memory, the Versatile board has a TZPC which gets configured by the example.  So if your board is similar you'll also have to modify that code to match your system.  Or you might be lucky, and have dedicated secure and non-secure RAM regions.  In which case just modify the scatter files and then rip out the TZPC code.