CPUIDLE not working on pinephone

Ah, I see now, you’ve ordered the jack from China. AFAIK, until a couple of years ago China had a special, privileged status when it comes to the international shipping costs. Basically, all other countries subsidized the transiting part of the international shipping costs for the parcels that originated from China. Add the subsidization of the small-parcel shipping costs by the Chinese government on top of that, and you’ll get the entire picture, or at least the way it used to be until a couple of years ago.

I’m not really sure how is it still possible to have such low shipping prices, with China losing its privileged status a couple of years ago. Perhaps they now ship the majority of small parcels not from China but from other countries, which are closer to the actual parcel destinations, but that assumption still doesn’t explain it all. Maybe the Chinese government has increased its subsidization? I really don’t know.

OK, i cobbled together an adapter from my previous phone’s headphones and i can barely make it work, if i plug it in all the way it fails but balancing it just at the right spot not all the way in it works.

Hopefully the plug i ordered works better, or maybe i could try cleaning the contacts with some methanol…

Good, at least now we know that your USB UART adapter works as expected. Let’s hope that the stereo jack you’ve ordered will work with no such issues.

How is the situation of now? I just got the new 3,5mm plugs i ordered to hopefully make the debug interface reliable and not just barely working.

It’s good to hear that the stereo jacks have arrived. I hope they’ll fix the reliability issues with the serial console of your PinePhone.

I’ve been busy with regaining strength and patching mostly smaller things here and there, this time in userspace utilities. Some of the patches have already been accepted upstream, I’m still fighting for some of them to become accepted, and I’m currently working on a few more patches. Here are some links:

Let’s hope that the above-described new feature for cut(1), which adds new command-line option -m that merges multiple consecutive delimiters and treats them as a single delimiter, will eventually find its way into the coreutils repository. I’ve needed that feature many, many times and other people on Stack Overflow and Stack Exchange needed it too, as visible in questions #21322968, #7142735, #109835, #606639, #387544 and #25447324. Thus, I went ahead by implementing this feature for cut(1) and submitting it upstream.

By the way, I’m unfortunately on antibiotics again since yesterday, :frowning: due to a rather mysterious nail infection. Let’s hope I won’t be taking that prescription for more than a week or so, so I won’t become messed up badly again.

4 Likes

Just a quick update… I’m still battling the mysterious nail infection, which has reared its ugly head again, unfortunately, after it had subsided for a couple of weeks… :frowning: It still isn’t too bad, thankfully, but there’s a real possibility for it to become really nasty at pretty much any point, so it needs to be addressed. Let’s hope that it will be taken care of in the next few feeks, with a new prescription of antibiotics.

Regarding my work on the PinePhone, I’ve been thinking about it quite a lot recently, and I came to a conclusion that I need to implement and upstream another combined U-Boot + TF-A feature for the PinePhone first, before diving into fixing the CPUIDLE issue. My reasoning behind this decision is that upstreaming the CPUIDLE patches, which will inevitably be rather convoluted, should have much higher chances to be successful if I establish myself first as a reliable U-Boot and TF-A contributor through the another feature that’s a bit less convoluted. I hope it makes sense.

There will be quite a lot of testing required for this new feature, which I’ll keep a bit secretive for now, and I hope you’ll be willing to help. Trust me, you’ll love it. :slight_smile:

By the way, my first patch for git that adds support for new diff.statNameWidth configuration option was accepted upstream in git commit bd48adc31d and has already reached the master git branch, which is one step away from being included in the next git release. My second git patch that performs some related code refactoring was accepted upstream in git commit 4ca7a3fd26 and has reached the seen git branch. Two more git patches are currently underway.

1 Like

You seem to have bad luck with your health. I hope you have discussed with your doctor the option of just pulling out the toenail and let it regrow to fix infection instead of trying to fix it using systemic poisons that can easily wreck your intestinal microbiome and cause acute and chronic issues.

What you said does make sense, work at it in whatever way you feel is best, it’s you who is doing the work after all :smiley: Just let me know when you need testing help and i will try to see what i can do as soon as possible.

1 Like

Ah, unfortunatey I’ve had issues with my health since early March, and frankly, it’s been quite exhausting. :frowning: The “original” health issues, which started much before the nail infection that reared its ugly head a couple of months ago, were like 50x worse, and I’m really thankful and I just keep knocking on wood for having those “original” health issues resolved with successful and complete recovery.

It’s also important to note that I’ve already dragged that nail infection for a couple of years, but in a really mild form that used to heal on its own rather quickly, but it kept returning a few times. It became much worse about a couple of months ago.

I’ve also thought about having the nail removed, and I already mentioned that to my doctor, but there are a couple of associated issues… First, only about 15-20% of the nail is actually infected, so it isn’t close to the point where removing it surgically is a viable option. Second, having a nail removed (it’s the thumbnail on my left hand, by the way) effectively renders the affected finger unusable for about half a year or even longer, because the nail provides a lot of the rigidity of the fingertip. As we know, making a thumb unusable effectively renders the affected hand unusable as a whole for most tasks, which isn’t great, if you agree. If it were a nail on my foot instead, its removal would’ve been a much more viable option.

Regarding the CPUIDLE patches, they will require an introduction of a pretty much brand-new category of the device-tree data that needs to be generated by TF-A, passed around to U-Boot, and applied by U-Boot to the final device tree. Having such changes introduced by a new contributor would probably raise a few eyebrows, reducing the chances for the patches to be accepted upstream.

On the other hand, the patches for the other PinePhone feature I mentioned in my earlier post will be relatively straightforward, and there should be no blockers (or even slightly raised eyebrows, hopefully) when the patches reach the point of being submitted upstream. Moreover, it will be a long-awaited PinePhone feature that will surely make many people happy. :slight_smile: The patches will also finally resolve some inconsistencies that were present forever in the suport for Allwinner A64 in TF-A and U-Boot as a whole, when compared with the support for other SoCs.

Thank you very much for your willingness to help with testing the patches! I’ll post here when some patches are ready for testing, which will surely be a gradual process.

Oh sorry, i just assumed it was toenail issue. I never even heard of chronic fingernail issues before covid vaccinations started. I hope your original issues and later nail issues are not derivative of that.

It’s really admirable that you seem to know exactly what needs to be done and are willing to properly implement this minor feature fix, on hardware that most would deem obsolete.

I bought the pinephone on the promise that it is not android and you can run mainline kernel once everything is upstreamed. It’s pretty many years past that point, and general interest seems to be waning for such old hardware. Never fulfilling the “promise”

No worries. That’s interesting, I haven’t heard of the increased number of nail infection cases during and after the pandemic. Actually, I haven’t been vaccinated for COVID, because I didn’t have to go somewhere that required the vaccination, and I opted for remaining inside at home most of the time during the pandemic.

Frankly, the PinePhone is far from being obsolete. First of all, there are already many PinePhones in the hands of their owners, and we simply must make sure that, from the software side, they will work just fine in 10 or 15 years from now. Next, I think it’s important to differentiate the obsolescence on different levels, i.e. on the software level, on the hardware level, and on the platform level, to be precise. Modern Android phones quickly become obsolete on both software and platform levels, unfortunately, because they’re pretty much throwaway devices intentionally treated by their manufacturers as short-lived projects whose sole purpose is to make money for them. Those Android phones are far from being obsolete on the hardware level, but their closed nature makes it pretty much impossible to do anything to prevent the overall obsolescence from happening. It’s also an incredibly massive waste of the natural resources and a huge source of global pollution, if you agree.

On the other hand, the PinePhone may easily be considered obsolete on the hardware level by modern standards, but the open nature of both hardware and software, combined with the current state of open-source software support for the Allwinner A64 SoC in the upstream projects, is what makes it nearly impossible for the PinePhone to become obsolete on the software and platform levels. The only missing piece to the puzzle is to make the PinePhone supported at the same level as the A64 in the upstream projects, together with implementing a number of missing features.

As an example of avoided obsolescence, we could take very old i486 or Pentium PCs from the early 1990s that can still run modern mainline Linux kernel just fine. Yes, they’re very slow by the modern standards, but the key is that even very old PCs can still work, and an old Pentium III or Athlon XP may still be usable for some purposes. Actually, old PCs from the Athlon64 X2 era are still very usable, for example.

The PinePhone is still a very nice piece of hardware, despite its rather underpowered SoC and modest amounts of RAM and eMMC storage, according to the modern standards. It’s all generally usable, but many more software optimizations and improvements are still needed to make the overall user experience much better. Let’s also remember that standard PC hardware and even server hardware from 15 or 20 years ago was much, much weaker than the PinePhone, yet people used it just fine and did many incredible things on it. These days we have much more powerful hardware, but modern software tends to be bloated and inefficient, with many layers of abstraction that allow hyperproduction of even more bloated software. :slight_smile:

In other words, I intend to fulfill the promise you described, by eventually upstreaming all that hasn’t been ustreamed yet. I’ll also implement some of the missing features for the PinePhone, such as the charge-only mode, which I already got implemented to about 50%. Here’s a short video that shows the charge-only mode in action, running under simulated conditions, of course. :slight_smile: Just to clarify, charge-only mode isn’t the “mysterious” new feature I mentioned in my earlier posts.

2 Likes

You are of course right in everything you said, and as i said only many deem it obsolete, even if in reality it is not. As long as someone is working on it and bringing it closer to “the phone that can run mainline”

I truly appreciate your attitude and efforts!

1 Like

Thank you very much, and I’m glad that you agree.

While risking to open a whole new can or worms, I’ll also mention that the PinePhone’s built-in cellular modem should also be able run mainline Linux kernel at some point, of course only on its ARM CPU part, also known as the application processor, as called by Quectel. The Hexagon DSP part of the modem must remain untouched, to remain compliant with various regulations. That would turn the PinePhone into a truly open and obsolescence-proof mobile platform. :slight_smile:

There’s no need to emphasize how hard, difficult and time-consuming that would be, which would probably require following of the “clean room” approach, among other things and hoops to jump through, but it should be doable. At least in theory.

By the way, I’m on a new prescription of antibiotics since today, and I really hope that it will finally take care of the nail infection. I’m afraid that the prescription will be extended so it will last for a couple of weeks, to prevent the nail infection from returning, which unfortunately means that I’ll be messed up really bad again. :confused:

I’m not that familiar with the yocto project that biktor uses in his images, but i thought it already used mainline kernel to boot the modem. And in fact only use the ADSP firmware as external code along the lines you mentioned.

I already used this “almost free software” version of the modem for a long time and it certainly helped with battery life.

Ah, I wish if that were the case… The modem actually runs some kind of old Android kernel patched by Quectel (or whoever) to add the drivers required by the SoC inside the modem. I had a look at one of those kernel drivers, in an attempt to add some debugging code for the modem-related USB issues.

By the way, have you checked out the sample video, linked in one of my earlier posts, which demonstrates the charge-only mode for the PinePhone I’m also working on? I’d like to know your opinion about that.

Oh well, i was living in a too optimistic world.

Yes i looked at it as soon as you posted, i don’t know if it was anything more than a demo of the animation? Having that running in middle of screen at 50% -30% coverage or so would seem pretty elegant.

Maybe we’ll have the modem running mainline Linux kernel one day, with the voice calls working and everything. What a glorious day would that be. :slight_smile:

Let me clarify the charge-only mode a bit, please. The idea is to prevent the installed Linux distribution from booting when the PinePhone is turned on by plugging in a USB charger. The AXP803 PMIC turns the system on automatically when a charger is connected, but that scenario can be detected in software, or to be more precise, the idea is to have that detected inside the initial ramdisk, using the additional support in the kernel’s PMIC driver, which I’ve also implemented already to about 50%. At that point, normal boot is interrupted and the charge-only screen is displayed, which will also provide an option to continue with the boot process as usual.

The video clip I already posted shows the entire screen of the PinePhone in the charge-only mode, as described above, but it was recorded in a simulated environment that obviously “charged” the simulated “battery” very rapidly. In other words, the video clip shows exactly what the charge-only mode looks like, but the part of the video that shows the charging is much faster than it is in the reality, which I recorded that way for the demonstration purposes.

There will be more parameters displayed on the charge-only screen, such as the current battery voltage, current date and time, etc. Also, the way I implemented it already, the size of the “battery” and the font size automatically adjust and scale according to the screen size, as visible in the example below, which was created for a few different screen sizes. As a note, I implemented all that from scratch. :slight_smile:

The example below also shows what the charge-only screen looks like for a few different battery charge percentages.

I previously saw this charge only mode implemented, but it might have been megi in his botloader work?

Anyhow, all i wanted to say regarding the video you posted, is that it is much more pleasant to the eye if it only fills a part in the middle of the screen. It’s just a bit too “brutal” to just blast it on the whole screen, IMHO

I haven’t seen another implementation of charge-only mode, except the SDL version provided by postmarketOS, which has a large downside of taking over 100 MB of disk space in the initial ramdisk, due to the libraries it uses.

Sure, the entire screen isn’t filled by the “battery”, it already scales in a way that it ends up taking only a portion of the screen. I agree with you that having it filling the entire screen wouldn’t be too pleasant to the eye. :slight_smile:

Correction: I actually saw one more implementation of charge-only mode, which was in the Rockchip’s downstream fork of U-Boot. However, placing the charge-only mode inside the boot loader isn’t a very good choice, IMHO, because it requires a lot of duplicated battery charging logic to be present in the boot loader.

The charge-only mode that @varikonniemi has seen might be the dedicated JumpDrive image for charging only. Obviously, that is not the same as what @dsimic is working on, because the JumpDrive image is a dedicated image and not a mode automatically detected by the normal kernel.

The advantage of the JumpDrive approach, and presumably also the Rockchip bootloader approach, is that it still works when the battery level is so low that the kernel refuses to boot.

I also had a look at JumpDrive while helping people who had some issues with it, and there isn’t much special about its charging mode, when it comes to how it actually charges the battery. Basically, JumpDrive boots the Linux kernel and turns the screen off, to save some power coming from the charger, and then indicates the battery charge level using the phone’s built-in tri-color status LED.

JumpDrive is actually a small, specialized Linux distribution, so it’s different from the Rockchip’s boot-loader approach, and it’s more similar to the charge-only mode I’m working on, in that regard. Also, it’s pretty much safe to charge a nearly depleted battery with nothing booted or running on the PinePhone, because the default power-on settings of the AXP803 PMIC are good enough not to cause any harm to the battery while it’s being charged in that state. The PMIC also reportely does a good job when charging nearly depleted batteries, which can be tricky.

Just as a clarification, the Rockchip’s downstream fork of U-Boot I mentioned was for the RK3588, and obviously not applicable to the PinePhone.