Hi,
On 06/26/2017 06:14 PM, rijurekha@...71... wrote:
In os/src/server/tz_vmm/spec/imx53/main.cc, added the following enums (1) UART_BASE = 0x53FBC000, (2) UART_SIZE = 0x43FFF
In os/src/server/tz_vmm/include/vm_base.h In Vm_base constructor, added (3)_ram_iomem_uart(uart_base, uart_size), (4)_ram_uart(uart_base, uart_size, (Genode::addr_t)Genode::env()->rm_session()->attach(_ram_iomem_uart.dataspace())),
In dump(), added (5)printf("The memory location is %08lx\n", va_to_pa(_state->dfar)); (6) printf("_ram.local() is %08lx\n",_ram.local()); (7) printf("_ram.local() contains %08x\n",*(unsigned int*)(_ram.local())); (8) printf("_ram_uart.local() is %08lx\n",_ram_uart.local()); (9) printf("_ram_uart.local() contains %08x\n",*(unsigned int*)(_ram_uart.local()));
The output: [init -> tz_vmm] The memory location is 53fbc080 [init -> tz_vmm] _ram.local() is 80000000 [init -> tz_vmm] _ram.local() contains eded1bb6 [init -> tz_vmm] _ram_uart.local() is 70078000 init -> tz_vmm -> vmm: raised unhandled data abort DFSR=0x00001008 ISFR=0x00000007 DFAR=0x70078000 ip=0x7001f440 sp=0xe01fed10
Thus though _ram and _ram_uart are assigned in the same way (over different physical addresses), _ram.local() can be de-referenced and the content read, while _ram_uart.local() gives a fault. How are these UART addresses starting at 0x53FBC000 different from the Trustzone::NONSECURE_RAM_BASE physical addresses?
Funnily, the DFSR=0x00001008, which is the same value as the abort in the normal world linux. That can occur due to CSU configuration of UART made secure. But the vmm is in secure world, why is that getting the same abort at that same UART physical address?
To be honest, it's a bit exhausting to follow the trap-emulate path that I discouraged you to follow from the first moment. We already investigated that, and published a detailed report showing that TrustZone indeed is not useful for doing device emulation. To me it is not comprehensible why you are still focussing this solution.
Having said that, what you are trying to do is accessing a device already in use by the kernel/core concurrently. You are trying to access the same UART device directly that is used to print all messages of core's LOG service. Although, that is certainly not the reason that you are getting the page-fault. Anyway, it is a very bad idea to do so!
It seems to me that you are using an older version of Genode? Looking at the current 'tz_vmm' component's source code, I can't clearly see what constructs you are refering to, when adding (3) and (4). It would be helpful to provide the whole source of the changed component. Without any further insights, above lines seem reasonable.
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