Hi, Thank you very much for clarifying that. :)
After looking a little bit into other devices' configurations, this line in etc/board.d/01_leds will do the trick: ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan" "switch0" "0x02" Last thing, I managed to get inside the stock firmware (a customized OpenWrt version, by the way) and I saw that: - the port labeled "LAN", in U-Boot is eth0, in the stock firmware is eth1 - the port labeled "WAN", in U-Boot is eth1, in the stock firmware is eth0 Should I be coherent to U-Boot and use the more common LAN-eth0//WAN-eth1 assignation, or do it the other way round (LAN-eth1//WAN-eth0) as in the stock firmware? Thanks for your comments, Roger El 17/12/18 a les 5:50, Chuanhong Guo ha escrit: > Hi! > > On Mon, Dec 17, 2018 at 7:43 AM Roger Pueyo Centelles | Guifi.net > <[email protected]> wrote: >> Hi Seb, >> >> You nailed it! :-) >> >> I was missing the ' "pinctrl-names = "default"; ' line. I must have >> removed it from the .dts file I used as the source for mine at some >> point. Then I just sorted the pinctrl-0/1 issue, which I had already >> tried in any possible combination. >> >> After fixing this, I have detected another issue that had passed >> unnoticed to me before. The eth1 interface always appears as UP (i.e., >> having link), even if I unplug the cable. > This is expected. gmac1 is connected to builtin switch, which means > this link is always up. Link changes happen in builtin switch, not > gmac. > ar71xx mixed switch and gmac driver together and it uses switch port > status for gmac link. These two drivers are separated in ath79. >> According to the datasheet, GMAC1 (eth1 here) is internally connected to >> the integrated switch. The "swconfig dev switch0 show" command gives: >> >> Port 0: >> enable_mirror_rx: 0 >> enable_mirror_tx: 0 >> pvid: 0 >> link: port:0 link:up speed:1000baseT full-duplex txflow rxflow >> Port 1: >> enable_mirror_rx: 0 >> enable_mirror_tx: 0 >> pvid: 1 >> link: port:1 link:up speed:100baseT full-duplex auto >> >> How should I manage this? >> >> Thank you very much for your support. >> >> Best, >> >> Roger >> >> El 16/12/18 a les 19:07, Sebastian Kemper ha escrit: >>> On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net >>> wrote: >>>> Hi, >>> Hello Roger! >>> >>>> [...] >>>> >>>> leds { >>>> compatible = "gpio-leds"; >>>> pinctrl-1 = <&led_rssilow_pin &led_rssimediumhigh_pin >>>> &led_rssihigh_pin>; >>>> >>>> [...] >>>> >>>> &pinmux { >>>> led_rssilow_pin: pinmux_rssilow_pin { >>>> pinctrl-single,bits = <0x8 0x0 0xff000000>; >>>> }; >>>> >>>> led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin { >>>> pinctrl-single,bits = <0xc 0x0 0x00ff0000>; >>>> }; >>>> >>>> led_rssihigh_pin: pinmux_rssihigh_pin { >>>> pinctrl-single,bits = <0x10 0x0 0x000000ff>; >>>> }; >>>> }; >>>> >>>> [...] >>> The pinmux part looks OK to me. Could you change the leds part to the >>> below and try again? >>> >>> leds { >>> compatible = "gpio-leds"; >>> >>> pinctrl-names = "default"; >>> pinctrl-0 = <&jtag_disable_pins &led_rssilow_pin >>> &led_rssimediumhigh_pin &led_rssihigh_pin>; >>> >>> [...] >>> >>> I added the jtag bit because I saw that you use it under keys. You have >>> to remove >>> >>> pinctrl-0 = <&jtag_disable_pins>; >>> >>> under keys. Just put them all in one place. >>> >>> From my testing, when defining pinctrl-0 and pinctrl-1, the second one >>> doesn't do anything. For example: >>> >>> pinctrl-0 = <&jtag_disable_pins>; // works >>> pinctrl-1 = <&enable_gpio_11>; // nothing happens >>> >>> But >>> >>> pinctrl-0 = <&jtag_disable_pins &enable_gpio_11>; // both are applied - >>> works >>> >>> >>> Kind regards, >>> Seb >> _______________________________________________ >> openwrt-devel mailing list >> [email protected] >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
