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.
Graham
On 26/05/2026 00:40, Konrad Dybcio wrote:
On 5/22/26 8:06 AM, Graham O'Connor wrote:
On QCS6490-based platforms booting via UEFI, the RSC hardware solver
is already active when the kernel takes over from the firmware. Calling
rpmh_probe_tcs_config() in this state reinitializes the controller
while the firmware is actively managing it, causing a security
violation and system reset.
I don't think this has been an issue so far on other platforms..
Do you have some more details?
Konrad
