Writing to UART mapped memory address

[rijurekha at ...71...]

Thanks Stefan. You are already helping a lot, so I don't want to actually
debug code.

We could do instruction emulation for a large class of peripherals mapped
to CSU (for example USB), but not all.

For the ones that we couln't, the issue is we cannot access the
corresponding peripheral addresses in tz_vmm. We get a data abort at the
following printf in the Vm_base constructor, which is called from

static Vm vm("linux" .... in main() at
repos/os/src/server/tz_vmm/spec/imx53/main.cc.

So this is before copying linux kernel and everything else in
repos/os/src/server/tz_vmm/include/vm_base.h.

(1) _ram_iomem_peripheral(peripheral_base, peripheral_size)
(2) _ram_peripheral(peripheral_base, peripheral_size,
(Genode::addr_t)Genode::env()->rm_session()->attach(_ram_iomem_peripheral.dataspace()))
(3) Genode::printf("_ram_peripheral.local() contains %08x\n",*(unsigned
int*)(_ram_peripheral.local()))

The following are the peripherals, with peripheral_base and
peripheral_size, that have this behavior, along with their CSL mappings.
CSL are all set to UNSECURE i.e. 0xff, so everything should be accessible.
The other 50+ peripherals work fine and print the values held in those
peripheral memory addresses in the printf mentioned above.
===========================================================================
(1) write<Csl26::Slave_a>(Csl00::UNSECURE); UART3, 5000C000,3FFF
(2) write<Csl27::Slave_a>(Csl00::UNSECURE); ESAI, 50018000, 3FFF
(3) write<Csl02::Slave_b>(Csl00::UNSECURE); KPP, 53F94000, 3FFF
(4) write<Csl03::Slave_a>(Csl00::UNSECURE); WDOG1, 53F98000,3FFF
(5) write<Csl03::Slave_b>(Csl00::UNSECURE); WDOG2, 53F9C000,3FFF
(6) write<Csl07::Slave_b>(Csl00::UNSECURE); UART1, 53FBC000, 3FFF
(7) write<Csl08::Slave_a>(Csl00::UNSECURE); UART2, 53FC0000, 3FFF
(8) write<Csl05::Slave_b>(Csl00::UNSECURE); CAN1, 53FC8000, 3FFF
(9) write<Csl06::Slave_a>(Csl00::UNSECURE); CAN2, 53FCC000, 3FFF
(10) write<Csl09::Slave_b>(Csl00::UNSECURE); CAN2, 53FCC000, 3FFF
(11) write<Csl30::Slave_b>(Csl00::UNSECURE); UART4,  53FF0000, 3FFF
(12) write<Csl19::Slave_a>(Csl00::UNSECURE); UART5, 63F90000, 3FFF
(13) write<Csl16::Slave_a>(Csl00::UNSECURE); ROMCP, 63FB8000, 3FFF
(14) write<Csl17::Slave_b>(Csl00::UNSECURE); I2C2, 63FC4000, 3FFF
(15) write<Csl18::Slave_a>(Csl00::UNSECURE); I2C1, 63FC8000, 3FFF
(16) write<Csl23::Slave_b>(Csl00::UNSECURE); SAHARA, 63FF8000, 3FFF
(17) write<Csl11::Slave_b>(Csl00::UNSECURE); AHBMAX/PL301_2x2/PL301_4x1,
63F94000, 3FFF, 63FDC000, 3FFF, 63FE0000, 3FFF (only AHBMAX)
(18) write<Csl09::Slave_a>(Csl00::UNSECURE); CCM/SRC/GPC/DPLLIP1-4/OWIRE,
53FD4000, 3FFF, 53FD0000, 3FFF, 53FD8000, 3FFF, 63F80000, 3FFF, 63F84000,
3FFF, 63F88000, 3FFF, 63F8C000, 3FFF, 63FA4000, 3FFF (only OWIRE gives
secure world abort)
===========================================================================

The other 50+ peripherals also work fine if we make CSL for that
peripheral secure (0x33), access that memory in linux, trap data abort to
monitor, come to tz_vmm, get the instruction from ip, decode it and do the
LDR/STR from the DFAR into the necessary _state->register and set
ip->ip+4.

Have these peripherals like UART, I2C, WDOG, SAHARA, CAN etc. been
specially set up in any way, that tz_vmm (secure world user mode) cannot
access them? Do these peripherals have anything in common?

Thanks!
Riju