[Banana Pi BPI-R64] Mainline OpenWRT image

That chain is processed by xt_OFFLOAD, in this patch: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/hack-5.4/650-netfilter-add-xt_OFFLOAD-target.patch

Will mt7623 also supported too? Can this also be used with “legacy” iptables?

work for all hwnat platforms.

I’ve updated my branch with 5.10 support.

You can enable it from: menuconfig -> Global build settings -> use the testing kernel version.

Hi guys. I have build image for R64 with kernel 5.10 https://cloud.mail.ru/public/cq89/AVqxejYqM. During building I have got one issue. Midnight Commander can’t compile.

1 Like

You can try to enable ext4 journaling (CONFIG_TARGET_EXT4_JOURNAL), it should help in cases of power loss.

Have you seen/fixed this bug with hw offload: [R64] Mainline OpenWRT image ?

Support for BananaPi BPi-R64

OpenWrt UBI installer image generator

is there a mainline-series to add hw-nat?

in openwrt it is pending, and i do not see the previous selection to mt7622 (and 7621/7629) only

Hi, I want to tell about my experience with new firmware update. Fist you need flash openwrt-mediatek-mt7622-bananapi_bpi-r64-boot-sdcard.img file to SD and load. After that you see new u-boot: uboot

Recovery system this openwrt-mediatek-mt7622-bananapi_bpi-r64-initramfs-recovery.itb, production system this openwrt-mediatek-mt7622-bananapi_bpi-r64-squashfs-sysupgrade.itb.

I have load openwrt-mediatek-mt7622-bananapi_bpi-r64-squashfs-sysupgrade this is status screen:

.

[email protected]:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                25.8M     25.8M         0 100% /rom
tmpfs                   496.7M      3.0M    493.8M   1% /tmp
tmpfs                   496.7M    504.0K    496.2M   0% /tmp/root
overlayfs:/tmp/root     496.7M    504.0K    496.2M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

But I have one big trouble. System can’t save settings after reboot (I use sysupgrade image). And other trouble, serial console does not react to keyboard (you must reboot some times and then it start react, I don’t understant how It work)

There has been a problem with the new way we deal with mmc/block storage and GPT partitions which lead to overlay being reinitialized on every boot. This is fixed in more recent builds after

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ec76cbc521e182d04bc07339e3c7b5a7a8f15a5b

If you are running an image where you still encounter that bug, you can fix it in the meantime by doing

ln -s 2 /overlay/.fs_state

I’ve also encountered the slightly weird behavior of the serial console which makes navigating the bootmenu more tricky than on other MT7622 boards I’ve been dealing with. Probably there is still something wrong/missing in DTS or pinctrl driver in U-Boot – the faulty red LED (always on despite GPIO88 being wired up) is an other indicator of that. The OpenWrt build of U-Boot is U-Boot 2020.10 with MediaTek’s patches on top plus adding defconfigs and environments for boards. For the BPi-R64 I’m using the dts contained in the U-Boot repository and just add LEDs and buttons to it (so that factory reset of the environment works by holding the button during power-on). For Linux it’s similar. So it’d be interesting to know if other people also encounter this when running recent U-Boot and Kernel, and if not, are they using the DTS from those upstream sources?

Other than that U-Boot works fine, I’ve just have it run 4 passes of Memtest86 9.0 EFI :sunny:

And everything needed for eMMC installation is now already integrated on the SD Card image to make it easier.

I’ve also made an OpenWrt wiki page:

Feel free to edit/complete stuff there.

Remaining issues are:

  • the red LED :slight_smile:
  • serial console weirdness
  • no way to load mt7622 wifi EEPROM from mmc (mt76 driver needs to be extended for that, ideally we put mt7622 wifi eeprom and maybe MAC addresses in the unused boot1 partition of the eMMC)
  • add SPI-NAND to DTS
  • boot from SPI-NAND (are bootselect pins exposed for that?)

Regarding the RED led, check my comment here from MT7622 programming manual: Official OpenWrt Support for BananaPi BPi-R64 & what is missing

I think GPIO88 pin needs to be told do do GPIO and not I2C1_SDA

Can you describe this a bit more? I have same behaviour like on r2 and no üroblems in bootmenu/uboot. Do you use a modified or upstream uboot? Maybe compare config with my one

I use upstream 2020.10 with the few patches on top (see package/boot/uboot-mediatek in OpenWrt tree). It works well with other MT7622 boards (Belkin RT3200/Linksys E8450), no problems with the serial port there. On the Bananapi serial RX has problems only with specific bytes sent, so maybe baud clocking slightly off or something like that.

Assigning GPIO function to PIN 88 happens automatically by the pinctrl-mt7622 driver when you request the GPIO PIN. Ie. that’s the mode which is set once you add the LED to gpio-leds, as that will request the PIN and thereby set it to GPIO mode (at least this is how pinctrl on those mtk SoCs is supposed to work)

I noticed that my 2 bpi boards (r2,r64) do not support specific usb2uart (e.g. with profilic chips),maybe this is the cause. I currently only using cp2102

You are right. I swapped the FTDI FT232R (could be a fake) for FTDI FT2232HL and now it works perfectly.

I want to tall that u-boot from graphin firmwere or firmware witch posted sinovoip don’t has this truble with serial console, they only appear in last OpenWRT.

I have try new build. Settings is saved fine. And I have noticed one detail, If you press arrow button many time during loading u-boot It will start response to keyboard.

Maybe there are more patches or DTS changes bundled into this U-Boot binary from @sinovoip? And yes, I’ve also noticed that only arrow keys in menu are affected and they do work after trying a lot of times. I suspect pinconf/pinctrl issue.