On 5/27/26 10:30 PM, Gekko wrote: > Hi Konrad, > > This one is confusing. > > I started the bring-up on this board on gentoo-sources 6.18.18 but the board > would not boot. After an almost subliminal flash of tux the board would lock > every time.I found the solution from PostmarketOS who obviously faced the > same issue which formed the genesis of this patch. With this patch applied > the board booted fine so I've applied it ever since. > > However, as a result of your response here I tried booting my current kernel > (gentoo-sources 7.0.10) without the patch and to my surprise it booted just > fine. This leaves a few options, including: > 1) the kernel source has changed > 2) this is a firmware issue and a firmware update fixed it > 3) It's a timing issue. > > To eliminate 2 I would have to test 6.18.18 with the current firmware, then > regress the firmware and test again. The do the same with 7.0.10. I can't > honestly recall whether the firmware upgrade was before or after this issue > first appeared. > > If it's a timing issue it's a bit more concerning. If the kernel is taking > slightly longer to initialise before calling rpmh_probe_tcs_config() then it > may just be missing the solver activation, everything appears to work and > nobody is any the wiser. If the existing solver code doesn't deal with early > firmware TCS initialisation then it could, under some circumstances, lead to > the security reset that I was seeing. This patch specifically tests for that > case. > > Based on the AI review feedback I've also modified the patch to not simply > return early but to just skip the sensitive parts of the code to allow any > other setup to complete normally. > > My current objective evidence is that the board boots without this patch and > it's quite possible this patch is unnecessary if the above is incorrect.
I would skew towards this being a firmware issue. But I'm interested in any findings you encounter. Maybe +Maulik could know more Konrad
