On 23.05.22 15:55, Lad, Prabhakar wrote: > Hi Jan, > > On Fri, May 20, 2022 at 7:08 AM Jan Kiszka <[email protected]> wrote: >> >> On 19.05.22 15:23, Lad, Prabhakar wrote: >>> Hi Jan, >>> >>> On Thu, May 19, 2022 at 12:39 PM Jan Kiszka <[email protected]> wrote: >>>> >>>> On 19.05.22 11:44, Lad, Prabhakar wrote: >>>>> On Thu, May 19, 2022 at 6:30 AM Jan Kiszka <[email protected]> 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/ >> > Thanks for the pointer. > I have tried reading/writing from the hypervisor location and that > goes all OK.
Means, you were able to generate output on the UART. Hmm, would have been too easy. > To avoid any issue related to debug UART is there any way > I could test this prior to enabling? Not without extra measures: Without JAILHOUSE_BORROW_ROOT_PT, which applies to arm64, the driver will not map the physical UART page. That only happens in init_bootstrap_pt which is run after jumping to EL2. So, we the jump goes wrong, you cannot find out where you are. Do you have the chance to get hold of some jtag to find out where the CPUs are? 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jailhouse-dev/385f8761-8d70-d0c4-f903-9adadb3c9a90%40siemens.com.
