Re: [OpenWrt-Devel] mt76x8: Strange GPIO numbering on Onion Omega2+
On Sat, May 2, 2020 at 10:15 PM Gerhard Bertelsmann wrote: > I've installed the latest OpenWRT trunk version. Everything > seems to be fine except the port numbering: (...) > Is this common to the new kernel versions or is there > something missing ? We are moving away from the global GPIO numberspace used by pretty much only the deprecated (since 5 years+) sysfs. The reasons behind deprecation of sysfs and the GPIO global numberspace is detailed in our TODO: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/TODO What we encourage as GPIO maintainers is for consuming projects to use the GPIO character device utilizing the libgpiod library: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ The library comes with a few example tools that are pretty useful for tinkering and experimenting with the character device. I'd be thrilled if libgpiod could be included with OpenWrt given how much use it actually sees in GPIO-based automation despite its roots in routers. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
On Sun, Jun 13, 2021 at 9:52 PM Joe Ayers wrote: > > I'm having a bit of heartburn with continuing with these instructions: > > > Flashing via stock GUI: > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions) > > This issue was resolved with: > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 Those commits resolve the problem for TFTP, but if people want to use the GUI, they still need to downgrade, right? Both instructions are included in the commit message. Note that the TFTP instructions don't mention downgrading. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mt76x8: Strange GPIO numbering on Onion Omega2+
On Mon, Jun 14, 2021 at 9:28 AM Linus Walleij wrote: > > On Sat, May 2, 2020 at 10:15 PM Gerhard Bertelsmann > wrote: > > > I've installed the latest OpenWRT trunk version. Everything > > seems to be fine except the port numbering: > (...) > > Is this common to the new kernel versions or is there > > something missing ? > > We are moving away from the global GPIO numberspace used by pretty > much only the deprecated (since 5 years+) sysfs. > > The reasons behind deprecation of sysfs and the GPIO global numberspace > is detailed in our TODO: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpio/TODO > > What we encourage as GPIO maintainers is for consuming projects > to use the GPIO character device utilizing the libgpiod library: > https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ > > The library comes with a few example tools that are pretty useful for > tinkering and experimenting with the character device. > > I'd be thrilled if libgpiod could be included with OpenWrt given how much > use it actually sees in GPIO-based automation despite its roots in > routers. > > Yours, > Linus Walleij Hi! I'm seeing that libgpiod v1.4.4 is available in OpenWRT but this version is quite dated. I'll see if I can upgrade it to v1.6.3. Bart ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
download: regression with USE_SOURCE_DIR and non-tarball packages?
Hello Petr, a while ago (after switching projects from 19.07.3 to 19.07.6) I experienced unexpected rebuilds of packages. I asked about this in the forum [1] with no echo, so last week I dug deeper and think I found your commit from last november "4e19cbc - download: handle possibly invalid local tarballs" [2] causing what I see. I'm a build system newbie, so please apologize if I misunderstand things here. But it seems to me that this patch only works for packages that pull their upstream source from a tarball via download.pl, because only there a hash check prevents redownloads (causing rebuilds) in the last possible moment by exiting the script before the download would happen. For packages with PKG_SOURCE_PROTO=git the new line in package.mk `$(DL_DIR)/$(FILE): FORCE` forces re-cloning the upstream repo and thus rebuilding the entire package every time. Also, the USE_SOURCE_DIR mechanism does not work any more. Both git based packages and USE_SOURCE_DIR are central to my work (which is building automation devices based on OpenWrt, so most work is happening *in* my own packages, which are in git or, during hot development phases, via USE_SOURCE_DIR even directly linked dirs). I realize this is not a common situation for OpenWrt platform developers, but only for developers basing other stuff on OpenWrt. As said, I don't understand the details of the build system enough to actually propose a proper patch right into the heart of it. But below is my current workaround to re-enable USE_SOURCE_DIR and git-based packages, hopefully not affecting anything else I can't see. So far, works for me, but definitely needs a thorough look by someone who actually understands the whole thing... Lukas [1] https://forum.openwrt.org/t/does-19-07-6-trigger-package-downloads-rebuilds-more-frequently-than-19-07-3/92471 [2] http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032235.html --- a/include/package.mk +++ b/include/package.mk @@ -177,6 +177,12 @@ define Build/Exports/Default endef Build/Exports=$(Build/Exports/Default) +ifneq ($(wildcard $(PKG_BUILD_DIR)/.source_dir),) + FORCE_DL:= +else + FORCE_DL=$(if $(findstring git,$(PKG_SOURCE_PROTO)),,$(DL_DIR)/$(FILE): FORCE) +endif + define Build/CoreTargets STAMP_PREPARED:=$$(STAMP_PREPARED) STAMP_CONFIGURED:=$$(STAMP_CONFIGURED) @@ -185,7 +191,7 @@ define Build/CoreTargets $(call Build/Autoclean) $(call DefaultTargets) - $(DL_DIR)/$(FILE): FORCE + $(FORCE_DL) download: $(foreach hook,$(Hooks/Download), signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ip rule processing partly broken (21.02 and Master)
ip rule command line parsing is partly broken in MASTER and 21.02 (using only default packages). The command below works fine in 19.07 and big Debian. If you remove the word "not", the command parses fine in 21.02 root@2102rc2# ip rule add not from all fwmark 0x888 lookup 239 ip: invalid argument 'not' to 'ip' My original bug tracker for this was about uci. https://bugs.openwrt.org/index.php?do=details&task_id=3876 But it appears there is a problem with BOTH the scripts which process the uci and with the "ip rule" command itself. When you specify "invert" in the uci, you do get an almost-right rule, but it looks like the "invert" was simply ignored. If the uci scripts had generated the correct "ip rule" command, the command would have failed and no "almost right" rule would be visible. Thanks! Happy to help in further triage. M ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
> > I'm having a bit of heartburn with continuing with these instructions: > > > > > Flashing via stock GUI: > > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see > > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions) > > > > This issue was resolved with: > > > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 > > Those commits resolve the problem for TFTP, but if people want to use > the GUI, they still need to downgrade, right? Both instructions are > included in the commit message. Note that the TFTP instructions don't > mention downgrading. I remember flashing via the stock GUI in AirOS v5.6.? had worked. As I recall, firmware signatures were not required until a future AirOS version . If so, downgrading shouldn't need to occur all the way back to v5.5.10-u2. The AirOS release note history should tell us when firmware signing was introduced. I'm sorry, I don't have time available to substantiate right now, to make sure my memory is correct. Would anyone ever follow the GUI flash with all the steps, when 1 tftp flash works?I suspect there is no impact regardless, might just move forward, not worth the time. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ip rule processing partly broken (21.02 and Master)
Hi, the ip rules encoded in /etc/config/network are processed by netifd C code directly, they're not translated into busybox ip calls. The entire busybox ip.c code contains not a single instance of FIB_RULE_INVERT so it simply does not implement inversion. It will also not be able to report inverted rules properly, since there is no code to print the FIB_RULE_INVERT flag. Are you absolutely sure that the uci rules are improperly applied or is this just a case of busybox ip rule displaying them wrongly without the "not" flag? Can you install ip-full or ip-tiny from the iproute2 suite and verify the "ip rule" output again? ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
On 27.05.21 10:16, Denis Kalashnikov wrote: From: Denis Kalashnikov RB912 needs two ad hoc drivers: gpio-latch and rb91x_nand. So I've ported them from ar71xx and added DTS. In RFC v1 I added a MFD driver that provided API for manipulating shared gpio lines to gpio-latch and nand drivers. In RFC v2 I just ported gpio-latch and rb91x_nand drivers from ar71xx to ath79 by adding DTS support and usage of a new gpio API (gpiod_*). This way is turned to be more clear and compact. So, I've tried to fix what you guys advised me and here is my patches v1. All seems to be working on my RB912UAG-2HPnD. Except a button and a beeper. The beeper seems is not important thing, but the button is. The button shares gpio 15 with NAND ALE and NAND IO7, but this is not easily supported by the current drivers. May be we need ad hoc driver for button. Or may be there is a more general solution for this problem (like rb91x-gpio driver that arbitrates all gpio lines instead of gpio-latch). This can be fixed in the next patches. Denis Kalashnikov (3): ath79: add gpio-latch driver for MikroTik RouterBOARDs ath79: add NAND driver for MikroTik RB91xG series ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD ...9342_mikrotik_routerboard-912uag-2hpnd.dts | 214 ++ .../ath79/files/drivers/gpio/gpio-latch.c | 203 ++ .../files/drivers/mtd/nand/raw/rb91x_nand.c | 375 ++ 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 + target/linux/ath79/mikrotik/config-default| 1 + .../patches-5.10/939-mikrotik-rb91x.patch | 49 +++ .../patches-5.4/939-mikrotik-rb91x.patch | 44 ++ 10 files changed, 899 insertions(+) create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch Tested on the 5GHz flavor and works fine Any other objections/remarks? I will merge this otherwise tomorrow. Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
Hi,
a few remaining comments below.
> + gpio-export {
> + compatible = "gpio-export";
> +
> + usb_power {
> + label = "power:usb";
gpio-export nodes normally don't have a label property. We have
gpio-export,name instead.
> + gpio-export,name = "power-usb";
> + gpio-export,output = <1>;
> + gpios = <&ssr 6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + pcie_power {
> + label = "power:pcie";
> + gpio-export,name = "power-pcie";
> + gpio-export,output = <0>;
> + gpios = <&ssr 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> +&spi {
> + status = "okay";
> +
> + compatible = "qca,ar7100-spi";
> +
> + cs-gpios = <0>, <&gpio_latch 0 GPIO_ACTIVE_LOW>;
I still don't think this belongs here. Why would it be the only device
requiring this, while we removed it everywhere else?
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <8000>;
Typically, speeds > 50 MHz require m25p,fast-read?
Best
Adrian
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: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
On Mon, Jun 14, 2021 at 6:54 AM Joe Ayers wrote: > > > > I'm having a bit of heartburn with continuing with these instructions: > > > > > > > Flashing via stock GUI: > > > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see > > > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions) > > > > > > This issue was resolved with: > > > > > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 > > > > Those commits resolve the problem for TFTP, but if people want to use > > the GUI, they still need to downgrade, right? Both instructions are > > included in the commit message. Note that the TFTP instructions don't > > mention downgrading. > > I remember flashing via the stock GUI in AirOS v5.6.? had worked. As > I recall, firmware signatures were not required until a future AirOS > version . If so, downgrading shouldn't need to occur all the way > back to v5.5.10-u2. The AirOS release note history should tell us > when firmware signing was introduced. I'm sorry, I don't have time > available to substantiate right now, to make sure my memory is > correct. > > Would anyone ever follow the GUI flash with all the steps, when 1 tftp > flash works?I suspect there is no impact regardless, might just > move forward, not worth the time. No one seems to have tried all the starting condition possibilities, I certainly haven't. If we were being crushingly complete in testing, we would try every one of them. If we knew how likely each starting condition is, we could even weight our instructions accordingly. Given that serial access is not easy right now, because of not being able (at least I'm not able) to non-destructively open the feedhorn enclosure to get access to the serial console pins, I'd rather not risk trying an AirOS that might make it impossible to recover. Given that this is *JUST A COMMIT MESSAGE* and not a mutable, improvable, instruction (which should live on the wiki anyway), it seems to me reasonable to accept being a little conservative in the instructions here, even if some of the steps turn out to not be strictly necessary. -- Russell Senior russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
