On 06/27/2017 12:21 PM, rijurekha@...71... wrote:
In base-hw/src/core/spec/arm_v7/trustzone/mode_transition.s, _nonsecure_kernel_entry:, where we go in the monitor handler after a DABT, we have mov r1, #0 mcr p15, 0, r1, c1, c1, 0 //sets SCR all 0s cps #SVC_MODE //changes processor mode to SVC
In base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc, in void Vm::exception(unsigned const cpu), case Genode::Cpu_state::DATA_ABORT:, Cpu::Scr::read() gives 00000000 and Cpu::Psr::read() gives 600001d3. So the NS bit in Scr is 0 and the mode bits in CPSR are 10011=19, which is the SVC mode. So we are getting the correct values that the monitor DABT handler sets.
We are in the secure SVC mode, when we try to access the uart physical address. So what is causing a data abort now?
No, you are in secure SVC mode within the kernel when entering this exception routine. Your access within the tz_vmm component is in secure USR mode.
Anyway, I doubt that it has something to do with kernel/user secure/non-secure issues, because otherwise all other userland drivers should fault too. Another possibility is that the page-table entries are not refering to the right address due to some wrong semantics in your added code. Or it is mapped with different caching attributes in kernel and user-land (please: do not use the device in kernel and userland), but I can't imagine how, if it's really an IOMEM dataspace in your code. Well, to be honest, I do not know, why it should fail, but again it would help if you provide a working branch.
Regards Stefan
Thanks! Riju
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main