Slowing down the PCIe bus

How can I slow down the PCI bus that goes to the radio ?
I have hardware problems with instability, sometimes it won't start, sometimes it will fall off.

The CPU is the MT7621D RAMIPS Mediatek
The Radio the MT7615D

To be clear, are you asking how to change the PCI Bus Clock?

I assume you asked the question because of this issue?

But I think the problem is bugs in the OpenWRT drivers.
Sometimes the WiFi doesn't start.
Sometimes it disappears after some time.
Sometimes 5G appears, and 2.5G a minute or two later.
Sometimes it starts after many minutes.
When it doesn't start, from the menus the radio shows online.
During one test, 5G it was very fast, during other test it is very slow 5MB

Can you provide the actual model information - so we can cross reference it with supported devices on the Table of Hardware?

Or you could provide the output of:

ubus call system board

My custom board.

Do you want DTF config ?

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

I don't understand why you say that.
Compiling with a custom DTS has nothing different from the official.

As a reminder, I asked so we can cross reference it as a supported device on the Table of Hardware.

Are you able to provide this information?

It's difficult to determine if your device is supported without this information.

# ubus call system board
	"kernel": "5.10.176",
	"hostname": "PowerLink_bt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "GEVA BatteryPoE at3 bt",
	"board_name": "geva,batteryPoE-at3-bt",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "22.03.5",
		"revision": "r20134-5f15225c1e",
		"target": "ramips/mt7621",
		"description": "OpenWrt 22.03.5 r20134-5f15225c1e"

I think, this might be an interesting device; can you answer some questions about it (i'm assuming you have it):

  • Is the USB-C port for power in/out only, or also data (at what speed)
  • Is the USB-A port USB2 or 3?
  • Is the USB-A port OTG-capable?
  • Can you toggle power feeding to the USB-Ports?
  • Can you measure power in/out? on POE and/or USB?
  • Is the LAN Port capable of receiving power via POE?
  • Have you found the serial port?
  • What does it say? boot log pasted somewhere?
  • Do you have pictures from the inside?
  • Can you post the 6 files mentioned on page 6 of the manual somewhere? (LED and Power config?)
  • Did you test the available voltage range from the claimed QC3.0 support? 3.2V - 20V?

From the other info you posted, iiuc, it looks like the device uses a recent-ish kernel on a more-or-less well-supported platform combo (MT7621 + MT7615 chipset) with more-or-less standard luci (Openwrt Logo and UI is screenshotted in the manual PDF (but an older 19.07 version, not the current 22.03)).

So If you can get to the serial port, you can probably just attempt to tftp-load some initramfs snapshot builds from devices from the same arch.

If you answer some of the above questions, others with in-depth knowledge can probably suggest good candidates and/or advise on possible dts-tweaks needed for your device.

Note: I may be misreading this somehow, but the manual includes iperf3 results that look underwhelming. (The port is GBE (as per manual), not FE, no?)

Only i/o only, data only for QC

Only 2 wire to MT7621, then USB2

I don't know, if MT7621 is then yes.
I put it for usb sticks or SIM modems.

I don't know if I understand correctly,
USB-C is a powerbank QC
USB-A has a 5V 1A power supply

On at2 version, the one with the diplay, I have a current shunt on the battery.
From those I calculate charge, discharge, or PoE W.
In the bt version I only read the PWM of the stepUp, I have an approximate idea of the current on the poe.


On at2 the consolle is connectet to the small CPU
On the bt not, maybe on the next version.
Not other serial port used.

This unit has more problems than the others; perhaps it has a hardware defect.

I have delivered the other units. I will receive more PCBs soon.


5V & 9V 2A
Next version maybe 5V & 9V & 12V 2A

It comes from a previous build

I didn't understand anything.
I can connect the console to my PC.
Did you understand that it is my design ?
I designed the board. tftp is via eth, not serial.
I have three ways to upload firmware, .bin
Via Flash key, via uboot (Flash Key, TFTP, HTML page) and via OpenWRT
"initramfs snapshot builds" this I don't know what it is.

I copied the manual from another manual of the smaller model.
In the first prototype I did, hyperf was 500M bidirectional, CPU to PC, via ETH

I don't know what this is, I only connected the WAN port of the MT7621D, the P4

1 Like

Can you, from Linux side enable/disable power on the USB and POE port at will?

Ah, OK. Do you know of a POE af/at/bt (powerbank) device with USB-C QC3.0 support with full voltage range supported?

I'm assuming your goal is to diagnose, whether your problem is solved with a more recent kernel (and openwrt release)

Not until you wrote that. Before I had assumed, that you had received a pre-sale prototype, since the webshop says "Available starting August".

Upload to where? Flash, or RAM? To make testing faster, I recommended InitRAMFS images, which can run from RAM, without needing to be flashed to permanent storage.
Much faster, and doesn't wear the flash.

The common/speediest way to test INITRAMFS images is to tftpload them into RAM via U-Boot commands, and "bootm" from RAM.

The builds from . With the above Uboot-Serial-TFTF-INITRAMFS workflow it takes barely a minute to test an image from the above list without danger to your current flash contents.

Ah, that make sense. the iperf figures looked they were from a FE(FastEthernet) 100MBit device as opposed to a GigaBitEthernet device

On this version not.
Is easy to change if there are quantity.

PoE to USB or USB to PoE ?
I don't know. I can do that.

I build the latest version, will compile the next one as well.
The previous one was much worse.
I don't know if anyone is still working on the problem.
There are discussions about it, but I don't understand everything.

Available from end of June 2023

But this is helpfoul for developer, i'm not.
It would take me too long to figure it out, my available time is negative by a lot.