Re: [OpenWrt-Devel] [PATCH] build: config: allow bool to select a module pkg
Eneas U de Queiroz wrote at Thu Apr 9 17:39:17 PDT 2020: > This was reported to me here: > https://github.com/openwrt/openwrt/commit/dcf3e63a35d05e7e5103819c0f17195bfafe9baa#commitcomment-38390450 > The update to kconfig-v5.6 broke TARGET_MULTI_PROFILE because it would not accept bool TARGET_DEVICE_ to select MODULE_DEFAULT_ because MODULE_DEFAULT_ 'depends on m'--should only have a 'n' or 'm' value. A 'y' value would imply an unmet direct dependency (depends on m). > > My first thought was OK, if it wants to be a 'y', get rid of the 'depends on m' line; that did not work, because MODULE_DEFAULT_ selects PACKAGE_pkg, then would be forced to be built-in. > So, unless someone has a better idea, let's revert to the old behavior, and tolerate some 'unmet dependencies' once again. Hopefully this gets fixed soon, as I have a hunch that this broke pretty much all TARGET_MULTI_PROFILE builds that have varying key components (like wifi firmware). Possibly also buildbot snapshots, as e.g. in ipq806x the included wifi firmware file varies by device. I noticed a problem with my own multi-device builds, and there is now forum dicsussion about an issue, which I think is related to this: https://forum.openwrt.org/t/wireless-fails-on-snapshot-r12900-kernel-5-4-on-c2600-ipq806x/60155/1 Applying the patch propsed here helped to fix my ath79 multi-device build. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mvebu: add support for GL.iNet GL-MV1000
Hi Li Zhang,
thank you very much for the contribution! Please stick to the device
tree naming schema of `manufacture,model` when adding devices to
OpenWrt. In this case the device should be called `glinet,gl-vm1000`
instead of just `gl-mv1000`.
For the device profile (inline commented below), please replace the `,`
with a `_`.
On Sat Apr 11, 2020 at 2:18 AM PST, Li Zhang wrote:
> This patch adds supports for GL-MV1000.
>
> Specification:
> - SOC: Marvell Armada 88F3720 (1GHz)
> - Flash: 16MB
> - RAM: 1GB DDR4
> - Ethernet: 3x GE (1 WAN + 2 LAN)
> - EMMC: 8GB EMMC
> - MicroSD: 1x microSD slot
> - USB: 1x USB 2.0 port;1x USB 3.0 port(typec)
> - Button: 1x reset button
> - LED: 16x LEDs (3x GPIO controllable)
> - UART: 1x UART on PCB (JP1: 3.3V, RX, TX, GND)
>
> Signed-off-by: Li Zhang
> ---
> package/boot/uboot-envtools/files/mvebu | 3 +
> .../linux/mvebu/base-files/etc/board.d/02_network | 3 +-
> .../linux/mvebu/base-files/lib/upgrade/platform.sh | 19 ++
> .../boot/dts/marvell/armada-gl-mv1000-emmc.dts | 68 +++
> .../arm64/boot/dts/marvell/armada-gl-mv1000.dts | 77
> ++
> target/linux/mvebu/image/Makefile | 15 +
> target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 6 ++
> .../mvebu/image/generic-arm64-emmc.bootscript | 12
> target/linux/mvebu/image/gl-mv1000.mk | 27
> 9 files changed, 229 insertions(+), 1 deletion(-)
> create mode 100644
> target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
> create mode 100644
> target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000.dts
> create mode 100644
> target/linux/mvebu/image/generic-arm64-emmc.bootscript
> create mode 100644 target/linux/mvebu/image/gl-mv1000.mk
>
> diff --git a/package/boot/uboot-envtools/files/mvebu
> b/package/boot/uboot-envtools/files/mvebu
> index c2e746d..d37c000 100644
> --- a/package/boot/uboot-envtools/files/mvebu
> +++ b/package/boot/uboot-envtools/files/mvebu
> @@ -24,6 +24,9 @@ globalscale,espressobin-v7-emmc|\
> marvell,armada8040-mcbin)
> ubootenv_add_uci_config "/dev/mtd0" "0x3f" "0x1" "0x1" "1"
> ;;
> +gl-mv1000)
Please call your device within OpenWrt `glinet,gl-mv1000`.
> + ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8000" "0x8000" "1"
> + ;;
> linksys,caiman|\
> linksys,cobra|\
> linksys,shelby)
> diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network
> b/target/linux/mvebu/base-files/etc/board.d/02_network
> index 0881910..65f13f1 100755
> --- a/target/linux/mvebu/base-files/etc/board.d/02_network
> +++ b/target/linux/mvebu/base-files/etc/board.d/02_network
> @@ -18,7 +18,8 @@ cznic,turris-omnia)
> globalscale,espressobin|\
> globalscale,espressobin-emmc|\
> globalscale,espressobin-v7|\
> -globalscale,espressobin-v7-emmc)
> +globalscale,espressobin-v7-emmc|\
> +gl-mv1000)
> ucidef_set_interfaces_lan_wan "lan0 lan1" "wan"
> ;;
> linksys,caiman|\
> diff --git a/target/linux/mvebu/base-files/lib/upgrade/platform.sh
> b/target/linux/mvebu/base-files/lib/upgrade/platform.sh
> index 58e7d83..840eb9c 100755
> --- a/target/linux/mvebu/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/mvebu/base-files/lib/upgrade/platform.sh
> @@ -19,6 +19,19 @@ platform_check_image() {
> esac
> }
>
> +platform_do_upgrade_mv1000(){
> + local firmware=`fw_printenv firmware | awk -F '=' '{print $2}'`
> +
> + case "$firmware" in
> + gl-mv1000-emmc)
> + platform_do_upgrade_sdcard "$1"
> + ;;
> + *)
> + default_do_upgrade "$1"
> + ;;
> + esac
> +}
> +
> platform_do_upgrade() {
> case "$(board_name)" in
> linksys,caiman|linksys,cobra|linksys,mamba|linksys,rango|linksys,shelby|linksys,venom)
> @@ -28,6 +41,9 @@ platform_do_upgrade() {
> marvell,armada8040-mcbin|solidrun,clearfog-base-a1|solidrun,clearfog-pro-a1)
> platform_do_upgrade_sdcard "$1"
> ;;
> + gl-mv1000)
> + platform_do_upgrade_mv1000 "$1"
> + ;;
> *)
> default_do_upgrade "$1"
> ;;
> @@ -42,5 +58,8 @@ platform_copy_config() {
> marvell,armada8040-mcbin|solidrun,clearfog-base-a1|solidrun,clearfog-pro-a1)
> platform_copy_config_sdcard
> ;;
> + gl-mv1000)
> + platform_copy_config_sdcard
> + ;;
> esac
> }
> diff --git
> a/target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
> b/target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
> new file mode 100644
> index 000..9e9c547
> --- /dev/null
> +++
> b/target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
> @@ -0,0 +1,68 @@
> +/*
> + * Device Tree file for GL.iNet GL-MV1000
> + */
> +
> +#include "armada-3720-espressobin.dts"
> +
> +/ {
> + model = "GL.inet GL-MV1000 (Marvell)";
> + compatible = "gl-mv1000";
Especially here `glinet,gl-mv1000`.
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + flash@0 {
> + reg = <0>;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <10400>;
> + m25p,fast-read;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + pa
[OpenWrt-Devel] [PATCH] mvebu: add support for GL.iNet GL-MV1000
This patch adds supports for GL-MV1000.
Specification:
- SOC: Marvell Armada 88F3720 (1GHz)
- Flash: 16MB
- RAM: 1GB DDR4
- Ethernet: 3x GE (1 WAN + 2 LAN)
- EMMC: 8GB EMMC
- MicroSD: 1x microSD slot
- USB: 1x USB 2.0 port;1x USB 3.0 port(typec)
- Button: 1x reset button
- LED: 16x LEDs (3x GPIO controllable)
- UART: 1x UART on PCB (JP1: 3.3V, RX, TX, GND)
Signed-off-by: Li Zhang
---
package/boot/uboot-envtools/files/mvebu| 3 +
.../linux/mvebu/base-files/etc/board.d/02_network | 3 +-
.../linux/mvebu/base-files/lib/upgrade/platform.sh | 19 ++
.../boot/dts/marvell/armada-gl-mv1000-emmc.dts | 68 +++
.../arm64/boot/dts/marvell/armada-gl-mv1000.dts| 77 ++
target/linux/mvebu/image/Makefile | 15 +
target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 6 ++
.../mvebu/image/generic-arm64-emmc.bootscript | 12
target/linux/mvebu/image/gl-mv1000.mk | 27
9 files changed, 229 insertions(+), 1 deletion(-)
create mode 100644
target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
create mode 100644
target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000.dts
create mode 100644 target/linux/mvebu/image/generic-arm64-emmc.bootscript
create mode 100644 target/linux/mvebu/image/gl-mv1000.mk
diff --git a/package/boot/uboot-envtools/files/mvebu
b/package/boot/uboot-envtools/files/mvebu
index c2e746d..d37c000 100644
--- a/package/boot/uboot-envtools/files/mvebu
+++ b/package/boot/uboot-envtools/files/mvebu
@@ -24,6 +24,9 @@ globalscale,espressobin-v7-emmc|\
marvell,armada8040-mcbin)
ubootenv_add_uci_config "/dev/mtd0" "0x3f" "0x1" "0x1" "1"
;;
+gl-mv1000)
+ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x8000" "0x8000" "1"
+ ;;
linksys,caiman|\
linksys,cobra|\
linksys,shelby)
diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network
b/target/linux/mvebu/base-files/etc/board.d/02_network
index 0881910..65f13f1 100755
--- a/target/linux/mvebu/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/base-files/etc/board.d/02_network
@@ -18,7 +18,8 @@ cznic,turris-omnia)
globalscale,espressobin|\
globalscale,espressobin-emmc|\
globalscale,espressobin-v7|\
-globalscale,espressobin-v7-emmc)
+globalscale,espressobin-v7-emmc|\
+gl-mv1000)
ucidef_set_interfaces_lan_wan "lan0 lan1" "wan"
;;
linksys,caiman|\
diff --git a/target/linux/mvebu/base-files/lib/upgrade/platform.sh
b/target/linux/mvebu/base-files/lib/upgrade/platform.sh
index 58e7d83..840eb9c 100755
--- a/target/linux/mvebu/base-files/lib/upgrade/platform.sh
+++ b/target/linux/mvebu/base-files/lib/upgrade/platform.sh
@@ -19,6 +19,19 @@ platform_check_image() {
esac
}
+platform_do_upgrade_mv1000(){
+local firmware=`fw_printenv firmware | awk -F '=' '{print $2}'`
+
+case "$firmware" in
+gl-mv1000-emmc)
+platform_do_upgrade_sdcard "$1"
+;;
+*)
+default_do_upgrade "$1"
+;;
+esac
+}
+
platform_do_upgrade() {
case "$(board_name)" in
linksys,caiman|linksys,cobra|linksys,mamba|linksys,rango|linksys,shelby|linksys,venom)
@@ -28,6 +41,9 @@ platform_do_upgrade() {
marvell,armada8040-mcbin|solidrun,clearfog-base-a1|solidrun,clearfog-pro-a1)
platform_do_upgrade_sdcard "$1"
;;
+gl-mv1000)
+platform_do_upgrade_mv1000 "$1"
+;;
*)
default_do_upgrade "$1"
;;
@@ -42,5 +58,8 @@ platform_copy_config() {
marvell,armada8040-mcbin|solidrun,clearfog-base-a1|solidrun,clearfog-pro-a1)
platform_copy_config_sdcard
;;
+gl-mv1000)
+platform_copy_config_sdcard
+;;
esac
}
diff --git
a/target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
b/target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
new file mode 100644
index 000..9e9c547
--- /dev/null
+++
b/target/linux/mvebu/files-4.14/arch/arm64/boot/dts/marvell/armada-gl-mv1000-emmc.dts
@@ -0,0 +1,68 @@
+/*
+ * Device Tree file for GL.iNet GL-MV1000
+ */
+
+#include "armada-3720-espressobin.dts"
+
+/ {
+ model = "GL.inet GL-MV1000 (Marvell)";
+ compatible = "gl-mv1000";
+};
+
+&spi0 {
+status = "okay";
+
+flash@0 {
+reg = <0>;
+compatible = "jedec,spi-nor";
+spi-max-frequency = <10400>;
+m25p,fast-read;
+partitions {
+compatible = "fixed-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+label = "u-boot";
+reg = <0 0xf>;
+
[OpenWrt-Devel] [RFC PATCH] ramips: remove patches for USB-dwc2
In FS#2738 we can see that patch first introduced in
e8ebcff ("ramips: add a explicit reset to dwc2")
breaks USB functionality since 18.06. Thus, this patch should be removed.
Removed:
- 0032-USB-dwc2-add-device_reset.patch
Fixes: FS#2738
Fixes: FS#2964
Signed-off-by: Alexey Dobrovolsky
---
Notes:
I can’t assess whether the root cause of the e8ebcff patch has been fixed
in upstream or the patch needs to be rewritten. From the description
of the bugs, it is only clear that in the latest OpenWrt versions this
patch does not work correctly.
I built 18.06.2 and master at 91c61aae200ecf98e332482d395beda819d6a4fa
for ZyXEL Keenetic with 0032-USB-dwc2-add-device_reset.patch removed
as described in FS#2738 and USB works with a USB flash drive (FS#2964).
.../0032-USB-dwc2-add-device_reset.patch | 29 ---
.../0032-USB-dwc2-add-device_reset.patch | 29 ---
2 files changed, 58 deletions(-)
delete mode 100644
target/linux/ramips/patches-4.14/0032-USB-dwc2-add-device_reset.patch
delete mode 100644
target/linux/ramips/patches-5.4/0032-USB-dwc2-add-device_reset.patch
diff --git
a/target/linux/ramips/patches-4.14/0032-USB-dwc2-add-device_reset.patch
b/target/linux/ramips/patches-4.14/0032-USB-dwc2-add-device_reset.patch
deleted file mode 100644
index c04e2db661..00
--- a/target/linux/ramips/patches-4.14/0032-USB-dwc2-add-device_reset.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From a758e0870c6d1e4b0272f6e7f9efa9face5534bb Mon Sep 17 00:00:00 2001
-From: John Crispin
-Date: Sun, 27 Jul 2014 09:49:07 +0100
-Subject: [PATCH 32/53] USB: dwc2: add device_reset()
-
-Signed-off-by: John Crispin
- drivers/usb/dwc2/hcd.c |3 +++
- 1 file changed, 3 insertions(+)
-
a/drivers/usb/dwc2/hcd.c
-+++ b/drivers/usb/dwc2/hcd.c
-@@ -48,6 +48,7 @@
- #include
- #include
- #include
-+#include
-
- #include
- #include
-@@ -5215,6 +5216,8 @@ int dwc2_hcd_init(struct dwc2_hsotg *hso
-
- retval = -ENOMEM;
-
-+ device_reset(hsotg->dev);
-+
- hcfg = dwc2_readl(hsotg->regs + HCFG);
- dev_dbg(hsotg->dev, "hcfg=%08x\n", hcfg);
-
diff --git
a/target/linux/ramips/patches-5.4/0032-USB-dwc2-add-device_reset.patch
b/target/linux/ramips/patches-5.4/0032-USB-dwc2-add-device_reset.patch
deleted file mode 100644
index ec837cda93..00
--- a/target/linux/ramips/patches-5.4/0032-USB-dwc2-add-device_reset.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-From a758e0870c6d1e4b0272f6e7f9efa9face5534bb Mon Sep 17 00:00:00 2001
-From: John Crispin
-Date: Sun, 27 Jul 2014 09:49:07 +0100
-Subject: [PATCH 32/53] USB: dwc2: add device_reset()
-
-Signed-off-by: John Crispin
- drivers/usb/dwc2/hcd.c |3 +++
- 1 file changed, 3 insertions(+)
-
a/drivers/usb/dwc2/hcd.c
-+++ b/drivers/usb/dwc2/hcd.c
-@@ -49,6 +49,7 @@
- #include
- #include
- #include
-+#include
-
- #include
- #include
-@@ -5023,6 +5024,8 @@ int dwc2_hcd_init(struct dwc2_hsotg *hso
-
- retval = -ENOMEM;
-
-+ device_reset(hsotg->dev);
-+
- hcfg = dwc2_readl(hsotg, HCFG);
- dev_dbg(hsotg->dev, "hcfg=%08x\n", hcfg);
-
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Java compiler
Le ven. 10 avr. 2020 à 17:09, Etienne Champetier a écrit : > > Hi Michael, > > Le ven. 10 avr. 2020 à 16:48, W. Michael Petullo a écrit : > > > > Has anyone tried to build a Java compiler package for OpenWrt? I am > > investigating doing this. I see the lang/jamvm JVM, but no compiler > > akin to devel/gcc or lang/golang. I have packaged a number of things, > > but I suspect this will be a bit more of a challenge. Hence my question > > here. > > Do you want the JDK on the router ? or the JDK in the toolchain and > "just" the JRE on the router ? > For both JDK and JRE I don't know what architecture are officially > supported, but that would be the first think to check, because > debugging a JIT compiler might require some work :P Here a bit old but good presentation of java hotspot debugging fun https://archive.fosdem.org/2016/schedule/event/hunting_the_bug_from_hell/ > Good luck! > > > > > Thank you! > > > > -- > > Mike > > > > :wq > > > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Java compiler
Hi Michael, Le ven. 10 avr. 2020 à 16:48, W. Michael Petullo a écrit : > > Has anyone tried to build a Java compiler package for OpenWrt? I am > investigating doing this. I see the lang/jamvm JVM, but no compiler > akin to devel/gcc or lang/golang. I have packaged a number of things, > but I suspect this will be a bit more of a challenge. Hence my question > here. Do you want the JDK on the router ? or the JDK in the toolchain and "just" the JRE on the router ? For both JDK and JRE I don't know what architecture are officially supported, but that would be the first think to check, because debugging a JIT compiler might require some work :P Good luck! > > Thank you! > > -- > Mike > > :wq > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Java compiler
Has anyone tried to build a Java compiler package for OpenWrt? I am investigating doing this. I see the lang/jamvm JVM, but no compiler akin to devel/gcc or lang/golang. I have packaged a number of things, but I suspect this will be a bit more of a challenge. Hence my question here. Thank you! -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Andre Valentin writes: > Am 07.04.20 um 17:49 schrieb Bjørn Mork: >> Just remembered an issue on my todo list: There have been some MTU >> handling changes in the kernel networking API. This affected the >> qmi_wwan QMAP handling. I am not sure about the current status. Will >> have to dig a bit more. But this might be your problem. > > > That made me set MTU of wwan0 to 1600, and the qmimux* to 1500. No more > problems anymore. > This should go into documentation, not that anybody makes the same errors. Yes, this goes into the list of issues I'd like to fix with the QMAP implementation. It's also unnecessary hard to configure. And there is no way to figure out which qmap netdev belongs to which mux_id. > How much overhead does qmux create (for correct calculated MTU > offset)? Looks like 4 bytes: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/qmi_wwan.c#n66 Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [ramips]:3 dependent patches for mt7620a_cameo-810 - howto roll out for testing
With forum help from @123serge123 the trendnet:internet:green gpio was enabled and added to a *dts and 01_leds. It is highly likely that this change will work for the D-Link DIR-810L. Both the Trendnet and the D-Link use a Cameo based board with the same cpu, spi flash and ram chips. They have Identical LED's. The led change does away with the need for an LAN4 NIC, mimics OEM and is configurable. I could roll out a cameo-810.dtsi patch, with led fix, followed by adding Trendnet support but this bypasses DIR-810 testing prior to committing. If DIR-810 testers reject the led change, I would, barring any major issues, keep it for the Trendnet which would modify the dts/dtsi changes. Alternatively, a patch for the DIR-810L/led for testing. If tests OK, cameo-810.dtsi, followed by adding Trendnet support. Alternatively could combine the dtsi patch with adding Trendnet support. Preference? -- J. Scott Heppler ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?
Am Dienstag, 7. April 2020, 16:22:37 CEST schrieb Hannu Nyman: > I do not think that there is a nice clean solution, as I do not remember > seeing a solution of different packages for iniramfs, factory and sysupgrade > images. > > I would approach that with a two-step build process, using two .config > recipes: > > * First a build with a smaller .config recipe without that large Quantenna > firmware. This creates the initramfs image, (which you copy to a safe place > before the second build) > > * Then a second build from a recipe including the Quantenna firmware. No > need to do "make clean", so the second build is rather quick. That produces > the full sysupgrade image. > > In your build automation scripts, those two builds could be run > consequtively, with a copy step between them. > For our Freifunk-build we do a similar 2-step thing * using a .config having all pacakges added modular and only the packages for the initrd set to "y" to have them embedded * doing a normal build produces the initrds and the imagebuilder * with the imagebuilder we generate the final sysupgrade images with the full package-set The generated initrds are just a luci-mod-failsafe wich allows flashing the sysupgrade via browser and of course console. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Fri, Apr 10, 2020 at 2:29 PM Andre Valentin wrote: > [snip] > > Does these changes makes the job for you? Attached new patch. This hopefully works. > No, it does not work. Again I get this: > root@OpenWrt:/# cat /proc/interrupts >CPU0 CPU1 CPU2 CPU3 > 8: 10317 10061 10366 10342 MIPS GIC Local 1 timer > 9: 10946 0 0 0 MIPS GIC 63 IPI call > 10: 0 1973 0 0 MIPS GIC 64 IPI call > 11: 0 0 24992 0 MIPS GIC 65 IPI call > 12: 0 0 0 2087 MIPS GIC 66 IPI call > 13: 1795 0 0 0 MIPS GIC 67 IPI resched > 14: 0 2072 0 0 MIPS GIC 68 IPI resched > 15: 0 0 1883 0 MIPS GIC 69 IPI resched > 16: 0 0 0 1920 MIPS GIC 70 IPI resched > 17: 0 0 0 0 MIPS GIC 19 > 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2 > 19:149 0 0 0 MIPS GIC 33 ttyS0 > 20: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1 > 21: 10 0 0 0 MIPS GIC 10 > 1e10.ethernet > 23: 0 0 0 0 MIPS GIC 11 mt7615e > ERR: 1 > > Shouldn't at least be something about pci interrupts here? Depending of the number of pcie buses your hardware is using you see here if it has associated irq. So for you only one bus (bus 0) and one slot (slot 1). This means your link status should be '0x2' and the irq to map for this bus should be the number 24 instead of 23. For me with this patch applied I got (not changes here because I am using the three buses): # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 7: 0 0 0 0 MIPS 7 timer 8: 13231 12986 12973 12982 MIPS GIC Local 1 timer 9: 3261 0 0 0 MIPS GIC 63 IPI call 10: 0 1025 0 0 MIPS GIC 64 IPI call 11: 0 0 2196 0 MIPS GIC 65 IPI call 12: 0 0 0 1498 MIPS GIC 66 IPI call 13:488 0 0 0 MIPS GIC 67 IPI resched 14: 0815 0 0 MIPS GIC 68 IPI resched 15: 0 0 2284 0 MIPS GIC 69 IPI resched 16: 0 0 0 3671 MIPS GIC 70 IPI resched 17: 0 0 0 0 MIPS GIC 19 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2 18:114 0 0 0 MIPS GIC 33 ttyS0 19: 0 0 0 0 MIPS GIC 27 1e13.sdhci 20: 26 0 0 0 MIPS GIC 29 xhci-hcd:usb1 21: 10 0 0 0 MIPS GIC 10 1e10.ethernet 23: 0 0 0 0 MIPS GIC 11 ahci[:01:00.0] 24: 0 0 0 0 MIPS GIC 31 ahci[:02:00.0] 25:279 0 0 0 MIPS GIC 32 ahci[:03:00.0] 26: 0 0 0 0 1e000600.gpio 18 reset ERR: 0 And a trace: [ 16.547082] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1) [ 16.561981] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0) [ 16.676717] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz [ 16.687833] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz [ 16.798874] mt7621-pci 1e14.pcie: PCIE0 enabled [ 16.808591] mt7621-pci 1e14.pcie: PCIE1 enabled [ 16.818313] mt7621-pci 1e14.pcie: PCIE2 enabled [ 16.828039] mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, mask/settings: 0xf002 [ 16.846783] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 [ 16.859473] pci_bus :00: root bus resource [io 0x1e16-0x1e16] [ 16.873171] pci_bus :00: root bus resource [mem 0x6000-0x6fff] [ 16.886880] pci_bus :00: root bus resource [bus 00-ff] [ 16.897862] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 [ 16.909864] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] [ 16.922358] pci :00:00.0: reg 0x14: [mem 0x-0x] [ 16.934928] pci :00:00.0: supports D1 [ 16.942894] pci :00:00.0: PME# supported from D0 D1 D3hot [ 16.954762] pci :00:01.0: [0e8d:0801] type 01 class 0x060400 [ 16.966779] pci :00:01.0: reg 0x10: [mem 0x-0x7fff] [ 16.979275] pci :00:01.0: reg 0x14: [mem 0x-0x] [ 16.991835] pci :00:01.0: supports D1 [ 16.999826] pci :00:01.0: PME# supported from D0 D1 D3hot [ 17.011649] pci :00:
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Sergio
Am 10.04.20 um 13:36 schrieb Sergio Paracuellos:
>> cat /proc/interrupts new:
>>CPU0 CPU1 CPU2 CPU3
>> 8: 75188 75268 75341 75246 MIPS GIC Local 1 timer
>> 9: 24413 0 0 0 MIPS GIC 63 IPI call
>> 10: 0 4442 0 0 MIPS GIC 64 IPI call
>> 11: 0 0 33324 0 MIPS GIC 65 IPI call
>> 12: 0 0 0 4574 MIPS GIC 66 IPI call
>> 13: 3424 0 0 0 MIPS GIC 67 IPI resched
>> 14: 0 4124 0 0 MIPS GIC 68 IPI resched
>> 15: 0 0 3974 0 MIPS GIC 69 IPI resched
>> 16: 0 0 0 4150 MIPS GIC 70 IPI resched
>> 17: 0 0 0 0 MIPS GIC 19
>> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>> 19:829 0 0 0 MIPS GIC 33 ttyS0
>> 20: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1
>> 21:817 0 0 0 MIPS GIC 10
>> 1e10.ethernet
>> 23: 0 0 0 0 MIPS GIC 11 mt7615e
>> ERR: 1
>>
>>
>> cat /proc/interrupts old:
>>
>>CPU0 CPU1 CPU2 CPU3
>> 8: 25513 25556 25674 25681 MIPS GIC Local 1 timer
>> 9: 23603 0 0 0 MIPS GIC 63 IPI call
>> 10: 0 4383 0 0 MIPS GIC 64 IPI call
>> 11: 0 0 32117 0 MIPS GIC 65 IPI call
>> 12: 0 0 0 4189 MIPS GIC 66 IPI call
>> 13: 3428 0 0 0 MIPS GIC 67 IPI resched
>> 14: 0 4144 0 0 MIPS GIC 68 IPI resched
>> 15: 0 0 3812 0 MIPS GIC 69 IPI resched
>> 16: 0 0 0 3769 MIPS GIC 70 IPI resched
>> 17: 0 0 0 0 MIPS GIC 19
>> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
>> 19: 1022 0 0 0 MIPS GIC 33 ttyS0
>> 20: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1
>> 21:269 0 0 0 MIPS GIC 10
>> 1e10.ethernet
>> 24: 1131 0 0 0 MIPS GIC 31 mt7615e
>> ERR: 0
>> => Interesting, different interrupts.
>
> That's weird. Should be the same, AFAICT.
> Needs some investigation but looks like you are not getting interrupts
> at all according to these traces...
>
> Looking into my gnubee I got also 23, 24 and 25.
>
> # cat /proc/interrupts
>CPU0 CPU1 CPU2 CPU3
> 7: 0 0 0 0 MIPS 7 timer
> 8: 3537 3346 3296 3351 MIPS GIC Local 1 timer
> 9: 3025 0 0 0 MIPS GIC 63 IPI call
> 10: 0 1209 0 0 MIPS GIC 64 IPI call
> 11: 0 0 2805 0 MIPS GIC 65 IPI call
> 12: 0 0 0 1200 MIPS GIC 66 IPI call
> 13: 1428 0 0 0 MIPS GIC 67 IPI resched
> 14: 0 4136 0 0 MIPS GIC 68 IPI resched
> 15: 0 0872 0 MIPS GIC 69 IPI resched
> 16: 0 0 0666 MIPS GIC 70 IPI resched
> 17: 0 0 0 0 MIPS GIC 19
> 1e000600.gpio-bank0, 1e000600.gpio-bank1, 1e000600.gpio-bank2
> 18:138 0 0 0 MIPS GIC 33 ttyS0
> 19: 0 0 0 0 MIPS GIC 27 1e13.sdhci
> 20: 26 0 0 0 MIPS GIC 29 xhci-hcd:usb1
> 21: 7 0 0 0 MIPS GIC 10
> 1e10.ethernet
> 23: 0 0 0 0 MIPS GIC 11
> ahci[:01:00.0]
> 24: 0 0 0 0 MIPS GIC 31
> ahci[:02:00.0]
> 25:279 0 0 0 MIPS GIC 32
> ahci[:03:00.0]
> 26: 0 0 0 0 1e000600.gpio 18 reset
> ERR: 0
>
>
>>
>> Diff DTS old to new driver:
>> diff --git b/target/linux/ramips/dts/mt7621.dtsi
>> a/target/linux/ramips/dts/mt7621.dtsi
>> index 0bf1069b5c..63befa1fdc 100644
>> --- b/target/linux/ramips/dts/mt7621.dtsi
>> +++ a/target/linux/ramips/dts/mt7621.dtsi
>> @@ -557,9 +550,10 @@
>>
>> pcie: pcie@1e14 {
>> compatible = "mediatek,mt7621-pci";
>> - reg = <0x1e14 0x100
>> - 0x1e142000 0x100>;
>> -
>> + reg = <0x1e14 0x100 /* host-pci bridg
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
On Fri, Apr 10, 2020 at 1:36 PM Sergio Paracuellos wrote: > > Hi André, > > On Fri, Apr 10, 2020 at 11:36 AM Andre Valentin wrote: > > > > Hi Sergio, > > > > the device has an onboard LTE modem. Tonight I noticed that the originial > > pci driver > > must have changed some additional GPIO pins. > > After more testing, I found the GPIO and the LTE device now operates again. > > Good! > > > > > But after more testing, I found out that the wifi chip does not fully > > initialize. > > new PCI driver: > > [0.641632] PCI: CLS 0 bytes, default 32 > > [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie > > [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for > > 1e14.pcie > > [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed > > [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie > > [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for > > 1e14.pcie > > [2.898180] rt2880-pinmux pinctrl: pcie is already enabled > > [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse > > things back > > [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > > port = 1) > > [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > > node '/pcie@1e14[0]' - status (0) > > [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > > of node '/pcie@1e14[1]' > > [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property > > of node '/pcie@1e14[1]' > > [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > > [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > > port = 0) > > [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > > [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > > [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > > of node '/pcie@1e14[2]' > > [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property > > of node '/pcie@1e14[2]' > > [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > > [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found > > [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > > [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > > [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & > > CLK) > > [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & > > CLK) > > [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled > > [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: > > 0x6000, mask/settings: 0xf002 > > [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 > > [3.244820] pci_bus :00: root bus resource [io > > 0x1e16-0x1e16] > > [3.258527] pci_bus :00: root bus resource [mem > > 0x6000-0x6fff] > > [3.272233] pci_bus :00: root bus resource [bus 00-ff] > > [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > > [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > > [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] > > [3.320294] pci :00:00.0: supports D1 > > [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot > > [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > > [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > > [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, > > limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 > > GT/s x1 link) > > [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] > > [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] > > [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] > > [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f > > pref] > > [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > > [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > > [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size > > 0x8000] > > [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > > [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f > > pref] > > [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] > > [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] > > [3.5414
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi André, On Fri, Apr 10, 2020 at 11:36 AM Andre Valentin wrote: > > Hi Sergio, > > the device has an onboard LTE modem. Tonight I noticed that the originial pci > driver > must have changed some additional GPIO pins. > After more testing, I found the GPIO and the LTE device now operates again. Good! > > But after more testing, I found out that the wifi chip does not fully > initialize. > new PCI driver: > [0.641632] PCI: CLS 0 bytes, default 32 > [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie > [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie > [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed > [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie > [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie > [2.898180] rt2880-pinmux pinctrl: pcie is already enabled > [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse > things back > [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > port = 1) > [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of > node '/pcie@1e14[0]' - status (0) > [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > of node '/pcie@1e14[1]' > [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of > node '/pcie@1e14[1]' > [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > port = 0) > [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property > of node '/pcie@1e14[2]' > [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of > node '/pcie@1e14[2]' > [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) > [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK) > [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled > [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: > 0x6000, mask/settings: 0xf002 > [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 > [3.244820] pci_bus :00: root bus resource [io 0x1e16-0x1e16] > [3.258527] pci_bus :00: root bus resource [mem 0x6000-0x6fff] > [3.272233] pci_bus :00: root bus resource [bus 00-ff] > [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] > [3.320294] pci :00:00.0: supports D1 > [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot > [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited > by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 > link) > [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] > [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] > [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] > [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f > pref] > [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] > [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f > pref] > [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] > [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] > [3.541489] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f > 64bit] > [3.556077] pci :00:00.0: PCI bridge to [bus 01] > [3.565975] pci :00:00.0: bridge window [io 0x1e16-0x1e160fff] > [3.579504] pci :00:00.0: bridge window
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi , Paul Sorry, I misread the mail contact. Our watchdog uses two GPIO to control, one is to use pulse to switch the watchdog, one GPIO is used to feed the dog, specifically the external single-chip to feed the dog, now the external single-chip cannot detect the level change of GPIO I now suspect that the wdt-gpio delay is too short, and the microcontroller part has not detected a falling edge change. I tried both toggle and level, but unfortunately both failed, and I will continue to test. -- Original -- From: "guilin.wang"http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi , MartinOur Watchdog uses two GPIO to control, one is to use pulse to switch the watchdog, one GPIO is used to feed the dog, specifically the external single-chip to feed the dog, now the external single-chip cannot detect the level change of GPIO I now suspect that the wdt-gpio delay is too short, and the microcontroller part has not detected a falling edge change. I tried both toggle and level, but unfortunately both failed, and I will continue to test. -- Original --From: "Paul Fertser";Date: Fri, Apr 10, 2020 07:10 PMTo: "guilin.wang"; Cc: "Martin Blumenstingl"; "openwrt-devel"; Subject: Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet) Hi, On Fri, Apr 10, 2020 at 06:55:59PM +0800, guilin.wang wrote: > but found that the dog could not be fed successfully. Why exactly? > Our external microcontroller feeds the dog. The cpu just gives the > microcontroller a trigger signal, but I tested that the > microcontroller cannot detect the level change using this method How is it able to detect the level change using another method then, what exactly makes them different? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi, On Fri, Apr 10, 2020 at 06:55:59PM +0800, guilin.wang wrote: > but found that the dog could not be fed successfully. Why exactly? > Our external microcontroller feeds the dog. The cpu just gives the > microcontroller a trigger signal, but I tested that the > microcontroller cannot detect the level change using this method How is it able to detect the level change using another method then, what exactly makes them different? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi ,Martin Thank your for your suggest, I initially followed this method, but found that the dog could not be fed successfully. Our external microcontroller feeds the dog. The cpu just gives the microcontroller a trigger signal, but I tested that the microcontroller cannot detect the level change using this method you said So I used the script. -- Original --From: "Martin Blumenstingl";Date: Fri, Apr 10, 2020 05:55 PMTo: "guilin.w...@gl-inet.com"; Cc: "openwrt-devel"; Subject: Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet) Hi, On Fri, Apr 10, 2020 at 11:47 AM guilin.w...@gl-inet.com wrote: > > Signed-off-by: guilin.w...@gl-inet.com the format should be "your name " > --- > package/kernel/om-watchdog/Makefile | 2 +- > package/kernel/om-watchdog/files/om-watchdog | 40 > +++ > package/kernel/om-watchdog/files/om-watchdog.init | 2 ++ > 3 files changed, 37 insertions(+), 7 deletions(-) why not use a GPIO watchdog node in board.dts instead? see [0] for an example Martin [0] https://github.com/torvalds/linux/blob/v5.4/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mvebu, cortexa9: rename linksys, rango to wrt3200acm
This patch was previously send to the Kernel, however as it also changes
labels and the DTS filename existing devices could break.
The internal Linksys codename `rango` is renamed to `wrt3200acm`, it's
common model name. This way the build code base becomes more readable as
developers don't need to keep track of two different names for the same
device.
Additionally running devices now know which profile was used to create
the running firmware, instead of requiring an additional mapping.
Signed-off-by: Paul Spooren
---
This is just meant as a RFC, in case the idea is good I'll send a patch
set for all 5 devices affected by the codename double naming.
package/boot/uboot-envtools/files/mvebu | 2 +-
.../cortexa9/base-files/etc/board.d/01_leds | 2 +-
.../base-files/etc/board.d/02_network | 2 +-
.../cortexa9/base-files/etc/init.d/bootcount | 2 +-
.../base-files/lib/preinit/06_set_iface_mac | 2 +-
.../base-files/lib/preinit/81_linksys_syscfg | 2 +-
.../base-files/lib/upgrade/platform.sh| 4 +-
target/linux/mvebu/image/cortexa9.mk | 4 +-
...s-linksys-rename-rango-to-wrt3200acm.patch | 132 ++
9 files changed, 142 insertions(+), 10 deletions(-)
create mode 100644
target/linux/mvebu/patches-4.19/007-arm-dts-linksys-rename-rango-to-wrt3200acm.patch
diff --git a/package/boot/uboot-envtools/files/mvebu
b/package/boot/uboot-envtools/files/mvebu
index 7902384a37..1049ce491b 100644
--- a/package/boot/uboot-envtools/files/mvebu
+++ b/package/boot/uboot-envtools/files/mvebu
@@ -32,7 +32,7 @@ linksys,shelby)
linksys,mamba)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x2"
;;
-linksys,rango|\
+linksys,wrt3200acm|\
linksys,venom)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x2"
;;
diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
index a7762f0080..5bdeaaa38b 100755
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/01_leds
@@ -14,7 +14,7 @@ boardname="${board##*,}"
case "$board" in
linksys,caiman|\
linksys,cobra|\
-linksys,rango|\
+linksys,wrt3200acm|\
linksys,shelby)
ucidef_set_led_netdev "wan" "WAN" "pca963x:$boardname:white:wan" "eth1"
ucidef_set_led_usbport "usb1" "USB 1" "pca963x:$boardname:white:usb2"
"usb1-port1"
diff --git a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
index b10e1419b5..51e4215329 100755
--- a/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa9/base-files/etc/board.d/02_network
@@ -18,7 +18,7 @@ cznic,turris-omnia)
linksys,caiman|\
linksys,cobra|\
linksys,mamba|\
-linksys,rango|\
+linksys,wrt3200acm|\
linksys,shelby|\
linksys,venom)
ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
diff --git a/target/linux/mvebu/cortexa9/base-files/etc/init.d/bootcount
b/target/linux/mvebu/cortexa9/base-files/etc/init.d/bootcount
index dd2266bdc8..9d8bbcc25d 100755
--- a/target/linux/mvebu/cortexa9/base-files/etc/init.d/bootcount
+++ b/target/linux/mvebu/cortexa9/base-files/etc/init.d/bootcount
@@ -7,7 +7,7 @@ boot() {
linksys,caiman |\
linksys,cobra |\
linksys,mamba |\
- linksys,rango |\
+ linksys,wrt3200acm |\
linksys,shelby |\
linksys,venom)
mtd resetbc s_env || true
diff --git
a/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
b/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
index fd41836c8d..9c09b5c899 100644
--- a/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
+++ b/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
@@ -9,7 +9,7 @@ preinit_set_mac_address() {
. /lib/functions.sh
case $(board_name) in
- linksys,caiman|linksys,cobra|linksys,rango|linksys,shelby|linksys,venom)
+
linksys,caiman|linksys,cobra|linksys,wrt3200acm|linksys,shelby|linksys,venom)
# rename interfaces back to the way they were with 4.4
case "$(readlink /sys/class/net/eth0)" in
*f107*)
diff --git
a/target/linux/mvebu/cortexa9/base-files/lib/preinit/81_linksys_syscfg
b/target/linux/mvebu/cortexa9/base-files/lib/preinit/81_linksys_syscfg
index 83448e5ace..257a890fc3 100644
--- a/target/linux/mvebu/cortexa9/base-files/lib/preinit/81_linksys_syscfg
+++ b/target/linux/mvebu/cortexa9/base-files/lib/preinit/81_linksys_syscfg
@@ -8,7 +8,7 @@ preinit_mount_syscfg() {
. /lib/upgrade/common.sh
case $(board_name) in
-
linksys,caiman|linksys,cobra|linksys,mamba|linksys,rango|linksys,shelby|linksys,venom)
+
linksys,caiman|linksys,cobra|linksys,mamba|linksys,wrt3200acm|linksys,shelby|linksys,venom)
needs_recovery=0
Re: [OpenWrt-Devel] [RFC][lantiq] Custom PHY and ethernet/switch driver
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 Andreas, On Sat, Mar 28, 2020 at 11:27 AM Andreas Böhler wrote: [...] > What is the current state in switching to the upstream DSA switch driver? > Can both drivers be handled, i.e. DSA for newly added devices and the > legacy driver for older devices? > Which driver should I target first, the legacy xrx200 or the DSA driver? personally I would like to switch to the upstream DSA driver as soon as possible. this reduced the maintenance overhead when updating kernel versions there's also some people (see recent mails) working on ARX300 support. I fear that they may need to change the Ethernet driver and having an out-of-tree driver just means that the work has to be done twice. on IRC I asked about the DSA migration as well (that was some weeks ago). here's the relevant conversation: Hauke: how about switching to the DSA driver for 5.4? I don't want to mess with the GPHY loader and the out-of-tree Ethernet driver xdarklight: I would like to swithc to the DSA driver but we probably need some migration path Hauke: maybe we can share a TODO-list somewhere so we can write down everything that comes to our mind and then work on it one-by-one Hauke: I think it makes sense to switch to dsa without migration the wish for migration scripts exists for at least two years (on mvebu and ipq806x) - and it's a good idea in principle, but /etc/config/network is complex - and may be very complex at times (and lantiq with the VLAN tagging necessary for multiple xDSL ISPs is not an exception to that rule), so making migration support a requirement probably ends up in a self-fullfilling prophecy to never switch to DSA (just because writing these scripts in a way that makes them remotely safe to use is somewhere between very hard and close to impossible) we do need to some enhance the existing for defining vlan membership, pvids etc with vlan_aware bridges yes and this time we should define how the config should look like, then implement it to avoid inconsistencies and poor config layout like with swconfig in the past Hauke: I suggest switching to DSA without migration as well. The biggest problem is the one CPU port issue. Needs a patch. so to me it seems that the swconfig to DSA migration is needed by Lantiq and multiple other targets as well (mvebu and ipq806x are listed above, but I think also ath79 is affected due to some qca8k switches for which OpenWrt is using an out-of-tree driver) unfortunately I have zero experience in that area and no insight into the requirements needed for this migration (for me personally resetting the network config to defaults when upgrading to a DSA based OpenWrt version would work perfectly fine) Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
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, On Fri, Apr 10, 2020 at 11:47 AM guilin.w...@gl-inet.com wrote: > > Signed-off-by: guilin.w...@gl-inet.com the format should be "your name " > --- > package/kernel/om-watchdog/Makefile | 2 +- > package/kernel/om-watchdog/files/om-watchdog | 40 > +++ > package/kernel/om-watchdog/files/om-watchdog.init | 2 ++ > 3 files changed, 37 insertions(+), 7 deletions(-) why not use a GPIO watchdog node in board.dts instead? see [0] for an example Martin [0] https://github.com/torvalds/linux/blob/v5.4/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] x86: append metadata to combined images
Now that the x86 target uses the new image generation code we can also attach metadata to the created images. As currently the `SUPPORTED_DEVICES` list is empty, no JSON metadata is attached, however the signing happens in the same step. This results in signature verification for x86 images. Signed-off-by: Paul Spooren --- target/linux/x86/image/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile index 7a474e7a6e..77516a4a9d 100644 --- a/target/linux/x86/image/Makefile +++ b/target/linux/x86/image/Makefile @@ -113,15 +113,15 @@ endef DEVICE_VARS += GRUB2_VARIANT define Device/Default ARTIFACT/image.iso := grub-config iso | iso - IMAGE/combined.img := grub-config pc | combined | grub-install - IMAGE/combined.img.gz := grub-config pc | combined | grub-install | gzip + IMAGE/combined.img := grub-config pc | combined | grub-install | append-metadata + IMAGE/combined.img.gz := grub-config pc | combined | grub-install | gzip | append-metadata IMAGE/combined.vdi := grub-config pc | combined | grub-install | qemu-image vdi IMAGE/combined.vmdk := grub-config pc | combined | grub-install | qemu-image vmdk IMAGE/rootfs.img := append-rootfs IMAGE/rootfs.img.gz := append-rootfs | gzip ARTIFACT/image-efi.iso := grub-config iso | iso efi - IMAGE/combined-efi.img := grub-config efi | combined efi | grub-install efi - IMAGE/combined-efi.img.gz := grub-config efi | combined efi | grub-install efi | gzip + IMAGE/combined-efi.img := grub-config efi | combined efi | grub-install efi | append-metadata + IMAGE/combined-efi.img.gz := grub-config efi | combined efi | grub-install efi | gzip | append-metadata IMAGE/combined-efi.vdi := grub-config efi | combined efi | grub-install efi | qemu-image vdi IMAGE/combined-efi.vmdk := grub-config efi | combined efi | grub-install efi | qemu-image vmdk ifeq ($(CONFIG_TARGET_IMAGES_GZIP),y) -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Signed-off-by: guilin.w...@gl-inet.com
---
package/kernel/om-watchdog/Makefile | 2 +-
package/kernel/om-watchdog/files/om-watchdog | 40 +++
package/kernel/om-watchdog/files/om-watchdog.init | 2 ++
3 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/package/kernel/om-watchdog/Makefile
b/package/kernel/om-watchdog/Makefile
index 403069b..02520d2 100644
--- a/package/kernel/om-watchdog/Makefile
+++ b/package/kernel/om-watchdog/Makefile
@@ -12,7 +12,7 @@ PKG_RELEASE:=2
PKG_VERSION:=1
include $(INCLUDE_DIR)/package.mk
-
+PKG_CONFIG_DEPENDS += BUSYBOX_CONFIG_FLOAT_DURATION
define Package/om-watchdog
SECTION:=base
CATEGORY:=Base system
diff --git a/package/kernel/om-watchdog/files/om-watchdog
b/package/kernel/om-watchdog/files/om-watchdog
index d730c68..b12db3e 100644
--- a/package/kernel/om-watchdog/files/om-watchdog
+++ b/package/kernel/om-watchdog/files/om-watchdog
@@ -1,15 +1,43 @@
#!/bin/sh
+. /lib/functions.sh
+
GPIO=$1
trap "" INT HUP
+om_feed_dog()
+{
+while true; do
+echo 1 > /sys/class/gpio/gpio${GPIO}/value
+sleep 1
+echo 0 > /sys/class/gpio/gpio${GPIO}/value
+sleep 180
+done
+}
+glinet_feed_dog()
+{
+local count=1
+for i in $(seq 1 $count);
+do
+echo 1 >/sys/class/gpio/gpio14/value
+sleep 0.01
+echo 0 >/sys/class/gpio/gpio14/value
+sleep 0.01
+done
+}
+
echo $GPIO > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio${GPIO}/direction
-while true; do
- echo 1 > /sys/class/gpio/gpio${GPIO}/value
- sleep 1
- echo 0 > /sys/class/gpio/gpio${GPIO}/value
- sleep 180
-done
+board=$(board_name)
+if [ "$board" = "glinet,gl-x1200-nor" -o "$board" = "glinet,gl-x1200-nor-nand"
];then
+echo 14 >/sys/class/gpio/export
+echo out >/sys/class/gpio/gpio14/direction
+while true;do
+glinet_feed_dog
+sleep 10
+done
+else
+om_feed_dog
+fi
diff --git a/package/kernel/om-watchdog/files/om-watchdog.init
b/package/kernel/om-watchdog/files/om-watchdog.init
index 4c407da..5d3ffdd 100644
--- a/package/kernel/om-watchdog/files/om-watchdog.init
+++ b/package/kernel/om-watchdog/files/om-watchdog.init
@@ -50,6 +50,8 @@ get_gpio() {
elif [ "$board" = "teltonika_rut5xx" ]; then
# ramips
return 11
+ elif [ "$board" = "glinet,gl-x1200-nor" -o "$board" =
"glinet,gl-x1200-nor-nand" ];then
+ return 16
else
#we assume it is om1p in this case
return 3
--
2.7.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Sergio, the device has an onboard LTE modem. Tonight I noticed that the originial pci driver must have changed some additional GPIO pins. After more testing, I found the GPIO and the LTE device now operates again. But after more testing, I found out that the wifi chip does not fully initialize. new PCI driver: [0.641632] PCI: CLS 0 bytes, default 32 [1.242280] rt2880-pinmux pinctrl: found group selector 6 for pcie [1.242302] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie [1.242447] mt7621-pci 1e14.pcie: Parsing DT failed [2.898143] rt2880-pinmux pinctrl: found group selector 6 for pcie [2.898166] rt2880-pinmux pinctrl: request pin 19 (io19) for 1e14.pcie [2.898180] rt2880-pinmux pinctrl: pcie is already enabled [2.909148] mt7621-pci 1e14.pcie: Error applying setting, reverse things back [2.924231] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port = 1) [2.938973] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset [2.938982] mt7621-pci 1e14.pcie: using device tree for GPIO lookup [2.939032] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/pcie@1e14[0]' - status (0) [2.939094] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset [2.939102] mt7621-pci 1e14.pcie: using device tree for GPIO lookup [2.939120] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/pcie@1e14[1]' [2.939136] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/pcie@1e14[1]' [2.939147] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup [2.939157] mt7621-pci 1e14.pcie: No GPIO consumer reset found [2.939211] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port = 0) [2.953954] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset [2.953962] mt7621-pci 1e14.pcie: using device tree for GPIO lookup [2.953985] of_get_named_gpiod_flags: can't parse 'reset-gpios' property of node '/pcie@1e14[2]' [2.954000] of_get_named_gpiod_flags: can't parse 'reset-gpio' property of node '/pcie@1e14[2]' [2.954011] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup [2.954019] mt7621-pci 1e14.pcie: No GPIO consumer reset found [3.053867] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz [3.064992] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz [3.175896] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) [3.189768] mt7621-pci 1e14.pcie: pcie2 no card, disable it (RST & CLK) [3.203643] mt7621-pci 1e14.pcie: PCIE1 enabled [3.213373] mt7621-pci 1e14.pcie: PCI coherence region base: 0x6000, mask/settings: 0xf002 [3.232132] mt7621-pci 1e14.pcie: PCI host bridge to bus :00 [3.244820] pci_bus :00: root bus resource [io 0x1e16-0x1e16] [3.258527] pci_bus :00: root bus resource [mem 0x6000-0x6fff] [3.272233] pci_bus :00: root bus resource [bus 00-ff] [3.283209] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 [3.295226] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] [3.307723] pci :00:00.0: reg 0x14: [mem 0x6020-0x6020] [3.320294] pci :00:00.0: supports D1 [3.328287] pci :00:00.0: PME# supported from D0 D1 D3hot [3.341226] pci :01:00.0: [14c3:7615] type 00 class 0x000280 [3.353293] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] [3.366998] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 link) [3.395633] pci :00:00.0: PCI bridge to [bus 01-ff] [3.406073] pci :00:00.0: bridge window [io 0x-0x0fff] [3.418220] pci :00:00.0: bridge window [mem 0x6000-0x600f] [3.431784] pci :00:00.0: bridge window [mem 0x6010-0x601f pref] [3.446184] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 [3.459414] pci :00:00.0: BAR 0: no space for [mem size 0x8000] [3.472600] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] [3.486479] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] [3.500016] pci :00:00.0: BAR 9: assigned [mem 0x6010-0x601f pref] [3.514411] pci :00:00.0: BAR 1: assigned [mem 0x6020-0x6020] [3.527951] pci :00:00.0: BAR 7: assigned [io 0x1e16-0x1e160fff] [3.541489] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f 64bit] [3.556077] pci :00:00.0: PCI bridge to [bus 01] [3.565975] pci :00:00.0: bridge window [io 0x1e16-0x1e160fff] [3.579504] pci :00:00.0: bridge window [mem 0x6000-0x600f] [3.593037] pci :00:00.0: bridge window [mem 0x6010-0x601f pref] [ 27.217458] pci :00:00.0: enabling device (0006 -> 0007) [ 27.217158] mt7615e :01:00.0: no of_node; not parsing pinc
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Am 07.04.20 um 17:49 schrieb Bjørn Mork: > Just remembered an issue on my todo list: There have been some MTU > handling changes in the kernel networking API. This affected the > qmi_wwan QMAP handling. I am not sure about the current status. Will > have to dig a bit more. But this might be your problem. That made me set MTU of wwan0 to 1600, and the qmimux* to 1500. No more problems anymore. This should go into documentation, not that anybody makes the same errors. How much overhead does qmux create (for correct calculated MTU offset)? Thanks you! Kind regards, André smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
