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) writeCsl26::Slave_a(Csl00::UNSECURE); UART3, 5000C000,3FFF (2) writeCsl27::Slave_a(Csl00::UNSECURE); ESAI, 50018000, 3FFF (3) writeCsl02::Slave_b(Csl00::UNSECURE); KPP, 53F94000, 3FFF (4) writeCsl03::Slave_a(Csl00::UNSECURE); WDOG1, 53F98000,3FFF (5) writeCsl03::Slave_b(Csl00::UNSECURE); WDOG2, 53F9C000,3FFF (6) writeCsl07::Slave_b(Csl00::UNSECURE); UART1, 53FBC000, 3FFF (7) writeCsl08::Slave_a(Csl00::UNSECURE); UART2, 53FC0000, 3FFF (8) writeCsl05::Slave_b(Csl00::UNSECURE); CAN1, 53FC8000, 3FFF (9) writeCsl06::Slave_a(Csl00::UNSECURE); CAN2, 53FCC000, 3FFF (10) writeCsl09::Slave_b(Csl00::UNSECURE); CAN2, 53FCC000, 3FFF (11) writeCsl30::Slave_b(Csl00::UNSECURE); UART4, 53FF0000, 3FFF (12) writeCsl19::Slave_a(Csl00::UNSECURE); UART5, 63F90000, 3FFF (13) writeCsl16::Slave_a(Csl00::UNSECURE); ROMCP, 63FB8000, 3FFF (14) writeCsl17::Slave_b(Csl00::UNSECURE); I2C2, 63FC4000, 3FFF (15) writeCsl18::Slave_a(Csl00::UNSECURE); I2C1, 63FC8000, 3FFF (16) writeCsl23::Slave_b(Csl00::UNSECURE); SAHARA, 63FF8000, 3FFF (17) writeCsl11::Slave_b(Csl00::UNSECURE); AHBMAX/PL301_2x2/PL301_4x1, 63F94000, 3FFF, 63FDC000, 3FFF, 63FE0000, 3FFF (only AHBMAX) (18) writeCsl09::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