Hi Denys,
On Wednesday 12 April 2017 08:05 PM, Denys Zagorui wrote:
Hello, Pratyush
Thanks for your reply.
Could you describe how i can find out wich enable method used. One more
things, i made this tests on qemu, and it works. Logs attached.
From your board log (log_for_com ):
PSCI: PSCI does not exist
and then
[ 60.561877] Can't kexec: CPUs are stuck in the kernel.
Above message is coming from machine_kexec_prepare() when
cpus_are_stuck_in_kernel() returns true. See, its implementation. It
will return true if number of possible cpus is > 1 and cpu_die() is not
implemented.
You can boot your first kernel with nr_cpus=1 in kernel cmdline and
then you should be able to kexec to the second kernel from there.
However, it can not be a solution. You should update your firmware with
psci implementation.
For the time being you can have spin-table work aroudn like this [1],
but please note that spin-table is discouraged upstream [2].
[1]
https://github.com/pratyushanand/linux/commit/a50e98635b7257c101f02f7ac488a4cb04187f6d
[2] https://patchwork.kernel.org/patch/7873571/
From your qemu log:
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv0.2 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: Trusted OS migration not required
and so it works :-)
~Pratyush
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
