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.
Latest ready to download image:
Download v1.3 SD card version Router setup (301MB) Kernel version v6.3.10 (linux-rolling-stable), Linux version latest (Arch Linux has rolling updates)
Write the image file for sd-card to the appropriate device, MAKE SURE YOU HAVE THE CORRECT DEVICE!
xz -dcv ~/Downloads/bpir64-RT.img.xz | sudo dd of=/dev/sdX
1 Like
New images available for download:
www.woudstra.mywire.org/images/
The path includes images for different setups.
Thanks again for your ongoing support.
I started to setup my bpi R64 as an PPPoE client (behind a bridged VDSL modem) via PPPd service. In PPPd I setup my ISP config using eth1. Unfortunatelly this does not work. Do you have any experience with such a setup? Is it the right way to use eth1 for this, especially in regards to the DSA?
Maybe you @ericwoud or @frank-w have some advices for that?
Thanks in advance for your reply.
Error message:
Plugin pppoe.so loaded.
PPPoE plugin from pppd 2.5.0
Send PPPOE Discovery V1T1 PADI session 0x0 length 12
dst ff:ff:ff:ff:ff:ff src 26:6a:0a:3e:95:8d
01 01 00 00 01 03 00 04 1c 13 00 00 ............
[service-name] [host-uniq 1c 13 00 00]
Send PPPOE Discovery V1T1 PADI session 0x0 length 12
dst ff:ff:ff:ff:ff:ff src 26:6a:0a:3e:95:8d
01 01 00 00 01 03 00 04 1c 13 00 00 ............
[service-name] [host-uniq 1c 13 00 00]
Send PPPOE Discovery V1T1 PADI session 0x0 length 12
dst ff:ff:ff:ff:ff:ff src 26:6a:0a:3e:95:8d
01 01 00 00 01 03 00 04 1c 13 00 00 ............
[service-name] [host-uniq 1c 13 00 00]
Timeout waiting for PADO packets
Unable to complete PPPoE Discovery phase 1
Are you sure the pppoe session has to be done directly on eth1? In Germany most ISP have pppoe sessions on vlans
I guess you are talking about the vlan tagā¦? The VLAN tag (tag 07) is handled via the VDSL modem (Draytek Vigor 130 in bridged mode) already. Thatās why I thought no further actions have to be taken or do you think I get sth. wrong with that?
Basically I did it like this:
One step further: as suspected it is something about the DSA. Now I used WAN instead of eth1 and before that I deleted WAN and AUX from brlan-bridge. Now I receive the following output:
using channel 14
Using interface ppp0
Connect: ppp0 <--> wan
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x105e19d9>]
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup
The problem here seems to be a missing kernel module CONFIG_NF_CONNTRACK_PPTP. So the next step will be building the kernel with this module and then I will report the result.
Iām pretty unsure about sideeffects or any negative implications regarding changing the WAN network configuration as @ericwoud provided, because there could be hardware offloading involved, as @ericwoud wrote in the readme (port 5). What is your opinion about that? Thank you in advance for your help.
Now Iāve tried it with the additional kernel module, but the error still persists. 
Iām sure you have to create the vlan and need to create the pppoe on the vlan interfaceā¦i donāt think that the vdsl modem does the vlanā¦mostly more than one vlan is needed (e.g. one for internet and one for voip,maybe a third for iptv),each one with its own pppoe sessionā¦in my case the vlans need to have different mac adresses which they normaly do not have because vlans mac is inherited from parent interface
Thank you very much for you reply. Do you have any configuration examples? 