Usually whenever I’ve seen a charger not playing well with L5 it was because it failed to provide the current it advertised without going out-of-spec with voltage. Other devices usually use higher voltages, so they may hide the charger’s misbehavior.
Is 9 meant to be 5?
1 Like
Hi, this might be a noobie question but what is the fullname of this new kernel? I did install the one in the first post of this topic, but not sure if I have updated to the latest one. Thanks.
@dos , Is this thread meant only for L5, or are you suggesting this could be open for testing on L14 / 15 / Mini, etc?
Only for Librem 5. If 6.12 is even available for the x86 platforms, please create a new topic if something comes up.
It has both 9.0 V 2A and 5.0V 2A (I missed 5.0 V 2A when typing). So 65W, 45W, 18W and 10W are supported.
1 Like
I bought a new 36W charger and with it I can suspend without issues while still charging. So I think the issue was really with my broken charger which likely did not honor its voltage promise.
This new one has 5V-3A/9V-3.4A/12V-3A options for USB A and 5V-3A/9V-3.67A/12V-3A/15V-2.4A/20V-1.8A options for USB C
1 Like
Kernel 6.12.75 has been made the default one in crimson-updates-proposed and landing yesterday.
5 Likes
It appears that there may have been a regression in the smartcard-reader-behaviour with the latest kernel update (I’ve been using 6.12 ever since the first announcement on this thread). Symptoms are as described here: Smartcard reader issues since update to "Crimson"
Nothing changed regarding smartcard reader for a long time now, so if you were having intermittent issues since upgrading to Crimson with its newer Debian base then it’s likely still the same thing regardless of the running kernel.
Ok, strange. Ever since the 6.6-Version mentioned in the other thread my issues stopped and didn’t reappear when I updated to 6.12, but it appears that they are back now. So the cause is potentially elsewhere.
Updated kernel 6.12.79 is now available in crimson-updates-proposed:
- fixes the issue with the display not turning on with old u-boots that was introduced in 6.12 kernels
- enables pstore/ramoops, which lets you gather logs after the phone reboots due to an unexpected kernel panic post-factum (it’ll be stored in
/var/lib/systemd/pstore/) - enables Input Current Optimizer feature of the charging controller, which should make the phone gracefully handle chargers that claim that they can provide more power than they actually can, or poorly made cables etc.
- improves reliability of the modem waking the phone up from system suspend on some devices[*]
- fixes spurious hardware kill switch events that could be reported on some devices despite of no actual switch activity
- improves reliability of detection of short volume button presses
- fixes a possible crash when toggling the camera/mic kill switch
[*] Remember that the modem firmware version needs to be at least V1.0.0.2_20220930 for it to wake the system up reliably, this requirement hasn’t changed. The version can be checked with bm818-tools.
Also, I haven’t mentioned that earlier, but the previous update - 6.12.75pureos1 - should have also fixed full system hangs that could sporadically occur when resuming from system suspend, so if you weren’t using system suspend due to reliability concerns you may want to re-test.
6 Likes
Just installed 6.12.79 and the screen turned on. Thanks for the fix.
Reference:
2 Likes
Do you know what it means if bm818-tool says it’s unable to detect the firmware version?
Debugging steps taken: rebooted the phone, and that’s it. Same result.
Please, @dos, could you help me to understand?
Using bm818-tool I can read:
FW version
M100E_YOU SN0_1.0.0_220926
YCSN0_M100E_1BAD_3117_V1.0.0.2_20220930
M100E_1.0.4_200715
So, ultimately, which version I’ve? 220926? 20220930? 200715?
Could you please explain all those codes?
Thank you
Obvious this. It is very unlikely to find a wrong long number that matches 100% of the sign. Also the length of the others do not fit the long number (which is probably the date 2022.09.30, while the others shorten the year number from 2022 to 22 etc).
2 Likes
I assume that the modem is showing up at all. You have a working phone to make calls?
No access to the device? i.e. permissions problem? sudo it from the command line?
Possibly not. It’s a fairly user-unfriendly presentation of the information by the modem. But is there any documentation from Broadmobi that explains what each version means and how an individual version is decoded? Possibly not.
The information presented by the tool is identical to the output from the relevant AT command to the modem, other than that the tool breaks the output at each comma and makes it a newline.
Note also that because there are 3 variants of the modem (for the three different regions of the world), the exact string might differ between two modems that are actually at the same version anyway. So it makes sense to quote only the suffix of the version string.
For what it’s worth, there’s only one ‘V’ in the entire thing. 
Edit: Add:
The doco that I have says only:
Response
+BMSWVER:<modem_ver>,<efs_ver>,<CDROM_ver>,<apps_ver>
and that is “disturbing” because it doesn’t even match the actual response. However it gives clues as to what you might guess.
1 Like
On PureOS Crimson, with no “backports” or other external stuff?
What does sudo bm818-fw-check report?
You have a working phone to make calls?
Yup.
No access to the device? i.e. permissions problem?
sudoit from the command line?
Nothing like that. I can’t launch it with sudo because Gtk-ERROR **: 22:34:41.118: Can't create a GtkStyleContext without a display connection.
Yup, plain Crimson with no extra repos or backports.
sudo mb818-fw-check:
chat: Apr 01 22:35:33 +BMSWVER: M100E_YCSN0_1.0.0_220926,YCSN0_M100E_1ACD_B325_V1.0.0.2_20220930,M100E_1.0.4_200715
M100E_YCSN0_1.0.0_220926
YCSN0_M100E_1ACD_B325_V1.0.0.2_20220930
M100E_1.0.4_200715
I suppose that gives me my version. But launching bm818-tool from the command line still tells me it “Failed to get Modem FW version” and “Can’t get LTE status”. Although I think the latter might be expected if I’m not on a call.
The output in my terminal when running is:
trying port /dev/ttyUSB3
Can't get CBS status None
Must my user be in any specific group? I’m not using the standard purism user and had to manually add the feedbackd group once to get that working. Random thought.
1 Like
You can’t launch bm818-tool from command line without elevating its privileges, so that’s fully expected. There’s a launcher icon that you can use which will work correctly.
1 Like