On 06/01/2023 15:08, Tommi Parkkila wrote:
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?
Interesting. What's behind IRQ 74? Would you please share
/proc/interrupts, /proc/iomem and the configuration of your root cell?
And also maybe the full device tree using
$ dtc -I fs -O dts /proc/device-tree -o stm32mp1.dts
Thanks
Ralf
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]
<mailto:[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 <https://groups.google.com/d/msgid/jailhouse-dev/369cc253-8606-476b-a8d7-38ed11beaa2fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/56643ee7-2f74-39a2-dfa7-ad2abf603bd5%40oth-regensburg.de.
