Latest OpenWrt for former ar71xx Device: Mikrotik RB912UAG-5HPnd


Im I right in the assumption that if I want to flash OpenWRT on a Mikrotik RB912UAG-5HPnd, that the latest Image is 19.07.10 because it has not been ported to ath79 and generic images do not exist for ath79?

The latest Release then would be:

Thanks for your help
best regards

It looks like this, yes. There is, however, support for the RB912UAG-2HPnd in ath79, I don't know what the difference to yours is. However, porting should be pretty straight forward if the devices share some (most?) internals.

I think they should nearly be identical. One has 2.4 Ghz WIFI, the other one has 5 Ghz.

Can you link me to the 2HPnd Image? I want to try it out of curiosity, but can not find it in the newest release.

no it's not in ath79

This .dts tells otherwise:

However, there seem to be no builds, so maybe it fails?

Can we see why it fails and fix this?

I just set up a Linux Mint and tried to compile OpenWRT myself.
To my surprise it works fine and is useable on the device. (The Image for the 2HPnd is working on the 5HPnd, even though it reports the wrong model in the overview page.)

Which raises the question: Why can't we have an autobuild for this device? On my old notebook it takes hourse for the compile to finish. :confused:

We can have a build: You need to fix the model number by adding a new device, create a shared dts and make sure that everything works. Then you can create a pull request and once it is accepted builds will show up.


I would be happy with an automated build for the 2HPnd, where a dts already exists.

How can we add this dts to the autobuild, before rely on it for "cloning" to 5HPnd?

Sorry, I misunderstood the question: I don't know why there is no build. You might want to raise this question on the mailing list, as it is more actively used for development purposes.

Thanks to @robimarko, who directed me to the github ressource, which does very well in explaining why it was intentionally disabled:

Note: It does not matter if someone runs LEDE, OpenWRT 19.07 or the newest OpenWRT. All builds are affected from this issue and could damage your device. Therefore they stopped building it.

Ah sure, now I remember having read that some time ago while researching other Mikrotik devices!

One last question on this topic:

My device can use either USB or mPCIe, not both at the same time.
In the old times there was an uci option system.usb_power_switch to toggle between those two. This is not the case anymore on newer OpenWRT builds.

How can someone switch those usb_power now?

Okay after some time I found the git commit for this usb_power_switch. It was implemented in 2016 and has been lost in the transition to ath79.

I guess if you want to use the power-switch in ath79 you would have to change it manually. In the old LEDE days it went like this:

echo "1" > /sys/class/gpio/gpio52/value

The new way is:

echo 0 > /sys/class/gpio/power-usb/value
echo 1 > /sys/class/gpio/power-pcie/value 

Where do i best put it, if i have to do it on every boot?

Probably /etc/rc.local. I'd doublecheck that it doesn't run before something else may change the values back.

The bigger question would be, does it make sense to leave PCI/ USB unpowered?
If not, and the default is reasonably expected to be on, defining it to be on in the DTS (e.g. via gpio-hog) would be sensible.

In the ar71xx target code, there was a switch in /etc/board.d/03_gpio_switches file.

I tried to compile an image with the same code in the file on the more mordern ath79 target.


. /lib/functions/


case "$board" in

	ucidef_add_gpio_switch "usb_power_switch" "USB Power Switch" "52"


exit 0

... but I didn't know at the time, that the gpio system has changed with the new linux kernel. Now there are somehow two different entries what used to be one value (gpio 52, 0 ==> mPCIe off + USB on, 1 ==> mPCIe on + USB off)

So here I am with the /etc/rc.local workaround.

I dont know how to implement this properly now with a switch. It could be implemented as two uci settings entries though.

Did you get anywhere with moving this forward?

no unfortunately. i do not know how to implement this correctly.