The OpenWrt team has added full target support (sdcard & emmc boot) for the Mediatek mt7622 based BananaPi BPi-R64 [1].
A big thank you goes to dangowrt that did the major coding work in the last days:
One question remains, as we could not find the EEPROM with the calibration and mac data for the internal on-board wifi mt7615 card… so for now the wifi has an uncalibrated state leading to just 6dBm output power and a random generated mac address … both information should be in an EEPROM somewhere on the board … who can help here ?
for wifi there is also an existing thread…here are steps to load eeprom-data from mtd partition or from file…by default eeprom is loaded from internal eeprom
I was not ware of the commit posting in the other thread … sry for doubleposting.
But been at the target, the question remains where to get the calibration data for the onboad Wifi und where to get the MAC addressen. The BananaPi comes without any EEPROM data for calib wifi and MAC addresses. The link you have send seems to by 150MByte of reference Debian image, where we could grep & snip out the wifi calib .bin but the mac address remains unset from vendor. Should we grab the wifi calib data from this reference Debian image or can you provide us the calib EEPROM data as .bin ?
Design wise the question remains where we properly store the calib data and the mac addresses once they are provided. The SPI NAND as mtd device seem to be an option, but is not present on all BananaPi batches. Another approach that seems much cleaner is: the boot0 partition on the EMMC is used for freeloader/preloader BL2 and there is an empty boot1 partition that would perfectly fit for storing EEPROM wifi calib data and mac adresses for ethernet and wifi as well. In the case the BananaPi is booted from the sdcard, the calib data could be loaded from the boot1 emmc as well. Does the SinoVoip BPI team has any sort of MAC address allocation for the BananaPi R64 in mind ?
This calibration bin [1] seems to be the wifi calib data within the Debian ref. image.
We could flash this calib.bin witin the initial OpenWrt flash procedure by the uboot bootloader into the boot1 emmc partition and add a hook into the mt7615 wifi driver to look for this calib.bin in the BananaPi R64 case on the boot1 emmc, we would add the needed modifications in mt7615 to be able to load the calib data from emmc boot0 (emmc driver support within mt7615). The more dirty approach is to load the calib data with a kind of firmware loader… we would like to avoid this and do the effort with the more cleaner emmc way.
So design suggestion:
BananaPi booted from sdcard -> mt7615 loads calib/mac data from emmc boot1 partition
BananaPi booted from emmc -> mt7615 loads calib/mac data from emmc boot1 partition
BananaPi booted from spi nand -> mt7615 loads calib/mac data from spi nand
You can use it with separate (mtd) partition or like my way as file in /lib/firmware (needs patch to load it). Please do not use boot1 for it. My gpt also contains an rf partition for this. Problem can be that only 1 eeprom can be used…on r64 with mt7615 you fall into this. So i think the file approach is much better
Your suggestion to store the calibration & mac address data on mtd/spi-nand partition or in a /lib/firmware file has certain drawbacks from our OpenWrt perspective.
Why do we think, this approach is problematic:
wifi calibration & mac addresses data should be associated to the hardware as tight as possible, should be read-only to prevent user interaction & failures and the storage memory should be as reliable as possible
an on-board EEPROM would be such a sufficient storage place, which the BananaPi R64 board does not provide, so we need to find an alternative memory for this
BananaPi R64 provides potential storage via sdcard, eMMC and spi nand
spi nand is quite unreliable compared to eMMC (bad blocks are not uncommon)
sdcard is a removable memory and hence not a preferable storage for device specific data like mac addresses (using your sdcard in a different BananaPi R64 should not transfer you mac addresses!)
files based approaches have been used in OpenWrt for legacy targets without device-tree support, as we start with a clean approach here - lets make use of dts
Our proposed way for OpenWrt calib/mac data handling:
lets use the onboard eMMc as it is most reliable on-board memory here
boot1 is an unused 4MByte partition in the eMMc that is sufficient for all calibration/mac data
we can write the calib data to boot1 / emmc at the bootloader initial openwrt flash stage and make the boot1 partition read-only afterward
eMMC storage is physically associated to the board and is not a removable storage for calib/mac
Does this make sense for you ?
What about the question on how to handle mac addresses ? Does the SinoVoip BPI team has a MAC address allocation for the BananaPi R64 or are random mac addresses the way to go ?
I understand why you want to use boot1. But this is for soc-eeprom (mt7622 wifi and bluetooth) only and for mt7615 you want to use rf partition as this is “user related” (wifi card can be removed and needs firmware on running os)
Btw. i don’t think,bpi has own address-space…maybe mtk has blocks reserved
There seems to be a misunderstanding … we are talking about the on-board/none-removeable 2,4 GHz mt7615 wifi card and its mac address that we want to store on boot1 / emmc partition (SoC ethernet mac’s as well)
For all external mPCI wifi cards you should have the calib and mac address data on their EEPROM.
i have understood this way (soc-eeprom for wifi/bt on boot1),except the external cards eeprom…had already a card without data on efuse (and i wanted to fix this too…but not yet tested). btw. some bytes in eeprom maybe needing modification to increase TX power (see discussion wifi-thread).
@graphine was this addressed to me? i have a v1.0 board (rtl8167 switch and on board mt7615) and one v1.1 (mt7531 switch and 2 pcie-slots where i have one disabled for sata)…
As there seems to be more than one board version with different hardware specs …lets try to clarify this, so that we can provide proper OpenWrt support for each sub-target.
The mt7622 SoC has a build in mt7615 4x4 wifi chip. The BananaPi R64 hardware version we have multiple times over here provide 4x u.fl pins to connect antennas to this mt7615 wifi (but not eeprom for calibration/mac address data rather a file that needs to be stored somewhere properly). As I understand your last post, this is revision 1.0 of the BananaPi R64… correct ?
You mention a revision 1.1 of the BananaPi R64 that does have the SoC build-in mt7615 wifi but does not provide antenna port to make use of this integrated wifi … correct ?
Would you mind specifying the revisions of the BananaPi R64 here with its hardware spec that someone can use (wifi/bluetooth/ethernet-ports/switch chip/nand/emmc/ect)… so that we can build sub-target specific OpenWrt support?
no, only the development-version (v1.0 non-sale) had mt7615 on board. the sale-variant (v1.1, with mt7531 switch) has only the mt7622 (afair 2ghz only) wmac wifi (uses parts from mt7615 driver). i only work on v1.1
An external mPCI wifi card without an on-board EEPROM that holds the calibration and mac data is typically for testing purposes at the integrator level - not for end-users. There is no good way without such an EEPROM to associate the mPCI specific calibration/mac data as a file connected to this wifi card.
If you plan to sell external mPCI wifi cards with your BananaPi board, please consider adding such an EEPROM on those cards for calib/mac data. Any manufacturer (e.g. AsiaRF) could add such an EEPROM chip, but yes… it adds some extra costs to the card.)
If the SinoVoip team plans to sell WiFi mPCI cards without an EEPROM for calib/mac data … this road adds several problems for end-users in the long term:
such mPCI wifi cards will not work in other embedded boards out of the box (you need to integrate the calib/mac data on each target)
once you developed and sell more than just one version of such a mPCI wifi card, you have to solve the problem of proper software bindings between calib/mac data and it’s individual physical opponent.
Our goal is to design a clean OpenWrt reference SDK for MTK support. Calibration & mac address data will only be handled for physical on-board chips without EEPROM support on reliable memory like eMMc. External mPCI wifi cards without EEPROM are a nightmare to support across multiple embedded targets.
if your boards are the v1.0 dev-variant (with the realtek-switch) yes…i got message from bpi/mtk/openwrt, that this board can be dropped as these are only for testing the SOC and were not in sale ever…only v1.1 was sold…and this is the one i use (the other lays in my shelf)
picture from aliexpress is a v1.1 (or later) because of 2 pcie slots
and I do not want to sell anything i’m user/tester only no employee of BPI
Over here in Europe we have bought several boards (that do have 2x mPCI slots! & 1x internal mt7615 4x4 antenna u.fl pins & mt7531 switch) and can still order them,… so this is rev 1.1. We are not aware of any store to order a rev 1.1+x version from, that does not provide a connectable internal mt7615 wifi.
Please provide a link for those boards you have & where to order them
Our guess is, that we have rev 1.1 hardware (just doublecheck the borad on my desk & re. 1.1 is printed on it) and you have a rev 1.1+x without usabel on-board wifi ?
i’m user/tester only no employee of BPI
had some pcie-trouble (missing capacitors)