Hi, Mauro,
On 11/02/2020 05:06 PM, Mauro Condarelli wrote:
Hi Jinyang,
On 11/2/20 3:04 AM, Jinyang He wrote:
Hi,
On 11/02/2020 08:01 AM, Mauro Condarelli wrote:
Can someone confirm (or disconfirm, of course) kexec is supposed to work on MIPS32R2?
My attempts to use it on a MT7628-based board result in a silent hang (watchdog cuts in)
right after:
[ 201.309836] kexec_core: Starting new kernel
[ 201.318239] Will call new kernel at 004f0000
[ 201.322581] Bye ...
Apparently old kernel jumps to `do_kexec()` and just dies; new kernel does not give a peep.
This can be completely my fault, of course, but I would like a confirm this is supposed to work.
Thanks in advance
Mauro Condarelli
I'm not familiar with MIPSR2. I guess your platform (MT7628-based board)
cannot use the common function. It may not give a machine specific function, too.
My SoC is single core, so I don't have CONFIG_SMP.
Apparently (if I read code correctly) `do_kexec()` is actually `relocate_new_kernel`
(arch/mips/kernel/relocate_kernel.S).
No specific provisions seem to be available for my CPU (I see just a
`#ifdef CONFIG_CPU_CAVIUM_OCTEON`, which is not my case).
Unfortunately my understanding of MIPS assembly is insufficient to accurately follow
this code.
How CPU0 do in do_kexec()? Maybe arch/mips/kernel/reloacate_kernel.S gives us
some useful information. In this file CPU0 goes relocate_new_kernel() and other
CPUs go kexec_smp_wait() if CONFIG_SMP is enabled. Normally CPU0 will enter the
kernel_entry() of the new kernel. In my own understanding of the kexec process,
I find it extremely difficult to pass parameters. Please make sure your platform
passes the parameters necessary for startup. (See arch/mips/kernel/head.S, such as
dtb, fw_args* or other necessary parameters, this is what I said "machine specific")
One possible cause of mishap is my kernel (currently) does *not* have a .dtb appended
and I see no explicit option to reuse current DT.
In my mips `kexec` there's a `--dtb=<file>` option but passing the same .dtb I use with
u-Boot does not seem to work:
# kexec -l /boot/vmlinuz --command-line="earlyprintk rootwait console=ttyS2,115200 mtdparts=spi0.0:312k(u-boot),4k(env),4k(factor
y),2368k(kernel),-(filesystem) root=/dev/mmcblk0p7 tryboot=B" --dtb=/boot/u-boot.dtb
# kexec -e
[ 2030.833119] mtk_soc_eth 10100000.ethernet eth0: Link is Down
[ 2030.848999] wlan0: deauthenticating from a0:04:60:9f:2f:f8 by local choice (Reason: 3=DEAUTH_LEAVING)
Received Deauthentication event, reason: 3, from_ap: false
Received error during CMD_TRIGGER_SCAN: Network is down (127)
[ 2030.894637] kexec_core: Starting new kernel
[ 2030.900005] Will call new kernel at 004f0000
[ 2030.904326] Bye ...
<HANG!>
<watchdog reset>
Any hint welcome as I'm completely out of my depth here.
TiA!
Mauro
The DTB problem is not a serious problem at the moment. Make sure the
parameters
have been passed before the new kernel running. What "kexec -l" do in
kernel code?
We can do "kexec -l ... -d" to get some debug info. Normally there is a
segment
about COMMAND_LINE(cmdline). We should do something with the cmdline in
kernel code.
See arch/mips/kernel/machine_kexec.c: machine_kexec_prepare(). If
CONFIG_UHI_BOOT was
enabled, we would pass 2 args. "-2" and fdt? (I'm not sure here, the
importance is
that it provide a way to pass fdt for these platform which pass cmdline
by fdt, I guess).
Just a simple chat with CONFIG_UHI_BOOT, I really case that cmdline
cannot be passed
if your platform disabled CONFIG_UHI_BOOT and _machine_kexec_prepare is
NULL.
Because no parameters would be passed, include cmdline.
Jinyang
