(07-14-2020, 08:13 AM)afigegoznaet Wrote: (07-13-2020, 07:06 PM)mil Wrote: Hey so your situation with the modem suddenly becoming flaky and then stopping working all together sounds exactly like what I experienced. Modem test times out for me as well. I documented my issues and a workaround (atleast for modemmanager) in the thread at: https://forum.pine64.org/showthread.php?tid=9934
I'm curious if you run `screen /dev/ttyS2` can you still issue AT commands? In my situation the USB connections on my BH died completely but the serial /dev/ttyS* devices are still operable. Dmesg prints some stuff on boot related to USB drivers I assume that isn't very pretty as well..
I think this is a hardware issue because it just happened randomly for me (and multiple images show the same issue). Very curious if this issue has been resolved on CE / 1.2 (I hope). Also by the way - my issues happened without any testing on crust / deep sleep; however what I will note is I did (and well... still do) have a habit of pulling the battery out of my pinephone to restart it - which maybe contributed..  but then again most phones can handle this fine.. so this shouldn't break anything on the hardware-level from my perspective. I don't know what "screen" is, but I think it's the same for me.
At least I see the /dev/ttyS* devices, and the dmesg USB errors.
Do you have the USB devices in /dev? Wonder if you might be able to post the output of `ls /dev/ttyS* /dev/ttyUSB*`; on a normal pinephone with a working modem I believe you should see entries for both serial & USB devices. On my Pinephone with the broken modem I only have serial devices.
It seems the SailfishOS image is doing something that brings the Modem back to life (even though it doesn't work in SFOS itself).
I noticed this for a couple of times already, I was playing with SFOS, then started Fedora image, and it had 4g signal.
07-15-2020, 01:02 PM
(This post was last modified: 07-15-2020, 01:05 PM by afigegoznaet.)
So, after a double check, it's not SFOS, but Fedora that is doing something.
And that something happens only with the mint, non-updated version of Fedora (I used the 0615 image).
It looks like the mint image doesn't have crust enabled, but the updated version does, since Modem disappears shortly after updating/restarting, I guess it happens after the modem is sent to standby mode.
This is just a presumption, I will need to verify this.
Me too. I wonder this only happened to people with the Braveheart edition, like me, or if some people with the UB Ports edition experienced this too.
I am a Brave Heart user.
I had pretty good results using UBPorts Ubuntu Touch early this year. But as a GUI user, as the newer releases kept coming out, the experience went downhill.
It got to be completely UN-usable....
Along came Debian/Phosh that was fairly usable in a new OS sort of way... That fell to the improved and improving Mobian.
Mobian worked real well, some minor faults, like multiple incoming texts, some screen sizing faults, but over-all improving really fast.
Then starting in July, I started seeing problems I assumed were "modem" related, my use of the text app was getting harder to use.
for a while the only way I could access my text app was to send myself a text from my second phone. Once opened it worked 'OK' ...
Then came the update where my text app disappeared ! ! !
There was not even an icon for the text app in the contact book -- Just the (phone) handset icon remained.
I decided to do some back tracking, The recent UBPorts downloads would no longer flash with Balena Etcher, it just freezes before it finishes flashing the sd card ?
The Mobian July 01 release would run my phone for calls, but not text.
Back to Mobian June 27, everything works, Except incoming text ! ?
I guess I need to go back to an earlier release.. ? I have not given up...
My question at the moment being, I wonder if there are minor firmware changes to the components, could be same part numbers, but built at different dates ?
That could explain why the software works fine for some, buggy for some, and not at all for others.... (?)
I have been extra careful to turn off my phone before removing the back cover, but even so, I have accidentally turned it on while removing the cover and the battery on more than one occasion.
That is why I thought I may have corrupted my modem, BUT, if it was corrupted it would not function on any OS I have tried since... right ? ?
I think eventually MOST of these problems will be resolved, ...
Just like waiting for your phone to "arrive" ...
. . . WE WANT IT NOW !
This is a documented issue with BH versions
Per the wiki
Quote:Modem PWR_KEY signal resistor population
Resolved in v1.2 by separating the modem PWRKEY (PB3) and STATUS (PH9) signals.
On the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).
https://wiki.pine64.org/index.php/PinePh...Braveheart
So in simpler terms the 1.1 (Brave Heart) self destructs ?
The 1.2 and the 1.2a are progressive improvements, but still 'flawed' ?
The PMOS Community Edition is the 1.2a board revision, Yes ? ?
(08-01-2020, 04:34 AM)SwordfishII Wrote: This is a documented issue with BH versions
Per the wiki
Quote:Modem PWR_KEY signal resistor population
Resolved in v1.2 by separating the modem PWRKEY (PB3) and STATUS (PH9) signals.
On the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can't do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).
https://wiki.pine64.org/index.php/PinePh...Braveheart
I see on Mobian OS, on the software page -- under download preferences there is an option to include firmware updates,
Perhaps that is why my modem appears to have partially recovered ?
I still cannot receive text,
but I can send text and my calls work both incoming and outgoing.
08-01-2020, 06:12 PM
(This post was last modified: 08-01-2020, 07:35 PM by SwordfishII.)
(08-01-2020, 10:45 AM)bcnaz Wrote: So in simpler terms the 1.1 (Brave Heart) self destructs ?
The 1.2 and the 1.2a are progressive improvements, but still 'flawed' ?
The PMOS Community Edition is the 1.2a board revision, Yes ? ?
Basically the modem needs to shut down before the phone shuts down.
Since direct access to the modem was needed for dev it had to be wired in a specific way and shutdown was offloaded to software which may or may not be correctly implemented.
The shutdown via hardware should be correctly triggered on versions after BH
|
