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
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: Re: [OpenWrt-Devel] mt76x8: Strange GPIO numbering on Onion Omega2+
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.--- Begin Message --- Hi Lukas, On Sat, Jun 12, 2021 at 9:49 PM Lukas Zeller wrote: > > Hi Gerd, > > > There is still one major issue migrating to 21.02 on my side: Reboot > > doesn't work. I need to switch power off/on on my Omega2+. AFAIU it has > > somethoing to do with the SPI 3byte/4byte mode. Older versions worked, but > > 4byte mode seems to boot faster. BTW: spi-nor spi0.0: mx25l25635e (32768 > > Kbytes) > > This is a hardware problem of the Omega2+ (so further details -> probably off > topic for here). But in short: The SPI flash chip must be in 3-byte mode for > the MT7688 to start the way CHIP_MODE pins are wired in the Omega2. A power > cycle resets the flash to 3 byte mode, however just a SoC reset does not, and > if the SPI chip is in 4 byte mode when the reset occurs, the MT7688 will try > to boot in 3 byte mode from a chip that is in 4 byte mode. There is a "broken-flash-reset" property which probably is missing in the Omega2+ .dts(i) files See target/linux/ramips/dts/mt7621_gnubee_gb-pc1.dts for an example on how it's used If you have already considered this and my comment does not apply then please ignore it (I am not familiar with any of the Ralink/Mediatek SoCs, I just recognized this problem description) Best regards, Martin [0] https://elixir.bootlin.com/linux/v5.4.48/source/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt#L72 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: [OpenWrt-Devel] mt76x8: Strange GPIO numbering on Onion Omega2+
Hi Gerd, > There is still one major issue migrating to 21.02 on my side: Reboot doesn't > work. I need to switch power off/on on my Omega2+. AFAIU it has somethoing to > do with the SPI 3byte/4byte mode. Older versions worked, but 4byte mode seems > to boot faster. BTW: spi-nor spi0.0: mx25l25635e (32768 Kbytes) This is a hardware problem of the Omega2+ (so further details -> probably off topic for here). But in short: The SPI flash chip must be in 3-byte mode for the MT7688 to start the way CHIP_MODE pins are wired in the Omega2. A power cycle resets the flash to 3 byte mode, however just a SoC reset does not, and if the SPI chip is in 4 byte mode when the reset occurs, the MT7688 will try to boot in 3 byte mode from a chip that is in 4 byte mode. This is only a problem for the 32M flash, as it needs 4-byte addresses. The Omega2 (non +) with 16M flash is thus not affected, it stays in 3 byte mode all the time. See [1] for a hardware solution Onion suggests for the Omega2S+ (the SMT version), which has the flash VDD exposed separately, so this does not work for the THT Omega2+ :-( Best Regards Lukas [1] https://github.com/OnionIoT/Omega2/blob/master/Documents/Omega2S%20Hardware%20Design%20Guide.pdf signature.asc Description: Message signed with OpenPGP ___ 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+
Hi Reto, excellent catch ! Looks much better now ;-) Thanks a lot ! There is still one major issue migrating to 21.02 on my side: Reboot doesn't work. I need to switch power off/on on my Omega2+. AFAIU it has somethoing to do with the SPI 3byte/4byte mode. Older versions worked, but 4byte mode seems to boot faster. BTW: spi-nor spi0.0: mx25l25635e (32768 Kbytes) Does you LinkIt Smart reboot works with actual OpenWRT versions ? Regards Gerd Am 2021-06-12 17:51, schrieb Reto Schneider: Hi Gerd, Very late to the party, but I had a similar problem on my MT7688 based device and came up with the attached (not yet upstreamed) patch. While I also was also able to verify the problem for OpenWRT (yesterdays OpenWrt SNAPSHOT r16925-b721579842) using a LinkIt Smart 7688, I have not actually integrated the patch in and therefore not tested on OpenWRT. Not sure if and when I'll find the time to do so. Hope this is still helpful to someone. Kind regards, Reto [1] https://github.com/husqvarnagroup/smart-garden-gateway-yocto-meta-mediatek/blob/38b41e0a68a9b1ca4cd7af33ad37177ef63ba62d/recipes-kernel/linux/linux-yocto-tiny-5.10.42/0013-gpio-mt7621-Assign-base-field-in-gpio_chip.patch ___ 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+
Hi Gerd,
Very late to the party, but I had a similar problem on my MT7688 based
device and came up with the attached (not yet upstreamed) patch.
While I also was also able to verify the problem for OpenWRT (yesterdays
OpenWrt SNAPSHOT r16925-b721579842) using a LinkIt Smart 7688, I have
not actually integrated the patch in and therefore not tested on
OpenWRT. Not sure if and when I'll find the time to do so. Hope this is
still helpful to someone.
Kind regards,
Reto
[1]
https://github.com/husqvarnagroup/smart-garden-gateway-yocto-meta-mediatek/blob/38b41e0a68a9b1ca4cd7af33ad37177ef63ba62d/recipes-kernel/linux/linux-yocto-tiny-5.10.42/0013-gpio-mt7621-Assign-base-field-in-gpio_chip.patch
From f0891893dd8d65e59f5ae4ef19c2a509f35d060f Mon Sep 17 00:00:00 2001
From: Reto Schneider
Date: Sat, 5 Jun 2021 14:21:17 +0200
Subject: [PATCH] gpio: mt7621: Assign base field in gpio_chip
This is needed for gpiochip_sysfs_register() to properly export
/sys/class/gpio/gpiochip{0,32,64}.
Without this fix, the field base in gpio_device remains at its
initialization value, which is -1. This causes
gpiochip_add_data_with_key() to call gpiochip_find_base(), which in turn
dynamically determines the base to be at ARCH_NR_GPIOS - 32/64/96,
resulting in gpiochip{480,448,416}.
Detected/fixed/tested on a MediaTek MT7688 based GARDENA smart gateway.
Signed-off-by: Reto Schneider
---
drivers/gpio/gpio-mt7621.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
index 82fb20dca53a..403d64cd65a6 100644
--- a/drivers/gpio/gpio-mt7621.c
+++ b/drivers/gpio/gpio-mt7621.c
@@ -234,6 +234,7 @@ mediatek_gpio_bank_probe(struct device *dev,
return ret;
}
+ rg->chip.base = rg->bank * MTK_BANK_WIDTH;
rg->chip.of_gpio_n_cells = 2;
rg->chip.of_xlate = mediatek_gpio_xlate;
rg->chip.label = devm_kasprintf(dev, GFP_KERNEL, "%s-bank%d",
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
