Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hello Adrian,
On Mon, May 31, 2021 at 1:15 AM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sergey Ryazanov
> > Sent: Montag, 24. Mai 2021 01:07
> > To: Adrian Schmutzler ; Denis Kalashnikov
> >
> > Cc: OpenWrt Development List ; Gabor
> > Juhos ; Koen Vandeputte
> >
> > 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
> > wrote:
> >
> > [skipped]
> >
> > >> + beeper {
> > >> + status = "disabled";
> > >> + compatible = "gpio-beeper";
> > >> + gpios = < 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 = < 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 = ;
> > > > + gpios = < 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
RE: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Koen Vandeputte > Sent: Donnerstag, 27. Mai 2021 13:52 > To: Adrian Schmutzler ; 'Denis Kalashnikov' > ; openwrt-devel@lists.openwrt.org > Cc: 'Gabor Juhos' ; 'Sergey Ryazanov' > > 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 openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sergey Ryazanov
> Sent: Montag, 24. Mai 2021 01:07
> To: Adrian Schmutzler ; Denis Kalashnikov
>
> Cc: OpenWrt Development List ; Gabor
> Juhos ; Koen Vandeputte
>
> 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
> wrote:
>
> [skipped]
>
> >> + beeper {
> >> + status = "disabled";
> >> + compatible = "gpio-beeper";
> >> + gpios = < 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 = < 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 = ;
> > > + gpios = < 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
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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? Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
> 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 = <_latch 3 GPIO_ACTIVE_HIGH>; > > + rdy-gpios = <_latch 4 GPIO_ACTIVE_HIGH>; > > + nce-gpios = <_latch 5 GPIO_ACTIVE_LOW>; /* Chip > > Enable */ > > + cle-gpios = <_latch 6 GPIO_ACTIVE_HIGH>; /* Command > > Latch */ > > + ale-gpios = <_latch 7 GPIO_ACTIVE_HIGH>; /* Address > > Latch */ > > + nrw-gpios = < 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hello Adrian
> > + {
> > + status = "okay";
> > +
> > + compatible = "qca,ar7100-spi";
> > +
> > + cs-gpios = <0>, <_latch 0 GPIO_ACTIVE_LOW>;
>
> Are you sure you need cs-gpios here? We've removed it everywhere else (for
> 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.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
On Fri, May 21, 2021 at 2:05 PM Denis Kalashnikov 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
> Signed-off-by: Denis Kalashnikov
> ---
>
> 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 00..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
> +#include
> +
> +/ {
> + compatible = "mikrotik,routerboard-912g", "qca,ar9342";
> + model = "Mikrotik RouterBoard 912G";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power {
> + label = "green:power";
> + gpios = <_latch 1 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + led_user {
> + label = "green:user";
> + gpios = <_latch 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led1 {
> + label = "green:led1";
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led2 {
> + label = "green:led2";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led3 {
> + label = "green:led3";
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led4 {
> + label = "green:led4";
> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led5 {
> + label = "green:led5";
> + gpios = < 4 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + beeper {
> + status = "disabled";
> + compatible = "gpio-beeper";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + };
> +
> + keys {
> + status = "disabled";
> + compatible = "gpio-keys";
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 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 = < 6 GPIO_ACTIVE_LOW>;
> + };
> +
> + pcie_power {
> +
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
wrote:
[skipped]
>> + beeper {
>> + status = "disabled";
>> + compatible = "gpio-beeper";
>> + gpios = < 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 = < 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 = ;
> > + gpios = < 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
RE: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Denis Kalashnikov
> Sent: Freitag, 21. Mai 2021 13:05
> To: openwrt-devel@lists.openwrt.org
> Cc: Gabor Juhos ; Koen Vandeputte
> ; Sergey Ryazanov
>
> 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
> Signed-off-by: Denis Kalashnikov
> ---
>
> 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 00..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
> +#include
> +
> +/ {
> + compatible = "mikrotik,routerboard-912g", "qca,ar9342";
> + model = "Mikrotik RouterBoard 912G";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power {
> + label = "green:power";
> + gpios = <_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 = <_latch 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led1 {
> + label = "green:led1";
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led2 {
> + label = "green:led2";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led3 {
> + label = "green:led3";
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led4 {
> + label = "green:led4";
> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led5 {
> + label = "green:led5";
> + g
[RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
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
Signed-off-by: Denis Kalashnikov
---
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 00..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
+#include
+
+/ {
+ compatible = "mikrotik,routerboard-912g", "qca,ar9342";
+ model = "Mikrotik RouterBoard 912G";
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power {
+ label = "green:power";
+ gpios = <_latch 1 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ led_user {
+ label = "green:user";
+ gpios = <_latch 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ led1 {
+ label = "green:led1";
+ gpios = < 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ led2 {
+ label = "green:led2";
+ gpios = < 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ led3 {
+ label = "green:led3";
+ gpios = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ led4 {
+ label = "green:led4";
+ gpios = < 3 GPIO_ACTIVE_HIGH>;
+ };
+
+ led5 {
+ label = "green:led5";
+ gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ beeper {
+ status = "disabled";
+ compatible = "gpio-beeper";
+ gpios = < 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ keys {
+ status = "disabled";
+ compatible = "gpio-keys";
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 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 = < 6 GPIO_ACTIVE_LOW>;
+ };
+
+ pcie_power {
+ label = "power:pcie";
+ gpio-export,name = "mikrotik:power:pcie";
+ gpio-export,output = <1>;
+ gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+ {
+ gpio_latch: gpio_latch {
+ compatible = "gpio-latch";
+ gpio-controller;
+
