[BPI-R4] TODO List


I think most things now work on vanilla 6.9.x kernel (with some patches) for the BPI-R4. For supporting BPI-R4 on a vanilla 6.9.x kernel what else is needed, i.e. what is the definition of done?:

  1. Network RSS (Attempting to get iperf3 UDP > 1 Gbps, TCP > 5 Gbps and closer to 10 Gbps) Note: I am working at this item at the moment. Note: RSS uses a hash to spread the incoming traffic across more than one CPU. The hash is only different if the src/destination IP address and TCP port are different. So on its own it will not improve iperf3, but it will mean one can run 2 iperf3 at the same time, on different ports, to get two tcp stream or 5 Gbps totaling 10 Gbps. I don’t know if mediatek’s implementation also understands VLANs or not.
  2. Network LRO (Attempting to get iperf3 TCP > 5 Gbps, and closer to 10 Gbps)
  3. UBOOT change so that Linux kernel is more portable across platforms.
  4. General SFP improvements.
  5. Wifi (waiting more wifi7 card availability)
  6. GPIO - Control of the GPIO Header features.
  7. Upstream the above so they get into mainline kernel
  8. Anything else.

You mean LRO (large receive offload),as daniel told me it is a receive issue not a transmit one. But he is also working on it,told me today)

My last state for lro was this (upported patches from @balika011): Commits · frank-w/BPI-Router-Linux · GitHub

For wifi i created this thread:

I have not yet verified gpio header,but biggest parts are listed so far…and of course the upstreaming which is much because code mostly has to be changed to get it accepted. @dangowrt do a great work here.

Definition of done in my eyes if the changes work stable and are upstreamed…maybe backported to openwrt kernels.


@jcdutton great idea. Could you link to the respective forum threads or single posts for each of those topics? Frank already listed two in his reply, I think. Then this could be a good overview if pinned.

@frank-w can you pin this post or do we need someone like @simon or @sinovoip to do it?

I have not found a way to pin a thread.

Anything else by @dangowrt

Pcie2 is working now in linux (patch should be already merged)…clock depends on pcie3.

1 Like

Just control the state of the gpio pins?

On linux nowadays use libgpiod, for example as in here:

GPIO Programming: Exploring the libgpiod Library | ICS

I have upported dma handling from sdk and rss/lro as far as i had to 6.9

Only checked if dma-patch does not break mt7988 (iperf good now),not yet tested rss/lro (upported patch from @balika011),but in older version there was something missing,but it’s a start :slight_smile:

1 Like

@frank-w I’d love to import the patches from your tree to OpenWrt but can’t because they are missing a Signed-off-by: line. Can you add that to each commit currently missing it?

1 Like

pinctrl should allow to use all pins as GPIOs. Maybe some groups will have to be split for more granularity, but generally it should all work.

1 Like

net: mediatek: make MTK_DMA_SIZE soc specific


arm64: dts: make pwm-fan work on r4

have now SoB…the other 2 are not really tested (upported patches for RSS/LRO)


In my initial work on RSS, I have found a lot to problems with the current drivers for 6.9-rc1. So, I think I am going to try to fix those before finally doing RSS.

In summary, If the SOC supports netsys_V2 or above, in some places it is trying to use V1 registers with a V2 SOC and in other places it is using V2 registers with a V2 SOC.

We need to fix this all so that the driver uses V2 registers with a V2 SOC and visa-versa. So that it matches the openwrt drivers that correctly does this. Unfortunately, the openwrt does it in such a way that it is unlikely to be able to be up-streamed to mainline.

1 Like

I notice that the current mtk_eth_soc.c just uses the device tree to detect which chip it is. Is there not a more robust way to detect which chip we have by reading an ID register or similar?

1 Like

Where do you see this? Maybe v2 has also v1 registers?

Have you looked in my code? Balika has done some cleanups before rss/lro

Dma patch only tested on r4 over switch yet

1 Like

Is bridging between 2xSFP+s accelerated by hardware?