在 2025/2/18 19:05, Ulf Hansson 写道:
On Tue, 18 Feb 2025 at 01:53, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote:
Hi Heiko, Steven
在 2025/2/18 4:50, Heiko Stübner 写道:
Am Montag, 17. Februar 2025, 18:10:32 MEZ schrieb Steven Price:
On 17/02/2025 15:16, Heiko Stübner wrote:
Hi Steven,
Am Montag, 17. Februar 2025, 15:47:21 MEZ schrieb Steven Price:
On 05/02/2025 06:15, Shawn Lin wrote:
Inform firmware to keep the power domain on or off.
Suggested-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx>
---
This patch is causing my Firefly RK3288 to fail to boot, it hangs
shortly after reaching user space, but the bootup messages include the
suspicious line "Bad mode in prefetch abort handler detected".
I suspect the firmware on this board doesn't support this new SMC
correctly. Reverting this patch on top of linux-next gets everything
working again.
Is your board actually running some trusted firmware?
Not as far as I know.
Stock rk3288 never had tf-a / psci [0], I did work on that for a while,
but don't think that ever took off.
I'm wondering who the smcc call is calling, but don't know about
about smcc stuff.
Good question - it's quite possible things are blowing up just because
there's nothing there to handle the SMC. My DTB is as upstream:
cpus {
#address-cells = <0x01>;
#size-cells = <0x00>;
enable-method = "rockchip,rk3066-smp";
rockchip,pmu = <0x06>;
I haven't investigated why this code is attempting to call an SMC on
this board.
I guess the why is easy, something to do with suspend :-) .
I did go testing a bit, booting a rk3288-veyron produces the same issue
you saw, likely due to the non-existent trusted-firmware.
On the arm64-side, I tried a plethora of socs + tfa-versions,
rk3328: v2.5 upstream(?)-tf-a
rk3399: v2.9 upstream-tf-a
px30: v2.4+v2.9 upstream-tf-a
rk3568: v2.3 vendor-tf-a
rk3588: v2.3 vendor-tf-a
and all ran just fine.
So it really looks like the smcc call going to some unset location is
the culprit.
Looking at other users of arm_smcc_smc, most of them seem to be handled
unguarded, but some older(?) arm32 boards actually check their DTs for an
optee node before trying their smc-call.
I guess in the pm-domain case, we could just wrap the call with:
if(arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_NONE)
Thanks for the report and helping find out the cause!
@Ulf, if the solution above seems reasonable to you, I can cook a fix-up
patch.
Seems reasonable to me, thanks!
Thanks Ulf, I have sent a individual fix-up patch.
[...]
Kind regards
Uffe
