I’ve tried kexec on the BananaPi R3(mini). It all pretty much looks fine, except for pcie.
When booting a kexec linux kernel, the kernel log shows:
[ 2.720921] mtk-pcie-gen3 11280000.pcie: host bridge /soc/pcie@11280000 ranges:
[ 2.728251] mtk-pcie-gen3 11280000.pcie: MEM 0x0020000000..0x002fffffff -> 0x0020000000
[ 2.948952] mtk-pcie-gen3 11280000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x3481f)
[ 2.958107] mtk-pcie-gen3: probe of 11280000.pcie failed with error -110
While the original boot was ok.
I guess the pcie bridge needs a hw reset of some sort…
I was planning to use kexec as alternative bootloader for nvme boot, but it seems I do not need it for that, as pcie support for u-boot is in the making.
But anyway, it would still be nice for developers to be able to use kexec, to test a patch in a kernel quickly or something similar.
detect.quiet sounds like a regulator is not activated (gpio)…afair the normal message with timeout is a bit different (card not supported or taking to long for pcie driver)…is it the same kernelimage you can boot the normal way without issues?
Maybe some el-issue? Imho some resets need to be done in securemode and possibly these calls are not available in your current state?
As far as i understand you want to boot a kernel with initrd from atf and then start another kernel from this initrd (kexec=linux syscall). So maybe you have no access anymore to atfs secure calls. But i’m no arm(64) expert