diff mbox series

[OpenWrt-Devel,v2] ar71xx: add support for RB SXTsq 2nD

Message ID 20200315103451.34439-1-hacks@slashdirt.org
State Rejected
Headers show
Series [OpenWrt-Devel,v2] ar71xx: add support for RB SXTsq 2nD | expand

Commit Message

Thibaut VARÈNE March 15, 2020, 10:34 a.m. UTC
[no change, commit msg update: fixed installation instructions]

This patch adds support for the MikroTik RouterBOARD SXTsq Lite2
https://mikrotik.com/product/sxtsq_lite2

Specifications:
- SoC: Qualcomm QCA9533 (650MHz)
- RAM: 64MB
- Storage: 16MB SPI NOR flash
- Wireless: QCA9533 built-in, dual-chain 802.11b/g/n
- Ethernet: 1x100M

Note: the reset button shares its GPIO with the last RSSI LED:
this is not supported, the last LED is thus disabled (reset works).
That aside, the device is fully supported.

Installation:
(Standard Mikrotik TFTP)

1. Setup a DHCP/BOOTP Server with the following parameters:
   * DHCP-Option 66 (TFTP server name): pointing to a local TFTP
     server within the same subnet of the DHCP range
   * DHCP-Option 67 (Bootfile-Name): matching the initramfs filename
     of the to be booted image. The usable intramfs files are:
       - openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf
       - openwrt-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf
       - openwrt-ar71xx-mikrotik-rb-nor-flash-16M-initramfs-kernel.bin

2. Press the reset button on the board and keep that pressed.

3. Connect the board to your local network via its ethernet port.

4. Release the button after the LEDs on the board are turned off.
   Now the board should load and start the initramfs image from
   the TFTP server.

5. Upload the sysupgrade image to the board with scp:
     $ scp openwrt-ar71xx-mikrotik-rb-nor-flash-16M-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/fw.bin

6. Log in to the running system listening on 192.168.1.1 via ssh
   as root (without password):
     $ ssh root@192.168.1.1

7. Flash the uploaded firmware file from the ssh session via the
   sysupgrade command:
     root@OpenWrt:~# sysupgrade /tmp/fw.bin

Signed-off-by: Thibaut VARÈNE <hacks@slashdirt.org>
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |  3 +-
 .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
 target/linux/ar71xx/base-files/etc/diag.sh         |  1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh       |  3 +
 .../ar71xx/base-files/lib/upgrade/platform.sh      |  2 +
 .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |  1 +
 .../ar71xx/files/arch/mips/ath79/mach-rbspi.c      | 78 +++++++++++++++++++++-
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
 target/linux/ar71xx/image/mikrotik.mk              |  2 +-
 9 files changed, 89 insertions(+), 3 deletions(-)

Comments

Adrian Schmutzler March 15, 2020, 12:05 p.m. UTC | #1
Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org]
> On Behalf Of Thibaut VARÈNE
> Sent: Sonntag, 15. März 2020 11:35
> To: openwrt-devel@lists.openwrt.org
> Cc: Thibaut VARÈNE <hacks@slashdirt.org>
> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD

the ar71xx target will only be supported in already released 19.07 branch and be removed afterwards.

Consequently, we do not accept any device support for this target anymore.

Please work with the ath79 target instead, which is meant to replace ar71xx and is also already included in 19.07.x (though Mikrotik devices have only been added in master).

Best

Adrian
Ole Kristian Lona via openwrt-devel March 15, 2020, 12:20 p.m. UTC | #2
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Hi Thibaut,

We're actually working on the ath79/mikrotik subtarget, to deal with the
particularities of MikroTik devices and migrate the two currently
supported. You may want to base your commit on the code at
https://github.com/openwrt/openwrt/pull/2811 .

Regards,

Roger

El 15/3/20 a les 13:05, mail@adrianschmutzler.de ha escrit:
> Hi,
>
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org]
>> On Behalf Of Thibaut VARÈNE
>> Sent: Sonntag, 15. März 2020 11:35
>> To: openwrt-devel@lists.openwrt.org
>> Cc: Thibaut VARÈNE <hacks@slashdirt.org>
>> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD
> the ar71xx target will only be supported in already released 19.07 branch and be removed afterwards.
>
> Consequently, we do not accept any device support for this target anymore.
>
> Please work with the ath79 target instead, which is meant to replace ar71xx and is also already included in 19.07.x (though Mikrotik devices have only been added in master).
>
> Best
>
> Adrian 
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Thibaut VARÈNE March 15, 2020, 12:38 p.m. UTC | #3
Hi,

> Le 15 mars 2020 à 13:05, <mail@adrianschmutzler.de> <mail@adrianschmutzler.de> a écrit :
> 
> Hi,
> 
>> -----Original Message-----
>> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org]
>> On Behalf Of Thibaut VARÈNE
>> Sent: Sonntag, 15. März 2020 11:35
>> To: openwrt-devel@lists.openwrt.org
>> Cc: Thibaut VARÈNE <hacks@slashdirt.org>
>> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq 2nD
> 
> the ar71xx target will only be supported in already released 19.07 branch and be removed afterwards.
> 
> Consequently, we do not accept any device support for this target anymore.
> 
> Please work with the ath79 target instead, which is meant to replace ar71xx and is also already included in 19.07.x (though Mikrotik devices have only been added in master).

I had a feeling this would be the answer.

At least the code is there for those who need it, and it details the necessary bits to get this hardware to work.

Regarding moving to ath79 there are a number of issues which I’m trying to wrap my head around.

Specifically, right now we have a (imo very convenient) « one image fits them all » approach for ar71xx-based mikrotik devices. This relies on load-time detection of the hardware which is based part on the kernel command string passed by the routerboot bootloader, and part on actual hardware detection at kernel load time (MIPS machine name).

I don’t know yet if it is possible to transcribe this in a DTS world: routerboot doesn’t support DTS, so my impression is that in order to maintain this feature an intermediary loader is needed, which is going to be non-trivial.

Second, I don’t know if the machine name detection can also be implemented in DTS: I was under the impression that all DTSes define a fixed string, there doesn’t seem to be a mechanism to lift that string from the mtd device as is currently done on ar71xx. Is this correct?

Thanks,
Thibaut
Thibaut VARÈNE March 15, 2020, 12:46 p.m. UTC | #4
Hi Roger,

> Le 15 mars 2020 à 13:20, Roger Pueyo Centelles | Guifi.net <roger.pueyo@guifi.net> a écrit :
> 
> Hi Thibaut,
> 
> We're actually working on the ath79/mikrotik subtarget, to deal with the
> particularities of MikroTik devices and migrate the two currently
> supported. You may want to base your commit on the code at
> https://github.com/openwrt/openwrt/pull/2811 .

Noted, but see my previous message to the list.

Also AFAICT, 4K sector is not currently used on SPI-NOR RB devices: enabling it without setting some sane limit will slow the devices and might cause upgrade issues.

I have two patches you might want to lift and include in that PR, see:
https://github.com/f00b4r0/openwrt/commit/084490569427595123666f6208e91de1521530ae <https://github.com/f00b4r0/openwrt/commit/084490569427595123666f6208e91de1521530ae>
https://github.com/f00b4r0/openwrt/commit/9d23bf314e3919ac7a2dd6d64c70442f4534a273 <https://github.com/f00b4r0/openwrt/commit/9d23bf314e3919ac7a2dd6d64c70442f4534a273>

HTH,
Thibaut
Adrian Schmutzler March 15, 2020, 12:52 p.m. UTC | #5
Hi,

> -----Original Message-----
> From: Thibaut [mailto:hacks@slashdirt.org]
> Sent: Sonntag, 15. März 2020 13:39
> To: mail@adrianschmutzler.de
> Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq
> 2nD
> 
> Hi,
> 
> > Le 15 mars 2020 à 13:05, <mail@adrianschmutzler.de>
> <mail@adrianschmutzler.de> a écrit :
> >
> > Hi,
> >
> >> -----Original Message-----
> >> From: openwrt-devel [mailto:openwrt-devel-
> bounces@lists.openwrt.org]
> >> On Behalf Of Thibaut VARÈNE
> >> Sent: Sonntag, 15. März 2020 11:35
> >> To: openwrt-devel@lists.openwrt.org
> >> Cc: Thibaut VARÈNE <hacks@slashdirt.org>
> >> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq
> 2nD
> >
> > the ar71xx target will only be supported in already released 19.07 branch
> and be removed afterwards.
> >
> > Consequently, we do not accept any device support for this target
> anymore.
> >
> > Please work with the ath79 target instead, which is meant to replace ar71xx
> and is also already included in 19.07.x (though Mikrotik devices have only
> been added in master).
> 
> I had a feeling this would be the answer.
> 
> At least the code is there for those who need it, and it details the necessary
> bits to get this hardware to work.
> 
> Regarding moving to ath79 there are a number of issues which I’m trying to
> wrap my head around.
> 
> Specifically, right now we have a (imo very convenient) « one image fits them
> all » approach for ar71xx-based mikrotik devices. This relies on load-time
> detection of the hardware which is based part on the kernel command string
> passed by the routerboot bootloader, and part on actual hardware detection
> at kernel load time (MIPS machine name).
> 
> I don’t know yet if it is possible to transcribe this in a DTS world: routerboot
> doesn’t support DTS, so my impression is that in order to maintain this
> feature an intermediary loader is needed, which is going to be non-trivial.
> 
> Second, I don’t know if the machine name detection can also be
> implemented in DTS: I was under the impression that all DTSes define a fixed
> string, there doesn’t seem to be a mechanism to lift that string from the mtd
> device as is currently done on ar71xx. Is this correct?

The way devices were detected in ar71xx also caused a lot of problem, as it was very confusing even to seasoned developers. Now, we just build a separate image for each device, so we do not need this mess of scripts for detection anymore.

Just have a look at how the few ath79 devices are implemented, but note that they will be moved to a mikrotik subtarget soon as indicated by Roger already.

Best

Adrian

> 
> Thanks,
> Thibaut
Thibaut VARÈNE March 15, 2020, 12:56 p.m. UTC | #6
Hi,

> Le 15 mars 2020 à 13:52, <mail@adrianschmutzler.de> <mail@adrianschmutzler.de> a écrit :
> 
> Hi,
> 
>> -----Original Message-----
>> From: Thibaut [mailto:hacks@slashdirt.org]
>> Sent: Sonntag, 15. März 2020 13:39
>> To: mail@adrianschmutzler.de
>> Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>
>> Subject: Re: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq
>> 2nD
>> 
>> Hi,
>> 
>>> Le 15 mars 2020 à 13:05, <mail@adrianschmutzler.de>
>> <mail@adrianschmutzler.de> a écrit :
>>> 
>>> Hi,
>>> 
>>>> -----Original Message-----
>>>> From: openwrt-devel [mailto:openwrt-devel-
>> bounces@lists.openwrt.org]
>>>> On Behalf Of Thibaut VARÈNE
>>>> Sent: Sonntag, 15. März 2020 11:35
>>>> To: openwrt-devel@lists.openwrt.org
>>>> Cc: Thibaut VARÈNE <hacks@slashdirt.org>
>>>> Subject: [OpenWrt-Devel] [PATCH v2] ar71xx: add support for RB SXTsq
>> 2nD
>>> 
>>> the ar71xx target will only be supported in already released 19.07 branch
>> and be removed afterwards.
>>> 
>>> Consequently, we do not accept any device support for this target
>> anymore.
>>> 
>>> Please work with the ath79 target instead, which is meant to replace ar71xx
>> and is also already included in 19.07.x (though Mikrotik devices have only
>> been added in master).
>> 
>> I had a feeling this would be the answer.
>> 
>> At least the code is there for those who need it, and it details the necessary
>> bits to get this hardware to work.
>> 
>> Regarding moving to ath79 there are a number of issues which I’m trying to
>> wrap my head around.
>> 
>> Specifically, right now we have a (imo very convenient) « one image fits them
>> all » approach for ar71xx-based mikrotik devices. This relies on load-time
>> detection of the hardware which is based part on the kernel command string
>> passed by the routerboot bootloader, and part on actual hardware detection
>> at kernel load time (MIPS machine name).
>> 
>> I don’t know yet if it is possible to transcribe this in a DTS world: routerboot
>> doesn’t support DTS, so my impression is that in order to maintain this
>> feature an intermediary loader is needed, which is going to be non-trivial.
>> 
>> Second, I don’t know if the machine name detection can also be
>> implemented in DTS: I was under the impression that all DTSes define a fixed
>> string, there doesn’t seem to be a mechanism to lift that string from the mtd
>> device as is currently done on ar71xx. Is this correct?
> 
> The way devices were detected in ar71xx also caused a lot of problem, as it was very confusing even to seasoned developers. Now, we just build a separate image for each device, so we do not need this mess of scripts for detection anymore.

I believe this is a waste of resources and a very suboptimal approach. I’m not sure I’m interested in spending time on this :P

Some devices share the exact same hardware and differ only in (marketing) name, as evidenced by:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1 <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1>

(this device uses the 911L platform)

> Just have a look at how the few ath79 devices are implemented, but note that they will be moved to a mikrotik subtarget soon as indicated by Roger already.

I’ve offered in this thread a couple patches to align the ath79 implementation on the existing ramips one wrt mtd partitioning and naming.

Best,
Thibaut
Ole Kristian Lona via openwrt-devel March 15, 2020, 1:20 p.m. UTC | #7
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
Hi,

> I believe this is a waste of resources and a very suboptimal approach.
> I’m not sure I’m interested in spending time on this :P
Probably it is. How would you approach it? Some devices that are the
same hardware with just a different name are already supported like
this:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ac36cca012dd1bbeea0fc4c2dc7a00941de34b52
>
> Some devices share the exact same hardware and differ only in
> (marketing) name, as evidenced by:
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1
>
> (this device uses the 911L platform)
>
>> Just have a look at how the few ath79 devices are implemented, but
>> note that they will be moved to a mikrotik subtarget soon as
>> indicated by Roger already.
>
> I’ve offered in this thread a couple patches to align the ath79
> implementation on the existing ramips one wrt mtd partitioning and naming.

To me they're OK, I have no preference for having the partitions nested
or not. What are the benefits and drawbacks?

Cheers!

>
> Best,
> Thibaut
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Thibaut VARÈNE March 15, 2020, 2 p.m. UTC | #8
Hi,

> Le 15 mars 2020 à 14:20, Roger Pueyo Centelles | Guifi.net <roger.pueyo@guifi.net> a écrit :
> 
> Hi,
> 
>> I believe this is a waste of resources and a very suboptimal approach. I’m not sure I’m interested in spending time on this :P
> Probably it is. How would you approach it? Some devices that are the same hardware with just a different name are already supported like this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ac36cca012dd1bbeea0fc4c2dc7a00941de34b52 <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ac36cca012dd1bbeea0fc4c2dc7a00941de34b52>

Yes, except in this case the resulting image name isn’t changed and the difference in naming is very subtle. In the case I quote below, one device is called RB 911L, the other RB SXT 2nD r3. The average user is never going to know they’re one and the same :P

That’s why I’d prefer maintaining the one-image for all devices approach, which has benefits both for the openwrt infrastructure (it scales and consumes less ressources) and for the users (« you have a mikrotik SPI NOR device? You can’t get it wrong, the image works on all of those we support »).

Considering routerboot’s lack of support for DTS, I suspect the only way to tackle this is via an intermediary loader, unless there is a specific mechanism in the kernel we could use (I’m not aware of any, but I know very little about the implementation details of DTS).

>> Some devices share the exact same hardware and differ only in (marketing) name, as evidenced by:
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1 <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5ac974f2145c770431a6eb7e006dd086b70224b1>
>> 
>> (this device uses the 911L platform)
>> 
>>> Just have a look at how the few ath79 devices are implemented, but note that they will be moved to a mikrotik subtarget soon as indicated by Roger already.
>> 
>> I’ve offered in this thread a couple patches to align the ath79 implementation on the existing ramips one wrt mtd partitioning and naming.
> To me they're OK, I have no preference for having the partitions nested or not. What are the benefits and drawbacks?
> 
> 
As was once discussed and eventually accepted (when renaming RBMxxG partitions), this is in line with the canonical way to define partitions in DTS, as documented in Documentation/devicetree/bindings/mtd/partition.txt

This method is apparently used in all bcm targets, including ath79, ipq and lantiq. The aforementioned documentation says:

	For backwards compatibility partitions as direct subnodes of the flash device are
	supported. This use is discouraged.


Cheers,
Thibaut
diff mbox series

Patch

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 54727a6e52..4d50f489d5 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -683,7 +683,8 @@  rb-2011uias-2hnd-r2)
 	ucidef_set_led_switch "eth9" "ETH9" "rb:green:eth9" "switch1" "0x04"
 	ucidef_set_led_switch "eth10" "ETH10" "rb:green:eth10" "switch1" "0x02"
 	;;
-rb-lhg-5nd)
+rb-lhg-5nd|\
+rb-sxtsq-2nd)
 	ucidef_set_led_netdev "lan" "LAN" "rb:green:eth" "eth0"
 	ucidef_set_rssimon "wlan0" "200000" "1"
 	ucidef_set_led_rssi "rssilow" "RSSILOW" "rb:green:rssi0" "wlan0" "1" "100" "0" "13"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 1487ff58de..1334e48e7a 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -116,6 +116,7 @@  ar71xx_setup_interfaces()
 	rb-sxt2n|\
 	rb-sxt-2nd-r3|\
 	rb-sxt5n|\
+	rb-sxtsq-2nd|\
 	rb-wap-2nd|\
 	rb-wapr-2nd|\
 	rb-wapg-5hact2hnd|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh b/target/linux/ar71xx/base-files/etc/diag.sh
index c5fe5bdcc1..b0e56fda8a 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -381,6 +381,7 @@  get_status_led() {
 	rb-map-2nd|\
 	rb-mapl-2nd|\
 	rb-sxt-2nd-r3|\
+	rb-sxtsq-2nd|\
 	rb-wap-2nd|\
 	rb-wapr-2nd)
 		status_led="rb:green:user"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 044ef4eae5..cf792783c4 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -542,6 +542,9 @@  mikrotik_board_detect() {
 	*"SXT Lite5")
 		name="rb-sxt5n"
 		;;
+	*"SXTsq 2nD")
+		name="rb-sxtsq-2nd"
+		;;
 	*"wAP 2nD r2")
 		name="rb-wap-2nd"
 		;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index a76842bdde..618fb3b8ca 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -726,6 +726,7 @@  platform_check_image() {
 	rb-map-2nd|\
 	rb-mapl-2nd|\
 	rb-sxt-2nd-r3|\
+	rb-sxtsq-2nd|\
 	rb-wap-2nd|\
 	rb-wapg-5hact2hnd|\
 	rb-wapr-2nd)
@@ -786,6 +787,7 @@  platform_do_upgrade() {
 	rb-map-2nd|\
 	rb-mapl-2nd|\
 	rb-sxt-2nd-r3|\
+	rb-sxtsq-2nd|\
 	rb-wap-2nd|\
 	rb-wapg-5hact2hnd|\
 	rb-wapr-2nd)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 6fd78c46a0..3657f9ca49 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -1189,6 +1189,7 @@  config ATH79_MACH_RBSPI
 	  MikroTik RouterBOARD LHG 5
 	  MikroTik RouterBOARD cAP (EXPERIMENTAL)
 	  MikroTik RouterBOARD SXT Lite 2 r3
+	  MikroTik RouterBOARD STXsq Lite2
 	  MikroTik RouterBOARD wAP
 	  MikroTik RouterBOARD wAP R-2nD
 
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
index 6bb42c78e3..bf4518698e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
@@ -14,6 +14,7 @@ 
  *  - MikroTik RouterBOARD 750P-PBr2
  *  - MikroTik RouterBOARD 750 r2
  *  - MikroTik RouterBOARD LHG 5nD
+ *  - MikroTik RouterBOARD SXTsq 2nD
  *  - MikroTik RouterBOARD wAP2nD
  *  - MikroTik RouterBOARD wAP G-5HacT2HnDwAP (wAP AC)
  *  - MikroTik RouterBOARD wAP R-2nD
@@ -24,7 +25,7 @@ 
  *  hardware as the mAP L-2nD. It is unknown if they share the same board
  *  identifier.
  *
- *  Copyright (C) 2017-2018 Thibaut VARENE <varenet@parisc-linux.org>
+ *  Copyright (C) 2017-2020 Thibaut VARENE <varenet@parisc-linux.org>
  *  Copyright (C) 2016 David Hutchison <dhutchison@bluemesh.net>
  *  Copyright (C) 2017 Ryan Mounce <ryan@mounce.com.au>
  *
@@ -479,6 +480,55 @@  static struct gpio_led rblhg_leds[] __initdata = {
 	},
 };
 
+/* RB SXTsq 2nD gpios */
+#define RBSXTSQ_GPIO_LED_0	11
+#define RBSXTSQ_GPIO_LED_1	9
+#define RBSXTSQ_GPIO_LED_2	12
+#define RBSXTSQ_GPIO_LED_3	13
+#define RBSXTSQ_GPIO_LED_4	16	// shared with reset button
+#define RBSXTSQ_GPIO_LED_ETH	4
+#define RBSXTSQ_GPIO_LED_POWER	17
+#define RBSXTSQ_GPIO_LED_USER	14
+#define RBSXTSQ_GPIO_BTN_RESET	16
+
+static struct gpio_led rbsxtsq_leds[] __initdata = {
+	{
+		.name = "rb:green:rssi0",
+		.gpio = RBSXTSQ_GPIO_LED_0,
+		.active_low = 1,
+	}, {
+		.name = "rb:green:rssi1",
+		.gpio = RBSXTSQ_GPIO_LED_1,
+		.active_low = 1,
+	}, {
+		.name = "rb:green:rssi2",
+		.gpio = RBSXTSQ_GPIO_LED_2,
+		.active_low = 1,
+	}, {
+		.name = "rb:green:rssi3",
+		.gpio = RBSXTSQ_GPIO_LED_3,
+		.active_low = 1,
+/*	}, {
+		// LED_4 GPIO is shared with reset button => Do not register this LED
+		.name = "rb:green:rssi4",
+		.gpio = RBSXTSQ_GPIO_LED_4,
+		.active_low = 1,
+*/	}, {
+		.name = "rb:green:eth",
+		.gpio = RBSXTSQ_GPIO_LED_ETH,
+		.active_low = 1,
+	}, {
+		.name = "rb:green:user",
+		.gpio = RBSXTSQ_GPIO_LED_USER,
+		.active_low = 1,
+	}, {
+		.name = "rb:green:power",
+		.gpio = RBSXTSQ_GPIO_LED_POWER,
+		.active_low = 0,
+		.default_state = LEDS_GPIO_DEFSTATE_ON,
+	},
+};
+
 /* RB w APG-5HacT2HnD (wAP AC) gpios*/
 #define RBWAPGSC_WIFI_LED_1		1
 #define RBWAPGSC_WIFI_LED_2		8
@@ -1021,6 +1071,31 @@  static void __init rblhg_setup(void)
 }
 
 /*
+ * Init the SXTsq Lite2 (QCA9533).
+ * This device has a single ethernet port connected to PHY0.
+ * Wireless is provided via 2.4GHz WLAN1.
+ */
+static void __init rbsxtsq_setup(void)
+{
+	u32 flags = RBSPI_HAS_WLAN1;
+
+	if (!rbspi_platform_setup())
+		return;
+
+	rbspi_peripherals_setup(flags);
+
+	/* GMAC1 is HW MAC, WLAN1 MAC is HW MAC + 1 */
+	rbspi_network_setup(flags, 0, 0, 1);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(rbsxtsq_leds), rbsxtsq_leds);
+
+	/* Make the eth LED controllable by software. */
+	ath79_gpio_output_select(RBSXTSQ_GPIO_LED_ETH, AR934X_GPIO_OUT_GPIO);
+
+	rbspi_register_reset_button(RBSXTSQ_GPIO_BTN_RESET);
+}
+
+/*
  * Init the wAP hardware.
  * The wAP 2nD has a single ethernet port.
  */
@@ -1260,3 +1335,4 @@  MIPS_MACHINE_NONAME(ATH79_MACH_RB_CAP, "cap-hb", rbcap_setup);
 MIPS_MACHINE_NONAME(ATH79_MACH_RB_MAP, "map2-hb", rbmap_setup);
 MIPS_MACHINE_NONAME(ATH79_MACH_RB_WAPAC, "wapg-sc", rbwapgsc_setup);
 MIPS_MACHINE_NONAME(ATH79_MACH_RB_931, "931", rb931_setup);
+MIPS_MACHINE_NONAME(ATH79_MACH_RB_SXTSQL2, "lhg-hb", rbsxtsq_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
index 900b4ec87b..7954a62835 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
+++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
@@ -233,6 +233,7 @@  enum ath79_mach_type {
 	ATH79_MACH_RB_WAPAC,			/* Mikrotik RouterBOARD wAPG-5HacT2HnD */
 	ATH79_MACH_RB_SXTLITE2ND,		/* Mikrotik RouterBOARD SXT Lite 2nD */
 	ATH79_MACH_RB_SXTLITE5ND,		/* Mikrotik RouterBOARD SXT Lite 5nD */
+	ATH79_MACH_RB_SXTSQL2,			/* Mikrotik RouterBOARD SXTsq 2nD */
 	ATH79_MACH_RE355,			/* TP-LINK RE355 */
 	ATH79_MACH_RE450,			/* TP-LINK RE450 */
 	ATH79_MACH_RME_EG200,			/* eTactica EG200 */
diff --git a/target/linux/ar71xx/image/mikrotik.mk b/target/linux/ar71xx/image/mikrotik.mk
index dbbccb1c3f..d23e26c069 100644
--- a/target/linux/ar71xx/image/mikrotik.mk
+++ b/target/linux/ar71xx/image/mikrotik.mk
@@ -46,7 +46,7 @@  define Device/rb-nor-flash-16M
   DEVICE_PACKAGES := rbcfg rssileds -nand-utils kmod-ledtrig-gpio
   IMAGE_SIZE := 16000k
   KERNEL_INSTALL := 1
-  SUPPORTED_DEVICES := rb-750-r2 rb-750up-r2 rb-750p-pbr2 rb-911-2hn rb-911-5hn rb-931-2nd rb-941-2nd rb-951ui-2nd rb-952ui-5ac2nd rb-962uigs-5hact2hnt rb-lhg-5nd rb-map-2nd rb-mapl-2nd rb-wap-2nd rb-wapr-2nd rb-sxt-2nd-r3
+  SUPPORTED_DEVICES := rb-750-r2 rb-750up-r2 rb-750p-pbr2 rb-911-2hn rb-911-5hn rb-931-2nd rb-941-2nd rb-951ui-2nd rb-952ui-5ac2nd rb-962uigs-5hact2hnt rb-lhg-5nd rb-map-2nd rb-mapl-2nd rb-wap-2nd rb-wapr-2nd rb-sxt-2nd-r3 rb-sxtsq-2nd
   IMAGE/sysupgrade.bin := append-kernel | kernel2minor -s 1024 -e | pad-to $$$$(BLOCKSIZE) | \
 	append-rootfs | pad-rootfs | append-metadata | check-size $$$$(IMAGE_SIZE)
 endef