Hi All,
It looks like we've finally got to the bottom of the issues around disappearing WiFi on the Raspberry Pi 3 series of devices. It should be fixed with kernel 4.19.10 for F-28/F-29.
Please test and provide feedback on the bug [1] or karma on the updates for F-29 [2] or F-28 [3].
To test with updates-testing please run: "dnf upgrade --enablerepo=updates-testing kernel*"
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1652093 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2018-95036ea383 [3] https://bodhi.fedoraproject.org/updates/FEDORA-2018-6e8c330d50
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found [root@rpi3 ~]# uname -r 4.19.10-200.fc28.aarch64
On 12/18/18 5:33 PM, Peter Robinson wrote:
Hi All,
It looks like we've finally got to the bottom of the issues around disappearing WiFi on the Raspberry Pi 3 series of devices. It should be fixed with kernel 4.19.10 for F-28/F-29.
Please test and provide feedback on the bug [1] or karma on the updates for F-29 [2] or F-28 [3].
To test with updates-testing please run: "dnf upgrade --enablerepo=updates-testing kernel*"
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1652093 [2] https://bodhi.fedoraproject.org/updates/FEDORA-2018-95036ea383 [3] https://bodhi.fedoraproject.org/updates/FEDORA-2018-6e8c330d50
Hi,
Am 21.12.18 um 08:01 schrieb Zamir SUN:
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
Can you provide a complete dmesg?
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
Does Fedora provide the necessary Bluetooth firmware?
Would be interesting to see what happends after providing the bluetooth firmware.
Regards Stefan
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
Can you provide a complete dmesg?
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
Does Fedora provide the necessary Bluetooth firmware?
No, because they're not upstream in linux-firmware and from the discussion I've had with RPi foundation either they or Cyprus need to do the redistribution bits so they can be added to linux-firmware so all linux distros can benefit from the improved bluetooth. The BT does work without it, but it is a lot more stable and gets proper MACs etc with the newer firmware.
Would be interesting to see what happends after providing the bluetooth firmware.
Regards Stefan _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Peter, Stefan,
See in-line.
On 12/22/18 10:47 AM, Peter Robinson wrote:
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
From the PCB it is RPi 3B v1.2.
Can you provide a complete dmesg?
Sure, here it is. https://paste.fedoraproject.org/paste/TlsJIanigMq6JVfMgezzeA
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
I've read about the comments in that bug. And I do cold reboot it. By this I mean, each time I test it, I poweroff and then set the socket to off from my PDU, and then set to ON, so I believe this is a different story.
Does Fedora provide the necessary Bluetooth firmware?
No, because they're not upstream in linux-firmware and from the discussion I've had with RPi foundation either they or Cyprus need to do the redistribution bits so they can be added to linux-firmware so all linux distros can benefit from the improved bluetooth. The BT does work without it, but it is a lot more stable and gets proper MACs etc with the newer firmware.
I have downloaded the firmware from Peter's blog. https://nullr0ute.com/2018/04/the-raspberry-pi-3-b-in-fedora/
Would be interesting to see what happends after providing the bluetooth firmware.
As I mentioned above, I just tried download the firmware again and it makes no different. The console log is what I got after downloading the firmware.
If you think this worth a separate bug to be tracked, or some more information I can provide, I would like to help.
Regards Stefan
On Sat, Dec 22, 2018 at 1:49 PM Zamir SUN zsun@fedoraproject.org wrote:
Hi Peter, Stefan,
See in-line.
On 12/22/18 10:47 AM, Peter Robinson wrote:
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
From the PCB it is RPi 3B v1.2.
Can you provide a complete dmesg?
Sure, here it is. https://paste.fedoraproject.org/paste/TlsJIanigMq6JVfMgezzeA
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
I've read about the comments in that bug. And I do cold reboot it. By this I mean, each time I test it, I poweroff and then set the socket to off from my PDU, and then set to ON, so I believe this is a different story.
Does Fedora provide the necessary Bluetooth firmware?
No, because they're not upstream in linux-firmware and from the discussion I've had with RPi foundation either they or Cyprus need to do the redistribution bits so they can be added to linux-firmware so all linux distros can benefit from the improved bluetooth. The BT does work without it, but it is a lot more stable and gets proper MACs etc with the newer firmware.
I have downloaded the firmware from Peter's blog. https://nullr0ute.com/2018/04/the-raspberry-pi-3-b-in-fedora/
Please don't do that any more, see the details in the FAQ: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
Would be interesting to see what happends after providing the bluetooth firmware.
As I mentioned above, I just tried download the firmware again and it makes no different. The console log is what I got after downloading the firmware.
With 4.19.10 and the recent linux-firmware there's no need for extra steps to get the wifi working.
If you think this worth a separate bug to be tracked, or some more information I can provide, I would like to help.
Regards Stefan
-- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯,访问 https://zh.fedoracommunity.org/
Hello,
I can confirm that the current kernel-4.19-10-300 re-enables the wifi on an RPi 3B for Fedora 29. I was on 4.19.7 without any wifi device noticeable by nmcli; ran dnf upgrade to latest kernel and the wifi is now showing and connecting as expected without any further configuration needed.
On 12/22/18 3:08 PM, Peter Robinson wrote:
On Sat, Dec 22, 2018 at 1:49 PM Zamir SUN zsun@fedoraproject.org wrote:
Hi Peter, Stefan,
See in-line.
On 12/22/18 10:47 AM, Peter Robinson wrote:
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
From the PCB it is RPi 3B v1.2.
Can you provide a complete dmesg?
Sure, here it is. https://paste.fedoraproject.org/paste/TlsJIanigMq6JVfMgezzeA
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
I've read about the comments in that bug. And I do cold reboot it. By this I mean, each time I test it, I poweroff and then set the socket to off from my PDU, and then set to ON, so I believe this is a different story.
Does Fedora provide the necessary Bluetooth firmware?
No, because they're not upstream in linux-firmware and from the discussion I've had with RPi foundation either they or Cyprus need to do the redistribution bits so they can be added to linux-firmware so all linux distros can benefit from the improved bluetooth. The BT does work without it, but it is a lot more stable and gets proper MACs etc with the newer firmware.
I have downloaded the firmware from Peter's blog. https://nullr0ute.com/2018/04/the-raspberry-pi-3-b-in-fedora/
Please don't do that any more, see the details in the FAQ: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
Would be interesting to see what happends after providing the bluetooth firmware.
As I mentioned above, I just tried download the firmware again and it makes no different. The console log is what I got after downloading the firmware.
With 4.19.10 and the recent linux-firmware there's no need for extra steps to get the wifi working.
If you think this worth a separate bug to be tracked, or some more information I can provide, I would like to help.
Regards Stefan
-- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯,访问 https://zh.fedoracommunity.org/
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hello,
I can confirm that the current kernel-4.19-10-300 re-enables the wifi on an RPi 3B for Fedora 29. I was on 4.19.7 without any wifi device noticeable by nmcli; ran dnf upgrade to latest kernel and the wifi is now showing and connecting as expected without any further configuration needed.
On 12/22/18 3:08 PM, Peter Robinson wrote:
On Sat, Dec 22, 2018 at 1:49 PM Zamir SUN zsun@fedoraproject.org wrote:
Hi Peter, Stefan,
See in-line.
On 12/22/18 10:47 AM, Peter Robinson wrote:
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
From the PCB it is RPi 3B v1.2.
Can you provide a complete dmesg?
Sure, here it is. https://paste.fedoraproject.org/paste/TlsJIanigMq6JVfMgezzeA
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
I've read about the comments in that bug. And I do cold reboot it. By this I mean, each time I test it, I poweroff and then set the socket to off from my PDU, and then set to ON, so I believe this is a different story.
Does Fedora provide the necessary Bluetooth firmware?
No, because they're not upstream in linux-firmware and from the discussion I've had with RPi foundation either they or Cyprus need to do the redistribution bits so they can be added to linux-firmware so all linux distros can benefit from the improved bluetooth. The BT does work without it, but it is a lot more stable and gets proper MACs etc with the newer firmware.
I have downloaded the firmware from Peter's blog. https://nullr0ute.com/2018/04/the-raspberry-pi-3-b-in-fedora/
Please don't do that any more, see the details in the FAQ: https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi
Would be interesting to see what happends after providing the bluetooth firmware.
As I mentioned above, I just tried download the firmware again and it makes no different. The console log is what I got after downloading the firmware.
With 4.19.10 and the recent linux-firmware there's no need for extra steps to get the wifi working.
If you think this worth a separate bug to be tracked, or some more information I can provide, I would like to help.
Regards Stefan
-- Zamir SUN GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯,访问 https://zh.fedoracommunity.org/
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Peter,
Peter Robinson pbrobinson@gmail.com hat am 22. Dezember 2018 um 03:47 geschrieben:
Tested against Fedora 28 aarch64 on RPi3. Unfortunately I have negative feedback.
I was happily running kernel-4.19.4-200.fc28.aarch64 with wifi before the update. But after the update and reboot, wifi disappeared. Moreover, reboot back to kernel-4.19.4-200.fc28.aarch64 also did not help.
i assume you have a 3 B not a B+.
Can you provide a complete dmesg?
[root@rpi3 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:a2:a9:f1 brd ff:ff:ff:ff:ff:ff inet 192.168.129.8/25 brd 192.168.129.127 scope global dynamic noprefixroute eth0 valid_lft 3563sec preferred_lft 3563sec inet6 fe80::f6b0:a847:88c7:1fe7/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@rpi3 ~]# nmcli device wifi list [root@rpi3 ~]# dmesg | egrep -i "brcm|firmware" [ 4.408297] raspberrypi-firmware soc:firmware: Attached to firmware from 2018-09-21 15:44 [ 21.876808] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 22.058065] brcmfmac: probe of mmc1:0001:1 failed with error -110 [ 22.100755] brcmfmac: probe of mmc1:0001:2 failed with error -110 [ 22.101025] usbcore: registered new interface driver brcmfmac [ 32.708983] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2 [ 32.726479] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found
Interesting the wifi chip is found, so the devicetree bugfix is working. So this seems to be a different a issue.
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
the mentioned fix is correct, but it is only half of the work. There is an issue in the sdhci driver which leads to an unwanted reset of the wifi chip.
Please try this little x-mas present: https://marc.info/?l=linux-arm-kernel&m=154559884601004
Regards Stefan
Hi Stefan,
I've found on a lot of devices if you just reboot with the fix it doesn't always work, a full unplug reset of the power generally makes it work again.
the mentioned fix is correct, but it is only half of the work. There is an issue in the sdhci driver which leads to an unwanted reset of the wifi chip.
Please try this little x-mas present: https://marc.info/?l=linux-arm-kernel&m=154559884601004
Testing in progress, will update once I can test.
Also please feel free to add me to the cc: on any Raspberry Pi related fixes/changes, with the Fedora kernel being very modular due to supporting a wide range of HW, and likely deploying newer kernels pretty quickly I can likely provide pretty quick testing/feedback, also useful to see things like this early.
Thanks a lot for you're assistance here.
Peter