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)
I've checked in my boards now, and all the boards mentioned above seem
to handle this well with smccc-versions of at least 0x10002 .
Heiko
