I assume it works now? Anyway, thanks for helping to clean up 2 bugs.
I can make a preliminary subtotal:
Now I have the Segmentation fault error does not appear, including when working with GPIO.
I used to take a prepared minimal demo image. I installed Postgres, Miniflux, gcc, … There was little free space left, but everything worked without errors on the tests. But I also expanded the root partition using GParted - it increased the partition size, but the file system size remained the same, so I additionally used the command :
resize.f2fs /dev/sda1
So the reason is my unqualified actions, not errors in the image assembly. But I hope that my questions will help make the project a little better.
On the new version of the script, the wired network started working immediately, there is Internet access. Wi-Fi AP is visible, but when trying to connect, it stops at the status :
"Getting an IP address"
Eric, do you have any suggestions what needs to be corrected?
Important correction: After a reboot, the Wi-Fi AP works well without any editing of configuration files.
Thank you for your support regarding the SD card and sorry for the delayed answer…
Currently we have the following model in operation: SanDisk Ultra 128 GB Micro SD XC A1 which works pretty well. We will try further SD cards in the future including A2 SD cards and report the results here.
Regarding the green LED as written above: We got it to work via a systemd service unit and we could contribute it to your repository, if you like. Just let us know.
Regarding the freeze issues mentioned above: They were all realted to an older hardware sample of the wifi module MT7615. With a newer hardware version of this wifi module everything works reliable. The funny thing is that the version of the wifi module has not been change, i. e. it is v1.0 for both hardware revisions. The changes can be seen at the first glance by looking at the boards. BTW: is there any possibility to solve this issue by flashing the software of the older hardware revision?
Thank you in advance for further support.
We would like to use containers on the bpi. But for that the compile option “CONFIG_UTS_NS” needs to be provided. Could you please add this option with the next build? BTW: Do you have any description/guide on how we can build the kernel by ourselves?
Kernel you can build as you can build any AUR package. Search the archlinux AUR, linux-bpir64-git is the name of the package. Basically you clone it, cd into it and run makepkg. That’s all, very simple.
AUR Packages don’t support crosscompiling, so you need to run it on the bpir. Use the command screen -R on the bpir64 to create a commandline you can detach from with ctrl-a + d. You can then close the ssh session and leave the build running. Reenter ssh and execute the same screen -R command to continue. Suggest running on Emmc but SD will also be fine but wears out eventually.
You could share your led experience in a new topic here on the forum if you like. It is also usefully for other then archlinux users.
About mt7615 i do not know, I do not own one
I will look at the new config option at a later moment in time…
A2 cards don’t work so well on linux. Have not tried it, but you might have trouble using A2.
Edit: seems latest linux kernels now do have A2 support, so it may work without trouble. Cards would be rated for continuous use anyway, which is better for building in the bpir64.
However, the BPIR64 has fixed 3.3V to the SD card. This means that the faster protocols cannot be used.
It already is enabled since 01-Mar-2023, so just need to update the kernel See:
Linux kernel for R64 and R3, include clang option - aur.git - AUR Package Repositories (archlinux.org) where the change was applied.
If someone wants to activate the blue LED (Keks wrote above that he tried to add). I did it like this : nano /boot/dtbos/led_blue.dts
/dts-v1/;
/plugin/;
/ {
model = "Bananapi BPI-R64";
compatible = "bananapi,bpi-r64", "mediatek,mt7622";
fragment@0 {
target-path = "/leds/";
__overlay__ {
blue {
compatible = "gpio-leds";
label = "bpi-r64:pio:blue";
gpios = <&pio 85 1>;
default-state = "keep";
function = "gpio_out";
//color = <3>;
};
};
};
};
Then run the command :
/usr/bin/bpir64-writefip
After the reboot, you can already use :
echo 1 > /sys/class/leds/bpi-r64\:pio\:blue/brightness #// on
echo 0 > /sys/class/leds/bpi-r64\:pio\:blue/brightness #// off/dts-v1/;
/plugin/;
&leds {
blue {
compatible = "gpio-leds";
label = "bpi-r64:pio:blue";
gpios = <&pio 85 1>;
default-state = "keep";
function = "gpio_out";
//color = <3>;
};
};
Try this for short
wonder about blue led…in schematics it is labeled LED_WLED_N (and yes connected to GPIO 85)…maybe thats the cause it was not added to mainline DTS (possibly connected to anything else like Wifi)
you can also change it directly in kernels dts:
--- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
@@ -70,6 +70,13 @@ led-1 {
gpios = <&pio 88 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
+
+ led-2 {
+ label = "bpi-r64:pio:blue";
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pio 85 GPIO_ACTIVE_HIGH>;
+ default-state = "keep";
+ };
};
memory {
btw. compatible is normally 1 level up, function imho not needed, why do you want state as keep?
We are using the standard dts prebuild, so offbeat found the correct way to add it as overlay.
If the short version is functioning correctly I will add it to the collection of overlays that is installed with the script.
At first I tried to activate via &leds
but got an error :
Failed to apply '/boot/dtbos/led_blue.dtbo': FDT_ERR_NOTFOUND
I think the reason is that leds is not declared in DT as a label that can be accessed by a link. But the option with fragment@0 worked for me.
I think “keep” allows you not to light the LED when you turn on the router. The user himself determines the logic of the LED’s behavior in scripts.
Then the short new style version would be:
/dts-v1/;
/plugin/;
#define LED_COLOR_ID_BLUE 3
#define GPIO_ACTIVE_LOW 1
&{/leds} {
blue {
compatible = "gpio-leds";
label = "bpi-r64:pio:blue";
gpios = <&pio 85 GPIO_ACTIVE_LOW>;
default-state = "keep";
function = "gpio_out";
color = <LED_COLOR_ID_BLUE>;
};
};
Added some defines… If this works, I will add it. Why do you have the line with //color = <3>; commented out?
I did not get a positive result right away, I tried options for different examples. I tried to adhere to the generally accepted standard. It worked in such an edition, I did not continue the experiments, I left it like this. As I understand it, it’s more for people who will work with this code, according to the idea there should be a color written in letters like in your example.
Thank you for your quick reply. We weren’t aware since we weren’t up-to-date. Now that we are up-to-date we’ve seen that the kernel has been build using this compile option. Thank you also for your hints on how to build the bpir64-package on our own. We will try it later.
Thank you. This worked for us as well 
Unfortunately, the optimizations proposed by Eric didn’t work for us, so it has something to do with the fragment@0, I guess.
Guess #define cannot be used, so it needs to be:
/dts-v1/;
/plugin/;
&{/leds} {
blue {
compatible = "gpio-leds";
label = "bpi-r64:pio:blue";
gpios = <&pio 85 1>;
default-state = "keep";
function = "gpio_out";
color = <3>;
};
};
It is added to the script.
define can only be used if dts is passed through c-preprocessor (like in kernel build-chain) 
dtc alone is not enough (i guess you use dtc only)
Indeed. The last one works ok and is now added to the script. In a new build of image it will already be added.
Some changes that also apply to R3 version:
The script now is much more fool proof. Continuing after download hickups.
Major settings are now chosen with an interactive menu. Some advanced tweaks can be done by changing definitions at top of script.