Done. Added to the Gitlab isssue.
@Strit Great, thank you!
Hmm, for some yet uknown reason the device tree isn’t properly amended in TF-A to reflect the CPU idle states available via Crust, despite the TF-A, basically, announcing that to be performed on the serial console. Either that, or the device tree amendments made in TF-A aren’t propagated further. That’s bad news, but it’s good news that there are probably no bugs on the kernel side.
I’ll add some custom debug code to the TF-A source code and use that to pinpoint the issue further, by locating the point where the execution of TF-A code actually fails to perform the expected device tree modifications, if that’s the actual culprit, etc. I’ll be able to work on all that on Sunday, because my schedule for tomorrow is already overflowing with all kinds of “real-life” stuff. I’m looking forward to getting to the bottom of this issue!
Thanks for working on this.
Thank you for providing the logs and additional debugging data.
can we give that a try as Megi patched out some regulators which might be needed by crust it seems after all. That run disables that patch: [pkg-upd] 2023.01-1 (0980595f) · Commits · manjaro-arm / packages / core / uboot-pinephone · GitLab
Sure, I’ll first try a few boot loader builds with as few patches as possible, to test the things incrementally. Quite frankly, I’m not sure why Megi uses the patch that disables the enabling of the regulators, it may have something to do with the fact that Megi uses p-boot on his PinePhones.
That is why I removed that patch again. Just let me know your findings …
I apologize for the delays, things were a little crazy on my side during the last week. It was all fine, but quite eventful, so to speak.
On the plus side, my PinePhone is now equipped with an external microSD card slot, for easy access to it that’s pretty much required for the testing. However, I spent a few hours trying to locate my multimeter, to check the voltage of the USB-to-UART adapter I’ll be using, and I was unable to locate the multimeter within the pile of hardware I’ve been lucky to acquire in the last few months. Though, I’ll find it as soon as possible, I promise.
Woohoo, I just found the multimeter! It’s too late (or too early?) over here at the moment, though, so I have to go to bed.
How is the troubleshooting going? Is there some testing i could help with without the serial cable?
I should have some results available later today. I’ll also provide you with the instructions how to replicate some of the tests, so we can verify the observed behavior in two different environments – if applicable, of course.
Just a brief update… I’ve been busy in the last few days writing a couple of articles for a regional long-lasting printed computer magazine, to meet the magazine’s publishing deadline. Those articles should be completed in a day or two, at which point I’ll happily get back to debugging this issue.
As part of writing one of those articles, I’ve discovered an issue with a Patriot Rage Pro, a high-performance USB flash drive, for which I’ll also work on a fix through USB quirks in the Linux kernel. It would be ideal to fix that issue through a firmware update for the drive, but frankly, I don’t see that happening. However, I’ll try contacting the drive manufacturer, once I’m 100% certain about the actual culprit.
All kinds of issues just keep popping up all over the place.
I see, I see. Let’s see how it unfolds.
I’m finally back to working on this issue. I’ve been on a true rollercoaster ride in my private life for the last few weeks, but thankfully, the things are settling down.
Excited to hear what you might find.
I just added some patch to 6.1.12-2 I’m currently building …
Can be downloaded here: https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-pinephone/-/jobs/12051/artifacts/download?file_type=archive
Is this the missing hardware definitions to make cpuidle work or something else? I recognized the commit text to be same as in this sunxi spec page documenting something they call cpuidle but might not be same as kernel cpuidle governor? CPUIDLE - linux-sunxi.org
Most likely as the Megi kernel seems not to have them by default: linux/sun50i-a64.dtsi at orange-pi-6.1 · megous/linux · GitHub linux/sun50i-h5.dtsi at orange-pi-6.1 · megous/linux · GitHub
Just let me know if it works now …
YES, it is working now. Thanks for chasing the issue down.