On 05.08.19 17:43, [email protected] wrote: > > > Basically, you have to replicate that CCU block above a few times, adjust > size > and start addresses, e.g. > > { > .phys_start = 0x01c200c0, > .virt_start = 0x01c200c0, > .size = 0x10, > .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | > JAILHOUSE_MEM_IO | JAILHOUSE_MEM_IO_32, > }, > > in order to define a region from 0x01c200c0..0x01c200cf, permitting 32-bit > accesses. Such a region could then be assigned to a non-root cell as a > whole > (breaking up sub-page regions on assignment is not possible, in contrast > to > page-aligned regions). > > > Thank you for your response. That seemed to solve the unhandled traps that I > was > having. Now I'm having the following when I load the bananapi-gic-demo cell: > > Cell "bananapi-gic-demo" can be loaded > Unhandled data write at 0x7bfe0000(1) > FATAL: unhandled trap (exception class 0x24) > pc=0xc06c770c cpsr=0x20000013 hsr=0x9000004f > r0=0xe0184000 r1=0x00023080 r2=0x00002134 r3=0xea00000d > r4=0xea000005 r5=0xea000005 r6=0xea000005 r7=0xea000005 > r8=0xea000005 r9=0xe0184000 r10=0x00023038 r11=0x00000001 > r12=0xea00001a r13=0xddf0be4c r14=0xea000005 > Parking CPU 0 (Cell: "Banana-Pi") > > This unhandled trap seems to be related to RAM. > > The configuration on bananapi's file is the following: > > /* RAM */ { > .phys_start = 0x40000000, > .virt_start = 0x40000000, > .size = 0x3bf00000, > .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | > JAILHOUSE_MEM_EXECUTE, > }, > > And for bananapi-gic-demo: > > /* RAM */ { > .phys_start = 0x7bfe0000, > .virt_start = 0, > .size = 0x00010000, > .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | > JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_LOADABLE,
Loadable does not imply that the root cell will get access to that region automatically. You also need a memory region in the root cell that covers this area. Access to the overlap will be controlled by the hypervisor safely, i.e. it will be taken from the root cell once the non-root cell starts to run. You can see this pattern also in the existing configs in the Jailhouse repo. Jan > }, > > By checking the /proc/iomem file, I can see that there's a region for the > System > RAM from 40000000 to 7a3fffff, as well for kernel 4.13.0 that I was > experimenting before. I have two questions: > > 1. The configuration defined for the RAM on bananapi's file exceeds the range > defined in the iomem file. Although the gic-demo worked with kernel 4.13.0 > (with the same region on /proc/iomem), can this be the reason why I'm > having > these traps? > 2. I've tried to replicate the block and adjust the sizes and start > addresses, > like you suggested above,but I kept having unhandled traps related to the > gic-demo's phys_start address. How can I solve this? > > > > > -- > You received this message because you are subscribed to the Google Groups > "Jailhouse" group. > To unsubscribe from this group and stop receiving emails from it, send an > email > to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jailhouse-dev/0a03b7bf-fcce-4de2-9a06-bb495cf47bb7%40googlegroups.com > <https://groups.google.com/d/msgid/jailhouse-dev/0a03b7bf-fcce-4de2-9a06-bb495cf47bb7%40googlegroups.com?utm_medium=email&utm_source=footer>. -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/a96c2d69-3449-b4e7-db1b-bf7a68708137%40siemens.com.
