[BPI-R3] kexec support

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.

Any ideas?

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?

Yes, same kernelimage.

It is already the pcie bridge itself that is down. This is even before trying the nvme card on port 01.

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 :slight_smile:

That may be the same issue I am having. Mediatek points to a possible clock problem. I’ve a patch to do & report back.

A temporary solution was to boot with clk_ignore_unused

That was the original idea, but it is not really necessary if u-boot supports pcie. But this is indeed the situation I have done to get to this error.

But for testing patches and such, it would be nice to have kexec functional.

kexec should take care of the state handling. All other hardware seems ok on first glance, only pcie not.

I may give that a try…

Under which conditions do you get it?

It was loading the pcie-mediatek-gen3 as a module.

You’ve replied to my post about it… BPi-R3 - Modules to get nvme working? Wrong pinctrl

So I tried this as kernel cmdline parameter for the kernel run with kexec. It does not work, still the same problem.

Anyway, so I was thinking, since I use a custom ATF, I might add another feature.

Because ddr is now ramoops compatible and survives reset, I may add the following.

On warmboot, check the presence of a preloaded kernel+initrd+dtb. If present run it.

So this would be in practice the same as kexec, but it uses a hard reset and would be compatible…