samueldr / wip-pinebook-pro

More information on the Unofficial NixOS Wiki
https://nixos.wiki/wiki/NixOS_on_ARM/PINE64_Pinebook_Pro
65 stars 18 forks source link

Early 2021 upgrades #24

Closed samueldr closed 3 years ago

samueldr commented 3 years ago

Pfffff... Lots of things here to unpack.

Note that #21 would still be needed if someone wants to run the mainline kernel... EXCEPT if they use Tow-Boot as their initial boot firmware, and use EFI boot. As Tow-Boot ships this patch in the built-in DT.

Then, we're basically updating everything.


The biggest change is how we are not bunding the initial boot firmware (e.g. U-Boot) in the build anymore. This is now left as an exercise to the reader, but really, I suggest looking at my project:

It is meant to be simpler than "bare" U-Boot to use and setup.


Please leave comments!

Though I'll be merging this soon.

samueldr commented 3 years ago

Going only from memory, I don't have the old firmware setup rolling around, it looks like 5Ghz Wi-Fi performance is better? Maybe? I'm running on 5.11.

I don't remember if it was working or not previously. But right now I had a stable connection all over my home on 5Ghz. 2.4Ghz is still a mess, but that's because it's a mess on all devices around my home.

samueldr commented 3 years ago

Somewhat breaking change.

Unless you're using an initial boot firmware which includes the required trustzone fixes (see #3) you will need to add this to your configuration:

  systemd.tmpfiles.rules = [
    "w /sys/power/mem_sleep - - - -  s2idle"
  }
zhaofengli commented 3 years ago

Nice work on Tow-Boot! I tried it and it's genuinely the best U-Boot build for Pinebook Pro. I really hope that you will share it with the wider Pine64 community (if you haven't already) :smile:

The changes look great, but the new firmware broke Wi-Fi on my PBP. With the new firmware:

[   22.403808] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   22.426674] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01-a41d86bd es7.c5.n4.a3
[   23.181377] ieee80211 phy0: brcmf_netdev_set_mac_address: Setting cur_etheraddr failed, -52
[  102.532217] ieee80211 phy0: brcmf_netdev_set_mac_address: Setting cur_etheraddr failed, -52
[  120.031235] ieee80211 phy0: brcmf_escan_timeout: timer expired
[  140.255303] ieee80211 phy0: brcmf_escan_timeout: timer expired

It worked after I swapped it out for the old one (everything else stayed the same):

[   18.129502] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[   18.194260] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
[   28.696984] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

I tested with both 5.10 and 5.11, and the new firmware exhibited the same problem.

samueldr commented 3 years ago

audibly groans...

I guess we have to figure out firmware sources, who uses which firmware for it, and compare them. I really hate those situations where there's no clear answer, and people just get firmware files from unknown locations, with unknown vintage, with unknown details about what it actually changes.

zhaofengli commented 3 years ago

Hmm, the plot thickens... Just got some time to try again, and apparently I can connect to Wi-Fi manually with wpa_supplicant, but NetworkManager times out with "association took too long" (the password is saved and correct). The Setting cur_etheraddr failed appears to be from NetworkManager's MAC randomization feature for scanning, and doesn't actually prevent me from connecting manually.

Edit: And yes, I tried disabling MAC randomization in NetworkManager.

samueldr commented 3 years ago

Odd, since on mine I didn't need to. I don't think I changed anything while connecting to the networks... whenever I did that initially.

But I'm not surprised either, since on another tablet/computer with a rtl8723bs it was needed.

May 14 19:16:13 luann NetworkManager[997]: <warn>  [1621034173.2572] platform-linux: do-change-link[2]: failure changing link: failure 52 (Invalid exchange)
May 14 19:16:13 luann NetworkManager[997]: <warn>  [1621034173.2573] device (wlan0): set-hw-addr: failed to set MAC address to 72:1C:1D:E4:45:D1 (scanning) (NME_UNSPEC)
May 14 19:16:23 luann NetworkManager[997]: <warn>  [1621034183.4180] sup-iface[ccc877e2417345ec,1,wlan0]: call-p2p-cancel: failed with P2P cancel failed

Looks like it does fail hard to set the MAC address though.

plabadens commented 3 years ago

After half a day building firefox on qemu-aarch64, I've tested this branch a bit (along with Tow-Boot). Some comments:

Thanks for the work you've put into this. This is becoming a very usable platform for light notetaking on the go.

samueldr commented 3 years ago

@plabadens could you state whether you were using the patched _lts or _latest? And can you use uname -a to explicitly show the in-use kernel version? (Since this is automatically trying patches on top of whatever version is in Nixpkgs.)

I'm mostly curious about the exact situations things are verified to work :).

plabadens commented 3 years ago

I'm on _latest based on NixOS/nixpkgs@83d907fd760d9ee4f49b4b7e4b1c6682f137b573. Here's my uname -a output:

Linux ocelot 5.11.21 #1-NixOS SMP Fri May 14 08:50:20 UTC 2021 aarch64 GNU/Linux

Also, bluetooth seems busted somehow, but I need to investigate further.

westurner commented 3 years ago

Is there an at least somewhat distro-portable integration test script that tests all of the requisite modules?

plabadens commented 3 years ago

Also, bluetooth seems busted somehow, but I need to investigate further.

After deleting all leftover state in /var/lib/bluetooth, this is no longer an issue, and pairing works normally.

samueldr commented 3 years ago

Given that I have re-installed my system using Tow-Boot and this branch, successfully, and tested it a bit more. And given other users have verified there is no serious regression, or even any regression.

Let's merge this!