Librem5 issueshttps://source.puri.sm/groups/Librem5/-/issues2019-10-11T12:55:15Zhttps://source.puri.sm/Librem5/virtboard/-/issues/17Labels change when keyboard is clicked2019-10-11T12:55:15ZDorota CzaplejewiczLabels change when keyboard is clickedSteps to reproduce:
0. Use Polish layout in gsettings
1. Fire up rootston
2. Fire up a *non-text-input* application (`yad --entry` works with GTK<3.24)
3. Fire up virtboard
4. Type a number
Expected result:
- letter is entered
Actual...Steps to reproduce:
0. Use Polish layout in gsettings
1. Fire up rootston
2. Fire up a *non-text-input* application (`yad --entry` works with GTK<3.24)
3. Fire up virtboard
4. Type a number
Expected result:
- letter is entered
Actual result:
- letter is entered
- labels on keys momentarily changehttps://source.puri.sm/Librem5/image-builder/-/issues/21vmdebootstrap leaves loop0p1 around2019-10-11T12:51:50ZGuido Gunthervmdebootstrap leaves loop0p1 aroundOn arm01 *loop0p1* is left around after an image build so that other builds afterwards fail like
```
device-mapper: reload ioctl on loop0p2p1 failed: Device or resource busy
create/reload failed on loop0p2p1
```
A `dmsetup remove loop0...On arm01 *loop0p1* is left around after an image build so that other builds afterwards fail like
```
device-mapper: reload ioctl on loop0p2p1 failed: Device or resource busy
create/reload failed on loop0p2p1
```
A `dmsetup remove loop0p1` works around this (which we currently do in */etc/cron.hourly/work-around-vmdebootstrap*).https://source.puri.sm/Librem5/OS-issues/-/issues/14Mac Address not stable2019-03-08T11:10:24ZGuido GuntherMac Address not stableThe mac changes on every boot it should be stable.The mac changes on every boot it should be stable.https://source.puri.sm/Librem5/OS-issues/-/issues/15USB Serial doesn't allow root login2019-01-05T09:36:02ZDorota CzaplejewiczUSB Serial doesn't allow root loginRoot cause: `/etc/securetty` doesn't list `ttyGS0`. Not exactly sure how to go about that, but:
- maybe `g_serial` has a parameter to change device name and we can change it to something allowed
- more likely, change `/etc/securetty` co...Root cause: `/etc/securetty` doesn't list `ttyGS0`. Not exactly sure how to go about that, but:
- maybe `g_serial` has a parameter to change device name and we can change it to something allowed
- more likely, change `/etc/securetty` contents in an appropriate wayhttps://source.puri.sm/Librem5/dvk-mx8m-bsb/-/issues/2SGTL5000's LINEOUT_R Used as Mono2019-02-01T05:07:33ZEric KuzmenkoSGTL5000's LINEOUT_R Used as MonoThe SGTL5000's right channel is used to drive the earpiece speaker, this was noticed after the prototypes were produced but was intentionally not changed in the final design so as to keep software compatibility between the prototypes and...The SGTL5000's right channel is used to drive the earpiece speaker, this was noticed after the prototypes were produced but was intentionally not changed in the final design so as to keep software compatibility between the prototypes and final units.
This implies that the software driver needs route all mono audio to the right channel, and keep the left channel muted.
The audio codec's MONOMODE_DAC and DAC_MUTE_LEFT should be set HIGH in order to use the right channel as a mono output. See its datasheet here: https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdfhttps://source.puri.sm/Librem5/dvk-mx8m-bsb/-/issues/3Swap Hierarchical Labels BT_PCM_SYNC and BT_PCM_CLK2019-03-06T21:51:05ZEric KuzmenkoSwap Hierarchical Labels BT_PCM_SYNC and BT_PCM_CLKThe WLAN sheet box's PCM hierarchical labels originally correctly corresponded to the top-level sheet's local labels, but they were changed on commit a961a248, specifically M2_PCM_CLK and M2_PCM_SYNC became BT_PCM_SYNC and BT_PCM_CLK res...The WLAN sheet box's PCM hierarchical labels originally correctly corresponded to the top-level sheet's local labels, but they were changed on commit a961a248, specifically M2_PCM_CLK and M2_PCM_SYNC became BT_PCM_SYNC and BT_PCM_CLK respectively, while keeping the top-level sheet's local labels the same. Doing so caused what is now SAI5_TX_BCLK and SAI5_TX_SYNC to mistakenly become swapped. Unfortunately, this error was not caught during the review process, nor the prototype phase since the Bluetooth's audio interface wasn't tested.
Here is where the swap was accidentally made: https://source.puri.sm/Librem5/dvk-mx8m-bsb/commit/a961a248c5dcf185e2b4189e673b4b3d558ccd1c#0846d3b85efdf198910b1c733a6410212be4caff_2781_2767 (scroll down to see the highlighted line 2767 in dvk-mx8m-bsb.sch).
Even though the top-level sheet's local labels were assigned/renamed to SAI5 on commit 1df2cd4d, the mistake was unfortunately not caught then.
With these two swapped, the Bluetooth's PCM audio interface likely won't work unless the M2_PCM_CLK and M2_PCM_SYNC traces are cut and swapped on the board.
RedPine mentioned that the I2S/PCM interface is not supported by their firmware which we are using, so this issue may not matter anyway.Eric KuzmenkoEric Kuzmenkohttps://source.puri.sm/Librem5/dvk-mx8m-bsb/-/issues/4USB-C 2.0 Interface Only Works In One Orientation For Some Units2019-10-23T07:54:48ZGuido GuntherUSB-C 2.0 Interface Only Works In One Orientation For Some UnitsI tried to flash a devkit (devkit A) with uuu as of mfgtools@c81a5dab6f590dc95aed26f0663bf7d89e75defb but the uuu script
```
uuu_version 1.0.1
SDP: boot -f u-boot-devkit-recovery.imx
SDPU: delay 1000
SDPU: write -f u-boot-devkit-recov...I tried to flash a devkit (devkit A) with uuu as of mfgtools@c81a5dab6f590dc95aed26f0663bf7d89e75defb but the uuu script
```
uuu_version 1.0.1
SDP: boot -f u-boot-devkit-recovery.imx
SDPU: delay 1000
SDPU: write -f u-boot-devkit-recovery.imx -offset 0x57c00
SDPU: jump
SDPS: boot -f u-boot-devkit-recovery.imx
SDPU: delay 1000
FB: ucmd setenv fastboot_dev mmc
FB: ucmd setenv mmcdev 0
FB: flash -raw2sparse all devkit.img
FB: Done
```
would stop at
```
1:1 1/ 1 [============100%============] SDP: boot -f u-boot-devkit-recovery.imx`
```
The serial console output showed
```
SDP: initialize...
```
I then tried another board (devkit B) and flashing worked right away. I then retried devkit A again and it seem that it matters which way of the USB-C plug is up. One way works, the other doesn't. That's 100% reproducible here atm.https://source.puri.sm/Librem5/OS-issues/-/issues/137Support Google Fi SMS2020-02-28T22:18:28ZKyle RankinSupport Google Fi SMS# Version info
* chatty 0.1.3
* Tmobile (Google Fi) cellular provider
* Chestnut phone
# Problem
When receiving incoming SMS messages from Google Fi, they are always followed by 16 characters of gibbering starting with a ~ symbols (see ...# Version info
* chatty 0.1.3
* Tmobile (Google Fi) cellular provider
* Chestnut phone
# Problem
When receiving incoming SMS messages from Google Fi, they are always followed by 16 characters of gibbering starting with a ~ symbols (see image)
![IMG_20200107_111348](/uploads/f6d9df906486a3597879965bf7b2a9fe/IMG_20200107_111348.jpg)
So far this has occurred in all of my incoming SMS messages from different senders, some in my contact list and some not. This is apparently a known issue when using Google Fi SIMs on an unsupported phone if you can't run the Fi app to "activate" it: https://www.reddit.com/r/ProjectFi/comments/5k3h9t/texts_ending_with_tilde_and_random_letters/
For what it's worth I've noticed that the text all follows the same pattern:
```
/[~][A-Za-z0-9]{14}[g]$/
```
While this is an issue specific to SMS messages, I have moved it from Chatty to OS-issues because Chatty is simply reading SMS as they come in without having knowledge of specific cellphone providers. Likely any provider-specific information (and filtering) should occur at a lower level within the OS.
# Expected Behavior
Incoming SMSes only have the text the sender typed without extra datahttps://source.puri.sm/Librem5/linux/-/issues/259CONFIG_COMMON_CLK_BD718XX=y hangs at boot2021-01-26T05:50:33ZSebastian KrzyszkowiakCONFIG_COMMON_CLK_BD718XX=y hangs at bootWhen `CONFIG_COMMON_CLK_BD718XX` is set to be built-in, the kernel hangs before handing the control over to the init process. Tested on 5.9/imx8-current-librem5.When `CONFIG_COMMON_CLK_BD718XX` is set to be built-in, the kernel hangs before handing the control over to the init process. Tested on 5.9/imx8-current-librem5.https://source.puri.sm/Librem5/arm-trusted-firmware/-/issues/2Needs a version in byzatium2021-01-27T14:46:07ZGuido GuntherNeeds a version in byzatiumOtherwise we're not self hosting - debian ships a newer ATF that conflicts with our 2.0 version.Otherwise we're not self hosting - debian ships a newer ATF that conflicts with our 2.0 version.https://source.puri.sm/Librem5/librem5-base/-/issues/545.16: sysctl nob for wireless roam2021-11-11T17:04:07ZGuido Gunther5.16: sysctl nob for wireless roamWe can set `arp_evict_nocarrier` from 5.16 on:
Details:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcdb44d08a95We can set `arp_evict_nocarrier` from 5.16 on:
Details:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcdb44d08a95https://source.puri.sm/Librem5/linux/-/issues/439TPS65982: IRQ storm when connecting a passive audio adapter2022-08-04T13:34:31ZSebastian KrzyszkowiakTPS65982: IRQ storm when connecting a passive audio adapterA minor issue since passive audio adapters are not supposed to work with Librem 5, but it would probably be good to not fire an interrupt storm when one is plugged in:
```
irq/80-0-003f-211 [001] ..... 41490.085949: tps6598x_irq:...A minor issue since passive audio adapters are not supposed to work with Librem 5, but it would probably be good to not fire an interrupt storm when one is plugged in:
```
irq/80-0-003f-211 [001] ..... 41490.085949: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.090578: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.092264: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.160810: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.162370: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.163128: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.265667: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.266829: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.267678: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.370424: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.371677: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.372481: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.475738: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.476925: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.477642: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.580054: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.581186: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.582481: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.684867: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.686187: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.687055: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.789700: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.790888: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
irq/80-0-003f-211 [001] ..... 41490.791664: tps6598x_power_status: conn: 0, pwr-role: source, typec: usb, bc: sdp
irq/80-0-003f-211 [001] ..... 41490.894539: tps6598x_irq: event1=PLUG_EVENT|PP_SWITCH_CHANGED|USER_VID_ALT_MODE_EXIT, event2=
irq/80-0-003f-211 [001] ..... 41490.895565: tps6598x_status: conn: no-conn, pp_5v0: off, pp_hv: off, pp_ext: off, pp_cable: off, pwr-src: vin-3p3, vbus: vSafe0V, usb-host: no, legacy: no, flags: PORTROLE|DATAROLE
```
```
[41490.097215] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.097540] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.134357] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.134856] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.166010] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.166628] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.172695] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.172927] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.254780] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.255161] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.281343] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.282196] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.374285] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.374672] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.378956] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.379121] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.381035] bq25890-charger 3-006a: Upstream supply changed: 0.
[41490.381055] bq25890-charger 3-006a: Disabling OTG_EN pin
[41490.396330] bq25890-charger 3-006a: Upstream supply changed: 0.
```