On 07/24/2017 12:21 PM, rijurekha@...71... wrote:
Hi, To get virtual address corresponding to any physical address in genode, we generally use:
Genode::Io_mem_connection _ram_iomem(phy_addr, 4); Ram _ram(phy_addr, 4, (Genode::addr_t)Genode::env()->rm_session()->attach(_ram_iomem.dataspace()));
_ram.local() then gives the necessary virtual address. This works vm_base.h for run/tz_vmm demo or vm.h for run/vmm, i.e. in the tz vmm user space.
What can we do to get virtual addresses for physical addresses which are already mapped?
You can just calculate them for locally mapped devices. In principle this "Ram" class is nothing more than a helper utility that saves the virtual and physical start address of a portion of RAM, and helps to calculate offsets.
E.g. in the imx53 sabre tablet demo, the 7 GPIO banks are already mapped to virtual addresses in os/src/drivers/gpio/imx53/driver.h.
If we have a physical address (from DFAR) corresponding to the GPIO address ranges, how can I get the virtual address in user space files corresponding to tz vmm?
In case of the GPIO banks used by the GPIO driver the situation is different. GPIO driver and VMM are different components with different address spaces. Here you are sliding into the same problem like with the UART used by the kernel. You cannot simply alter the memory-mapped I/O registers within the VMM. I mean technically you can, by adding it as local device like every other device as well, but you will end up in devil's kitchen, when altering the registers from two different "drivers" concurrently. Instead, you have to analyse semantically what the Linux OS tries to do with the device, and use the GPIO drivers API appropriatedly.
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