Wifi/bluetooth issues

Hardware Librem 5
61

For a test I would switch back to your old firmware (you find it here) and your old operation mode 13 in /etc/modprobe.d/librem5-devkit.conf. I assume that this is not a firmware problem.

1 Like
62

thanks pit i installed FW2.0.0.24 and bluetooth controller came right back.

63

Well for that good luck reason that the Firmware comes bundled with the Driver in the same version number folder, it is necessary to consider to MATCH the versions for optimal work. Braves people can burn a different firmware that works suboptimal with driver. MHO

64

In general, that is a very bad idea. In practice, if you keep your phone secure (i.e. donā€™t allow randoms to remote access it) then it doesnā€™t really matter.

I would expect that write access to the file is not required. I would expect that only root would need any access at all so maybe r--r----- but I have never changed the firmware on my WiFi card so take with a grain of salt. Maybe @dos can comment?

2 Likes
65

I got it now. It means that the firmware to burn is the same as the one that already exists in the controller.

1 Like
66

Thanks to this thread, I checked my bluetooth and it said that there is no bt hardware. After loading the new firmware, bt showed up. So far, both work simultaneously. Great! :slight_smile:

2 Likes
67

I tried to load them all and found that the version shown in dmesg is a total mess:

firmware
firmware874Ɨ132 31 KB

To keep an overview I symlinked on my L5 the version shown in dmesg (as ā€œFW Versionā€) to the file I downloaded from the repo.

The two files named as versions 1.2.1 , 1.2.20 make the module show in dmesg the exact same ā€œFW Versionā€ and itā€™s not possible to flash one on the other. To switch between them itā€™s necessary to flash a third firmware first and then flash the other of the two mentioned.

BTW: where do I find the original repos with the software? I looked around and found:

1 Like
68

Yeap all is mess : (

  • dmesg it has to be showing the combo-version of the firmware/driver, otherwise people will confused.
1 Like
69

This is it. We have renamed the module when importing to our tree.

1 Like
70

Just curious: do you remember the reason?

71

The reason is simple - thereā€™s already a module with this name in mainline kernel (an old driver that Redpine appears to have abandoned). Eventually we would like to drop the out-of-tree driver and use the mainline one, but it needs some improvements before this could happen.

2 Likes
73

Hi @angus.ainslie the new Redpine driver version GNU.LNX.OSD.2.5.1.11 it already shipped on current kernel version or it was stopped shipping to L5.?
kernel5.18.7: dmesg still is showing:
[ 465.897234] redpine_91x: Driver Version : GNU.LNX.OSD.2.0.0.0024

74

We canā€™t ship the new Silicon Labs (redpine) driver until they fix this

3 Likes
75

Thanks you angus.ainslie

1 Like
76

The last couple of weeks Iā€™ve had a problem with wifi tethering. Iā€™ve used it extensively for 6 months before that and have almost never had a problem, but probably after an upgrade a few weeks to a month ago I started getting restarts. I start tethering and after a while the wifi module seems to go offline since itā€™s not even displayed in the settings. After another while it comes back on again and I have to re-enable the tethering. Sometimes this happens several times in a row before it becomes ā€œstableā€. Did anyone else experience these problems? Could it be a glitch with my HKS?

1 Like
77

Commented on the issue and hit the thumbs-up button.

Maybe someone likes to join in up-voting or giving her/his point of view on this issue?

1 Like
78

Good initiative. Iā€™ve upvoted your comment now.

79

It looks to me like the issue is that the macros claim GPL compatibility, but the source code claims a different license which does not seem compatible with the GPL (see 5.1.3 of https://www.silabs.com/about-us/legal/master-software-license-agreement ).

The licensor of this software is Silicon Laboratories Inc. Your use of this
software is governed by the terms of Silicon Labs Master Software License
Agreement (MSLA) available at
www.silabs.com/about-us/legal/master-software-license-agreement. This
software is distributed to you in Source Code format and is governed by the
sections of the MSLA applicable to Source Code.

Angus Ainslie canā€™t simply change the copyright and license. The only thing he can do is change the macros which declare GPL compatibility ā€¦ so as to no longer assert compatibility. If that is done, AFAICT the only thing Purism can do is to revert to a previous GPL-compatible version (or convince Silicon Labs to change their license [fat chance!]. Edit: Given Section 7 of the MSLA it is possible that Silicon Labs might provide a clarification.).

And, for others who are not aware: Silicon Labs is the new owner of RedPine.

2 Likes
80

This all is more or LEDs obvious.

What I do not understand - if youā€™re right - why couldnā€™t SiliconLabs simply put the software again under GPL if they own all the rights? Could they theoretically or not? If not, why?

If their intended move has been to take a competitor and its open source software off the market to secure their market share and shut down the development of an open source stack they could just tell us.

81

They could. But why would they?

Iā€™m not sure why you want to view the world as agents making tactical anti-competitive decisions in regard to FOSS. Most HW companies arenā€™t giving FOSS a second thought because it is such a small market.