Writing to UART mapped memory address

rijurekha at ...71... rijurekha at ...71...
Mon Jun 26 18:14:14 CEST 2017

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,

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

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?


More information about the users mailing list