Hi Bob,
On 11/18/2013 11:20 PM, bob wrote:
I haven't heard back from the TI E2E group, but if the kernel was not in the Secure state it would not be able to read the Scr register because it has restricted access. Thanks to Christian reading what I should have read, the kernel is starting in user mode. Do I have to generate some kind of excpetion in order to change the mode to a privileged one? How would I go about getting into a correct mode? Thanks for all the time you guys have spent responding to me.
I'm afraid, you misunderstood Christian's mail. He just stated, that the kernel starts in non-secure mode. It is most likely in supervisor mode, and not in user mode ;-)
So I assume the whole TrustZone discussion leads to a dead end. Everything is correct if you just set SECURITY_EXTENSION back to zero. If set to one, the kernel assumes to run in secure mode on top of a TrustZone supported CPU, which obviously isn't the case regarding your board. In general, setting the SECURITY_EXTENSION to zero is the safe path even if your platform is starting in secure mode. This flag should be switched on only, if the base-hw kernel acts as a TrustZone hypervisor.
I strongly advise you to follow Norman's second proposal to first check whether you've a working UART. First, I would print something before the MMU is enabled, just to ensure you've the right physical addresses used to initialize the UART driver. If that works, follow Norman's approach to enable, and immediately disable the MMU again, and then print something. Just to see, whether the MMU, and the kernel's page-table are really the problem.
Regards Stefan