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.
Hi,
I just got a raspberry pi 2 and I'd like to play with Trustzone.
People on the Raspberry forum http://www.raspberrypi.org/forums/viewtopic.php?p=697474#p697474 explained me how to
get my hand on the boot of the 4 core A7 CPU, and I managed to boot my kernel (at 0x8000) in monitor mode, thus I can
do pretty much whatever I want (by replacing the 'movs pc, lr' by a 'bx lr' at the end of the secure_monitor, cf line 50 at http://pastebin.com/rgGgBuTN).
However, I'm trying to understand the code they gave me, and I noticed some really weird situation:
- If I replace the 'smc #0' instruction line 80 with a 'cps #MON_MODE' followed by the body of the _secure_monitor handler, the boot hangs (see http://pastebin.com/TngpAmt1)
I thought that 'smc' only updated cpsr, sprs and lr. Is an explicit 'smc' instruction is required to successfully initialize a cortex A7 ?
- In the _secure_monitor, if I do not set SCR.NS to 1, I expected to stay in secure mode, but the boot hangs
- However, once I reached my code (0x8000), I can change SCR.NS any way I want.
I'm really not familiar with CPU initialization and SMP context, any help to understand what is happening is welcome !
Best,
Vincent
Hi, thank you for the detailed feedback.
I'll start with your question first: The "normal" configuration of the raspi is to run this code (which is linked at 0x0000) and then jump core 0 at 0x8000 where uboot/kernel/random code should have been linked. Using a config option, one can disable this behavior and make the board boot by executing code at 0x0, in monitor mode. In this configuration, no initial boot code from raspberry is executed. For my tests, I used this second booting option, linked their code at 0x0, and my code at 0x8000. Therefore, by modifying their code, I can see the changes once (if) I reach my own code. The issue with this approach is that I don't have any debugger, I use uart output to debug, thus the difficulty to debug this part of the boot code. I am really not sure where the board hangs during the boot, but I (wrongly) guessed it had to do with changing mode.
I think my main mistake was about the NS bit. I thought that you can only accessed the banked Secure CP15 register while in monitor mode, because monitor mode is always considered secure. If I understand correctly your explanation, I should add a ISB after line 11 so that I am sure to write to the correct version (non secure) of the CP15 registers. So if I want to exit in secure mode, I have to switch back to NS = 0 "after" this CP15 changes ? I'll try that today and come back to you with more feedback.
I think I finally understood what happens and I managed to do exactly what I wanted in the "boot" part of their code.
Just for the record, I added an ISB in the secure monitor, to be sure. And after changing the "non secure only" cp15 registers, I switch back NS to 0. Then, when I exit from the smc call, I am still in SVC secure mode.
I am now able to rewrite this boot sequence in another way, and setup a meaningful secure_monitor instead.
Thanks to your input, it was very helpful.