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