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.
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://groups.google.com/d/optout.
