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
Re: [PATCH] tools: fix ninja build dependency
Martin Blumenstingl writes: > Felix pushed a fix like 1.5 hours ago: [0] > to me your patch looks identical to Felix' Great! That's the result of being interrupted between preparing a patch and sending it. I should have pulled again. Nice timing :-) Anyway, happy to see it fixed. And to see us both choosing the exact same place to put this. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] tools: fix ninja build dependency
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 ---
On Sat, Jun 12, 2021 at 2:15 PM Bjørn Mork wrote:
>
> Fixing this build error:
>
> make[3]: Entering directory '/p/tools/ccache'
> MAKEFLAGS="" /p/staging_dir/host/bin/ninja -j1 -C
> /p/build_dir/host/ccache-4.2.1
> bash: /p/staging_dir/host/bin/ninja: No such file or directory
> make[3]: *** [Makefile:43: /p/build_dir/host/ccache-4.2.1/.built] Error 127
> make[3]: Leaving directory '/p/tools/ccache'
> time: tools/ccache/compile#0.03#0.00#0.04
> ERROR: tools/ccache failed to build.
> make[2]: *** [tools/Makefile:158: tools/ccache/compile] Error 1
>
> Fixes: 97258f53634d ("build: add ninja build tool and make it available for
> cmake")
> Signed-off-by: Bjørn Mork
Felix pushed a fix like 1.5 hours ago: [0]
to me your patch looks identical to Felix'
Best regards,
Martin
[0]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=d45baa860ffc79ae1cf68fceb94990e39bb06bab
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools: fix ninja build dependency
Fixing this build error:
make[3]: Entering directory '/p/tools/ccache'
MAKEFLAGS="" /p/staging_dir/host/bin/ninja -j1 -C
/p/build_dir/host/ccache-4.2.1
bash: /p/staging_dir/host/bin/ninja: No such file or directory
make[3]: *** [Makefile:43: /p/build_dir/host/ccache-4.2.1/.built] Error 127
make[3]: Leaving directory '/p/tools/ccache'
time: tools/ccache/compile#0.03#0.00#0.04
ERROR: tools/ccache failed to build.
make[2]: *** [tools/Makefile:158: tools/ccache/compile] Error 1
Fixes: 97258f53634d ("build: add ninja build tool and make it available for
cmake")
Signed-off-by: Bjørn Mork
---
tools/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Makefile b/tools/Makefile
index 47a82fd23782..dccf298af6ee 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -43,7 +43,7 @@ $(curdir)/b43-tools/compile := $(curdir)/bison/compile
$(curdir)/bc/compile := $(curdir)/bison/compile $(curdir)/libtool/compile
$(curdir)/bison/compile := $(curdir)/flex/compile
$(curdir)/cbootimage/compile += $(curdir)/automake/compile
-$(curdir)/cmake/compile += $(curdir)/libressl/compile
+$(curdir)/cmake/compile += $(curdir)/libressl/compile $(curdir)/ninja/compile
$(curdir)/dosfstools/compile := $(curdir)/autoconf/compile
$(curdir)/automake/compile
$(curdir)/e2fsprogs/compile := $(curdir)/libtool/compile
$(curdir)/fakeroot/compile := $(curdir)/libtool/compile
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ramips: fix at803x patch again
Hi John, On 6/12/21 12:51 AM, John Thomson wrote: On Fri, 11 Jun 2021, at 08:10, David Bauer wrote: Can you be more precise in terms of which issues are you facing? The PHY capabilities on the AR8333 now read 1000B-X as a supported link mode, so fiber operation should be possible. Can you share the capabilities advertised with current master and your path (ethtool). Reverting these patches would divert from upcoming kernel versions (mind both are backports, not downstream hacks), thus this is not a solution. Ideally, the fiber operation should be integrated into the upstream driver. I agree that this should be corrected atop the backports. It would be great to see this SFP support upstreamed. I have not tested SFP on OpenWrt master for some time, so I cannot blame a change yet. This is what I am seeing on ramips 760igs: SFP (module, and driver LOS) has link detected, but this is not reflected by the interface (which is configured in OpenWrt as part of a bridge) I suppose what is happening here is the bootloader switched the PHY to the fiber page while linux now switches it to the copper page unconditionally. Technically, this is correct from upstream perspective, as the PHY upstream only supports copper opmode. But it breaks the hacked fiber support downstream. DENGs initial patch fixed this with the old downstream hacks, where the page was only switched when the PHY operated in SGMII mode, as the whole assumption this patch was based upon was wrong but lead to the correct result. However, while we now get the correct link modes, we now switch to the fiber page upon probe. Note that I haven't verified this, as i do not own this board. I'll prepare a patch and send it to this thread this weekend. Would be great if someone with this board could test it :) Best David sfp: mtu 1500 qdisc fq_codel master br-wan state DOWN qlen 1000 r16925+6-b721579842 master, plus my SPI-NOR changes: https://github.com/openwrt/openwrt/pull/3271/commits I do not remember these being looped in dmesg when I had working SFP: sfp sfp1: SM: enter present:up:link_up event dev_up sfp sfp1: SM: exit present:up:link_up ethtool sfp Settings for sfp: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 1000baseX/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 1000baseX/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Port: MII PHYAD: 7 Transceiver: external Auto-negotiation: on Current message level: 0x00ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: no Pieces missing from a very old (r14885+1-fe302d472a) working SFP build: link partner advertisement and link speed / duplex Link partner advertised link modes: 1000baseX/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 7 Transceiver: external Auto-negotiation: on Current message level: 0x00ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: yes these cannot be forced on my current build: ethtool -s sfp speed 1000 duplex full [ 182.182182] at803x_config_aneg: fiber Attached: version=$(cat /etc/openwrt_version) mkdir -p "/tmp/sfp/$version" dmesg > "/tmp/sfp/$version/dmesg" logread > "/tmp/sfp/$version/logread" ethtool sfp > "/tmp/sfp/$version/ethtool_sfp" ethtool -m sfp > "/tmp/sfp/$version/ethtool_m_sfp" echo -n 'file sfp.c +p' > /sys/kernel/debug/dynamic_debug/control /etc/init.d/network restart dmesg > "/tmp/sfp/$version/dmesg_reup" logread > "/tmp/sfp/$version/logread_reup" # remove, and reinsert SFP module dmesg > "/tmp/sfp/$version/dmesg_reinsert" logread > "/tmp/sfp/$version/logread_reinsert" diffconfig: CONFIG_TARGET_ramips=y CONFIG_TARGET_ramips_mt7621=y CONFIG_TARGET_ramips_mt7621_DEVICE_mikrotik_routerboard-760igs=y CONFIG_KERNEL_DYNAMIC_DEBUG=y CONFIG_KERNEL_MTD_PARTITIONED_MASTER=y CONFIG_PACKAGE_ethtool=y CONFIG_ETHTOOL_PRETTY_DUMP=y Cheers, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
