Support for Mikrotik LDF 5 ac

For Developers
1

The Mikrotik LDF 5 ac (RBLDFG-5acD) is a device in the formfactor of a satellite dish feed (in sat tv called LNB) with a single Gigabit ethernet port with PoE and 5 GHz 802.11ac 2x2 MIMO single radio for bit rates up to MCS9 (867 Mbps). It can be combined with parabolic offset dishes of various size and gain to connect over large distances in point-to-point connections. See https://mikrotik.com/product/ldf_5_ac

The LDF 5 ac is ipq4018 based (quad core 32 bit ARM, 716 MHz) and comes with 256 MB RAM and 16 MB flash.

With the valued help of robimarko have created OpenWrt support for this device that can be tested here:
github.com/wwortel/openwrt (choose branch Mikrotik-LDF-5-ac).

2

Nice work @wwortel.

It would be really helpful if you rebased and squashed your commits. That way, one commit can show the device support being added. Then all you should need to get this added to OpenWrt is more in the commit message: device details and a signoff.

rebase example: 
git switch Mikrotik-LDF-5-ac
git switch -c Mikrotik-LDF-5-ac-rebase
git rebase -i master

In the rebase -i editor, leave the first LDF-5-ac commit as pick, and change the rest of the LDF-5-ac commits pick into squash.
delete the lines for the commits that master will already have, but git should do this for you.
once you are happy & have tested the rebase, you can switch back to your main device branch, and reset --hard it to your rebase branch, then push --force this to github.

You can modify the last commit with git commit --amend

If the networking is similar to the SXTsq5ac's, you might need some extra settings to get VLANs (1 and 2 are usually problematic) working correctly with the Qualcomm driver.

3

thanks! Will give it a try.
Question:
in Mikrotik's original .dts qcom,phy_mdio_addr, qcom,poll_required, qcom,forced_speed, and qcom,forced_duplex are listed directly under edma@c080000. You put them under the &gmac subentries, one level lower. Is that intentional? Probably things that are not gmac specific but always applicable could be a level higher. Will the driver still find it when one shifts a .dts definition level up or down?

4

and also:
Mikrotik has two .dts entries under edma@c080000 that do not return in OpenWrt:
qcom,wan_port_id_mask = <0x10>; and
port_map = <0x04 0xffffffff>;

Would they only be needed in case of used of the switch and multiple ethernet ports?

Update:
Have tried these .dts mods but the 'LDF 5 ac' single ethernet port does not come up and the eth led stays off.

5

With single-phy, I think you will need to use ucidef_set_interface_lan "eth0"
If still no ethernet, you may need to change the phy_mdio_addr as well.

The differences to the Mikrotik OEM DTS: You are better off looking at OpenWrt device dts with single-phy, rather than the OEM DTS, as they use different drivers.
The OpenWrt ess-switch and ess-edma ipq40xx drivers are here

Qualcomm did not upstream these drivers, so vendors take QSDK ess-edma and ess-switch from some point in time and work from there.

6

Success! Needed in .dts to deactivate the switch, to add your suggestions, and to activate ess-psgmii.
Now OpenWrt boots with lan @ eth0. 02_network entry is now identical to that of sqtsq-5-ac2. Have updated github.
Will now try to read up on how to do this rebasing and squashing.
The one entry in your suggestion that I could not find in the drivers is phy-mode. It only gets parsed in the Distributed Switch Architecture driver, which appears not active here.

7

Hi @wwortel,

I saw you are having some trouble with wireless performance (1, 2).

It might be worth mentioning on the PR. Adrian will probably be able to point you towards someone with a good understanding of ath10k, and you also may not want the device merged (yet) if you are not happy with performance. Another hint to git fetch origin master; git rebase origin/master for your PR branch, so that you are not adding additional commits (Merge branch 'openwrt) to your PR.

There is an OpenWrt build config option that enables the ath10k debug options:
openwrt/package/kernel/mac80211/ath.mk: CONFIG_PACKAGE_ATH_DEBUG
You will also need to set the debug mask value on device.

The OpenWrt IRC, or openwrt-devel mailing-list might find someone suitable. You do not get much exposure with a forum post buried in an old thread.

You might also want to look for who has made commits to ath10k and ath10k-ct in OpenWrt. You could email them, or tag them in the forum, or PR, to try and get their help.

If you are seeing that ath10k-ct has regressions compared to ath10k, the ath10k-ct developer may be able to help.

Good luck

8

@johnth
Thanks for your advise; although I've been silent, I have not given up and am making good progress.
It turns out that the QCA firmware does have an option to set the so called TX_ACK_TIMEOUT via the wmi interface. So hope to be back soon with a full solution that is more elegant than the hack currently in ath10k to constantly write to a register, countering the actions of the firmware that resets Coverage Class all the time to zero. Sensitivity of the 5 GHz radio is fine. So this Coverage Class item is the only thing missing.

1 Like
9

Have you tried disabling the low ACK disassoc that OpenWrt has by default?

10

Hi Robert,
Thanks.
Since this morning have the Coverage Class setting working via the elegant way and tested on a long distance link. The wmi interface to the QCA firmware, unlike what current backported ath10k' source code suggests, does cater for setting this. There is an addition to ath10k on its way written by brainslayer that takes care of this, and more, for the ipq40xx. It is basically unrelated to this particular 'LDF 5 ac' device as any ipq40xx device that needs to work over larger distances will benefit. All credits to BrainSlayer who provided the essential clues.

1 Like
11

That is great as it will universally work.
Great work.

12

A patch that provides for setting of Coverage Class (Distance) on these ipq40xx devices can be found here:

13

I don't have my github credentials at hand right now, but quite a few unrelated changes crept into your PR, when you pulled in changes from master, instead of rebasing.

14

tnx, have cleaned it up.

15

Hi, Can I ask for a working copy of the firmware. I am too dumb to understand the highly technical talk here.

Thanks in advance