| Message ID | 20210521110503.5568-4-denis281089@gmail.com |
|---|---|
| State | Superseded |
| Delegated to: | Koen Vandeputte |
| Headers | show |
| Series | ath79: add support for Mikrotik RouterBoard 912G | expand |
Hi, > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Denis Kalashnikov > Sent: Freitag, 21. Mai 2021 13:05 > To: openwrt-devel@lists.openwrt.org > Cc: Gabor Juhos <juhosg@openwrt.org>; Koen Vandeputte > <koen.vandeputte@citymesh.com>; Sergey Ryazanov > <ryazanov.s.a@gmail.com> > Subject: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G Thanks for the update. Some additional comments below. > > This board has been supported in the ar71xx. > > Links: > * https://mikrotik.com/product/RB912UAG-2HPnD > * https://mikrotik.com/product/RB912UAG-5HPnD > * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd > * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd > > Hardware: > * SoC: Atheros AR9342, > * RAM: DDR 64MB, > * SPI NOR: 64KB, > * NAND: 128MB, > * Ethernet: x1 10/100/1000 port with passive POE in, > * Wi-Fi: 802.11bgn, > * PCIe, > * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A > port -- both can be used for LTE modem. But only one can be used. > * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED, > Ethernet phy LED, > * Button, > * Beeper. > > Not working: > * Button: it shares gpio line 15 with NAND ALE and NAND IO7, > and current drivers doesn't easily support this configuration, > * Beeper: it is connected to bit 5 of a serial shift register > (tested with sysfs led trigger timer). But kmod-gpio-beeper > doesn't work -- we left this as is for now. > > You can flash image by sysupgrade utility or load it by net (by DHCP/TFTP, > hold the button while booting). > > Co-Developed-by: Koen Vandeputte <koen.vandeputte@citymesh.com> > Signed-off-by: Denis Kalashnikov <denis281089@gmail.com> > --- > > Changelog: > > v1->v2: > - Delete uneeded comments from DTS, > - Delete ascii-art of board scheme near NAND latch from DTS, > - Rewrite gpio_latch and nand_gpio nodes to be consistent with the > new versions of drivers, > - Fix SPI NOR flash and SPI serial shift register maximum speeds > (thanks to Koen Vandeputte), > - Add UART, PCIe, USB support and gpio exports (thanks to Koen > Vandeputte), > - Fix Ethernet node (thanks to Koen Vandeputte), > - Add key and beeper nodes in disabled state just to be documented. > > --- > .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++++++++++++++++++ > target/linux/ath79/image/mikrotik.mk | 9 + > .../base-files/etc/board.d/02_network | 2 + > .../etc/hotplug.d/firmware/10-ath9k-eeprom | 1 + > .../base-files/lib/upgrade/platform.sh | 1 + > 5 files changed, 246 insertions(+) > create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard- > 912g.dts > > diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > new file mode 100644 > index 0000000000..a23fc04a99 > --- /dev/null > +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > @@ -0,0 +1,233 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > + > +#include "ar9344.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/input/input.h> > + > +/ { > + compatible = "mikrotik,routerboard-912g", "qca,ar9342"; > + model = "Mikrotik RouterBoard 912G"; > + > + leds { > + compatible = "gpio-leds"; > + > + led_power { > + label = "green:power"; > + gpios = <&gpio_latch 1 GPIO_ACTIVE_HIGH>; > + default-state = "on"; > + }; Since you have a GPIO-controlled power-led, you should use the led-* aliases in the aliases block to indicate boot states (just look into one of the other ath79 DTS files.) > + > + led_user { > + label = "green:user"; > + gpios = <&gpio_latch 2 GPIO_ACTIVE_HIGH>; > + }; > + > + led1 { > + label = "green:led1"; > + gpios = <&ssr 0 GPIO_ACTIVE_HIGH>; > + }; > + > + led2 { > + label = "green:led2"; > + gpios = <&ssr 1 GPIO_ACTIVE_HIGH>; > + }; > + > + led3 { > + label = "green:led3"; > + gpios = <&ssr 2 GPIO_ACTIVE_HIGH>; > + }; > + > + led4 { > + label = "green:led4"; > + gpios = <&ssr 3 GPIO_ACTIVE_HIGH>; > + }; > + > + led5 { > + label = "green:led5"; > + gpios = <&ssr 4 GPIO_ACTIVE_HIGH>; > + }; > + }; > + > + beeper { > + status = "disabled"; > + compatible = "gpio-beeper"; > + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>; > + }; If it's broken, I'd not add it here but just name the correct GPIO number in the commit message. > + > + keys { > + status = "disabled"; Like above: If it's broken, remove it, so nobody enables it accidentally and causes harm. (But document how to set it up in the commit message, as you mostly did already ...) > + compatible = "gpio-keys"; > + reset { > + label = "reset"; > + linux,code = <KEY_RESTART>; > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > + debounce-interval = <60>; > + }; > + }; > + > + gpio_export { > + compatible = "gpio-export"; > + > + usb_select { > + label = "select:usb"; gpio-exports don't have a label. You have gpio-export,name instead. Drop it. > + gpio-export,name = "mikrotik:select:usb"; Remove the "mikrotik:" prefix, this has no use. Apart from that, I prefer to not mimic the LED naming scheme with colons here in a broken way. Just use "select-usb" or "usb-select". Same applies to the following node. > + gpio-export,output = <0>; /* 0: mini-pcie, 1: Type-A > port */ > + gpios = <&ssr 6 GPIO_ACTIVE_LOW>; > + }; > + > + pcie_power { > + label = "power:pcie"; > + gpio-export,name = "mikrotik:power:pcie"; > + gpio-export,output = <1>; > + gpios = <&ssr 7 GPIO_ACTIVE_LOW>; > + }; > + }; > +}; > + > +&ahb { > + gpio_latch: gpio_latch { > + compatible = "gpio-latch"; > + gpio-controller; > + #gpio-cells = <2>; > + gpios = <&gpio 0 0>, > + <&gpio 1 0>, > + <&gpio 2 0>, > + <&gpio 3 0>, > + <&gpio 4 0>, > + <&gpio 13 0>, > + <&gpio 14 0>, > + <&gpio 15 0>, > + <&gpio 11 0>; > + latch-enable-gpios = <&gpio 11 GPIO_ACTIVE_LOW>; > + }; > + > + nand_gpio { > + compatible = "rb91x-nand"; > + > + /* NAND control gpios */ > + read-gpios = <&gpio_latch 3 GPIO_ACTIVE_HIGH>; > + rdy-gpios = <&gpio_latch 4 GPIO_ACTIVE_HIGH>; > + nce-gpios = <&gpio_latch 5 GPIO_ACTIVE_LOW>; /* Chip > Enable */ > + cle-gpios = <&gpio_latch 6 GPIO_ACTIVE_HIGH>; /* > Command Latch */ > + ale-gpios = <&gpio_latch 7 GPIO_ACTIVE_HIGH>; /* Address > Latch */ > + nrw-gpios = <&gpio 12 GPIO_ACTIVE_LOW>; /* Read/Write > */ > + > + latch-enable-gpios = <&gpio_latch 8 GPIO_ACTIVE_LOW>; > + > + partitions { > + compatible = "fixed-partitions"; > + #size-cells = <1>; > + > + partition@0 { > + label = "booter"; > + reg = <0x0 0x0040000>; > + read-only; > + }; > + > + partition@40000 { > + label = "kernel"; > + reg = <0x0040000 0x03c0000>; > + }; > + > + partition@400000 { > + label = "ubi"; > + reg = <0x0400000 0x7c00000>; > + }; > + }; > + }; > +}; > + > +&spi { > + status = "okay"; > + > + compatible = "qca,ar7100-spi"; > + > + cs-gpios = <0>, <&gpio_latch 0 GPIO_ACTIVE_LOW>; Are you sure you need cs-gpios here? We've removed it everywhere else (for &spi node): https://github.com/openwrt/openwrt/commit/e5f81ea3fe79ad484d454f5959814b3a1b094dcb > + > + flash@0 { > + compatible = "jedec,spi-nor"; > + reg = <0>; > + spi-max-frequency = <80000000>; > + > + partitions { > + compatible = "mikrotik,routerboot-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "routerboot"; > + reg = <0x0 0x0>; > + read-only; > + }; > + > + hard_config: hard_config { > + read-only; > + }; > + > + bios { > + size = <0x1000>; > + read-only; > + }; > + > + soft_config { > + }; > + }; > + }; > + > + ssr: ssr@1 { > + compatible = "fairchild,74hc595"; > + gpio-controller; > + #gpio-cells = <2>; > + registers-number = <1>; > + reg = <1>; > + spi-max-frequency = <50000000>; > + }; > +}; > + > +&pcie { > + status = "okay"; > +}; > + > +&uart { > + status = "okay"; > +}; This node can be dropped, uart is enabled by default now. > + > +&mdio0 { > + status = "okay"; > + > + phy-mask = <0>; > + > + phy0: ethernet-phy@0 { > + reg = <0>; > + }; > +}; > + > +ð0 { > + status = "okay"; > + > + phy-mode = "rgmii-id"; > + phy-handle = <&phy0>; > + pll-data = <0x02000000 0x00000101 0x00001313>; > + > + gmac-config { > + device = <&gmac>; > + rgmii-gmac0 = <1>; > + rgmii-enabled = <1>; > + rxd-delay = <1>; > + txd-delay = <1>; > + }; > +}; > + > +&wmac { > + status = "okay"; > + qca,no-eeprom; > +}; > + > +&usb { > + status = "okay"; > +}; > + > +&usb_phy { > + status = "okay"; > +}; > diff --git a/target/linux/ath79/image/mikrotik.mk > b/target/linux/ath79/image/mikrotik.mk > index 74f8603b5a..0072ec527d 100644 > --- a/target/linux/ath79/image/mikrotik.mk > +++ b/target/linux/ath79/image/mikrotik.mk > @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef > TARGET_DEVICES += mikrotik_routerboard-493g > > +define Device/mikrotik_routerboard-912g > + $(Device/mikrotik_nand) > + SOC := ar9342 > + DEVICE_MODEL := RouterBOARD 912G > + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper > + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef So, both have exactly the same setup as implemented here? Best Adrian > +TARGET_DEVICES += mikrotik_routerboard-912g > + > define Device/mikrotik_routerboard-921gs-5hpacd-15s > $(Device/mikrotik_nand) > SOC := qca9558 > diff --git a/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network > b/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network > index 4ffe82588c..07bb22c088 100644 > --- a/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network > +++ b/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network > @@ -14,6 +14,7 @@ ath79_setup_interfaces() > ucidef_add_switch "switch1" \ > "0@eth1" "1:lan:4" "2:lan:1" "3:lan:2" "4:lan:3" > ;; > + mikrotik,routerboard-912g|\ > mikrotik,routerboard-921gs-5hpacd-15s|\ > mikrotik,routerboard-lhg-2nd|\ > mikrotik,routerboard-sxt-5nd-r2|\ > @@ -36,6 +37,7 @@ ath79_setup_macs() > local mac_base="$(cat > /sys/firmware/mikrotik/hard_config/mac_base)" > > case "$board" in > + mikrotik,routerboard-912g|\ > mikrotik,routerboard-921gs-5hpacd-15s|\ > mikrotik,routerboard-lhg-2nd|\ > mikrotik,routerboard-sxt-5nd-r2|\ > diff --git a/target/linux/ath79/mikrotik/base- > files/etc/hotplug.d/firmware/10-ath9k-eeprom > b/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10-ath9k- > eeprom > index 7ef6fdbe0f..7868ceaac9 100644 > --- a/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10- > ath9k-eeprom > +++ b/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10-a > +++ th9k-eeprom > @@ -23,6 +23,7 @@ board=$(board_name) > case "$FIRMWARE" in > "ath9k-eeprom-ahb-18100000.wmac.bin") > case $board in > + mikrotik,routerboard-912g|\ > mikrotik,routerboard-lhg-2nd|\ > mikrotik,routerboard-sxt-5nd-r2|\ > mikrotik,routerboard-wapr-2nd) > diff --git a/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh > b/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh > index 97d388168f..736a0932f7 100644 > --- a/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh > +++ b/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh > @@ -32,6 +32,7 @@ platform_do_upgrade() { > > case "$board" in > mikrotik,routerboard-493g|\ > + mikrotik,routerboard-912g|\ > mikrotik,routerboard-921gs-5hpacd-15s|\ > mikrotik,routerboard-922uags-5hpacd|\ > mikrotik,routerboard-sxt-5nd-r2) > -- > 2.26.3 > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hello Adrian and Denis, sorry for interfering with your conversation, I would like to discuss the best way to document not yet finished functionality. Please find my question and proposal below. On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler <mail@adrianschmutzler.de> wrote: [skipped] >> + beeper { >> + status = "disabled"; >> + compatible = "gpio-beeper"; >> + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>; >> + }; > > If it's broken, I'd not add it here but just name the correct GPIO number in the commit message. > >> + >> + keys { >> + status = "disabled"; > > Like above: If it's broken, remove it, so nobody enables it accidentally and causes harm. > (But document how to set it up in the commit message, as you mostly did already ...) Factoring out realization details to the commit message is quite unusual, I personally assume that the commit message is a place where a committer should describe reasons for a particular change. While hard to understand things should be commented on in the code themself. I agree with Adrian that a not yet finished code should not be committed to the master branch. But the device tree has a dualistic nature, on one hand it is a place for driver configuration, on the other hand it is a way to document board stuff interconnections. So maybe we should combine Denise's approach to document even a not yet fully supported component in the DTS with Adrian's suggestion to document why a component is not supported yet and place the reason to disable DTS node as comment inside the node? E.g.: -------------------------------- 8< --------------------------- keys { compatible = "gpio-keys-polled"; reset { ... gpios = <&gpio 15 GPIO_ACTIVE_LOW>; /* * GPIO line #15 is shared between the reset button on input and * the NAND ALE (via the latch) on output. We are unable to just * enable the reset button. So, this node here is for * documentation purposes only. * * [Here should be a text describing the possible ways to * overcome shared line issues] */ status = "disabled"; }; }; -------------------------------- 8< --------------------------- This way we will keep all interconnection documentation in DTS and at the same time we will make sure that no sane user enables this node. > > + compatible = "gpio-keys"; > > + reset { > > + label = "reset"; > > + linux,code = <KEY_RESTART>; > > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > > + debounce-interval = <60>; > > + }; > > + };
On Fri, May 21, 2021 at 2:05 PM Denis Kalashnikov <denis281089@gmail.com> wrote: > > This board has been supported in the ar71xx. > > Links: > * https://mikrotik.com/product/RB912UAG-2HPnD > * https://mikrotik.com/product/RB912UAG-5HPnD > * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd > * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd > > Hardware: > * SoC: Atheros AR9342, > * RAM: DDR 64MB, > * SPI NOR: 64KB, > * NAND: 128MB, > * Ethernet: x1 10/100/1000 port with passive POE in, > * Wi-Fi: 802.11bgn, > * PCIe, > * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A > port -- both can be used for LTE modem. But only one can be used. > * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED, > Ethernet phy LED, > * Button, > * Beeper. > > Not working: > * Button: it shares gpio line 15 with NAND ALE and NAND IO7, > and current drivers doesn't easily support this configuration, > * Beeper: it is connected to bit 5 of a serial shift register > (tested with sysfs led trigger timer). But kmod-gpio-beeper > doesn't work -- we left this as is for now. > > You can flash image by sysupgrade utility or load it by net > (by DHCP/TFTP, hold the button while booting). > > Co-Developed-by: Koen Vandeputte <koen.vandeputte@citymesh.com> > Signed-off-by: Denis Kalashnikov <denis281089@gmail.com> > --- > > Changelog: > > v1->v2: > - Delete uneeded comments from DTS, > - Delete ascii-art of board scheme near NAND latch from DTS, > - Rewrite gpio_latch and nand_gpio nodes to be consistent with the > new versions of drivers, > - Fix SPI NOR flash and SPI serial shift register maximum speeds > (thanks to Koen Vandeputte), > - Add UART, PCIe, USB support and gpio exports (thanks to Koen Vandeputte), > - Fix Ethernet node (thanks to Koen Vandeputte), > - Add key and beeper nodes in disabled state just to be documented. > > --- > .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++++++++++++++++++ > target/linux/ath79/image/mikrotik.mk | 9 + > .../base-files/etc/board.d/02_network | 2 + > .../etc/hotplug.d/firmware/10-ath9k-eeprom | 1 + > .../base-files/lib/upgrade/platform.sh | 1 + > 5 files changed, 246 insertions(+) > create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > > diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > new file mode 100644 > index 0000000000..a23fc04a99 > --- /dev/null > +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts > @@ -0,0 +1,233 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > + > +#include "ar9344.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/input/input.h> > + > +/ { > + compatible = "mikrotik,routerboard-912g", "qca,ar9342"; > + model = "Mikrotik RouterBoard 912G"; > + > + leds { > + compatible = "gpio-leds"; > + > + led_power { > + label = "green:power"; > + gpios = <&gpio_latch 1 GPIO_ACTIVE_HIGH>; > + default-state = "on"; > + }; > + > + led_user { > + label = "green:user"; > + gpios = <&gpio_latch 2 GPIO_ACTIVE_HIGH>; > + }; > + > + led1 { > + label = "green:led1"; > + gpios = <&ssr 0 GPIO_ACTIVE_HIGH>; > + }; > + > + led2 { > + label = "green:led2"; > + gpios = <&ssr 1 GPIO_ACTIVE_HIGH>; > + }; > + > + led3 { > + label = "green:led3"; > + gpios = <&ssr 2 GPIO_ACTIVE_HIGH>; > + }; > + > + led4 { > + label = "green:led4"; > + gpios = <&ssr 3 GPIO_ACTIVE_HIGH>; > + }; > + > + led5 { > + label = "green:led5"; > + gpios = <&ssr 4 GPIO_ACTIVE_HIGH>; > + }; > + }; > + > + beeper { > + status = "disabled"; > + compatible = "gpio-beeper"; > + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>; > + }; > + > + keys { > + status = "disabled"; > + compatible = "gpio-keys"; > + reset { > + label = "reset"; > + linux,code = <KEY_RESTART>; > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > + debounce-interval = <60>; > + }; > + }; > + > + gpio_export { > + compatible = "gpio-export"; > + > + usb_select { > + label = "select:usb"; > + gpio-export,name = "mikrotik:select:usb"; > + gpio-export,output = <0>; /* 0: mini-pcie, 1: Type-A port */ > + gpios = <&ssr 6 GPIO_ACTIVE_LOW>; > + }; > + > + pcie_power { > + label = "power:pcie"; > + gpio-export,name = "mikrotik:power:pcie"; > + gpio-export,output = <1>; > + gpios = <&ssr 7 GPIO_ACTIVE_LOW>; > + }; > + }; > +}; > + > +&ahb { I am just curious, why did you place beeper and LEDs in the root node, but specify latch and NAND as the AHB bus child nodes? > + gpio_latch: gpio_latch { > + compatible = "gpio-latch"; > + gpio-controller; > + #gpio-cells = <2>; > + gpios = <&gpio 0 0>, > + <&gpio 1 0>, > + <&gpio 2 0>, > + <&gpio 3 0>, > + <&gpio 4 0>, > + <&gpio 13 0>, > + <&gpio 14 0>, > + <&gpio 15 0>, > + <&gpio 11 0>; > + latch-enable-gpios = <&gpio 11 GPIO_ACTIVE_LOW>; > + }; > + > + nand_gpio { > + compatible = "rb91x-nand"; Should this be "mikrotik,rb91x-nand"? > + /* NAND control gpios */ > + read-gpios = <&gpio_latch 3 GPIO_ACTIVE_HIGH>; > + rdy-gpios = <&gpio_latch 4 GPIO_ACTIVE_HIGH>; > + nce-gpios = <&gpio_latch 5 GPIO_ACTIVE_LOW>; /* Chip Enable */ > + cle-gpios = <&gpio_latch 6 GPIO_ACTIVE_HIGH>; /* Command Latch */ > + ale-gpios = <&gpio_latch 7 GPIO_ACTIVE_HIGH>; /* Address Latch */ > + nrw-gpios = <&gpio 12 GPIO_ACTIVE_LOW>; /* Read/Write */ Why did you use so complex set of properties for configuration? You anyway add comments to a large portion of properties. So why do not follow the 'gpio-control-nand' driver approach and simply use a single 'gpios' array? > + > + latch-enable-gpios = <&gpio_latch 8 GPIO_ACTIVE_LOW>; > + > + partitions { > + compatible = "fixed-partitions"; > + #size-cells = <1>; > + > + partition@0 { > + label = "booter"; > + reg = <0x0 0x0040000>; > + read-only; > + }; > + > + partition@40000 { > + label = "kernel"; > + reg = <0x0040000 0x03c0000>; > + }; > + > + partition@400000 { > + label = "ubi"; > + reg = <0x0400000 0x7c00000>; > + }; > + }; > + }; > +}; > + > +&spi { > + status = "okay"; > + > + compatible = "qca,ar7100-spi"; > + > + cs-gpios = <0>, <&gpio_latch 0 GPIO_ACTIVE_LOW>; > + > + flash@0 { > + compatible = "jedec,spi-nor"; > + reg = <0>; > + spi-max-frequency = <80000000>; > + > + partitions { > + compatible = "mikrotik,routerboot-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "routerboot"; > + reg = <0x0 0x0>; > + read-only; > + }; > + > + hard_config: hard_config { > + read-only; > + }; > + > + bios { > + size = <0x1000>; > + read-only; > + }; > + > + soft_config { > + }; > + }; > + }; > + > + ssr: ssr@1 { > + compatible = "fairchild,74hc595"; > + gpio-controller; > + #gpio-cells = <2>; > + registers-number = <1>; > + reg = <1>; > + spi-max-frequency = <50000000>; > + }; > +}; > + > +&pcie { > + status = "okay"; > +}; > + > +&uart { > + status = "okay"; > +}; > + > +&mdio0 { > + status = "okay"; > + > + phy-mask = <0>; > + > + phy0: ethernet-phy@0 { > + reg = <0>; > + }; > +}; > + > +ð0 { > + status = "okay"; > + > + phy-mode = "rgmii-id"; > + phy-handle = <&phy0>; > + pll-data = <0x02000000 0x00000101 0x00001313>; > + > + gmac-config { > + device = <&gmac>; > + rgmii-gmac0 = <1>; > + rgmii-enabled = <1>; > + rxd-delay = <1>; > + txd-delay = <1>; > + }; > +}; > + > +&wmac { > + status = "okay"; > + qca,no-eeprom; > +}; > + > +&usb { > + status = "okay"; > +}; > + > +&usb_phy { > + status = "okay"; > +}; -- Sergey
Hello Adrian > > +&spi { > > + status = "okay"; > > + > > + compatible = "qca,ar7100-spi"; > > + > > + cs-gpios = <0>, <&gpio_latch 0 GPIO_ACTIVE_LOW>; > > Are you sure you need cs-gpios here? We've removed it everywhere else (for &spi node): > https://github.com/openwrt/openwrt/commit/e5f81ea3fe79ad484d454f5959814b3a1b094dcb On this board for the serial shift register a separate gpio line is used as nCS, not the SoC SPI controller dedicated nCS line. So, without cs-gpios DTS property the serial shift register doesn't work. Denis.
Hello Sergey > the device tree has a dualistic > nature, on one hand it is a place for driver configuration, on the > other hand it is a way to document board stuff interconnections I agree with you here, but I don't think that I should insist on this.
> I am just curious, why did you place beeper and LEDs in the root node, > but specify latch and NAND as the AHB bus child nodes? Ack, you are right. > > + /* NAND control gpios */ > > + read-gpios = <&gpio_latch 3 GPIO_ACTIVE_HIGH>; > > + rdy-gpios = <&gpio_latch 4 GPIO_ACTIVE_HIGH>; > > + nce-gpios = <&gpio_latch 5 GPIO_ACTIVE_LOW>; /* Chip Enable */ > > + cle-gpios = <&gpio_latch 6 GPIO_ACTIVE_HIGH>; /* Command Latch */ > > + ale-gpios = <&gpio_latch 7 GPIO_ACTIVE_HIGH>; /* Address Latch */ > > + nrw-gpios = <&gpio 12 GPIO_ACTIVE_LOW>; /* Read/Write */ > > Why did you use so complex set of properties for configuration? You > anyway add comments to a large portion of properties. So why do not > follow the 'gpio-control-nand' driver approach and simply use a single > 'gpios' array? I'll fix this in v3. Denis
On 23.05.21 11:01, Adrian Schmutzler wrote: > ... >> diff --git a/target/linux/ath79/image/mikrotik.mk >> b/target/linux/ath79/image/mikrotik.mk >> index 74f8603b5a..0072ec527d 100644 >> --- a/target/linux/ath79/image/mikrotik.mk >> +++ b/target/linux/ath79/image/mikrotik.mk >> @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef >> TARGET_DEVICES += mikrotik_routerboard-493g >> >> +define Device/mikrotik_routerboard-912g >> + $(Device/mikrotik_nand) >> + SOC := ar9342 >> + DEVICE_MODEL := RouterBOARD 912G >> + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper >> + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef > So, both have exactly the same setup as implemented here? > > Best > > Adrian > yes. I personally use rb-912uag-5hpnd board. The hardware is identical with the exception of the band used. What's your 2 cents to get both supported using a single target? Thanks, Koen
Hi, > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Sergey Ryazanov > Sent: Montag, 24. Mai 2021 01:07 > To: Adrian Schmutzler <mail@adrianschmutzler.de>; Denis Kalashnikov > <denis281089@gmail.com> > Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>; Gabor > Juhos <juhosg@openwrt.org>; Koen Vandeputte > <koen.vandeputte@citymesh.com> > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G > > Hello Adrian and Denis, > > sorry for interfering with your conversation, I would like to discuss the best > way to document not yet finished functionality. Please find my question and > proposal below. > > On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler > <mail@adrianschmutzler.de> wrote: > > [skipped] > > >> + beeper { > >> + status = "disabled"; > >> + compatible = "gpio-beeper"; > >> + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>; > >> + }; > > > > If it's broken, I'd not add it here but just name the correct GPIO number in > the commit message. > > > >> + > >> + keys { > >> + status = "disabled"; > > > > Like above: If it's broken, remove it, so nobody enables it accidentally and > causes harm. > > (But document how to set it up in the commit message, as you mostly > > did already ...) > > Factoring out realization details to the commit message is quite unusual, I > personally assume that the commit message is a place where a committer > should describe reasons for a particular change. While hard to understand > things should be commented on in the code themself. > > I agree with Adrian that a not yet finished code should not be committed to > the master branch. But the device tree has a dualistic nature, on one hand it > is a place for driver configuration, on the other hand it is a way to document > board stuff interconnections. So maybe we should combine Denise's > approach to document even a not yet fully supported component in the DTS > with Adrian's suggestion to document why a component is not supported yet > and place the reason to disable DTS node as comment inside the node? E.g.: My main motivation is preventing too much bloat in the DTS files. Nevertheless, typically, if stuff is not working it will either not be resolved ever or the solution will deviate from what people were thinking it would be initially (otherwise, they would have solved it back then). Thus, the DTS "implementation" of that part is either irrelevant (first case) or wrong/subject to change (second case) later. In both cases, I don't think it really makes sense to add it to the DTS in the first place. Hovewer, I'm relatively flexible here. So if you really think it would be necessary to have this broken part of configuration in the DTS, I won't stop you because of that. Best Adrian > > -------------------------------- 8< --------------------------- keys { > compatible = "gpio-keys-polled"; > > reset { > ... > gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > /* > * GPIO line #15 is shared between the reset button on input and > * the NAND ALE (via the latch) on output. We are unable to just > * enable the reset button. So, this node here is for > * documentation purposes only. > * > * [Here should be a text describing the possible ways to > * overcome shared line issues] > */ > status = "disabled"; > }; > }; > -------------------------------- 8< --------------------------- > > This way we will keep all interconnection documentation in DTS and at the > same time we will make sure that no sane user enables this node. > > > > + compatible = "gpio-keys"; > > > + reset { > > > + label = "reset"; > > > + linux,code = <KEY_RESTART>; > > > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > > > + debounce-interval = <60>; > > > + }; > > > + }; > > -- > Sergey > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hi, > -----Original Message----- > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > On Behalf Of Koen Vandeputte > Sent: Donnerstag, 27. Mai 2021 13:52 > To: Adrian Schmutzler <mail@adrianschmutzler.de>; 'Denis Kalashnikov' > <denis281089@gmail.com>; openwrt-devel@lists.openwrt.org > Cc: 'Gabor Juhos' <juhosg@openwrt.org>; 'Sergey Ryazanov' > <ryazanov.s.a@gmail.com> > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G > > > On 23.05.21 11:01, Adrian Schmutzler wrote: > > ... > >> diff --git a/target/linux/ath79/image/mikrotik.mk > >> b/target/linux/ath79/image/mikrotik.mk > >> index 74f8603b5a..0072ec527d 100644 > >> --- a/target/linux/ath79/image/mikrotik.mk > >> +++ b/target/linux/ath79/image/mikrotik.mk > >> @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef > >> TARGET_DEVICES += mikrotik_routerboard-493g > >> > >> +define Device/mikrotik_routerboard-912g > >> + $(Device/mikrotik_nand) > >> + SOC := ar9342 > >> + DEVICE_MODEL := RouterBOARD 912G > >> + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper > >> + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef > > So, both have exactly the same setup as implemented here? > > > > Best > > > > Adrian > > > yes. > > I personally use rb-912uag-5hpnd board. > The hardware is identical with the exception of the band used. > > What's your 2 cents to get both supported using a single target? I do not have any problems with the presented solution, this was just a question. The naming and organization of the Mikrotik devices in OpenWrt has been an open discussion for quite some time now, and I have given up any hope of finding a solution that will be satisfying all competing requirements. (The only thing that I try to keep consistent for now is having "routerboard-" instead of "rb-" for the "new" names.) So, no objections for the choice made here. Best Adrian > > Thanks, > > Koen > > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hello Adrian, On Mon, May 31, 2021 at 1:15 AM Adrian Schmutzler <mail@adrianschmutzler.de> wrote: > > Hi, > > > -----Original Message----- > > From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] > > On Behalf Of Sergey Ryazanov > > Sent: Montag, 24. Mai 2021 01:07 > > To: Adrian Schmutzler <mail@adrianschmutzler.de>; Denis Kalashnikov > > <denis281089@gmail.com> > > Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>; Gabor > > Juhos <juhosg@openwrt.org>; Koen Vandeputte > > <koen.vandeputte@citymesh.com> > > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G > > > > Hello Adrian and Denis, > > > > sorry for interfering with your conversation, I would like to discuss the best > > way to document not yet finished functionality. Please find my question and > > proposal below. > > > > On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler > > <mail@adrianschmutzler.de> wrote: > > > > [skipped] > > > > >> + beeper { > > >> + status = "disabled"; > > >> + compatible = "gpio-beeper"; > > >> + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>; > > >> + }; > > > > > > If it's broken, I'd not add it here but just name the correct GPIO number in > > the commit message. > > > > > >> + > > >> + keys { > > >> + status = "disabled"; > > > > > > Like above: If it's broken, remove it, so nobody enables it accidentally and > > causes harm. > > > (But document how to set it up in the commit message, as you mostly > > > did already ...) > > > > Factoring out realization details to the commit message is quite unusual, I > > personally assume that the commit message is a place where a committer > > should describe reasons for a particular change. While hard to understand > > things should be commented on in the code themself. > > > > I agree with Adrian that a not yet finished code should not be committed to > > the master branch. But the device tree has a dualistic nature, on one hand it > > is a place for driver configuration, on the other hand it is a way to document > > board stuff interconnections. So maybe we should combine Denise's > > approach to document even a not yet fully supported component in the DTS > > with Adrian's suggestion to document why a component is not supported yet > > and place the reason to disable DTS node as comment inside the node? E.g.: > > My main motivation is preventing too much bloat in the DTS files. > > Nevertheless, typically, if stuff is not working it will either not be resolved ever > or the solution will deviate from what people were thinking it would be initially > (otherwise, they would have solved it back then). Thus, the DTS > "implementation" of that part is either irrelevant (first case) or wrong/subject > to change (second case) later. In both cases, I don't think it really makes > sense to add it to the DTS in the first place. Well! These reasons for not adding broken nodes to DTS sounds perfectly reasonable for me. But what is the best way to document hard-to-find but not yet functional GPIO lines then? Wiki? If so, should we add a wiki page URL as a comment to the DTS to facilitate work of future contributors? > Hovewer, I'm relatively flexible here. So if you really think it would be necessary to have this broken part of configuration in the DTS, I won't stop you because of that. > > > > > -------------------------------- 8< --------------------------- keys { > > compatible = "gpio-keys-polled"; > > > > reset { > > ... > > gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > > /* > > * GPIO line #15 is shared between the reset button on input and > > * the NAND ALE (via the latch) on output. We are unable to just > > * enable the reset button. So, this node here is for > > * documentation purposes only. > > * > > * [Here should be a text describing the possible ways to > > * overcome shared line issues] > > */ > > status = "disabled"; > > }; > > }; > > -------------------------------- 8< --------------------------- > > > > This way we will keep all interconnection documentation in DTS and at the > > same time we will make sure that no sane user enables this node. > > > > > > + compatible = "gpio-keys"; > > > > + reset { > > > > + label = "reset"; > > > > + linux,code = <KEY_RESTART>; > > > > + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; > > > > + debounce-interval = <60>; > > > > + }; > > > > + };
diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts new file mode 100644 index 0000000000..a23fc04a99 --- /dev/null +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts @@ -0,0 +1,233 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include "ar9344.dtsi" + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> + +/ { + compatible = "mikrotik,routerboard-912g", "qca,ar9342"; + model = "Mikrotik RouterBoard 912G"; + + leds { + compatible = "gpio-leds"; + + led_power { + label = "green:power"; + gpios = <&gpio_latch 1 GPIO_ACTIVE_HIGH>; + default-state = "on"; + }; + + led_user { + label = "green:user"; + gpios = <&gpio_latch 2 GPIO_ACTIVE_HIGH>; + }; + + led1 { + label = "green:led1"; + gpios = <&ssr 0 GPIO_ACTIVE_HIGH>; + }; + + led2 { + label = "green:led2"; + gpios = <&ssr 1 GPIO_ACTIVE_HIGH>; + }; + + led3 { + label = "green:led3"; + gpios = <&ssr 2 GPIO_ACTIVE_HIGH>; + }; + + led4 { + label = "green:led4"; + gpios = <&ssr 3 GPIO_ACTIVE_HIGH>; + }; + + led5 { + label = "green:led5"; + gpios = <&ssr 4 GPIO_ACTIVE_HIGH>; + }; + }; + + beeper { + status = "disabled"; + compatible = "gpio-beeper"; + gpios = <&ssr 5 GPIO_ACTIVE_HIGH>; + }; + + keys { + status = "disabled"; + compatible = "gpio-keys"; + reset { + label = "reset"; + linux,code = <KEY_RESTART>; + gpios = <&gpio 15 GPIO_ACTIVE_LOW>; + debounce-interval = <60>; + }; + }; + + gpio_export { + compatible = "gpio-export"; + + usb_select { + label = "select:usb"; + gpio-export,name = "mikrotik:select:usb"; + gpio-export,output = <0>; /* 0: mini-pcie, 1: Type-A port */ + gpios = <&ssr 6 GPIO_ACTIVE_LOW>; + }; + + pcie_power { + label = "power:pcie"; + gpio-export,name = "mikrotik:power:pcie"; + gpio-export,output = <1>; + gpios = <&ssr 7 GPIO_ACTIVE_LOW>; + }; + }; +}; + +&ahb { + gpio_latch: gpio_latch { + compatible = "gpio-latch"; + gpio-controller; + #gpio-cells = <2>; + gpios = <&gpio 0 0>, + <&gpio 1 0>, + <&gpio 2 0>, + <&gpio 3 0>, + <&gpio 4 0>, + <&gpio 13 0>, + <&gpio 14 0>, + <&gpio 15 0>, + <&gpio 11 0>; + latch-enable-gpios = <&gpio 11 GPIO_ACTIVE_LOW>; + }; + + nand_gpio { + compatible = "rb91x-nand"; + + /* NAND control gpios */ + read-gpios = <&gpio_latch 3 GPIO_ACTIVE_HIGH>; + rdy-gpios = <&gpio_latch 4 GPIO_ACTIVE_HIGH>; + nce-gpios = <&gpio_latch 5 GPIO_ACTIVE_LOW>; /* Chip Enable */ + cle-gpios = <&gpio_latch 6 GPIO_ACTIVE_HIGH>; /* Command Latch */ + ale-gpios = <&gpio_latch 7 GPIO_ACTIVE_HIGH>; /* Address Latch */ + nrw-gpios = <&gpio 12 GPIO_ACTIVE_LOW>; /* Read/Write */ + + latch-enable-gpios = <&gpio_latch 8 GPIO_ACTIVE_LOW>; + + partitions { + compatible = "fixed-partitions"; + #size-cells = <1>; + + partition@0 { + label = "booter"; + reg = <0x0 0x0040000>; + read-only; + }; + + partition@40000 { + label = "kernel"; + reg = <0x0040000 0x03c0000>; + }; + + partition@400000 { + label = "ubi"; + reg = <0x0400000 0x7c00000>; + }; + }; + }; +}; + +&spi { + status = "okay"; + + compatible = "qca,ar7100-spi"; + + cs-gpios = <0>, <&gpio_latch 0 GPIO_ACTIVE_LOW>; + + flash@0 { + compatible = "jedec,spi-nor"; + reg = <0>; + spi-max-frequency = <80000000>; + + partitions { + compatible = "mikrotik,routerboot-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + label = "routerboot"; + reg = <0x0 0x0>; + read-only; + }; + + hard_config: hard_config { + read-only; + }; + + bios { + size = <0x1000>; + read-only; + }; + + soft_config { + }; + }; + }; + + ssr: ssr@1 { + compatible = "fairchild,74hc595"; + gpio-controller; + #gpio-cells = <2>; + registers-number = <1>; + reg = <1>; + spi-max-frequency = <50000000>; + }; +}; + +&pcie { + status = "okay"; +}; + +&uart { + status = "okay"; +}; + +&mdio0 { + status = "okay"; + + phy-mask = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + }; +}; + +ð0 { + status = "okay"; + + phy-mode = "rgmii-id"; + phy-handle = <&phy0>; + pll-data = <0x02000000 0x00000101 0x00001313>; + + gmac-config { + device = <&gmac>; + rgmii-gmac0 = <1>; + rgmii-enabled = <1>; + rxd-delay = <1>; + txd-delay = <1>; + }; +}; + +&wmac { + status = "okay"; + qca,no-eeprom; +}; + +&usb { + status = "okay"; +}; + +&usb_phy { + status = "okay"; +}; diff --git a/target/linux/ath79/image/mikrotik.mk b/target/linux/ath79/image/mikrotik.mk index 74f8603b5a..0072ec527d 100644 --- a/target/linux/ath79/image/mikrotik.mk +++ b/target/linux/ath79/image/mikrotik.mk @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef TARGET_DEVICES += mikrotik_routerboard-493g +define Device/mikrotik_routerboard-912g + $(Device/mikrotik_nand) + SOC := ar9342 + DEVICE_MODEL := RouterBOARD 912G + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd +endef +TARGET_DEVICES += mikrotik_routerboard-912g + define Device/mikrotik_routerboard-921gs-5hpacd-15s $(Device/mikrotik_nand) SOC := qca9558 diff --git a/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network b/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network index 4ffe82588c..07bb22c088 100644 --- a/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network +++ b/target/linux/ath79/mikrotik/base-files/etc/board.d/02_network @@ -14,6 +14,7 @@ ath79_setup_interfaces() ucidef_add_switch "switch1" \ "0@eth1" "1:lan:4" "2:lan:1" "3:lan:2" "4:lan:3" ;; + mikrotik,routerboard-912g|\ mikrotik,routerboard-921gs-5hpacd-15s|\ mikrotik,routerboard-lhg-2nd|\ mikrotik,routerboard-sxt-5nd-r2|\ @@ -36,6 +37,7 @@ ath79_setup_macs() local mac_base="$(cat /sys/firmware/mikrotik/hard_config/mac_base)" case "$board" in + mikrotik,routerboard-912g|\ mikrotik,routerboard-921gs-5hpacd-15s|\ mikrotik,routerboard-lhg-2nd|\ mikrotik,routerboard-sxt-5nd-r2|\ diff --git a/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom index 7ef6fdbe0f..7868ceaac9 100644 --- a/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom +++ b/target/linux/ath79/mikrotik/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom @@ -23,6 +23,7 @@ board=$(board_name) case "$FIRMWARE" in "ath9k-eeprom-ahb-18100000.wmac.bin") case $board in + mikrotik,routerboard-912g|\ mikrotik,routerboard-lhg-2nd|\ mikrotik,routerboard-sxt-5nd-r2|\ mikrotik,routerboard-wapr-2nd) diff --git a/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh b/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh index 97d388168f..736a0932f7 100644 --- a/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh +++ b/target/linux/ath79/mikrotik/base-files/lib/upgrade/platform.sh @@ -32,6 +32,7 @@ platform_do_upgrade() { case "$board" in mikrotik,routerboard-493g|\ + mikrotik,routerboard-912g|\ mikrotik,routerboard-921gs-5hpacd-15s|\ mikrotik,routerboard-922uags-5hpacd|\ mikrotik,routerboard-sxt-5nd-r2)
This board has been supported in the ar71xx. Links: * https://mikrotik.com/product/RB912UAG-2HPnD * https://mikrotik.com/product/RB912UAG-5HPnD * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd Hardware: * SoC: Atheros AR9342, * RAM: DDR 64MB, * SPI NOR: 64KB, * NAND: 128MB, * Ethernet: x1 10/100/1000 port with passive POE in, * Wi-Fi: 802.11bgn, * PCIe, * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A port -- both can be used for LTE modem. But only one can be used. * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED, Ethernet phy LED, * Button, * Beeper. Not working: * Button: it shares gpio line 15 with NAND ALE and NAND IO7, and current drivers doesn't easily support this configuration, * Beeper: it is connected to bit 5 of a serial shift register (tested with sysfs led trigger timer). But kmod-gpio-beeper doesn't work -- we left this as is for now. You can flash image by sysupgrade utility or load it by net (by DHCP/TFTP, hold the button while booting). Co-Developed-by: Koen Vandeputte <koen.vandeputte@citymesh.com> Signed-off-by: Denis Kalashnikov <denis281089@gmail.com> --- Changelog: v1->v2: - Delete uneeded comments from DTS, - Delete ascii-art of board scheme near NAND latch from DTS, - Rewrite gpio_latch and nand_gpio nodes to be consistent with the new versions of drivers, - Fix SPI NOR flash and SPI serial shift register maximum speeds (thanks to Koen Vandeputte), - Add UART, PCIe, USB support and gpio exports (thanks to Koen Vandeputte), - Fix Ethernet node (thanks to Koen Vandeputte), - Add key and beeper nodes in disabled state just to be documented. --- .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++++++++++++++++++ target/linux/ath79/image/mikrotik.mk | 9 + .../base-files/etc/board.d/02_network | 2 + .../etc/hotplug.d/firmware/10-ath9k-eeprom | 1 + .../base-files/lib/upgrade/platform.sh | 1 + 5 files changed, 246 insertions(+) create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts