On 19.05.22 15:23, Lad, Prabhakar wrote: > Hi Jan, > > On Thu, May 19, 2022 at 12:39 PM Jan Kiszka <jan.kis...@siemens.com> wrote: >> >> On 19.05.22 11:44, Lad, Prabhakar wrote: >>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka <jan.kis...@siemens.com> wrote: >>>> Forgot: that cannot work. The call of arm_dcaches_flush will overwrite >>>> lr, thus the second ret will only return to where the first ret jumped >>>> to - endless loop. You would have to restore lr (x30) from x17 in >>>> arch_entry first: >>>> >>>> mov x30, x17 >>>> ret >>>> >>> That did the trick thanks! >>> >>> diff --git a/hypervisor/arch/arm64/entry.S b/hypervisor/arch/arm64/entry.S >>> index a9cabf7f..7b340bd1 100644 >>> --- a/hypervisor/arch/arm64/entry.S >>> +++ b/hypervisor/arch/arm64/entry.S >>> @@ -109,6 +109,8 @@ arch_entry: >>> mov x0, #LINUX_HVC_SET_VECTORS_LEGACY >>> 1: >>> hvc #0 >>> + mov x30, x17 >>> + ret >>> >>> hvc #0 /* bootstrap vectors enter EL2 at el2_entry */ >>> b . /* we don't expect to return here */ >>> >>> >>> With the above diff I do get the below: >>> >>> [ 42.980805] jailhouse: loading out-of-tree module taints kernel. >>> Reading configuration set: >>> Root cell: Renesas RZ/V2L SMARC (renesas-r9a07g054l2.cell) >>> Overlapping memory regions inside cell: None >>> Overlapping memory regions with hypervisor: None >>> Missing resource interceptions for architecture arm64: None >>> [ 46.582588] obcode @arm_dcaches_flush: d53b0024 >>> [ 46.582616] obcode @arm_dcaches_flush: d53b0024 >>> [ 46.611311] The Jailhouse is opening. >>> >>> So it looks like something to do with the debug console. This has to >>> be poked in the dark or any easy way to debug? >> >> Well, we do not yet know what goes wrong. We do know that we can call >> into the hyp take-over stub and register Jailhouse with it. We do not >> know if we will then end up in Jailhouse in hyp mode and just lack >> console output or if we crash on entry already. >> > Right agreed. > >> To move the uart console out of the picture: Did you already check if >> the driver you select in the Jailhouse config is actually one that >> should support the UART on your board? Next is to double check if poking > The UART on this platform is almost identical to > JAILHOUSE_CON_TYPE_SCIFA type, but with some differences which I have > patched to work on this platform. > >> registers in the way the Jailhouse driver will do at the addresses you >> configured will work: Pull the code into the kernel module or even into >> a userspace application with /dev/mem raw register access and try out if >> that works in a "safe" environment (without hypervisor mode). >> > Sure will give that a shot, any pointers on doing this from userspace? >
Something like this may help if you do that the first time: https://bakhi.github.io/devmem/ Jan -- Siemens AG, Technology 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 jailhouse-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/eafaaed1-604f-569b-47f5-232b01cfcee5%40siemens.com.
