I was not aware of Petitboot before reading the following thread so thank you ribalda.
A little research indicated that it would be just the thing for booting from my hard drive. So I too started to investigate kexec.
I installed kexec-tools on my Debian install (linaro-buster-alip-dragonboard-820c-221.img):
root@linaro-alip:~# apt-get install kexec-tools
root@linaro-alip:~# kexec -v
The kexec userspace tool does not seem to handle device tree reserved-memory nodes with an alloc-ranges property correctly.
Little Kernel does appear to handle them correctly. I have examined /proc/device-tree/reserved-memory/rmtfs@86700000 and it seems to be correct.
If I transfer the Image.gz, initramfs and .dtb files and /lib/modules/4.18.0 from:
and boot the dragonboard by fastboot with:
# fastboot boot boot-rootfs-linux-integration-v4.18-273-gdc6c774913bc-107-dragonboard820c.img
then load the Image.gz with:
root@linaro-alip:~# kexec -d -l /boot/Image.gz --initrd=/boot/initramfs-bootrr-image-dragonboard-820c-20180829152612-44.rootfs.cpio.gz --command-line="root=/dev/disk/by-partlabel/rootfs rw rootwait console=ttyMSM0,115200n8 androidboot.bootdevice=624000.ufshc androidboot.serialno=683393bf androidboot.baseband=apq mdss_mdp.panel=0 earlyprintk earlycon=msm_serial_dm,0x75b0000 debug memblock=debug ignore_loglevel ftrace=function ftrace_dump_on_oops" --dtb=/boot/apq8096-db820c.dtb
then execute the kernel using:
root@linaro-alip:~# systemctl kexec
the second kernel fails to reserve memory for the node with the alloc-ranges property, rmtfs@86700000, and a panic ensues. The other nodes in /reserved-memory seem to be handled correctly, according to memblock=debug.
... [ 0.000000] OF: reserved mem: failed to allocate memory for node 'rmtfs@86700000' [ 0.000000] Reserved memory: created DMA memory pool at 0x0000000090b00000, size 10 MiB [ 0.000000] OF: reserved mem: initialized node gpu@8f200000, compatible id shared-dma-pool [ 0.000000] cma: Failed to reserve 16 MiB [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x0000000000001000 bytes below 0x0000000000000000. ...
However, if I do not include a device tree with the kexec -l and, presumably, reuse the already loaded device tree, the second kernel does allocate memory for rmtfs@86700000.
The second kernel still fails to boot, but at a later stage, while bringing up the secondary cpus, as ribalda also found. I am guessing that this is because the interrupt controller has not been set up correctly.
The boot messages from the first kernel, at this point, are:
[ 0.047809] smp: Bringing up secondary CPUs …
[ 0.080347] Detected PIPT I-cache on CPU1
[ 0.080376] GICv3: CPU1: found redistributor 1 region 0:0x0000000009c40000
[ 0.080411] CPU1: Booted secondary processor 0x0000000001 [0x511f2112]
[ 0.115085] Detected PIPT I-cache on CPU2
[ 0.115962] GICv3: CPU2: found redistributor 100 region 0:0x0000000009c80000
[ 0.116822] CPU2: Booted secondary processor 0x0000000100 [0x511f2052]
[ 0.154786] Detected PIPT I-cache on CPU3
[ 0.155607] GICv3: CPU3: found redistributor 101 region 0:0x0000000009cc0000
[ 0.156422] CPU3: Booted secondary processor 0x0000000101 [0x511f2052]
[ 0.159716] smp: Brought up 1 node, 4 CPUs
The line, ‘smp: Bringing up secondary CPUs …’, being the last line from the second kernel.
and, at the end of the first kernel shutdown, I get:
[ 52.365624] kexec_core: Starting new kernel
[ 52.372260] Disabling non-boot CPUs …
[ 52.448981] CPU1: shutdown
[ 52.455721] psci: CPU1 killed.
[ 52.520984] CPU2: shutdown
[ 52.527117] psci: CPU2 killed.
[ 52.568144] cpu cpu3: opp_migrate_dentry: Failed to rename link from: cpu2 to cpu3
[ 52.576075] CPU3: shutdown
[ 52.583083] psci: CPU3 killed.
[ 52.606336] Bye!
There seems to be some recent traffic on http://lists.infradead.org/mailman/listinfo/kexec related to this but I cannot discern if a solution is imminent. The posts appear to be more concerned with the effect on kdump which would appear to be difficult to resolve.
Can anyone shed any light on if/when kexec will work?