linux issueshttps://source.puri.sm/Librem5/linux/-/issues2019-12-18T09:23:27Zhttps://source.puri.sm/Librem5/linux/-/issues/122GNSS UART Interface No Longer Working2019-12-18T09:23:27ZEric KuzmenkoGNSS UART Interface No Longer WorkingI tested using `screen` to observe the data coming from the GNSS's UART interface on the recent "linux-image-5.3.0-librem5-dirty_5.3.0-librem5-dirty-492_arm64" kernel but I got nothing. So I flashed a really old image from back in early ...I tested using `screen` to observe the data coming from the GNSS's UART interface on the recent "linux-image-5.3.0-librem5-dirty_5.3.0-librem5-dirty-492_arm64" kernel but I got nothing. So I flashed a really old image from back in early September and verified that it's not a hardware-related issue. So something along the way has broken.
Here's a snippet of what I get using the old image, the new image/kernel yield nothing (omitting personal info):
```
purism@pureos:~$ uname -a
Linux pureos 5.2.0-g46caa519a #1 SMP PREEMPT Fri Sep 6 07:11:29 PDT 2019 aarch64 GNU/Linux
purism@pureos:~$ sudo screen /dev/ttymxc1 9600
$GP,,0.0,030917,,,N*7C
...
...
...
```https://source.puri.sm/Librem5/linux/-/issues/121Need a minimal DT for linux-next2019-12-16T16:40:10ZGuido GuntherNeed a minimal DT for linux-nextA minimal DT for the Libre5 that works on mainline linux-next would be great to test upstream submissions that affect the phone only. @martin.kepplinger since you're using linux-next as well, did you look at that already? (it would also ...A minimal DT for the Libre5 that works on mainline linux-next would be great to test upstream submissions that affect the phone only. @martin.kepplinger since you're using linux-next as well, did you look at that already? (it would also be a good seed for initial mainline submission).https://source.puri.sm/Librem5/linux/-/issues/120Shutting Down and Power Button Behavior2020-11-09T10:44:27ZEric KuzmenkoShutting Down and Power Button BehaviorIn order for the phone to behave in a predictable manner when turning off like other smartphones, we need to power off the device in a proper manner/sequence.
The BQ25895 charge controller is able to enter a state known as "ship mode" w...In order for the phone to behave in a predictable manner when turning off like other smartphones, we need to power off the device in a proper manner/sequence.
The BQ25895 charge controller is able to enter a state known as "ship mode" where the battery is not powering the system at all; the charge controller's SYS output voltage is disabled. This state is entered by setting bit 5 of register 0x09 (BATFET_DIS) in the BQ25895 to 1 (this can be tested by running `i2cset -f -y 3 0x6a 0x09 0x64`):
![BATFET_DIS](/uploads/7124d095da0fa9c61a1df78d1fc7f983/BATFET_DIS.png)
In order to prevent the i.MX 8M from bringing the PMIC's PMIC_ON_REQ pin LOW and having the PMIC turn off the SoC when the power button is being pressed, we need to set the BUTTON_PRESS_TIME bits to being 11:
![BUTTON_PRESS_TIME](/uploads/cb60860fd2f7fadbc096ac86537df624/BUTTON_PRESS_TIME.png)
By doing this, we give ourselves the time we need to properly shut down the device and instead use the charge controller's "ship mode" as the method to completely turn off the device when powered from a battery. If the phone, when powered from just the battery, is instead turned off via the PMIC, then connecting a USB VBUS source would not cause the device to turn on (e.g. presenting some "charging" indication on the screen).
We have tested setting BUTTON_PRESS_TIME to 11 by giving U-Boot the command `mw 0x30370038 0x00030020`, this was validated and gave us the expected behavior (pressing and holding the power button didn't cause the PMIC to turn off).
What we want to do instead is establish a time window for how long the user should press the power button in order for the phone to shut down without the use of a dialog. This time window needs to be longer than what will be used to bring up a prompt asking the user if they want to shut down their device, reboot, or whatever else (e.g. 2 seconds for a dialog, handled at a higher level).
The power button is also connected to the QON# pin of the BQ25895 charge controller. When the button is pressed anywhere from 10-18 seconds the charge controller will hard reset the whole board by disabling its SYS output voltage for roughly 500ms. Unfortunately, the BQ25895 has some conflicting documentation when it comes to how long the QON# pin needs to be held LOW for this reset condition to occur, in one instance in the datasheet it says 10 seconds and in the Timing Requirements section they say anywhere from 12 to 18 seconds:
![Screenshot_from_2019-09-25_14-28-50](/uploads/d15525ad60a3db3fe0f23ec8c417ee17/Screenshot_from_2019-09-25_14-28-50.png)
![Screenshot_from_2019-09-25_14-36-02](/uploads/bb61e3fbec6f1d0ceef93e2db2f82e3f/Screenshot_from_2019-09-25_14-36-02.png)
After some brief testing we did, we found that pressing the button for roughly 11 seconds caused the charge controller to reset.
This QON# function of the charge controller is desirable in case the user needs to forcefully hard reset the device for whatever reason (without taking the back cover off). This roughly 10 seconds therefore defines an absolute upper limit for how long the button can be pressed before we initiate a software-controlled power-off sequence.
I suggest using a marker of around **6 seconds** of the button being pressed for the OS to initiate shutting down. At the very end of the sequence, we would set bit 5 of register 0x09 in the charge controller to 1, this will completely turn off the device if it is solely powered from a battery. Once the user plugs in a USB VBUS source the charge controller will automatically turn on again and allow the battery to resume powering the system. When in "ship mode" the power button can also be pressed for 1 to 2.25 seconds to turn the charge controller back on. This same method of setting BATFET_DIS to 1, when powered from only a battery, at the very end should also be used if the user selects to turn off their device from a software dialog method.
If needed, the BQ25895 charge controller has the optional ability to turn off the power that the battery supplies to the board after a hard set delay of 10 to 15 seconds (timer is not programmable). To achieve this, we would simply need to set the charge controller's bit 3 of register 0x09 (BATFET_DLY) to 1:
![BATFET_DLY](/uploads/921e5a91e619b57dbb7935e71b907d11/BATFET_DLY.png)
However, there is one caveat to this. When we are shutting down the phone while there is a USB VBUS source present we will have to shut down the device in a different manner, meaning we should not use BATFET_DIS when there is a USB VBUS source present. Instead, when a USB VBUS source is present, we would ideally restart the device and enter U-Boot in some charging state. If this cannot be achieved in the short-term then we can instead turn off the PMIC. The reason for this is because the BQ25895 charge controller will not completely turn off with VBUS present, it will turn off completely _only_ when powered from just the battery.
Obviously, with the display on, a button press of roughly 750ms or less should turn the display off; and if the display is already off then pressing and holding the button should cause the display to come on (effectively regardless of how long you press, then a dialog and shutdown sequence can occur after holding it for an extended period, as described).
All of this can and probably should be tested on the dev kits as well. The same behavior can be accomplished on the dev kit.https://source.puri.sm/Librem5/linux/-/issues/119Does not notice when a modem goes away2020-09-15T15:51:43ZGuido GuntherDoes not notice when a modem goes awaywhen toggling of the kill switch the modem stays visible in `ModemManager`:
```sh
$ mmcli -L
/org/freedesktop/ModemManager1/Modem/1 [manufacturer unknown] model unknown
```
when doing a `mmcli -r -m 0` it correctly vanishes. I don't th...when toggling of the kill switch the modem stays visible in `ModemManager`:
```sh
$ mmcli -L
/org/freedesktop/ModemManager1/Modem/1 [manufacturer unknown] model unknown
```
when doing a `mmcli -r -m 0` it correctly vanishes. I don't think MM has a way to correctly notice this except for polling (and we certainly don't want it to wake up a suspended modem) so i'm not yet sure what's the best thing to do here.https://source.puri.sm/Librem5/linux/-/issues/118Brightness slider seems linear2019-12-21T18:17:46ZDorota CzaplejewiczBrightness slider seems linearThe brightness slider's halfway setting is not that different from its full setting, and the lower part of the range makes little differences enormous.
There needs to be a mapping somewhere in the pipeline to make the slider-power relat...The brightness slider's halfway setting is not that different from its full setting, and the lower part of the range makes little differences enormous.
There needs to be a mapping somewhere in the pipeline to make the slider-power relationship closer to how humans perceive brightness.https://source.puri.sm/Librem5/linux/-/issues/117g_multi warning on unload2021-09-07T16:32:53ZDorota Czaplejewiczg_multi warning on unload`g_multi` gives a warning in `composite_unbind`. This might be related to other weird behaviour relating to USB interfaces, like the failure to modprobe `g_mass_storage` afterwards.
Main warning
```
purism@pureos:~$ sudo rmmod g_multi
...`g_multi` gives a warning in `composite_unbind`. This might be related to other weird behaviour relating to USB interfaces, like the failure to modprobe `g_mass_storage` afterwards.
Main warning
```
purism@pureos:~$ sudo rmmod g_multi
purism@pureos:~$ dmesg | tail -n 55
[ 119.022298] etnaviv-gpu 38000000.gpu: genpd_runtime_resume()
[ 119.271498] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
[ 119.501821] etnaviv-gpu 38000000.gpu: genpd_runtime_resume()
[ 119.751267] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
[ 125.021949] etnaviv-gpu 38000000.gpu: genpd_runtime_resume()
[ 125.273166] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
[ 139.445443] etnaviv-gpu 38000000.gpu: genpd_runtime_resume()
[ 139.694193] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
[ 143.269795] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
[ 148.932523] etnaviv-gpu 38000000.gpu: genpd_runtime_resume()
[ 149.269298] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
[ 154.665207] ------------[ cut here ]------------
[ 154.665307] WARNING: CPU: 1 PID: 1047 at drivers/usb/gadget/composite.c:2010 __composite_unbind+0x4c/0xe8 [libcomposite]
[ 154.665311] Modules linked in: usb_f_acm u_serial usb_f_rndis g_multi(-) usb_f_mass_storage u_ether libcomposite aes_ce_ccm rfcomm bnep redpine_sdio redpine_91x aes_ce_blk crypto_simd bluetooth mac80211 crct10dif_ce ghash_ce cfg80211 sha2_ce sha1_ce rfkill st_lsm6dsx_spi pwm_vibra snd_soc_gtm601 st_magn_spi st_sensors_spi mousedev bq25890_charger snd_soc_wm8962 st_magn_i2c vcnl4000 st_magn st_sensors_i2c st_lsm6dsx_i2c st_sensors st_lsm6dsx industrialio_triggered_buffer kfifo_buf tps6598x typec m25p80 spi_nor mtd snvs_pwrkey imx2_wdt imx_sdma virt_dma watchdog ip_tables x_tables ipv6 nf_defrag_ipv6 uas usb_storage xhci_plat_hcd xhci_hcd usbcore dwc3 ulpi udc_core usb_common phy_fsl_imx8mq_usb
[ 154.665435] CPU: 1 PID: 1047 Comm: rmmod Not tainted 5.3.0-librem5-h1 #1
[ 154.665439] Hardware name: Purism Librem 5 (DT)
[ 154.665445] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 154.665462] pc : __composite_unbind+0x4c/0xe8 [libcomposite]
[ 154.665479] lr : __composite_unbind+0x4c/0xe8 [libcomposite]
[ 154.665483] sp : ffff80007a60fd10
[ 154.665486] x29: ffff80007a60fd10 x28: ffff80007bb30dc0
[ 154.665493] x27: 0000000000000000 x26: 0000000000000000
[ 154.665500] x25: 0000000056000000 x24: 0000000000000015
[ 154.665507] x23: 0000000000000001 x22: ffff000008d4e0e0
[ 154.665514] x21: ffff8000a47913b8 x20: ffff8000a4787810
[ 154.665521] x19: ffff8000a670ee00 x18: 0000000000000000
[ 154.665528] x17: 0000000000000000 x16: 0000000000000000
[ 154.665535] x15: ffffffffffffffff x14: 5355007465676461
[ 154.665542] x13: 000000000000fb34 x12: ffff000010fb2000
[ 154.665549] x11: ffff000010e98000 x10: ffff000010fb26f0
[ 154.665555] x9 : 0000000000000000 x8 : 0000000000000004
[ 154.665562] x7 : 000000000000104a x6 : ffff8000bf95aad8
[ 154.665569] x5 : ffff8000bf95aad8 x4 : 0000000000000000
[ 154.665575] x3 : 0000000000000001 x2 : d6d2cfd9f0666900
[ 154.665582] x1 : 0000000000000000 x0 : 0000000000000024
[ 154.665588] Call trace:
[ 154.665606] __composite_unbind+0x4c/0xe8 [libcomposite]
[ 154.665621] composite_unbind+0x24/0x30 [libcomposite]
[ 154.665643] usb_gadget_remove_driver+0x40/0xa0 [udc_core]
[ 154.665659] usb_gadget_unregister_driver+0xc4/0xf8 [udc_core]
[ 154.665675] usb_composite_unregister+0x20/0x30 [libcomposite]
[ 154.665687] multi_driver_exit+0x18/0xb10 [g_multi]
[ 154.665699] __arm64_sys_delete_module+0x184/0x240
[ 154.665710] el0_svc_common.constprop.0+0x98/0x170
[ 154.665716] el0_svc_handler+0x2c/0x38
[ 154.665723] el0_svc+0x8/0xc
[ 154.665728] ---[ end trace a0aeb8ec3385f501 ]---
[ 154.668478] device: 'lun0': device_unregister
[ 154.668577] PM: Removing info for No Bus:lun0
[ 154.669024] device: 'ttyGS0': device_unregister
[ 154.669187] PM: Removing info for No Bus:ttyGS0
[ 154.671785] printk: console [ttyGS-1] disabled
[ 154.682692] PM: Removing info for No Bus:usb0
[ 155.018314] etnaviv-gpu 38000000.gpu: genpd_runtime_resume()
[ 155.268970] etnaviv-gpu 38000000.gpu: genpd_runtime_suspend()
```
Mass storage failure:
```
purism@pureos:~$ sudo modprobe g_mass_storage file=/var/lib/mass_storage_dummy stall=0
```
```
[ 458.299377] Mass Storage Function, version: 2009/09/11
[ 458.299392] LUN: removable file: (no medium)
[ 458.299439] device: 'lun0': device_add
[ 458.299487] PM: Adding info for No Bus:lun0
[ 458.299523] LUN: file: /var/lib/mass_storage_dummy
[ 458.299532] Number of LUNs=1
[ 458.299773] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[ 458.299782] g_mass_storage gadget: userspace failed to provide iSerialNumber
[ 458.299790] g_mass_storage gadget: g_mass_storage ready
[ 458.302173] dwc3 38100000.usb: failed to enable ep0in
```
Nothing in lsusb, but rmmod works.https://source.puri.sm/Librem5/linux/-/issues/115Clock doesn't keep time across power-down and later power-up2020-01-03T03:47:23ZTodd WeaverClock doesn't keep time across power-down and later power-up# What problem did you encounter
The clock does not keep time current upon power-up.
## What is the current behaviour?
Power down at 11:03am; wait 10 minutes; power-up it shows 11:03am (and will until a network connection updates it)....# What problem did you encounter
The clock does not keep time current upon power-up.
## What is the current behaviour?
Power down at 11:03am; wait 10 minutes; power-up it shows 11:03am (and will until a network connection updates it).
## What is the expected behaviour?
Hardware clock is set, and is used to show current time.
## How to reproduce
1. Power down; note actual time.
2. Wait a few minutes.
3. Power up; note it was the same time as power-down.
```
purism@pureos:~$ dpkg -s phosh
Package: phosh
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 804
Maintainer: Guido Günther <agx@sigxcpu.org>
Architecture: arm64
Version: 0.1.4
Provides: notification-daemon, polkit-1-auth-agent
Depends: dconf-gsettings-backend | gsettings-backend, libc6 (>= 2.17), libcairo2 (>= 1.2.4), libgcr-base-3-1 (>= 3.8.0), libgcr-ui-3-1 (>= 3.8.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.53.2), libgnome-desktop-3-17 (>= 3.17.92), libgtk-3-0 (>= 3.21.5), libhandy-0.0-0 (>= 0.0.11), libnm0 (>= 1.0.0), libpam0g (>= 0.99.7.1), libpango-1.0-0 (>= 1.22.0), libpangocairo-1.0-0 (>= 1.14.0), libpolkit-agent-1-0 (>= 0.99), libpolkit-gobject-1-0 (>= 0.94), libpulse-mainloop-glib0 (>= 0.99.1), libpulse0 (>= 0.99.1), libsecret-1-0 (>= 0.7), libupower-glib3 (>= 0.99.4-3~), libwayland-client0 (>= 1.9.91), fonts-lato
Recommends: gnome-session, phoc
Description: Pure Wayland shell for mobile devices
Phosh is a simple shell for Wayland compositors speaking the layer-surface
protocol. It currently supports
.
* a lockscreen
* brightness control and nighlight
* the gcr system-prompter interface
* acting as a polkit auth agent
* enough of org.gnome.Mutter.DisplayConfig to make gnome-settings-daemon happy
* a homebutton that toggles a simple favorites menu
* status icons for battery, wwan and wifi
.
If you're not working on a Wayland compositor then this package is likely not
very useful for you.
Homepage: https://source.puri.sm/Librem5/phosh
purism@pureos:~$ uname -a
Linux pureos 5.3.0-librem5-g24b9d535b #1 SMP PREEMPT Fri Nov 29 13:19:16 PST 2019 aarch64 GNU/Linux
```
# What hardware are you running phosh on?
- Librem 5 Birchhttps://source.puri.sm/Librem5/linux/-/issues/114USB devices connected through a hub are not seen by the kernel on birch device2021-02-01T17:46:13ZBob HamUSB devices connected through a hub are not seen by the kernel on birch deviceI've tried to connect both a j5 Create JCA374 and Startech HB30C3AGEPD hub. One end of the thick type-C to type-C cable is plugged into the wall wart and the other end is plugged into the hub's power port. The hub's cable is plugged in...I've tried to connect both a j5 Create JCA374 and Startech HB30C3AGEPD hub. One end of the thick type-C to type-C cable is plugged into the wall wart and the other end is plugged into the hub's power port. The hub's cable is plugged into the type-C socket on the birch device.
In both cases, the battery icon in the status bar in phosh changes to the charging icon. However, no devices connected to the hub's ports are seen by the kernel. On the j5 Create hub, a mouse plugged in does not get powered up. On the Startech hub, the mouse is powered up (lights come on) but nothing is seen by the kernel. Devices on my KVM switch are not seen. None of the on-board devices in either hub, in particular the Ethernet NIC (the motivation for getting the USB port working), are seen by the kernel.
This is very similar to the behaviour described in linux-emcraft#41.https://source.puri.sm/Librem5/linux/-/issues/11350% packet loss to redpine module in birch device2021-02-26T02:09:04ZBob Ham50% packet loss to redpine module in birch deviceAfter connecting to an open wireless network and pinging the device from another host:
```
138 packets transmitted, 68 received, +4 errors, 50.7246% packet loss, time 1046ms
rtt min/avg/max/mdev = 1.327/17.759/872.240/104.491 ms, pipe 4...After connecting to an open wireless network and pinging the device from another host:
```
138 packets transmitted, 68 received, +4 errors, 50.7246% packet loss, time 1046ms
rtt min/avg/max/mdev = 1.327/17.759/872.240/104.491 ms, pipe 4
```
This unfortunately makes remote SSH unusable.Angus Ainslieangus.ainslie@puri.smAngus Ainslieangus.ainslie@puri.smhttps://source.puri.sm/Librem5/linux/-/issues/112system shutdown doesn't work on linux-next2019-12-04T17:43:19ZMartin Kepplingersystem shutdown doesn't work on linux-nextrunning: https://source.puri.sm/martin.kepplinger/linux-next/commits/next-20191203/librem5
the following, as can be seen, takes "forever" until the board shuts down:
```
[ OK ] Reached target Shutdown.
[ OK ] Reached target Final S...running: https://source.puri.sm/martin.kepplinger/linux-next/commits/next-20191203/librem5
the following, as can be seen, takes "forever" until the board shuts down:
```
[ OK ] Reached target Shutdown.
[ OK ] Reached target Final Step.
[ OK ] Started Power-Off.
[ OK ] Reached target Power-Off.
[ 285.640686] printk: systemd-shutdow: 52 output lines suppressed due to ratelimiting
[ 285.690524] systemd-shutdown[1]: Syncing filesystems and block devices.
[ 285.748499] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[ 285.765379] systemd-journald[279]: Received SIGTERM from PID 1 (systemd-shutdow).
[ 363.615165] INFO: task qmi-proxy:534 blocked for more than 120 seconds.
[ 363.621812] Not tainted 5.4.0-next-20191203-librem5-00005-g589ded0936f7 #14
[ 363.629337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 363.637388] qmi-proxy D 0 534 1 0x0000082d
[ 363.642891] Call trace:
[ 363.645359] __switch_to+0xc0/0x210
[ 363.648878] __schedule+0x288/0x5a8
[ 363.652380] schedule+0x48/0x100
[ 363.655627] wdm_flush+0xe8/0x128 [cdc_wdm]
[ 363.659840] filp_close+0x3c/0x90
[ 363.663170] put_files_struct+0x110/0x118
[ 363.667192] exit_files+0x44/0x58
[ 363.670512] do_exit+0x2a8/0x9f8
[ 363.673767] do_group_exit+0x48/0xa8
[ 363.677357] get_signal+0xec/0x828
[ 363.680772] do_notify_resume+0x30c/0x468
[ 363.684808] work_pending+0x8/0x14
[ 375.764807] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[ 375.778374] systemd-shutdown[1]: Sending SIGKILL to PID 534 (qmi-proxy).
[ 465.789929] systemd-shutdown[1]: Unmounting file systems.
[ 465.798316] [757]: Remounting '/' read-only in with options 'errors=remount-ro'.
[ 465.818562] [757]: Failed to remount '/' read-only: Device or resource busy
[ 465.826512] systemd-shutdown[1]: Not all file systems unmounted, 1 left.
[ 465.833311] systemd-shutdown[1]: Deactivating swaps.
[ 465.838471] systemd-shutdown[1]: All swaps deactivated.
[ 465.843737] systemd-shutdown[1]: Detaching loop devices.
[ 465.852775] systemd-shutdown[1]: All loop devices detached.
[ 465.858375] systemd-shutdown[1]: Detaching DM devices.
[ 465.863722] systemd-shutdown[1]: All DM devices detached.
[ 465.870004] systemd-shutdown[1]: Unmounting file systems.
[ 465.877736] [758]: Remounting '/' read-only in with options 'errors=remount-ro'.
[ 465.885347] [758]: Failed to remount '/' read-only: Device or resource busy
[ 465.893069] systemd-shutdown[1]: Not all file systems unmounted, 1 left.
[ 465.965278] reboot: Power down
```https://source.puri.sm/Librem5/linux/-/issues/111Cellular modem hardware kill switch activation2020-04-06T18:15:53ZTodd WeaverCellular modem hardware kill switch activationReproduction:
1. Cellular ON
2. Cellular turned OFF
3. Active connection still visible
![hks-cellular-not-triggered](/uploads/562801dda3ecf0735503d887f0a69b05/hks-cellular-not-triggered.webm)Reproduction:
1. Cellular ON
2. Cellular turned OFF
3. Active connection still visible
![hks-cellular-not-triggered](/uploads/562801dda3ecf0735503d887f0a69b05/hks-cellular-not-triggered.webm)Angus Ainslieangus.ainslie@puri.smAngus Ainslieangus.ainslie@puri.smhttps://source.puri.sm/Librem5/linux/-/issues/110Battery doesn't charge2021-02-03T13:57:04ZAngus Ainslieangus.ainslie@puri.smBattery doesn't chargeEN_SNK doesn't turn on the BQ25896EN_SNK doesn't turn on the BQ25896https://source.puri.sm/Librem5/linux/-/issues/109Power Button Not Turning Device Back On2020-03-23T17:46:30ZEric KuzmenkoPower Button Not Turning Device Back OnThe power button no longer turns the device back on after the PMIC is shut down (this worked on kernel 5.3.0-g8908ba21f).
I can tell that BUCK6 (VDD_3V3) is turning on when the power button is pressed because the red LED becomes illumin...The power button no longer turns the device back on after the PMIC is shut down (this worked on kernel 5.3.0-g8908ba21f).
I can tell that BUCK6 (VDD_3V3) is turning on when the power button is pressed because the red LED becomes illuminated after pressing it but it does not bring up the SoC. This means the issue is likely has something to do with how the PMIC is configured to handle the button press events in one of its I2C registers (e.g. something like C1_SHORT_PUSH_EN, C1_LONG_PUSH_EN, etc).
In Matrix @angus.ainslie mentioned this commit as a potential suspect (though he said reverting this would prevent the screen blanking function: https://source.puri.sm/Librem5/linux-next/commit/6f9f6dec1a089a4e31da464e289fb4c61f4e38e9
The workaround for this issue is to press and hold the power button for 15-18 seconds or so in order to cause the BQ25895 charge controller to hard-reset the entire device.Angus Ainslieangus.ainslie@puri.smAngus Ainslieangus.ainslie@puri.smhttps://source.puri.sm/Librem5/linux/-/issues/108drop our old etnaviv BO management2023-12-07T17:48:40ZGuido Guntherdrop our old etnaviv BO managementjust a single revert but i want to test it first und so i don't forgetjust a single revert but i want to test it first und so i don't forgethttps://source.puri.sm/Librem5/linux/-/issues/107build kernels with a stable kver2022-08-23T10:11:05ZGuido Guntherbuild kernels with a stable kvercurrently each build debian package has the git revision in the package name, that is great for development but for long term maintenance we want to creat specific packages like
`linux-image-5.4.0-1-librem5`
that is
`linux-iamge-<ups...currently each build debian package has the git revision in the package name, that is great for development but for long term maintenance we want to creat specific packages like
`linux-image-5.4.0-1-librem5`
that is
`linux-iamge-<upstream-version>-<abi-version>-librem5`
since we otherwise fill up user partitions quickly. These package will then be built with `deb-pkg` instead of `bindeb-pkg` so we can (hopefully) upload them to the pureos archive. the `amber-phone` images can then pull in these instaed of fetching latest, this also gives us a testing period in `amber-phone-staging`.
this involves several components, just starting here since we need to build such package first (i guess manually would even be o.k. as a start)https://source.puri.sm/Librem5/linux/-/issues/106Dev Kit VSYS_MIN Too Low2020-04-14T15:20:46ZEric KuzmenkoDev Kit VSYS_MIN Too LowVSYS_MIN on the Dev Kit device tree must be 3.5V or higher.VSYS_MIN on the Dev Kit device tree must be 3.5V or higher.Angus Ainslieangus.ainslie@puri.smAngus Ainslieangus.ainslie@puri.smhttps://source.puri.sm/Librem5/linux/-/issues/105review wakeup-source configs in devicetree2019-12-17T14:29:08ZMartin Kepplingerreview wakeup-source configs in devicetreeFeature: https://source.puri.sm/Librem5/use-cases/issues/75
sometimes the system would currently just resume after suspending. also, the console wakes it up.
review our dts for possible unnecessary wakeup sources for real-life workloads.Feature: https://source.puri.sm/Librem5/use-cases/issues/75
sometimes the system would currently just resume after suspending. also, the console wakes it up.
review our dts for possible unnecessary wakeup sources for real-life workloads.https://source.puri.sm/Librem5/linux/-/issues/104redpine module draws 130mA2020-10-16T07:56:11ZAngus Ainslieangus.ainslie@puri.smredpine module draws 130mAWhen connected but actively transmitting the redpine modules draws around 130mA.
How can we reduce the power consumption.When connected but actively transmitting the redpine modules draws around 130mA.
How can we reduce the power consumption.EvgAngus Ainslieangus.ainslie@puri.smAngus Ainslieangus.ainslie@puri.smhttps://source.puri.sm/Librem5/linux/-/issues/103Add batch names to device tree files names and board type2020-07-16T08:54:06ZGuido GuntherAdd batch names to device tree files names and board typeWith birch moving into place we should
- rename `arch/arm64/boot/dts/freescale/imx8mq-librem5.dts` to `arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi`
- add `arch/arm64/boot/dts/freescale/imx8mq-librem5-aspen.dts` and `arch/arm64/boo...With birch moving into place we should
- rename `arch/arm64/boot/dts/freescale/imx8mq-librem5.dts` to `arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi`
- add `arch/arm64/boot/dts/freescale/imx8mq-librem5-aspen.dts` and `arch/arm64/boot/dts/freescale/imx8mq-librem5-birch.dts`
- adjust the `model` in each dts accordingly, e.g. `Purism Librem 5 Aspen`
- adjust any further hardware chanegs
so we can distinguish the batches later on for updates from userspace and to identify customer devices and to e.g. pick the right uboot / dtb file when updating.https://source.puri.sm/Librem5/linux/-/issues/102redpine: use mainline driver2021-09-14T15:25:38ZGuido Guntherredpine: use mainline driverthis allows us to test e.g. linux-next which is otherwise hard since the vendor driver usually lacks behind.
nothing to act on right now, more a mental note, so i don't forget.this allows us to test e.g. linux-next which is otherwise hard since the vendor driver usually lacks behind.
nothing to act on right now, more a mental note, so i don't forget.