Add support for MikroTik RB5009UG

qualcommax is using the driver from SSDK for QCA8081 but I doubt this is a PHY driver issue as the driver had little to no changes.
It's more likely that mv88e6xxx driver had a regression in advertising the port capabilities.

I may be able to dig my board out and try this out over the weekend but no promises

8 Likes

Thanks! Appreciate it.

1 Like

Question about the image matching 23.05.0 (when ready). Anyone so kind to provide this?

I mean with luci and the release modules compatibility?

Thanks

2 Likes

Am I correct that the RB5009UPr+S+IN can run from the same set of patches as the RB5009UG+S+IN, with exception to its PoE functionality?

In what state is this, how feasible it to get PoE working on UPr model?

I would like to know if getting the PoE version of that router makes sense, even if not having the PoE functional for some time yet.

1 Like

This is correct. I have the PoE version and run OpenWRT on it with these patches. No PoE functionality indeed.

1 Like

I can successfully do everything except read the current port status and power (Mikrotik RB750 r2 series POE - #69 by TheChaosJack see my last two posts here. Setting the one GPIO pin could also be moved to the device tree for a more permanent setup).

3 Likes

I did not look at the API but the get_poe sounds like the status info only. Does it mean the PoE cable negotiation works for all the 8 ports and the peers are correctly powered?

1 Like

Yes PoE is fully working. You can even select off, forced on and auto for each port.

4 Likes

Thank you for the patch and dts instructions. I've simply set all ports to auto and that works exactly as I hoped.

2 Likes

Is mainline support for this device realistic this year?
I know that everyone does it in their free time and for free, that's why I'm only asking about plans :slight_smile:

I am using version 23.05 + 5.15 kernel patch
Always, if a power failure occurs, set the clock resets to 2104-12-09

[    1.510932] armada38x-rtc f2284000.rtc: registered as rtc0
[    1.516453] armada38x-rtc f2284000.rtc: setting system clock to 2104-12-09T11:58:57 UTC (4258267137)

Is it normal ?

I don't think so. I'm on 23.05 as well, and this is what I have:

# dmesg |grep rtc
[    1.485247] armada38x-rtc f2284000.rtc: registered as rtc0
[    1.490784] armada38x-rtc f2284000.rtc: setting system clock to 2023-09-18T16:28:00 UTC (1695054480)
root@RB5009UG+S+IN:~# uptime
 00:31:21 up 11 days,  5:59,  load average: 0.00, 0.01, 0.00
root@MikroTik:~# date
Sat Sep 30 08:01:55 CEST 2023
root@MikroTik:~# dmesg |grep rtc
[    1.510866] armada38x-rtc f2284000.rtc: registered as rtc0
[    1.516386] armada38x-rtc f2284000.rtc: setting system clock to 2104-12-09T11:58:57 UTC (4258267137)
root@MikroTik:~# hwclock 
Tue Dec  9 11:59:43 2104  0.000000 seconds
root@MikroTik:~# hwclock -w -l
root@MikroTik:~# hwclock 
Sat Sep 30 08:02:27 2023  0.000000 seconds

....

root@MikroTik:~# hwclock -w -l
root@MikroTik:~# date
Sat Sep 30 08:08:47 CEST 2023
...
root@MikroTik:~# date
Sat Sep 30 08:10:24 CEST 2023
root@MikroTik:~# hwclock 
Sat Sep 30 08:09:19 2023  0.000000 seconds

1 hour later

root@MikroTik:~# date
Sat Sep 30 09:10:31 CEST 2023
root@MikroTik:~t# hwclock 
Sat Sep 30 06:59:49 2023  0.000000 seconds

Edit: It was already here

1 Like

In the original dts decompiled by @adron

		rtc@284000 {
				compatible = "marvell,armada-8k-rtc";
				reg = <0x284000 0x20 0x284080 0x24>;
				reg-names = "rtc\0rtc-soc";
				interrupts = <0x00 0x4d 0x04>;
			};

But it's not in the patch.
Shouldn't it be added?

I'm on master with 6.1 patch;

root@MikroTik:~# dmesg |grep rtc
[    1.247828] armada38x-rtc f2284000.rtc: registered as rtc0
[    1.253351] armada38x-rtc f2284000.rtc: setting system clock to 2105-11-01T13:45:26 UTC (4286526326)

It's not part of adrons's nor robimarko's DTS, but feel free to test and report back. I'm not sure the DTS is supposed to actually set the hardware clock.

Just keep in mind your observations from here in out might be skewed, since you reset the clock.

Internal RTC is useless without an external battery

1 Like

I supposed so, yes. Thanks for confirming.

Were you able to look into the Marvel driver by any chance?

Sadly no, its on the TODO pile

3 Likes

I made some changes to the mtpoe_ctrl for RB5009UPr+S+IN:

  • the status of the ports can be get via get_poe - it's the mA status
  • the ports configuration is not read, which is not a problem if it's set to the known state (I did not look at the v4 driver)
  • configuration can be loaded with load_poe_from_uci
  • the gpio40 has to be set manually, e.g. in init script

I'll raise a merge request to the original repo, for now you can get is from https://github.com/prudy/mtpoe_ctrl.git, branch feature/RB5009UPr+S+IN.

3 Likes