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!
[...]
Kind regards
Uffe
