> -----Original Message-----
> From: jailhouse-dev@googlegroups.com
> [mailto:jailhouse-dev@googlegroups.com] On Behalf Of Jan Kiszka
> Sent: 2018年8月14日 15:49
> To: Giovani Gracioli <giova...@gmail.com>; Jailhouse
> <jailhouse-dev@googlegroups.com>
> Subject: Re: ARM64 unhandled trap (exception class 0x17)
>
> On 2018-08-13 15:15, Giovani Gracioli wrote:
> > There is only the root cell. The problem does not happen when the root cell
> > is
> not loaded.
> >
> > My understanding is that the zynqmp_r5_remoteproc driver issues and hvc
> instruction to get information whether the R5 is running or not. This
> instruction
> is somehow intercepted by Jailhouse and does not return the expected (the R5
> is
> actually running).
> >
>
> OK, starting to understand that assembly fragment you posted. But I'm
> confused: Even without Jailhouse, that hvc should end up being rejected by the
> hyp stub of the mainline kernel and never get through to a provider outside of
> the kernel. Or are you running some downstream Xilinx kernel?
>
> In any case, that call won't work under Jailhouse. But we first of all need to
> understand where it should be handled (ATF?) in order to clarify if replacing
> *hvc
> with *smc can help.
Currently handle_hvc only handles jailhouse driver hvc call. So if other
Linux components use hvc, jailhouse will report failure. Need to add support
in handle_hvc/hypercall.
Regards,
Peng
>
> Jan
>
> >>>> Hi,
> >>>>
> >>>> On 08/09/2018 06:35 PM, Giovani Gracioli wrote:
> >>>>> Thanks Ralf.
> >>>>>
> >>>>> I updated to the latest version, 0.9.1, and the original problem is
> >>>>> gone.
> >>>>
> >>>> Great.
> >>>>
> >>>>>
> >>>>> Then I got an unhandled data write:
> >>>>
> >>>> One bug down, the next shows up ;-)
> >>>>
> >>>>>
> >>>>> Unhandled data write at 0xffe01800(1)
> >>>>
> >>>> That's weird, I'm wondering why this didn't happen with the old
> >>>> Jailhouse version.
> >>>>
> >>>>>
> >>>
> >>> It did not happen because in version 0.8 I got the exception 0x17, which
> >>> is
> solved by version 0.9.1.
> >>>
> >>>>> FATAL: unhandled trap (exception class 0x24)
> >>>>>
> >>>>> To solve this, I added the TCM memory region 0xffe00000 to the root cell
> config. This memory is used by the R5 to boot its image:
> >>>>>
> >>>>> /* TCM region for the R5 */ {
> >>>>> .phys_start = 0xffe00000,
> >>>>> .virt_start = 0xffe00000,
> >>>>> .size = 0xC0000,
> >>>>> .flags = JAILHOUSE_MEM_READ |
> JAILHOUSE_MEM_WRITE |
> >>>>> JAILHOUSE_MEM_EXECUTE,
> >>>>
> >>>> Is it IO? JAILHOUSE_MEM_IO?
> >>>>
> >>>
> >>> The TCM memory is not I/O. It is the memory the R5s use.
> >>>
> >>>
> >>>>> },
> >>>>>
> >>>>> However, when I use the zynqmp_r5_remoteproc driver with the
> jailhouse, the driver has an error, and the code is not ran:
> >>>>>
> >>>>> remoteproc remoteproc0: powering up ff9a0100.zynqmp_r5_rproc
> >>>>> remoteproc remoteproc0: Booting fw image dma_scheduler.elf, size
> >>>>> 815824 Failed to get RPU node status.
> >>>>> Failed to get RPU node status.
> >>>>
> >>>> Hmm, don't know what's exactly behind that memory area or how R5
> >>>> works, but I'd guess it's iomem. Try to add JAILHOUSE_MEM_IO to the
> region.
> >>>
> >>> Does not work with JAILHOUSE_MEM_IO either. I got the following:
> >>>
> >>> remoteproc remoteproc0: powering up ff9a0100.zynqmp_r5_rproc
> >>> remoteproc remoteproc0: Booting fw image dma_scheduler.elf, size
> >>> 815824 Failed to get RPU node status.
> >>> Failed to get RPU node status.
> >>> Unhandled data write at 0xffe01800(1)
> >>>
> >>> FATAL: unhandled trap (exception class 0x24) Cell state before
> >>> exception:
> >>> pc: ffffff80089f5dac lr: ffffff8008789a78 spsr: 40000145 EL1
> >>> sp: ffffff80097d3c10 esr: 24 1 0000061
> >>> x0: ffffff8009421800 x1: 0000000000000000 x2:
> 00000000000077c0
> >>> x3: 0000000000000004 x4: 0000000000000000 x5:
> 0000000000000040
> >>> x6: 000000000000003f x7: 0000000000000000 x8:
> ffffff8009421800
> >>> x9: 0000000000000000 x10: 0000000000000000 x11:
> >>> 0000000000000000
> >>> x12: 0000000000000000 x13: 0000000000000000 x14:
> 0000000000000000
> >>> x15: ffffffffffffffff x16: 0000000040034850 x17: 000000001b6b01bd
> >>> x18: 0000000000000010 x19: ffffff8009c01054 x20:
> 0000000000000001
> >>> x21: 0000000000001800 x22: 0000000000009000 x23: ffffffc04b0ac800
> >>> x24: ffffff8009c01000 x25: ffffffc04b0ac838 x26: ffffffc04c3e3480
> >>> x27: ffffff8009420000 x28: 0000000000000000 x29: ffffff80097d3c10
> >>>
> >>> Parking CPU 1 (Cell: "ZynqMP-ZCU102")
> >>>
> >>
> >> Could it be that the non-root cell config steals that memory region
> >> from the root cell? Or is only the root cell present at that point?
> >>
> >> Jan
>
> --
> 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 jailhouse-dev+unsubscr...@googlegroups.com.
> For more options, visit
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups
> .google.com%2Fd%2Foptout&data=02%7C01%7Cpeng.fan%40nxp.com%7
> C2ec077fa791d4a5f46a808d601ba6a0e%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C636698297483991390&sdata=0b%2BbKecfVa7WpOLQ
> 3%2Bsp1ece9LhGEnmRy8Yj9bLdn08%3D&reserved=0.
--
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.
For more options, visit https://groups.google.com/d/optout.
