Support for Mikrotik RB3011UiAS-RM?

For Developers
62


As is. It still need a lot of work and integration in OpenWRT.
Now it understands only uImage format! So no *.itb images, yet.

diff --git a/target/linux/ipq40xx/image/Makefile b/target/linux/ipq40xx/image/Makefile
index a670380..61277c7 100644
--- a/target/linux/ipq40xx/image/Makefile
+++ b/target/linux/ipq40xx/image/Makefile
@@ -14,6 +14,12 @@ define Device/Default
        IMAGE/sysupgrade.bin/squashfs :=
 endef
 
+define Device/LegacyImage
+       KERNEL_SUFFIX := -uImage
+       KERNEL = kernel-bin | append-dtb | uImage none
+       KERNEL_NAME := zImage
+endef
+
 define Device/FitImage
        KERNEL_SUFFIX := -fit-uImage.itb
        KERNEL = kernel-bin | gzip | fit gzip $$(DTS_DIR)/$$(DEVICE_DTS).dtb
@@ -53,8 +59,7 @@ DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_HW_ID
 
 
 define Device/8dev_jalapeno
-       $(call Device/FitImage)
-       $(call Device/UbiFit)
+       $(call Device/LegacyImage)
        DEVICE_DTS := qcom-ipq4018-jalapeno
        BLOCKSIZE := 128k
        PAGESIZE := 2048
@@ -98,7 +103,7 @@ endef
 TARGET_DEVICES += avm_fritzbox-4040
 
 define Device/compex_wpj428
-       $(call Device/FitImage)
+       $(call Device/LegacyImage)
        DEVICE_DTS := qcom-ipq4028-wpj428
        DEVICE_DTS_CONFIG := config@4
        BLOCKSIZE := 64k
@@ -112,7 +117,7 @@ endef
 TARGET_DEVICES += compex_wpj428
63

Thanks, how do I use it ?

I may have figured it out, and edited the Build.sh accordingly

64

First edit Build.sh file.

OPENWRT_DIR variable is your OpenWRT dir path.
KERNEL_IMAGE variable is determines which uImage to use

Then, do sh ./Build.sh
If everything goes well, then an ./loader file is formed.
Next, with the help of an bootp/tftp, upload this file to a RouterBOOT.

65

Thanks for all your work.

66

Not at all. When you will have results(dts file changes, etc..) for rb450Gx4, put them here please.

67

I will post WIP as it goes here.
Current DTS and config should not work at all as it is simply do have something to boot.
But Toshiba BENAND ECC support is backported, LDO driver for SD card and SDHCI driver are included.

68

qcom-ipq-aux-loader has been updated. Please test the new version. Thanks.

69

It works, even printing works now.

transfer started ................................... transfer ok, time=5.71s
setting up elf image... OK
jumping to kernel code

TEXT_BASE = 0x81820000

Kernel header:
  ih_magic = 27051956. magic OK
  ih_size = 4607392
  ih_name = 'ARM OpenWrt Linux-4.19.19'

Copy kernel...Done
Starting kernel at 0x80208000

I am now trying to figure out how the hell did Mikrotik manage to connect NAND and SPI NOR.
In decompiled DTB pulled from SPI-NOR they claim to use GPIO54, GPIO55, GPIO56 and GPIO57 for SPI but those pins are used for NAND in every board I found, using MR33 pins for NAND it gets detected.
Also, for whatever reason changing UART GPIO pins makes no effect and UART always works.

I published the decompiled DTB here:

70

Perhaps because a UART does not use gpio on program level. Work with them is based on a registers mapped in memory. To write to it, for example, you only need a dm_base address(0x78af00 for UART1, 0x78b000 for UART2).

Did you manage to run a network? My kernel falls due to the fact that the mdio for switch is not detected(priv->mii_bus == NULL on ar40xx_probe).

libphy: ipq40xx_mdio: probed
[    0.838531] mdio_bus 90000.mdio: MDIO device at address 0 is missing.
[    0.841479] mdio_bus 90000.mdio: MDIO device at address 1 is missing.
[    0.847849] mdio_bus 90000.mdio: MDIO device at address 2 is missing.
[    0.854240] mdio_bus 90000.mdio: MDIO device at address 3 is missing.
[    0.860681] mdio_bus 90000.mdio: MDIO device at address 4 is missing.
71

Well, even if they are not used on a program level but as far as I know there are no dedicated UART pads on the IC but rather there is a pinctrl group of GPIOs that you can use for UART output/input but I assume that they are all used for UART unless pinctrl is set for another group.

No, mine fails too and will actually crash the kernel during probing.
DTS that I posted misses the node to gmac1 as that 1 is only used by Mikrotik but even that does not help as probing does not find MDIOs at all.
MDIO is usually initialized by U-boot as far as I know, so I will compile in /dev/mem and busybox devmem to look if anything is set at all in MDIO registers.

Also, I gotta take a look at Mikrotiks IPQ40xx series drivers in the GPL, I wouldnt be surprised if they modified the QCA driver to initialize MDIO

72

They could use non-standard gpio pins(gpio bit-bang) to communicate with the switch via mdio bus.

73

They could, but I doubt that they do as DTS would need to have those modifications and it does not look anything different than other semi reference board designs, especially since IPQ4019 has a ton of GPIO pins and they are really not using much at all.

74

For RB3011 it uses gpio0, gpio1 for first switch mdio and gpio10, gpio11 for second.

[    3.223994] libphy: GPIO Bitbanged MDIO: probed
[    3.272336] switch0: Atheros AR8337 rev. 2 switch registered on gpio-0
[    4.242869] libphy: GPIO Bitbanged MDIO: probed
[    4.287490] switch1: Atheros AR8337 rev. 2 switch registered on gpio-1
[    5.271223] libphy: Fixed MDIO Bus: probed
75

Yes, but pretty much all of IPQ806X series do it that way.
I have yet to see IPQ40XX board that uses it.

76

Doesn't a Meraki MR33 does not use bitbang?
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-mr33.dts

mdio@90000 {
                        status = "okay";
                       pinctrl-0 = <&mdio_pins>;
}
...
mdio_pins: mdio_pinmux {
               mux_1 {
                       pins = "gpio6";
                       function = "mdio";
                       bias-pull-up;
               };
               mux_2 {
                       pins = "gpio7";
                       function = "mdc";
                       bias-pull-up;
               };
       };
77

That MR33 is a weird one since it has AR8035 PHY connected and uses it for pretty much everything.
But stock DTS has to define those as well and it does not so I doubt that they are bitbanging but rather that MDIOs are not initialized at all and its most likely hidden inside a 13MB Mikrotik GPL that contains code for all targets.
Its just that finding stuff in it is terrible

78

As you remember, U-Boot also stuck on a search for phy(via mdio).

79

I also tried to look for the description of a RB450Gx4 mdio in a linux-3.3.5.patch. Unfortunately I did not find anything like it.

80

Yes, they are doing something weird.
Take a look at what RouterOS supout indicates.
4294967295 is reset value for a lot of MMIO stuff they have.
But I cant find anything specific that looks interesting

2019.02.06-22:28:57.92@0: (eth0#6): phy id 4dd0b1
2019.02.06-22:28:57.92@0: ioctl ifreqDataIoctl#35142(8946)@eth0 failed: Invalid argument(22)
2019.02.06-22:29:01.44@3: (eth1#7): phy id 4dd0b1
2019.02.06-22:29:01.44@3: ioctl ifreqDataIoctl#35142(8946)@eth1 failed: Invalid argument(22)
2019.02.06-22:29:01.45@3: (eth2#8): phy id 4dd0b1
2019.02.06-22:29:01.45@3: ioctl ifreqDataIoctl#35142(8946)@eth2 failed: Invalid argument(22)
2019.02.06-22:29:01.46@3: (eth3#9): phy id 4dd0b1
2019.02.06-22:29:01.46@3: ioctl ifreqDataIoctl#35142(8946)@eth3 failed: Invalid argument(22)
2019.02.06-22:29:01.47@3: (eth4#10): phy id 4dd0b1
2019.02.06-22:29:01.47@3: ioctl ifreqDataIoctl#35142(8946)@eth4 failed: Invalid argument(22)
2019.02.06-22:29:01.49@3: SWITCHES: handle switch change
2019.02.06-22:29:01.52@0: apply s27 id:1 num:1 ver:1 4294967295
2019.02.06-22:29:01.52@0: apply s27 id:2 num:2 ver:1 4294967295
2019.02.06-22:29:01.52@0: apply s27 id:3 num:3 ver:1 4294967295
2019.02.06-22:29:01.52@0: apply s27 id:4 num:4 ver:1 4294967295
2019.02.06-22:29:01.52@0: apply s27 id:5 num:5 ver:1 4294967295
2019.02.06-22:29:01.52@0: apply s27 id:16777216 num:0 ver:1 4294967295

Hm, it looks like they are actually doing something with ath8327.ko driver module since after running strings on it this pops up:

dakota 450g
dakota_xmit_fast
dakota_rx_fast
dakota_xmit_fast

And dakota 450g pops up multiple times during boot.

81

I try to read MDIO regs from my bootloader. MDIO_BASE = 0x90000.
Here is a result:

MDIO_CTRL_0_REG = 0x150ff
MDIO_CTRL_1_REG = 0x1811
MDIO_CTRL_2_REG = 0x1f
MDIO_CTRL_3_REG = 0xbc5c