There is no lan5
https://wiki.fw-web.de/doku.php?id=en:bpi-r4pro:start#network
I guess you mean the mgmt interface (builtin 1G port). Not sure if it blinks for me,i’m sure i had tested this before upstreaming.but not sure if i had changed 6.18 after it.
Just assign ip address to it and test network ignoring the leds for now. I try to look when i’m back at home.
Seems this is the mgmt that does not lights up any LEDs.
Summarizing what I was able to check:
My board has:
Mgmt is unrelated to combo port…mgmt is the soc builtin 1G port. Combo is sfp+10gPhy right of mgmt (last rj45 on left side).
Strange that leds do not work…definition is there
Ah,mom,youean not link led,but the activity led…afair that one was not connected in hardware
maybe misprint on a color?
I see “GREEN” as LED:
&gsw_phy0 {
pinctrl-names = "gbe-led";
pinctrl-0 = <&gbe0_led0_pins>;
};
&gsw_phy0_led0 {
status = "okay";
color = <LED_COLOR_ID_GREEN>;
};
In the OpenWRT file I also noticed other slight discrepency - the Those are all defined:
&gsw_phy1 {
pinctrl-names = "gbe-led";
pinctrl-0 = <&gbe1_led0_pins>;
};
&gsw_phy1_led0 {
status = "okay";
color = <LED_COLOR_ID_GREEN>;
};
&gsw_phy2 {
pinctrl-names = "gbe-led";
pinctrl-0 = <&gbe2_led0_pins>;
};
&gsw_phy2_led0 {
status = "okay";
color = <LED_COLOR_ID_GREEN>;
};
&gsw_phy3 {
pinctrl-names = "gbe-led";
pinctrl-0 = <&gbe3_led0_pins>;
};
&gsw_phy3_led0 {
status = "okay";
color = <LED_COLOR_ID_GREEN>;
};
vs in the file you have we have only gsw_phy0, and it says :
/* R4Pro has only port 0 connected, so disable the others */
&gsw_phy1 {
status = "disabled";
};
Could be some difference between r4pro vs the r4pro-8x.
Are those actually not connected? but somehow they exist in the bpi-r4-pro-8x.dts
There are also some mdio_bus definitions:
mdio_bus {
/* external Airoha AN8831X is connected to Mxl 2.5G switch */
phy24: ethernet-phy@24 {
reg = <24>;
compatible = "ethernet-phy-ieee802.3-c45";
reset-gpios = <&pio 83 GPIO_ACTIVE_LOW>;
reset-assert-us = <200000>;
reset-deassert-us = <350000>;
firmware-name = "as21x1x_fw.bin";
Possibly we can add them and few others stuff to the .dtsi you have, for full completness of this board definition?
The r4pro dtsi is a common dtsi for both r4pro variants (4e and 8x) i have only 8x. Does link led work with your downstream openwrt?
Based on shematic only port 0 is exposed to rj45…not checked the fpc connector which is maybe enabled downstream.
Yes. In Openwrt - the led works.
But it’s interesting as dtsi of Openwrt defined it as green, buy actually yellow light comes up only. (Maybe they connected only yellow on the board but marked it with green? Did not check schematics).
But in your U-Boot dtsi, no led comes on on this port.
I also have r4-pro-8x variant myself.
By '‘common’ you mean it’s superset (union) of those two? Or ‘common’ means only things that are in both variants are included (intersection). if someone will be using specific variant, does it mean his board will be fully supported or just common things, but he will not be able to use boards full functionality?
I’m actually looking at using full board functionality to the max and reason for me installing Ubuntu is I don’t want to have openwrt as this os is very restricting regarding packages.
Are you talking about uboot or linux? Both use indepent dts. I uboot i know that no led is working,in linux the yellow one should work and green was afair not connected…so linux dts should be right (and downstream wrong due to color).so in downstream openwrt you have also only the yellow led working,but green in dts,right?
Common means these parts are same in both variants so only defined once in the dtsi…the 8x defines parts which are different to 4e and came on top of the common dtsi…you see the 8x (and 4e) dts include the common dtsi.
in OpenWRT the yellow led lights up on hardware, but in dts for 8x I see it is defined as LED GREEN. So possibly even though it was only connected/wired as yellow led, it should still be referenced in dts as GREEN?
As for DTOs etc… I know that u-boot loads own dto, and then if kernel has dto as well, sometimes it “merges” things (not replaces), and most of the time this merging works, sometimes there are issues.
What I would look for is:
or
I noticed you are building uImage_noDto (I think?) Does it mean kernel does not ship with DTO and uses fully the one that is in u-boot?
I think maybe we can just add ability to specify somewhere exact model of the card, so at least the fully booted ubuntu kernel can benefit from all hardware features.
Can the actual pro-8x somehow be added either to your u-boot (to be selected as model), or generic to u-boot, but then full ubuntu with pro-8x?
What do you think?
I basically would like to get advantage of entire board functionality (to not be restricted by DTI that might be too generic), and advantage of ubuntu image, so I can install lots of packages I need etc.
P.S. You have cool repos! I really like your github!
My uboot uses a generic r4pro dtb independ of 4e or 8x as the differences have no driver in uboot (sfp,10g phy). Ram is only selected by the right bl2,not sure if i use 8g bl2 for image but i think i do (for r4 i do not).
Btw. DTO stands for devicetree overlay,which has to be applied to a base dt. In our case there is a base dtb like for r4pro 8x board and then dt overlays like for sdmmc or emmc are applied.
The ubuntu/debian uses my “full” dtb at current state of development for mainline. It makes no sense adding dt nodes which have no matching driver or are untested with upstream linux.
I still do not know which function do you miss in linux compared to downstream and where something in dt is missing.
This is a leftover from older boards (r2 r64) so these files (uImage_nodt + dtb) are built and packed for all boards. And image builder just unpacks all in kernel tarball.
Basicly they are not needed except anyone will play with exlinux config or apply own overlays not packed into fit image.
So far the only thing (that I know of), that is missing - is the LED on the port. Otherwise it is not possible tell physically if cable has CARRIER or not.
Can you possibly try to change this led to GREEN one? I can then test it if this solves the LED issue.
Regarding DTS, DTI and and other features - I haven’t yet started enabling those, so I haven’t looked closely.
The dts is designed in include model (dti etc), so common parts are common and then when it runs on specific board, the actual board dtb is compiled.
Is there any specific reason why in your kernel images repo you try to “merge” the specifc boards? Instead of just going “easy approach” of just adding to the dts folder all the boards exact configs (from vendors), and have the users be able to specify variant for the exact board? So there is no guessing that “manual merge” was done correctly? This in my opinion would solve all the potential compatibility issues (like with the LED we have now), and also any potential future ones (in case they occur).
As the 4e and 8x is actually different board, the OS should basically boot with that explicit DTO, not some merged DTO or upstream DTO.
apologies for out of topic … @ericwoud any plans to add rpi-r4 Pro ? I am keen as i am finding against debian i need to build a lot of other packages whereas with arch i can trust it is rolling on the latest
Maybe at some point, but not any time soon. Still need to fully add R4, when the wifi hardware issues are solved probably. Then the R4 lite , etc…
I am currently still fixing small bugs after a major overhaul of the script and packages. Still small issues pop up.
The color is unrelated to function and as far as i understood you,the issue is only in uboot (where led part is maybe missing),not linux.
Why defining same things twice when they are same? User do not merge anything…this is done by code in kernel buildchain. User have a 8x dtb and 4e dtb…then overlays for changing hardware like sdmmc and emmc where hw switches define what to use. Currently there is only the 8x supported as the 4e only contains common parts.
The issue is actually in linux. In linux, when ubuntu finishes login, the LED does not come up.
yes, I was referring here to the build scripts and the dts that is checked in into your repo. As the dts is for r4-pro, and looks different from content of r4-prod-8x (that I see on OpenWRT repo, at the same time OpenWRT repo does not have just the r4-pro, they have r4-pro-8x etc). Thats why I was wondering - did you take those r4-pro from other location or manually picked up some changes from r4-pro-8x and “merged” into the r4-pro dts you have checked in into your u-boot and/or linux repo.
I am wondering - is there a way you can include the actual fully r4-pro-8x from the OpenWRT repo I mentioned (where everything works), and add just to the build of the linux kernel in your repo that will build as part of that specific variant?
downstream openwrt does not support the 4e variant, but i have prepared this in my repo and in mainline. just copy dts does not work as we need the bindings in drivers. you cannot just copy downstream drivers to mainline linux…and dts alone does not make things working. trust me i know what i do (except from small bugs which can always happen) 
it is only a small bug in the led-part where i’m not sure it is dts related…could be config too. 6.19 (a rc1 which i have on my tftp - but 6.19-main does not) works, 6.18 on my tftp not. but led is lighten up in 6.19 when link detected, but also when link is set to down. dts and config have no differences there, only the phy-led config…maybe a naming issue (but afaik kernel renames leds then and proceed)…currently compiling actual versions for testing…
so only one led is connected to gpio 64
gsw_phy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
interrupts = <0>;
nvmem-cells = <&phy_calibration_p0>;
nvmem-cell-names = "phy-cal-data";
leds {
#address-cells = <1>;
#size-cells = <0>;
gsw_phy0_led0: led@0 {
reg = <0>;
status = "disabled";
};
gsw_phy0_led1: led@1 {
reg = <1>;
status = "disabled";
};
};
};
&gsw_phy0 {
pinctrl-0 = <&gbe0_led0_pins>;
pinctrl-names = "gbe-led";
};
&gsw_phy0_led0 {
color = <LED_COLOR_ID_YELLOW>;
status = "okay";
};
gbe0_led0_pins: gbe0-led0-pins {
mux {
function = "led";
groups = "gbe0_led0";
};
};
in pinctrl driver:
static const int mt7988_gbe0_led0_pins[] = { 64 };
static int mt7988_gbe0_led0_funcs[] = { 1 };
so looks right so far. checked for possible missing config symbols, but seem all enabled.
fixed led bug in 6.18-main…it was not dts related
the as21 phy driver have set phydev->phy-id for all phys and assigned 0 to the mt7988 internal 1G phy, so phy driver was not probed and so did not initialize the led
i applied an earlier fix from 6.19 which got “reverted” by the 1.9.1 driver version and was not backported to 6.18 yet…phy led on mgmt interface now working for me.
in 6.19 i applied a patch from @rmandrad which gives more detail than my “quick fix” (which i have reverted to keep in tree - will be removed in 6.20-rc)
@Michal_Zygmunt you do not need rebuild/reflash image, just pull 6.18 kernel-tree, rebuild kernel only and use install option of build.sh for sdcard or wait till my pipeline has finished and then install the kernel (itb should be enough as as21 phy driver is builtin and kernel version has not changed).
you can also install like this:
maybe just adjust your mountpoints
kernelfile=<filename>
sudo tar -xzf $kernelfile --strip-components=1 -C /media/$USER/BPI-BOOT BPI-BOOT
sudo tar -xzf $kernelfile --strip-components=2 -C /media/$USER/BPI-ROOT/lib/. BPI-ROOT/lib/
(commands copied from buildimg.sh with changed mountpoints where card is mounted by default in ubuntu)
Thanks Frank! I will try it tomorrow. Awesome!