Yes, it connects with the other mobile and says on both devices connected. It paired already yesterday, so they know each other. A new device gets paired and connected fine.
Then perhaps it is working as it should i.e. discovery is an ongoing (never finishing) process.
According to https://puri.sm/posts/hard-not-soft-kill-switches/ it is actually the radio that gets disabled, not the power that gets cut:
With the HKS in the +3.3 Volt position, pins 54 and 56 in the M.2 NGFF connector will receive a HIGH voltage, and the radios on the WiFi card will be turned OFF. With the HKS in the Ground (GND) position, pins 54 and 56 will receive a LOW voltage, and the radios will be turned ON.
Does the WIFI/BT HKS work in a different way on the Librem 5?
Does the L5, i.e. Debian, writes somewhere something like /var/log/syslog or /var/log/messages?
I catched the new lines produced by dmesg when I go to Systems Settings --> Bluetooth and the Wifi stops working:
[ 59.400703] redpine_91x: EAPOL 4 confirm
[ 59.507251] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 251.077616] edt_ft5x06 2-0038: Unable to fetch data, error: -6
now we go the ...Bluetooth
[ 1888.269822] redpine_91x: RSI `hci0' flush
[ 1888.269858] redpine_91x: RSI HCI DEVICE "hci0" closed
[ 1888.269864] redpine_91x: rsi_hci_close: device `hci0' not running
Does this ring someone’s bell?
I believe so. You can study the schematics for yourself if you are an electrical engineer. I’m not! @amosbatto ?
That blog post is 6 years old and is clearly talking about laptops, but for the Librem 5 the proof of the pudding is in the schematics.
I think not by default but see: How to get Lirem 5 kernel log in /var/log/syslog in addition to systemd journal?
I installed rsyslog and have here the part of the log when BT is switched to ON in System Settings --> Buetooth: http://www.unixarea.de/syslog-bt-switched-on.txt
As you can see gnome-bluetooth 3.34 still there on Byzantium, this part make the BT unsync.
Purism devs it already tracking this bug.
Where can I see what? I don’t understand what you want to express…
Oh I did not know that -or I missed that in the conversations. I am also on amber and I never had a firmware directory as well. But since doing those commands I have not had any problems. Also running the mode on 13 as opposed to 5 in the /etc/modprobe.d/librem5-devkit.conf That is interesting though? I though you also had similar issues for some reason? Thanks for the clarification. Also -thanks for using the proof of the pudding saying properly. So many say “The proof is in the pudding” and I don’t know why. Either way thanks -hope this gets figured out.
1 Like
In https://source.puri.sm/Librem5/linux-next/-/issues/358#note_174164 some Dev from Purism stated that it is an issue with the firmware used in byzantium. So all at this point will have the same problem. I will not downgrade the firmware, because I use BT not very much and can wait until the issue get solved.
There is no “firmware used in byzantium”, the firmware is read from flash on the WiFi module (unless you put it manually into /lib/firmware).
The fw is written into the the flash if the CRC of the flash doesn’t match with the file in /lib/firmware. This was meant by the “firmware used in byzantium”. See also: https://source.puri.sm/Librem5/linux-next/-/issues/358#note_174200
Yes, but there’s no such file anywhere in byzantium (or any other part of PureOS).
See https://source.puri.sm/Librem5/redpine-firmware-nonfree
This is what I’m told to flash with byzantium; see also
https://source.puri.sm/Librem5/linux-next/-/issues/358#note_174200
I’m perfectly aware of what we have written there 
What I meant is that there’s no such thing as “firmware in byzantium”, since used firmware will depend on when the phone was shipped and whether the module was reflashed by the user afterwards. Which means that it’s not true that everyone will have this problem, or that it’s an issue specific to byzantium. In fact, the same reflash instructions will work on amber-phone as well, since the latest kernels are still being regularly backported there.
When it comes to Bluetooth on Redpine cards, it generally works on both amber-phone and byzantium, but there are several distinct issues at play that can affect different sets of people, with bad firmware being one of them.
1 Like
Getting back to the original post, I will report to you my experience with customer service. I don’t know if my starting issue was exactly the same as yours, but it’s probably worth checking out the solution they gave me.
-
When I start my L5 for the first time I checked BT, and it says to “No Bluetooth Found Plug in a dongle to use Bluetooth” implying that there was no BT hardware detected. I actually attached the USB A BT dongle I use on my Librem 13, but it didn’t work on the L5 with a USB A to C adapter.
-
I wrote tech support, and within a few hours, @mladen got back to me with some command lines to implement a patch by @angus.ainslie. After running the commands, I rebooted the phone, and I had bluetooth. Maybe Mladen and/or Angus could comment on this and let us know if it’s a general fix? Like @irvinewade, I can use my BT keyboard to browse the internet, install applications from the store, install applications from command line, so there doesn’t seem to be any WiFi interference.
-
Like mentioned here, if I turn off BT with the hardware switch, it comes back when I turn it back on, but if I toggle it off in System, it won’t come back on. I have found that just restarting phosh (as opposed to a full reboot) restores it. That can be done in command line with “sudo systemctl restart phosh”
1 Like
@dos can you paste here the syntax to burn the firm into redpine card please… just for the record for peoples not understanding…
You just place the firmware file in /lib/firmware and reboot. When the driver detects that the firmware on flash differs from the provided file, it reflashes it.
2 Likes
Wow. But there is a script to burn the firm into redpine manually, just for to know it??
I remember i saw a script somewhere to programing the redpine card with a new firm…manually…