BTW do you know if it’s possible to include binary files in patches? The idea is to have a mt76-firmware package which would put two additional calibration data files in /lib/firmware/mediatek/ directory.
The package is built per target (intead of per architecture) due to PKG_NONSHARED:=1 being set. This is because it’s a kernel module and needs to match the exact kernel build of the target, and not just the architecture.
I don’t think it’s possible to include binaries in patches, and it’s also just something nobody should do imho. You can, however, place the files in package/kernel/mt76/files and edit package/kernel/mt76/Makefile to have them included in the a generated package mt7622-default-eeprom (or something like that).
I don’t think they should go into base-files as they are board-specific for the BPi-R64. All other MT7622 boards do have proper populated calibration data.
If you build locally (using the buildroot or ImageBuilder) you can pass a list of files to be added to the images using the FILES env variable.
I was assuming @svintuss would like to also push what ever is needed upstream.
I don’t know if patch from @frank-w can be pushed upstream. It solves the problem of development boards (like mine) with both mt7622 and mt7615 without calibration data.
I doubt that the calibration data itself could or should be pushed in OpenWRT. It may be copyrighted material of BananaPi and most important it contains a MAC-address.
That being said I would like to make a package that would update mt76 driver to a patched version and at the same time place calibration data files to /lib/firmware/mediatek
Is it possible to make a patch to mt76 package Makefile so that upon updating I would only need to place it in patch directory?
Having a package containing the default calibration data for a specific board is acceptable – we do that for the brcmfmac on some RasbPi models in the same way. It just shouldn’t break boards which got proper calibration in flash, so patching mt76 to always load calibration data from a file is not acceptable hence. I don’t think these collection of numerical constants can even be subject to copyright law. And regarding the mac address, we got ways to discard invalid mac and use random instead. For that we just need to make sure that the mac address in the file loaded is actually invalid.
In OpenWrt the root filesystem of all boards of a subtarget is usually shared, hence the mere presence of that file is not a good indicator, as it would either never or always be present for all MT7622 boards (in snapshots and initramfs; for release builds we generate per-device rootfs), ie. as-is this patch will still break wifi on all other MT7622 boards.
A (quick and dirty) solution could be to handle the acquisition of the file by the driver in /etc/hotplug.d/firmware and there handle the BPi-R64 as the only case returning the file.
However, the best would actually be to embed the EEPROM into the device-tree or at least hint to an external EEPROM file there, so differentiation would not have to be done in user-space.
Hi, I just received a R64 and am having trouble getting OpenWRT running. Initially, per the OpenWRT wiki, I used the sdcard.img snapshot (built 26/9) which fails with warning that partition fip not found. Building current git head (today 28/9) I still get the same error. Thought it might a SD card incompatibility issue but it still happens with another card.
NOTICE: BL2: v2.4(release):OpenWrt v2021-05-08-d2c75b21-1 (mt7622-sdmmc-2ddr)
NOTICE: BL2: Built : 13:38:01, Sep 26 2021
ERROR: Partition 'fip' not found
PANIC at PC : 0x000000000020473c
Checking with fdisk there is definitely fip partition.
Disk /dev/sdc: 1.87 GiB, 2002780160 bytes, 3911680 sectors
Device Start End Sectors Size Type
/dev/sdc1 1024 2047 1024 512K Linux filesystem (named "bl2")
/dev/sdc2 4096 8191 4096 2M EFI System (named "fip")
/dev/sdc3 8192 10239 2048 1M Linux filesystem (named "ubootenv")
/dev/sdc4 12288 77823 65536 32M Linux filesystem (named "recovery")
/dev/sdc5 77824 92159 14336 7M Linux filesystem (named "install")
/dev/sdc6 92160 524287 432128 211M unknown (named "production")
/dev/sdc128 34 1023 990 495K BIOS boot
There are no recent r64 or mt7622 commits that would appear to cause this other than perhaps uboot mediatek: several fixes for MT7622 from 11/7 but which I’d assume others would have noticed?
Running wipefs didn’t make a difference unfortunately. However, using another (much) newer SD card did work using exactly the same image. The other older SD cards were pre-SDHC/SDXC but still working without errors so it may indeed have been a compatibility issue.
Now to see if I can get my untested second hand WLE900VX card recognised given it’s known PCI compatibility issues.
As the in-SoC bootrom was able to load ARM Trusted Firmware bl2 even from the older/slower SD card, I wonder if we can improve the mmc driver in TF-A (and possibly U-Boot) to also be a bit more tolerant… @hackpascal ?
Thanks!