Oh, I was missing *.cell from the point 2. Now fixed and no complaints. to 5. tammik. 2023 klo 12.20 Tommi Parkkila ([email protected]) kirjoitti:
> Jan - Just ran the config check on the host PC and on target. > > 1. On host, it identified some memregion overlappings that were due my own > copy/paste errors. It also complained a missing resource interception for > architecture x86: > > > > > > > > > > *In cell 'STM32MP1-Root', region 1 phys_start: 0x00000000f7600000 > virt_start: 0x00000000f7600000 size: 0x0000000009a00000 flags: > JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE | JAILHOUSE_MEM_EXECUTEoverlaps > with xAPIC phys_start: 0x00000000fee00000 virt_start: 0x00000000fee00000 > size: 0x0000000000001000 flags: * > I fixed the copy paste mem overlappings, do I need to worry about the > xAPIC overlapping? > > 2. On target, the check complained the configuration is not root cell > configuration??? > > > *root@stm32mp1:~# jailhouse/tools/jailhouse-config-check > jailhouse/configs/stm32mp157.cReading configuration set:Not a root cell > configuration: jailhouse/configs/arm/stm32mp157.c* > The config here is the same as ran on the host PC. What causes it to > complain the above? > > to 5. tammik. 2023 klo 11.55 Jan Kiszka ([email protected]) > kirjoitti: > >> On 05.01.23 17:53, Tommi Parkkila wrote: >> > Jan - Thanks again. I have not tried the config check yet. Actually, it >> > does not work on hw currently, it does not find pyjailhouse module. I'll >> > check whats going wrong with it and let you know. >> >> You can also run it offline, even directly from the source folder >> (tools/jailhouse-config-check ...). >> >> Jan >> >> > -tommi >> > >> > to 5. tammik. 2023 klo 10.21 Jan Kiszka ([email protected] >> > <mailto:[email protected]>) kirjoitti: >> > >> > On 05.01.23 15:34, Tommi Parkkila wrote: >> > > Thanks for your reply, Jan. I managed to get forward from the >> 'hang' >> > > condition. There were several misdefinitions on my root-cell >> > > configuration. Now I get the root-cell started sometimes, but more >> > often >> > > I get two types of issues after enable command. Any help or ideas >> > where >> > > to continue my debugging would be greatly appreciated. Please, >> see the >> > > issues explained below. >> > >> > Already tried "jailhouse config check"? >> > >> > > >> > > Thanks, >> > > -tommi >> > > >> > > +++++++++++++++++++++++++++++++++ >> > > >> > > 1. Terminal hangs >> > > -- After the enable command for the root cell, jailhouse gets >> started >> > > but then the terminal goes unresponsive. Below, example log, >> where I >> > > give ls cmd, which then causes terminal to go unresponsive...: >> > > >> > >> > Missing interrupts could be one reason. Or something is completely >> > broken with memory mapping so that a kernel device driver gets >> stuck on >> > waiting for some register bit to flip, e.g. But most frequent are >> > interrupt issues, specifically around GIC resources being improperly >> > passed through. The config checker may find that. >> > >> > > /*root@stm32mp1:~# modprobe jailhouse >> > > [ 1315.034414] jailhouse: loading out-of-tree module taints >> kernel. >> > > root@stm32mp1:~# jailhouse enable >> > > ~/jailhouse/configs/arm/itron_stm32mp157.cell >> > > >> > > Initializing Jailhouse hypervisor v0.12 (314-gc7a1b697-dirty) on >> CPU 0 >> > > Code location: 0xf0000040 >> > > Page pool usage after early setup: mem 28/1514, remap 0/131072 >> > > Initializing processors: >> > > CPU 0... OK >> > > CPU 1... OK >> > > Initializing unit: irqchip >> > > Initializing unit: PCI >> > > Page pool usage after late setup: mem 50/1514, remap 5/131072 >> > > [0] Activating hypervisor >> > > [ 1355.352714] The Jailhouse is opening. >> > > root@stm32mp1:~# ls*/ >> > > >> > > 2. Issue with setting CPU clock >> > > -- The second issue I see is related to i2c bus and system clock. >> > > Terminal starts printing error statements infinitely after >> Jailhouse >> > > opening. Below, is a snippet of an example logs. >> > > >> > > */[ 85.322027] The Jailhouse is opening. >> > > [ 85.322648] stm32f7-i2c 5c002000.i2c: failed to prepare_enable >> > clock >> > > root@stm32mp1:~# [ 85.339233] cpu cpu0: _set_opp_voltage: >> failed to >> > > set voltage (1350000 1350000 1350000 mV): -22 >> > > [ 85.350413] cpufreq: __target_index: Failed to change cpu >> > frequency: -22 >> > > [ 85.357706] cpu cpu0: _set_opp_voltage: failed to set voltage >> > > (1350000 1350000 1350000 mV): -22 >> > > [ 85.365124] cpufreq: __target_index: Failed to change cpu >> > frequency: -22 >> > > [ 85.381985] cpu cpu0: _set_opp_voltage: failed to set voltage >> > > (1350000 1350000 1350000 mV): -22 >> > > /*- - - >> > > +++++++++++++++++++++++++++++++++ >> > >> > Same possible reasons as above. Or do you know how clock control >> happens >> > on that platform? Is there firmware (TF-A?) involved? >> > >> > Jan >> > >> > -- >> > Siemens AG, Technology >> > Competence Center Embedded Linux >> > >> >> -- >> 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/CAP8Rr619qqqSCc0QBBzet2DfL10B0axK_2s0Pohb6p_JqrBxqg%40mail.gmail.com.
