Ubuntu 24.04 LTS on Banana RPI-R4 Pro 8X

Michal_Zygmunt · February 11, 2026, 4:07pm

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.

frank-w · February 11, 2026, 4:13pm

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.

Michal_Zygmunt · February 11, 2026, 5:38pm

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:

U-boot - having either the common Pro DTO (without anything that specific 8x overwrites) and Image - having specific pro-8x DTO (so once booted to ubuntu I can use all the features of the board)

or

U-boot - having already the pro-8x DTO and kernel being either no DTO (using the u-boot one), or exactly the same DTO of pro-8x.

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!

frank-w · February 11, 2026, 6:36pm

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.

Michal_Zygmunt · February 11, 2026, 7:44pm

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.

rmandrad · February 11, 2026, 9:12pm

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

ericwoud · February 11, 2026, 9:31pm

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.

frank-w · February 11, 2026, 10:50pm

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.

Michal_Zygmunt · February 12, 2026, 12:58am

The issue is actually in linux. In linux, when ubuntu finishes login, the LED does not come up.

Michal_Zygmunt · February 12, 2026, 1:01am

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?

frank-w · February 12, 2026, 6:39am

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.

frank-w · February 12, 2026, 4:22pm

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)

Michal_Zygmunt · February 13, 2026, 7:38am

Thanks Frank! I will try it tomorrow. Awesome!

Michal_Zygmunt · February 13, 2026, 7:48am

6.18-main branch or 6.18-r4pro branch?

Michal_Zygmunt · February 13, 2026, 7:49am

Assume 6.18-main, as I noticed this commit as last one: net: phy: as21: fix phy-id overwrite for all phys (breaking leds on m

frank-w · February 13, 2026, 9:32am

The 6.18-main…endusers should stay at main branches,mainly LTS (6.12,6.18,for R4pro and r4lite 6.18).

And yes this commit fixes the phy led issue

ericwoud · February 13, 2026, 3:01pm

See:

Michal_Zygmunt · February 16, 2026, 9:17am

Hey Frank,

How do you exactly compile the 8X variant of r4-pro in the BPI-Router-Linux?

I am using 6.18-main branch.

build.conf:

uploaduser=$USER
uploadserver=r3
uploaddir=/var/lib/tftp
#uploaduser=root
#uploadserver=192.168.0.11
#uploaddir=/boot/bananapi/bpi-r2/linux

builddir=../build
ramdisksize=8G
#numproc=8

#board=bpi-r2
#board=bpi-r64
#board=bpi-r2pro
#board=bpi-r3
#board=bpi-r3mini
#board=bpi-r4
board=bpi-r4pro
#board=bpi-r4lite

#r64 with rtl8367
#boardversion=v0.1
#r2pro with rtl8367
#boardversion=v00

#mainline uboot for r64 (old ATF) needs 64bit uImage
#uimagearch=arm64

#grep whitelist filter for adding modules to initramfs
ownmodules='mt76\|bluetooth'

I am getting this:

cp: cannot stat '/work/bpi/build/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtb': No such file or directory

I can only see those files there:

# ls -al /work/bpi/build/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro*.dtb
-rw-r--r-- 1 root root 35067 Feb 16 09:07 /work/bpi/build/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-4e.dtb
-rw-r--r-- 1 root root 38422 Feb 16 09:07 /work/bpi/build/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-8x.dtb
root@0b31aec1f51d:/work/bpi/BPI-Router-Linux#

Same later during package creation:

cp: cannot stat './bpi-r4.dtb': No such file or directory

Where the file on disk is actually called:

ls -al bpi-r4*.dtb
-rw-r--r-- 1 root root 38422 Feb 16 09:26 bpi-r4pro.dtb

I can ‘hack it up’ locally so it builds, but wondering if there is any official way to do this via build.conf.

Am I missing some flag there?

Where do you specify the 8x in the build.conf?

Michal_Zygmunt · February 16, 2026, 9:20am

also - side question - can you enable KEXEC by default in your build?

I am planning to use the following setup:

/boot on eMMC that has custom initramfw + custom boot.cfg
that initramfs has custom /init script with options of different kernels, different partitions etc
that /init in initramfs loads the kernel from specific partition and use kexec to move execution to this kernel

I am planning to use two-kernel boot approach to have my boot loaded doing some more advanced stuff (ex. checking from network which kernel to boot, and then booting either full ubuntu or openwrt etc).

That’s why kexec would be beneficial to have in the ubuntu kernel that is being used with uboot.

frank-w · February 16, 2026, 11:28am

You can just build with board=bpi-r4 in build.conf

The bpi-r4pro there is only an alias to set names for e.g. upload function,open dts source and such.seems there is a bug. Basicly the r4 defconfig is used for all R4 boards with all dts(o). Uboot chooses right config based on isr4pro var and i have only 8x support.

You want to boot openwrt from running ubuntu? Or how can i imagine this? You can check this in uboot and either boot openwrt initramfs/recovery or ubuntu.