Please Add Latest MediaTek Firmware For Edge Kernel

thesunexpress commented 11 months ago

Description

Howdie, have a finicky new-ish WiFi module that's refusing to be detected correctly by the Alpine Image.

It revolves around a (new?) MediaTek MT7922 module, that should be detected as the port lists MT79* as supported. I suspect it requires newer firmware perhaps. I built the wifibox-alpine image with both the vanilla 6.1. & 'edge' 6.5.* kernels, neither of which contained latest-greatest firmware. Old instruction broadly outlined by https://github.com/pgj/freebsd-wifibox/issues/6#issuecomment-1003378323 no longer work in the latest iteration of wifibox using http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/linux-firmware-mediatek-20230919-r2.apk What's the correct way to inject newer firmware into the Alpine image?

Host operating system

FreeBSD 13.2-STABLE / 14-STABLE

Wireless NIC

ppt0@pci0:8:0:0:    class=0x028000 rev=0x00 hdr=0x00 vendor=0x14c3 device=0x0616 subvendor=0x105b subdevice=0xe0cd
    vendor     = 'MEDIATEK Corp.'
    device     = 'MT7922 802.11ax PCI Express Wireless Network Adapter'
    class      = network

Wifibox version

wifibox-1.3.0
wifibox-alpine-20230926
wifibox-core-0.12.0

Disk image type and version

Latest

Changes to the default configuration files

No response

Logs

N/A

Additional context

No response

Have you tried to turn it on and off?

[X] Yes, I have read all the manual pages first!

pgj commented 11 months ago

Hi @thesunexpress, long time no see! Yes, you are right, the Alpine-based image is now based on different foundations. You can find the details of that in the definition of the net/wifibox-alpine port.

As a consequence, no Alpine packages are used for installing the firmware files. They are instead directly added from the linux-firwmare repository, depending on the configuration options of the net/wifibox-alpine port.

In theory, the MT7922 cards are handled by the mt7921e driver which should be available in the image. However, by looking at the firmware files what the driver expects, there is a problem. Output from the wifibox console:

# modinfo mt7921e
filename:       /lib/modules/6.5.4-0-edge/kernel/drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko.xz
author:         Lorenzo Bianconi <lorenzo@kernel.org>
author:         Sean Wang <sean.wang@mediatek.com>
license:        Dual BSD/GPL
parm:           disable_aspm:disable PCI ASPM support
alias:          pci:v000014C3d00000616sv*sd*bc*sc*i*
alias:          pci:v000014C3d00000608sv*sd*bc*sc*i*
alias:          pci:v000014C3d00007922sv*sd*bc*sc*i*
alias:          pci:v000014C3d00007961sv*sd*bc*sc*i*
depends:        mt76,mt7921-common,mt76-connac-lib
intree:         Y
vermagic:       6.5.4-0-edge mod_unload 
firmware:       mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin
firmware:       mediatek/WIFI_RAM_CODE_MT7922_1.bin
firmware:       mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
firmware:       mediatek/WIFI_RAM_CODE_MT7961_1.bin

But the port adds the MT76xx files only. I will create a version that changes this so you could test it.

pgj commented 11 months ago

Hrmm, apparently I was wrong. On selecting the FW_MEDIATEK option, or using the mediatek flavor, all the Mediatek firmware files are installed under /lib/firmware. Which means that the driver should just work in this case.

Could you please share output the following commands? They should issued on the guest, using the wifibox console command.

dmesg
lsmod
ls -h /lib/firmware/mediatek/WIFI_*.bin
modprobe mt7921e

pgj commented 11 months ago

@thesunexpress ?

thesunexpress commented 10 months ago

@thesunexpress ?

Hi, sorry for the delay. I'm in/out of hospital a lot lately. Recent stay was certainly totally unplanned & didn't think of bringing my laptop or anything... which wouldn't have helped much since I had shutdown the system with the target hardware. I was totally useless for the first week+ after operation anyways. Getting old sucks. I'm getting back up to speed again now, have large backlog to deal with still. Just fired up the machine & looks like I need to do much more debugging before anything, as loading vmm.ko hardlocks the OS immediately now. Looks like somebody else is dealing with something very similar at issue #73 https://github.com/pgj/freebsd-wifibox/issues/73

IIRC I noticed some error while building the firmware when I last compiled from weeks ago. I'll get back to you ASAP.

thesunexpress commented 9 months ago

@thesunexpress ?

Right, back to work! Finally getting back to normalcy here. Spent yesterday & today staring at digital assaults from my console terminal -- tried a bunch of different things / configs when compiling wifibox-alpine:

/usr/bin/env LD_LIBRARY_PATH=/usr/ports/net/wifibox-alpine/work-default/freebsd-wifibox-alpine-2646128d92561b62fe4ea863aee9cad4b5fa8eda/work/bootstrap/lib  /usr/ports/net/wifibox-alpine/work-default/freebsd-wifibox-alpine-2646128d92561b62fe4ea863aee9cad4b5fa8eda/work/bootstrap/sbin/apk add  --initdb  --no-network  --no-cache  --force-non-repository  --allow-untrusted  --no-progress  --clean-protected  --root /usr/ports/net/wifibox-alpine/work-default/freebsd-wifibox-alpine-2646128d92561b62fe4ea863aee9cad4b5fa8eda/work/image-contents  --no-scripts  --no-chown  /usr/ports/distfiles/wifibox-alpine/baselayout-3.4.3-r1.apk /usr/ports/distfiles/wifibox-alpine/busybox-1.36.1-r1.apk /usr/ports/distfiles/wifibox-alpine/ifupdown-ng-0.12.1-r1.apk /usr/ports/distfiles/wifibox-alpine/iptables-1.8.9-r1.apk /usr/ports/distfiles/wifibox-alpine/iw-5.19-r1.apk /usr/ports/distfiles/wifibox-alpine/libcap2-2.69-r0.apk /usr/ports/distfiles/wifibox-alpine/libcap-utils-2.69-r0.apk /usr/ports/distfiles/wifibox-alpine/libcrypto3-3.1.2-r0.apk /usr/ports/distfiles/wifibox-alpine/libmnl-1.0.5-r1.apk /usr/ports/distfiles/wifibox-alpine/libnftnl-1.2.5-r1.apk /usr/ports/distfiles/wifibox-alpine/libnl3-3.7.0-r1.apk /usr/ports/distfiles/wifibox-alpine/libssl3-3.1.2-r0.apk /usr/ports/distfiles/wifibox-alpine/musl-1.2.4-r1.apk /usr/ports/distfiles/wifibox-alpine/openrc-0.48-r0.apk /usr/ports/distfiles/wifibox-alpine/socat-1.7.4.4-r1.apk /usr/ports/distfiles/wifibox-alpine/uds_passthru-0.1.1-r2.apk /usr/ports/distfiles/wifibox-alpine/radvd-2.19-r0.apk /usr/ports/distfiles/wifibox-alpine/dhcpcd-10.0.2-r0.apk /usr/ports/distfiles/wifibox-alpine/pcsc-lite-libs-1.9.9-r3.apk /usr/ports/distfiles/wifibox-alpine/wpa_supplicant-2.10-r5.apk /usr/ports/distfiles/wifibox-alpine/linux-lts-6.1.54-r0.apk
Abort trap
*** [/usr/ports/net/wifibox-alpine/work-default/freebsd-wifibox-alpine-2646128d92561b62fe4ea863aee9cad4b5fa8eda/work/image-contents/.done] Error code 134

make[2]: stopped in /usr/ports/net/wifibox-alpine/work-default/freebsd-wifibox-alpine-2646128d92561b62fe4ea863aee9cad4b5fa8eda
1 error

make[2]: stopped in /usr/ports/net/wifibox-alpine/work-default/freebsd-wifibox-alpine-2646128d92561b62fe4ea863aee9cad4b5fa8eda
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/net/wifibox-alpine
*** Error code 1

Stop.
make: stopped in /usr/ports/net/wifibox-alpine

Both linux.ko & linux64.ko are kldload'ed. Needless to say, I'm so far not successful at getting wifibox to run on the Ryzen 7000 platform. The abort trap is a bit cryptic to me & the error code is most unfamiliar.

For what it is worth, and probably not related, we are having some significant issues with running btop++ on Ryzen 7000 as well. The code compiles fine, without any notable issues, but when the binary is executed, we've been confronted with different cryptic errors, aborts & core dumps. A fellow dev on a Ryzen 7000 platform with Fedora Linux OS was having very similar btop++ issues. The odd thing is, I have a Ryzen 7700 (non-X cpu), where both wifibox & btop++ ran fine previously. Really curious stuff. But again, probably unrelated, and just coincidental that these problems started around the same time.

In any case, the binary pkg of wifibox etc installs & runs fine, just cannot compile it with custom switches. Any ideas?

pgj commented 9 months ago

I think "Abort trap" above signals a crash of the given program, which is the native Linux (ELF64) APK utility. This is run through the Linux compatibility layer of FreeBSD and the issue is probably associated it with servicing one of the (emulated) system calls. There shall either be a core dump somewhere around, which could give use some insights about the location of the crash, or a log message on the crash in the FreeBSD dmesg output.

Could you please try to find those for me?

The fact that other programs crash on this CPU also let me believe that it is either a hardware issue or something that the base OS does not (yet) handle well. In such cases the application itself cannot do too much, perhaps only hope for user-space workarounds. Running 64-bit Linux of recent versions over FreeBSD's emulation layer is a gamble anyway, I simply consider myself lucky that I have been able to get away with this trick :-P

thesunexpress commented 9 months ago

I think "Abort trap" above signals a crash of the given program, which is the native Linux (ELF64) APK utility. This is run through the Linux compatibility layer of FreeBSD and the issue is probably associated it with servicing one of the (emulated) system calls. There shall either be a core dump somewhere around, which could give use some insights about the location of the crash, or a log message on the crash in the FreeBSD dmesg output.

Could you please try to find those for me?

The fact that other programs crash on this CPU also let me believe that it is either a hardware issue or something that the base OS does not (yet) handle well. In such cases the application itself cannot do too much, perhaps only hope for user-space workarounds. Running 64-bit Linux of recent versions over FreeBSD's emulation layer is a gamble anyway, I simply consider myself lucky that I have been able to get away with this trick :-P

Good hints! Have tested & can confirm build failure on: AMD Ryzen 7700 (non-X model, this is recent, worked previously), AMD Ryzen 7950X3D, Intel Core i7-8565U (WTF?!?! Worked fine before...using it right now). All of which are either FreeBSD-13.2 STABLE or FreeBSD-14.0 STABLE. I managed successful builds on i9-7940X & i9-8920X for both FreeBSD13.2 STABLE & FreeBSD-14.0 STABLE. Ditto AMD Ryzen 5950X (luckily?). I will now use these machines now to generate workable packages, I hope. Will try this approach to get the Edge Kernel build -- to get most recent firmware(s) working. The build failures are all the same cryptic Abort trap -- which I can assure you, provides no useful dumps of any kind to analyze. I'll have to try some virtual environment(s) to see I can catch it in the act. Nothing is reported to dmesg or anywhere else. FYI: The build environments I use are all identical, for consistency among the different systems I run. By necessity.

The issue we had with btop is likely 99.9999999% totally UNrelated. It is looking more & more like recent FreeBSD base system libs/includes in cmake-files update. The older version of btop works fine still, where the most recent git pull would fail to enumerate cpus etc when the compiled binary is executed. Have been working with the btop devs to ferret-out what the heck the actual cause is -- as we have a hacky fix in place at the moment.

thesunexpress commented 9 months ago

Here we go...

dmesg : https://pastebin.com/See0QQ9k

lsmod :

wifibox:~# lsmod
Module                  Size  Used by    Not tainted
mt7921e                16384  0 
mt7921_common          61440  1 mt7921e
mt76_connac_lib        53248  2 mt7921e,mt7921_common
mt76                   65536  3 mt7921e,mt7921_common,mt76_connac_lib
iptable_nat            12288  1 
ip6table_nat           12288  1 
ip6table_filter        12288  1 
ip6_tables             20480  2 ip6table_nat,ip6table_filter
ipv6                  454656 12 [permanent]
wifibox:~#

ls -h /lib/firmware/mediatek/WIFI_*.bin :

/lib/firmware/mediatek/WIFI_MT7922_patch_mcu_1_1_hdr.bin
/lib/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
/lib/firmware/mediatek/WIFI_RAM_CODE_MT7922_1.bin
/lib/firmware/mediatek/WIFI_RAM_CODE_MT7961_1.bin

and finally, modprobe mt7921e : crickets

screenie:

wifibox problems

thesunexpress commented 9 months ago

And here is my wifibox-alpine package as built & installed on this machine. Note: I can confirm this custom compiled package is functional, as I use the exact same packages on my laptop -- where it works wonderfully. wifibox problems 002

pgj commented 9 months ago

Thanks for the feedback! A couple of comments:

I was talking about the dmesg of the FreeBSD host. When a program crashes (which is the Linux-native apk in our case) there shall be a log message about that in the logs. Something like that, which is not a crash per se but a notice from the OS:

linux: jid 0 pid 57037 (apk): unsupported umount2 flags 0xa

Here is a log line on a crash, which happened for a FreeBSD-native binary:

pid 12666 (pulseaudio), jid 0, uid 1001: exited on signal 6

The modprobe mt7921e command on the Wifibox guest should not produce any output if everything goes well. It simply loads the module and all of its dependencies to the memory. The output of lsmod clearly shows that it happened as expected.
The behavior of the mt7921e module could be traced through the messages it sends to the dmesg of the Wifibox guest. The lack of those messages indicates that the driver did not think that any supported device is available. You may want to use the lspci -k command on the Wifibox guest to see if your wireless device is available there and the driver was successfully attached to that. For example, this is the output from my instance where the line with iwlwifi and the associated device is the matter of interest:

# lspci -k
00:1f.0 Class 0601: 8086:7000
00:04.2 Class 0100: 1af4:1009 virtio-pci
00:04.0 Class 0100: 1af4:1001 virtio-pci
00:00.0 Class 0600: 1275:1275
00:04.3 Class 0100: 1af4:1009 virtio-pci
00:06.0 Class 0280: 8086:24f3 iwlwifi
00:04.1 Class 0100: 1af4:1009 virtio-pci
00:05.0 Class 0200: 8086:100f e1000

Sorry, I am not sure I understood your last comment right -- is it working, has the issue been solved?

pgj / freebsd-wifibox