Jan and Ralf - It looks like I have something wrong with the IRQ/GIC. When
I get root cell up successfully, and if I press a button (that presumably
is assigned to a IRQ routine) I get the error print below and the whole
system hangs. Is there any documentation on how I should specify IRQ/GIC on
root cell configuration or jailhouse configuration for the target?
Thanks,
-tommi
*[ 84.080587] irq 74: nobody cared (try booting with the "irqpoll"
option)[ 84.085876] CPU: 0 PID: 606 Comm: kworker/0:4 Tainted: G
OE 5.15.24-dirty #3[ 84.094144] Hardware name: STM32 (Device Tree
Support)[ 84.099236] Workqueue: events dbs_work_handler[ 84.103724]
[<c0110d3c>] (unwind_backtrace) from [<c010c6c0>] (show_stack+0x10/0x14)[
84.111377] [<c010c6c0>] (show_stack) from [<c0bb3c50>]
(dump_stack_lvl+0x40/0x4c)[ 84.118918] [<c0bb3c50>] (dump_stack_lvl) from
[<c0baf750>] (__report_bad_irq+0x3c/0xc0)[ 84.126986] [<c0baf750>]
(__report_bad_irq) from [<c0185b8c>] (note_interrupt+0x2a8/0x2f4)[
84.135265] [<c0185b8c>] (note_interrupt) from [<c0181fd8>]
(handle_irq_event_percpu+0x80/0x88)[ 84.143964] [<c0181fd8>]
(handle_irq_event_percpu) from [<c0182018>] (handle_irq_event+0x38/0x5c)[
84.152769] [<c0182018>] (handle_irq_event) from [<c0186614>]
(handle_edge_irq+0xc4/0x218)[ 84.161046] [<c0186614>] (handle_edge_irq)
from [<c073c8b4>] (stm32_pwr_handle_irq+0x118/0x190)[ 84.169650]
[<c073c8b4>] (stm32_pwr_handle_irq) from [<c018165c>]
(handle_domain_irq+0x7c/0xb0)[ 84.178348] [<c018165c>]
(handle_domain_irq) from [<c063ff04>] (gic_handle_irq+0x7c/0x90)[
84.186522] [<c063ff04>] (gic_handle_irq) from [<c0100afc>]
(__irq_svc+0x5c/0x90)[ 84.193950] Exception stack(0xced55bb8 to
0xced55c00)[ 84.199040] 5ba0:
00000000 00000000[ 84.207198] 5bc0: 1d624000 c105fe80 c105fe80
00000000 c1810800 00000080 ced54000 ced55ca8[ 84.215356] 5be0: ced55ca8
ced55c08 ced54000 ced55c08 c0101254 c0101268 20010113 ffffffff[
84.223509] [<c0100afc>] (__irq_svc) from [<c0101268>]
(__do_softirq+0xc0/0x430)[ 84.230833] [<c0101268>] (__do_softirq) from
[<c012c8e0>] (irq_exit+0xd4/0x110)[ 84.238157] [<c012c8e0>] (irq_exit)
from [<c0181660>] (handle_domain_irq+0x80/0xb0)[ 84.245797] [<c0181660>]
(handle_domain_irq) from [<c063ff04>] (gic_handle_irq+0x7c/0x90)[
84.253965] [<c063ff04>] (gic_handle_irq) from [<c0100afc>]
(__irq_svc+0x5c/0x90)[ 84.261392] Exception stack(0xced55ca8 to
0xced55cf0)[ 84.266383] 5ca0: df858000 df858004
00000000 c1b6cb80 c1b6cb80 c1b3cec0[ 84.274541] 5cc0: c1bf8074 c120b400
c1b3cf40 c1b3cf48 c1986010 cf0ba580 c205ac44 ced55cf8[ 84.282695] 5ce0:
c09a38d8 c09a34fc 60010013 ffffffff[ 84.287781] [<c0100afc>] (__irq_svc)
from [<c09a34fc>] (shmem_tx_prepare+0xcc/0xdc)[ 84.295422] [<c09a34fc>]
(shmem_tx_prepare) from [<c09a38d8>] (smc_send_message+0x24/0x120)[
84.303696] [<c09a38d8>] (smc_send_message) from [<c099ae50>]
(do_xfer+0x98/0x464)[ 84.311234] [<c099ae50>] (do_xfer) from [<c099f40c>]
(scmi_clock_rate_get+0x70/0xc4)[ 84.318983] [<c099f40c>]
(scmi_clock_rate_get) from [<c067f358>] (scmi_clk_recalc_rate+0x3c/0x70)[
84.327791] [<c067f358>] (scmi_clk_recalc_rate) from [<c0677004>]
(clk_recalc+0x34/0x74)[ 84.331653] sched: RT throttling activated[
84.339991] [<c0677004>] (clk_recalc) from [<c0679e18>]
(clk_change_rate+0xf8/0x544)[ 84.347653] [<c0679e18>] (clk_change_rate)
from [<c067a3f4>] (clk_core_set_rate_nolock+0x190/0x1d8)[ 84.356687]
[<c067a3f4>] (clk_core_set_rate_nolock) from [<c067a46c>]
(clk_set_rate+0x30/0x88)[ 84.365300] [<c067a46c>] (clk_set_rate) from
[<c095a910>] (_set_opp+0x2d0/0x5f0)[ 84.372647] [<c095a910>] (_set_opp)
from [<c095acc0>] (dev_pm_opp_set_rate+0x90/0x16c)[ 84.380508]
[<c095acc0>] (dev_pm_opp_set_rate) from [<c095ff8c>]
(__cpufreq_driver_target+0x110/0x2f8)[ 84.389840] [<c095ff8c>]
(__cpufreq_driver_target) from [<c0962f94>] (od_dbs_update+0xb4/0x160)[
84.398540] [<c0962f94>] (od_dbs_update) from [<c0963b18>]
(dbs_work_handler+0x2c/0x58)[ 84.406499] [<c0963b18>] (dbs_work_handler)
from [<c0141dec>] (process_one_work+0x1dc/0x588)[ 84.414881] [<c0141dec>]
(process_one_work) from [<c01421e4>] (worker_thread+0x4c/0x520)[
84.422940] [<c01421e4>] (worker_thread) from [<c0149df8>]
(kthread+0x170/0x1a0)[ 84.430367] [<c0149df8>] (kthread) from
[<c0100130>] (ret_from_fork+0x14/0x24)[ 84.437481] Exception
stack(0xced55fb0 to 0xced55ff8)[ 84.442571] 5fa0:
00000000 00000000 00000000 00000000[ 84.450726] 5fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000[
84.458880] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000[
84.465448] handlers:[ 84.467682] [<716ecdd6>] irq_default_primary_handler
threaded [<63fec1af>] regmap_irq_thread[ 84.476083] Disabling IRQ #74*
torstai 5. tammikuuta 2023 klo 13.00.34 UTC-5 Tommi Parkkila kirjoitti:
> Ralf - Not sure what you mean by your note.
>
> Jan - root cell configuration is now fixed what comes to overlapped memory
> regions. However, the both issues: *1. Terminal hangs*, and *2. Issue
> with setting CPU clock* still exists. I am not familiar with clock
> configurations on the target, but yes TF-A is in use.
>
> -tommi
>
> to 5. tammik. 2023 klo 12.54 Ralf Ramsauer ([email protected])
> kirjoitti:
>
>>
>>
>> On 05/01/2023 18:24, Jan Kiszka wrote:
>> > On 05.01.23 18:21, Tommi Parkkila wrote:
>> >> 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]
>> >> <mailto:[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_EXECUTE
>> >> overlaps with xAPIC
>> >
>> > Another detail when running cross: "-a arm" - you don't have to worry
>> > about x86 resources on your target.
>>
>> Side note: We should store the architecture in the configuration. Just
>> for the same reason why we introduced the magic byte at the beginning…
>>
>> Ralf
>>
>> >
>> > Jan
>> >
>> >> 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.c
>> >> Reading 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]
>> >> <mailto:[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]>
>> >> > <mailto:[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/369cc253-8606-476b-a8d7-38ed11beaa2fn%40googlegroups.com.
