[OpenWrt-Devel] Question Re: Sourceful SDK
Hi Felix, I've been thinking about the sourceful SDK and have some ideas on how to implement, I just want to clarify one point: Are you thinking the SDK should be like the buildroot where everything (including tools and toolchain) is built from source, or are you thinking tools and toolchain (but not kernel, because that introduces build_dir/staging_dir messiness) should be precompiled (so that the rest may be compiled without much in the way of external dependencies). I'm actually think OpenWrt's build dependencies are light enough that it might make sense to do an entirely sourceful SDK, and completely skip pacakaging binaries (except for the option of downloading and including source archives). With your recent target/linux commit this shouldn't cause any major headaches, and the SDK can already generate the Config.in placeholders that make sure both the base system and SDK are configured with the same settings (e.g for kernel compile). Actually I have to review the SDK and figure out why the kernel is in the SDK in the first place (ImageBuilder those binaries are obviously required, but the SDK I'm not sure why they're there, or if I'm actually misremembering and there is no kernel in the SDK; if that is the case then the whole thing gets a lot easier). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question Re: Sourceful SDK
Also, I'm thinking that for the SDK sources it might make sense to only include packages with an InstallDev section and the toolchain and do some work to make sure that packages built as part of the base system can't have their config options overridden (at least for an already included flavour), in order to guarantee that the compilation produces identical libraries and such. Regards, Daniel On 08/01/16 03:14 AM, Daniel Dickinson wrote: Hi Felix, I've been thinking about the sourceful SDK and have some ideas on how to implement, I just want to clarify one point: Are you thinking the SDK should be like the buildroot where everything (including tools and toolchain) is built from source, or are you thinking tools and toolchain (but not kernel, because that introduces build_dir/staging_dir messiness) should be precompiled (so that the rest may be compiled without much in the way of external dependencies). I'm actually think OpenWrt's build dependencies are light enough that it might make sense to do an entirely sourceful SDK, and completely skip pacakaging binaries (except for the option of downloading and including source archives). With your recent target/linux commit this shouldn't cause any major headaches, and the SDK can already generate the Config.in placeholders that make sure both the base system and SDK are configured with the same settings (e.g for kernel compile). Actually I have to review the SDK and figure out why the kernel is in the SDK in the first place (ImageBuilder those binaries are obviously required, but the SDK I'm not sure why they're there, or if I'm actually misremembering and there is no kernel in the SDK; if that is the case then the whole thing gets a lot easier). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question Re: Sourceful SDK
Actually I've thought about the toolchain thing a little more and I have an idea: make it possible for the SDK to use an Openwrt Toolchain tarball as the toolchain, and don't ship the binary toolchain as part of the SDK at all. One possible improvement would be for the binary toolchain to also include relevant host tools, and not be strictly the compile toolchain. Regards, Daniel On 08/01/16 03:14 AM, Daniel Dickinson wrote: Hi Felix, I've been thinking about the sourceful SDK and have some ideas on how to implement, I just want to clarify one point: Are you thinking the SDK should be like the buildroot where everything (including tools and toolchain) is built from source, or are you thinking tools and toolchain (but not kernel, because that introduces build_dir/staging_dir messiness) should be precompiled (so that the rest may be compiled without much in the way of external dependencies). I'm actually think OpenWrt's build dependencies are light enough that it might make sense to do an entirely sourceful SDK, and completely skip pacakaging binaries (except for the option of downloading and including source archives). With your recent target/linux commit this shouldn't cause any major headaches, and the SDK can already generate the Config.in placeholders that make sure both the base system and SDK are configured with the same settings (e.g for kernel compile). Actually I have to review the SDK and figure out why the kernel is in the SDK in the first place (ImageBuilder those binaries are obviously required, but the SDK I'm not sure why they're there, or if I'm actually misremembering and there is no kernel in the SDK; if that is the case then the whole thing gets a lot easier). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question Re: Sourceful SDK
Oh, can't ship tools - some them end up with hard-coded paths which is part of the problem. Still using an openwrt toolchain tarball would eliminate with what would be the lengthy part of a sourceful SDK build, and you could even make it a drop-in option (that is drop in some directory and it is automagically found and used if present) since we already know the name from the config options and usual naming rules. Regards, Daniel On 08/01/16 03:31 AM, Daniel Dickinson wrote: Actually I've thought about the toolchain thing a little more and I have an idea: make it possible for the SDK to use an Openwrt Toolchain tarball as the toolchain, and don't ship the binary toolchain as part of the SDK at all. One possible improvement would be for the binary toolchain to also include relevant host tools, and not be strictly the compile toolchain. Regards, Daniel On 08/01/16 03:14 AM, Daniel Dickinson wrote: Hi Felix, I've been thinking about the sourceful SDK and have some ideas on how to implement, I just want to clarify one point: Are you thinking the SDK should be like the buildroot where everything (including tools and toolchain) is built from source, or are you thinking tools and toolchain (but not kernel, because that introduces build_dir/staging_dir messiness) should be precompiled (so that the rest may be compiled without much in the way of external dependencies). I'm actually think OpenWrt's build dependencies are light enough that it might make sense to do an entirely sourceful SDK, and completely skip pacakaging binaries (except for the option of downloading and including source archives). With your recent target/linux commit this shouldn't cause any major headaches, and the SDK can already generate the Config.in placeholders that make sure both the base system and SDK are configured with the same settings (e.g for kernel compile). Actually I have to review the SDK and figure out why the kernel is in the SDK in the first place (ImageBuilder those binaries are obviously required, but the SDK I'm not sure why they're there, or if I'm actually misremembering and there is no kernel in the SDK; if that is the case then the whole thing gets a lot easier). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Question Re: Sourceful SDK
Actually if you include the toolchain source in the SDK and have this toolchain tarball drop in option you get the bonus of being able to build on platforms other than for which you have precompiled binaries, while gaining the benefit of already having the binaries when you have the appropriate tarball. Regards, Daniel On 08/01/16 03:41 AM, Daniel Dickinson wrote: Oh, can't ship tools - some them end up with hard-coded paths which is part of the problem. Still using an openwrt toolchain tarball would eliminate with what would be the lengthy part of a sourceful SDK build, and you could even make it a drop-in option (that is drop in some directory and it is automagically found and used if present) since we already know the name from the config options and usual naming rules. Regards, Daniel On 08/01/16 03:31 AM, Daniel Dickinson wrote: Actually I've thought about the toolchain thing a little more and I have an idea: make it possible for the SDK to use an Openwrt Toolchain tarball as the toolchain, and don't ship the binary toolchain as part of the SDK at all. One possible improvement would be for the binary toolchain to also include relevant host tools, and not be strictly the compile toolchain. Regards, Daniel On 08/01/16 03:14 AM, Daniel Dickinson wrote: Hi Felix, I've been thinking about the sourceful SDK and have some ideas on how to implement, I just want to clarify one point: Are you thinking the SDK should be like the buildroot where everything (including tools and toolchain) is built from source, or are you thinking tools and toolchain (but not kernel, because that introduces build_dir/staging_dir messiness) should be precompiled (so that the rest may be compiled without much in the way of external dependencies). I'm actually think OpenWrt's build dependencies are light enough that it might make sense to do an entirely sourceful SDK, and completely skip pacakaging binaries (except for the option of downloading and including source archives). With your recent target/linux commit this shouldn't cause any major headaches, and the SDK can already generate the Config.in placeholders that make sure both the base system and SDK are configured with the same settings (e.g for kernel compile). Actually I have to review the SDK and figure out why the kernel is in the SDK in the first place (ImageBuilder those binaries are obviously required, but the SDK I'm not sure why they're there, or if I'm actually misremembering and there is no kernel in the SDK; if that is the case then the whole thing gets a lot easier). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Atomic/failsafe upgrades?
Eric Schultz [2016-01-07 12:48:50]: > I've had some similar interest in this topic. As far as I know, there > isn't anything like this on OpenWrt. There might be some overlap with the > discussion of automatic updates from last week as well. AFAIK, OpenMesh devices has this feature[1]. Please note, that bootloader/U-Boot source is not available. 1. target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: Add kernel module for Freescale SNVS RTC on chip module
Signed-off-by: Petr Štetiar --- package/kernel/linux/modules/other.mk | 16 1 file changed, 16 insertions(+) diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk index 62fdc3c..69099a5 100644 --- a/package/kernel/linux/modules/other.mk +++ b/package/kernel/linux/modules/other.mk @@ -656,6 +656,22 @@ endef $(eval $(call KernelPackage,rtc-pt7c4338)) +define KernelPackage/rtc-snvs + SUBMENU:=$(OTHER_MENU) + TITLE:=Freescale SNVS RTC support + DEPENDS:=@RTC_SUPPORT + KCONFIG:=CONFIG_RTC_DRV_SNVS \ + CONFIG_RTC_CLASS=y + FILES:=$(LINUX_DIR)/drivers/rtc/rtc-snvs.ko + AUTOLOAD:=$(call AutoProbe,rtc-snvs) +endef + +define KernelPackage/rtc-snvs/description + Kernel module for Freescale SNVS RTC on chip module +endef + +$(eval $(call KernelPackage,rtc-snvs)) + define KernelPackage/mtdtests SUBMENU:=$(OTHER_MENU) -- 1.7.9.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] imx6: kernel: Add Micrel PHY used on Apalis SOM
Signed-off-by: Petr Štetiar Cc: Luka Perkov --- target/linux/imx6/config-4.1 |1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/imx6/config-4.1 b/target/linux/imx6/config-4.1 index 52544a7..e07a5b7 100644 --- a/target/linux/imx6/config-4.1 +++ b/target/linux/imx6/config-4.1 @@ -223,6 +223,7 @@ CONFIG_LZO_COMPRESS=y CONFIG_LZO_DECOMPRESS=y CONFIG_MDIO_BOARDINFO=y CONFIG_MFD_SYSCON=y +CONFIG_MICREL_PHY=y CONFIG_MIGHT_HAVE_CACHE_L2X0=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_MMC=y -- 1.7.9.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] fstools: Check FS state before writing
It reduces number of flash writes on systems with FS ready.
Signed-off-by: Wojciech Dubowik
---
libfstools/overlay.c | 3 ++-
mount_root.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/libfstools/overlay.c b/libfstools/overlay.c
index 7f69606..b51a6ae 100644
--- a/libfstools/overlay.c
+++ b/libfstools/overlay.c
@@ -251,7 +251,8 @@ jffs2_switch(struct volume *v)
return ret;
sync();
- fs_state_set("/overlay", FS_STATE_READY);
+ if (fs_state_get("/overlay") != FS_STATE_READY)
+ fs_state_set("/overlay", FS_STATE_READY);
return 0;
}
diff --git a/mount_root.c b/mount_root.c
index bf70265..29b2758 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -106,7 +106,8 @@ done(int argc, char *argv[1])
case FS_JFFS2:
case FS_UBIFS:
- fs_state_set("/overlay", FS_STATE_READY);
+ if (fs_state_get("/overlay") != FS_STATE_READY)
+ fs_state_set("/overlay", FS_STATE_READY);
break;
}
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Description of the old packages repo at git.openwrt.org should be changed to "oldpackages"
The git description of the old packages repository is confusingly still "OpenWrt main package feed", although the repo is currently the unmaintained "oldpackages" feed. It would be more clear for a casual user if the git description would match the current contents... Description could be something like "oldpackages - unmaintained" http://git.openwrt.org/?p=packages.git;a=summary descriptionOpenWrt main package feed http://git.openwrt.org/ ... openwrt.git OpenWrt main development branch svn:trunk 15 hours ago summary... packages.git OpenWrt main package feed svn:packages 5 weeks ago summary... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] imx6: backport upstream patch to fix pwm pinmux for GW51xx/GW52xx/GW53xx
Signed-off-by: Tim Harvey
---
...ventana-fix-PWM-pinmux-for-Ventana-boards.patch | 69 ++
1 file changed, 69 insertions(+)
create mode 100644
target/linux/imx6/patches-4.3/042-ARM-dts-imx-ventana-fix-PWM-pinmux-for-Ventana-boards.patch
diff --git
a/target/linux/imx6/patches-4.3/042-ARM-dts-imx-ventana-fix-PWM-pinmux-for-Ventana-boards.patch
b/target/linux/imx6/patches-4.3/042-ARM-dts-imx-ventana-fix-PWM-pinmux-for-Ventana-boards.patch
new file mode 100644
index 000..1493787
--- /dev/null
+++
b/target/linux/imx6/patches-4.3/042-ARM-dts-imx-ventana-fix-PWM-pinmux-for-Ventana-boards.patch
@@ -0,0 +1,69 @@
+commit 3371600cc36d2a6c19cc985660a21c6830f7e7cd
+Author: Tim Harvey
+Date: Thu Jan 7 09:03:03 2016 -0800
+
+ARM: dts: imx: ventana: fix PWM pinmux for Ventana boards
+
+Fix some invalid pwm pinmux configurations.
+
+Signed-off-by: Tim Harvey
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+index fb0abd6..2e2cd5c 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+@@ -320,13 +320,13 @@
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+- MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
++ MX6QDL_PAD_SD1_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm4: pwm4grp {
+ fsl,pins = <
+- MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x1b0b1
++ MX6QDL_PAD_SD1_CMD__PWM4_OUT0x1b0b1
+ >;
+ };
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+index 7fc45a4..7172e11 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+@@ -473,7 +473,7 @@
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+- MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
++ MX6QDL_PAD_SD1_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+index c37f89d..8097d6a 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+@@ -462,7 +462,7 @@
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+- MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
++ MX6QDL_PAD_SD1_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+index cca39f1..f27f184 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+@@ -262,7 +262,7 @@
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+- MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
++ MX6QDL_PAD_SD1_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] imx6: fix upstream patch name
Signed-off-by: Tim Harvey
---
...llow-HDMI-and-LVDS-to-work-simultaneously.patch | 76 ++
...mx-ventana-fix-GW53xx-GW54xx-lvds-channel.patch | 76 --
2 files changed, 76 insertions(+), 76 deletions(-)
create mode 100644
target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-Allow-HDMI-and-LVDS-to-work-simultaneously.patch
delete mode 100644
target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-fix-GW53xx-GW54xx-lvds-channel.patch
diff --git
a/target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-Allow-HDMI-and-LVDS-to-work-simultaneously.patch
b/target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-Allow-HDMI-and-LVDS-to-work-simultaneously.patch
new file mode 100644
index 000..768648e
--- /dev/null
+++
b/target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-Allow-HDMI-and-LVDS-to-work-simultaneously.patch
@@ -0,0 +1,76 @@
+From d86b202436b6f3111c4c37b8701daa0764d2ca55 Mon Sep 17 00:00:00 2001
+From: Tim Harvey
+Date: Thu, 5 Nov 2015 11:10:00 -0800
+Subject: [PATCH 3/3] ARM: dts: imx: ventana: Allow HDMI and LVDS to work
+ simultaneously
+
+Currently it is not possible to have HDMI and LVDS working simultaneously,
+because both ports try to use PLL5.
+
+Move the LVDS clock parent to PLL3_USB_OTG, so that HDMI and LVDS can be
+driven from independent sources.
+
+With this change the LDB pixel clock goes to 68.57 MHz, which is still
+within the valid range for the displays supported by the Ventana boards.
+
+Signed-off-by: Tim Harvey
+---
+ arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 7 +++
+ arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 7 +++
+ arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 7 +++
+ 3 files changed, 21 insertions(+)
+
+Index: linux-4.3/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+===
+--- linux-4.3.orig/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi 2015-11-01
16:05:25.0 -0800
linux-4.3/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi2015-12-18
10:43:32.0 -0800
+@@ -151,6 +151,13 @@
+ status = "okay";
+ };
+
++&clks {
++ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
++<&clks IMX6QDL_CLK_LDB_DI1_SEL>;
++ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
++<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
++};
++
+ &fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+Index: linux-4.3/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+===
+--- linux-4.3.orig/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 2015-12-18
10:39:44.867158318 -0800
linux-4.3/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi2015-12-18
10:43:32.0 -0800
+@@ -152,6 +152,13 @@
+ status = "okay";
+ };
+
++&clks {
++ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
++<&clks IMX6QDL_CLK_LDB_DI1_SEL>;
++ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
++<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
++};
++
+ &fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+Index: linux-4.3/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+===
+--- linux-4.3.orig/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 2015-12-18
10:39:44.871158318 -0800
linux-4.3/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi2015-12-18
10:43:32.0 -0800
+@@ -142,6 +142,13 @@
+ status = "okay";
+ };
+
++&clks {
++ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
++<&clks IMX6QDL_CLK_LDB_DI1_SEL>;
++ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
++<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
++};
++
+ &fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
diff --git
a/target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-fix-GW53xx-GW54xx-lvds-channel.patch
b/target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-fix-GW53xx-GW54xx-lvds-channel.patch
deleted file mode 100644
index 768648e..000
---
a/target/linux/imx6/patches-4.3/037-ARM-dts-imx-ventana-fix-GW53xx-GW54xx-lvds-channel.patch
+++ /dev/null
@@ -1,76 +0,0 @@
-From d86b202436b6f3111c4c37b8701daa0764d2ca55 Mon Sep 17 00:00:00 2001
-From: Tim Harvey
-Date: Thu, 5 Nov 2015 11:10:00 -0800
-Subject: [PATCH 3/3] ARM: dts: imx: ventana: Allow HDMI and LVDS to work
- simultaneously
-
-Currently it is not possible to have HDMI and LVDS working simultaneously,
-because both ports try to use PLL5.
-
-Move the LVDS clock parent to PLL3_USB_OTG, so that HDMI and LVDS can be
-driven from independent sources.
-
-With this change the LDB pixel clock goes to 68.57 MHz, which is still
-within the valid range for the displays supported by the Ventana boards.
-
-Signed-off-by: Tim Harvey
- arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 7 +++
- arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 7 +++
- arch/arm/boot/dts/imx6q
[OpenWrt-Devel] [PATCH] dnsmasq: add dhcp relay option
Signed-off-by: dbugnar
---
package/network/services/dnsmasq/files/dhcp.conf| 6 ++
package/network/services/dnsmasq/files/dnsmasq.init | 19 +++
2 files changed, 25 insertions(+)
diff --git a/package/network/services/dnsmasq/files/dhcp.conf
b/package/network/services/dnsmasq/files/dhcp.conf
index 362b90a..7a66b44 100644
--- a/package/network/services/dnsmasq/files/dhcp.conf
+++ b/package/network/services/dnsmasq/files/dhcp.conf
@@ -30,3 +30,9 @@ config dhcp lan
config dhcp wan
option interfacewan
option ignore 1
+
+config relay
+ option local_addr '192.168.1.1'
+ option server_addr '0.0.0.0'
+ option interface'eth0'
+
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index 3ef2b3d..ac45d1b 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -538,6 +538,24 @@ dhcp_hostrecord_add() {
xappend "--host-record=$record"
}
+dhcp_relay_add() {
+ local cfg="$1"
+ local local_addr server_addr interface
+
+ config_get local_addr "$cfg" local_addr
+ [ -n "$local_addr" ] || return 0
+
+ config_get server_addr "$cfg" server_addr
+ [ -n "$server_addr" ] || return 0
+
+ config_get interface "$cfg" interface
+ if [ -z "$interface" ]; then
+ xappend "--dhcp-relay=$local_addr,$server_addr"
+ else
+ xappend "--dhcp-relay=$local_addr,$server_addr,$interface"
+ fi
+}
+
service_triggers()
{
procd_add_reload_trigger "dhcp"
@@ -597,6 +615,7 @@ start_service() {
config_foreach dhcp_subscrid_add subscrid
config_foreach dhcp_domain_add domain
config_foreach dhcp_hostrecord_add hostrecord
+ config_foreach dhcp_relay_add relay
# add own hostname
local lanaddr
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Even better rebuild times coming
Hi all, I just thought I'd let you know that with some changes I am testing I have reduced the >7m rebuild 'real' time to 4m (and before Felix's work it was 14m for the same build). Basically I have a patch that let's you build a selected set of profiles instead either all or one. For targets like ar71xx and brcm63xx this becomes important because of the large number of profiles (almost one per model of router) which produce a different image. The 4m vs >7m is with six profiles selected instead of all (and as before rebuilding SDK and ImageBuilder). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Even better rebuild times coming
That's just awesome - I'm on ar71xx, so this is much appreciated! - Original Message - From: "Daniel Dickinson" To: openwrt-devel@lists.openwrt.org Sent: Friday, January 8, 2016 10:38:56 AM Subject: [OpenWrt-Devel] Even better rebuild times coming Hi all, I just thought I'd let you know that with some changes I am testing I have reduced the >7m rebuild 'real' time to 4m (and before Felix's work it was 14m for the same build). Basically I have a patch that let's you build a selected set of profiles instead either all or one. For targets like ar71xx and brcm63xx this becomes important because of the large number of profiles (almost one per model of router) which produce a different image. The 4m vs >7m is with six profiles selected instead of all (and as before rebuilding SDK and ImageBuilder). Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: check for stuck DMA on AR724x & fix sirq storm after recovery
On 2016-01-08 06:26, Conn O'Griofa wrote:
> Hi,
>
> I'm proposing the following patch to resolve ticket #18922 fully.
>
> With the current master revision, when a tx timeout condition occurs,
> the interface recovers successfully, but a soft irq storm occurs
> (causing ksoftirqd to peg the CPU, due to this goto being called
> without end:
> https://github.com/openwrt-mirror/openwrt/blob/master/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c#L1073
> ). Forcing the tx and rx rings to be cleared and re-inited in
> ag71xx_restart_work_func seems to avoid the sirq storm, but I'd
> appreciate feedback on whether there's a more effective workaround.
>
> Additionally, ag71xx_check_dma_stuck *does* successfully detect the
> stuck DMA condition on AR7241 (TR-WL842ND v1), so enabling the check
> for this chipset series ensures a link adjust occurs *before* an
> actual tx timeout is detected. This avoids the brief network
> interruption that normally occurs during the DMA stuck -> tx timeout
> -> link adjust condition.
>
> Conn
>
> P.S. The sirq storm also occurs when ag71xx_check_dma_stuck is utilized on
> this chipset to avoid the tx timeout condition, so it appears that both
> changes are necessary (or at least, a better way to solve the sirq storm
> needs to be discovered).
Thanks for investigating this further. Please try this patch:
---
---
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -631,34 +631,61 @@ void ag71xx_link_adjust(struct ag71xx *ag)
ag71xx_rr(ag, AG71XX_REG_MAC_IFCTL));
}
+static int ag71xx_hw_enable(struct ag71xx *ag)
+{
+ int ret;
+
+ ret = ag71xx_rings_init(ag);
+ if (ret)
+ return ret;
+
+ napi_enable(&ag->napi);
+ ag71xx_wr(ag, AG71XX_REG_TX_DESC, ag->tx_ring.descs_dma);
+ ag71xx_wr(ag, AG71XX_REG_RX_DESC, ag->rx_ring.descs_dma);
+ netif_start_queue(ag->dev);
+
+ return 0;
+}
+
+static void ag71xx_hw_disable(struct ag71xx *ag)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&ag->lock, flags);
+
+ netif_stop_queue(ag->dev);
+
+ ag71xx_hw_stop(ag);
+ ag71xx_dma_reset(ag);
+
+ napi_disable(&ag->napi);
+ del_timer_sync(&ag->oom_timer);
+
+ spin_unlock_irqrestore(&ag->lock, flags);
+
+ ag71xx_rings_cleanup(ag);
+}
+
static int ag71xx_open(struct net_device *dev)
{
struct ag71xx *ag = netdev_priv(dev);
unsigned int max_frame_len;
int ret;
+ netif_carrier_off(dev);
max_frame_len = ag71xx_max_frame_len(dev->mtu);
ag->rx_buf_size = max_frame_len + NET_SKB_PAD + NET_IP_ALIGN;
/* setup max frame length */
ag71xx_wr(ag, AG71XX_REG_MAC_MFL, max_frame_len);
+ ag71xx_hw_set_macaddr(ag, dev->dev_addr);
- ret = ag71xx_rings_init(ag);
+ ret = ag71xx_hw_enable(ag);
if (ret)
goto err;
- napi_enable(&ag->napi);
-
- netif_carrier_off(dev);
ag71xx_phy_start(ag);
- ag71xx_wr(ag, AG71XX_REG_TX_DESC, ag->tx_ring.descs_dma);
- ag71xx_wr(ag, AG71XX_REG_RX_DESC, ag->rx_ring.descs_dma);
-
- ag71xx_hw_set_macaddr(ag, dev->dev_addr);
-
- netif_start_queue(dev);
-
return 0;
err:
@@ -669,24 +696,10 @@ err:
static int ag71xx_stop(struct net_device *dev)
{
struct ag71xx *ag = netdev_priv(dev);
- unsigned long flags;
netif_carrier_off(dev);
ag71xx_phy_stop(ag);
-
- spin_lock_irqsave(&ag->lock, flags);
-
- netif_stop_queue(dev);
-
- ag71xx_hw_stop(ag);
- ag71xx_dma_reset(ag);
-
- napi_disable(&ag->napi);
- del_timer_sync(&ag->oom_timer);
-
- spin_unlock_irqrestore(&ag->lock, flags);
-
- ag71xx_rings_cleanup(ag);
+ ag71xx_hw_disable(ag);
return 0;
}
@@ -870,14 +883,10 @@ static void ag71xx_restart_work_func(struct work_struct
*work)
{
struct ag71xx *ag = container_of(work, struct ag71xx, restart_work);
- if (ag71xx_get_pdata(ag)->is_ar724x) {
- ag->link = 0;
- ag71xx_link_adjust(ag);
- return;
- }
-
- ag71xx_stop(ag->dev);
- ag71xx_open(ag->dev);
+ rtnl_lock();
+ ag71xx_hw_disable(ag);
+ ag71xx_hw_enable(ag);
+ rtnl_unlock();
}
static bool ag71xx_check_dma_stuck(struct ag71xx *ag, unsigned long timestamp)
@@ -919,7 +928,7 @@ static int ag71xx_tx_packets(struct ag71xx *ag, bool flush)
struct sk_buff *skb = ring->buf[i].skb;
if (!flush && !ag71xx_desc_empty(desc)) {
- if (pdata->is_ar7240 &&
+ if (pdata->is_ar724x &&
ag71xx_check_dma_stuck(ag, ring->buf[i].timestamp))
schedule_work(&ag->restart_work);
break;
_
Re: [OpenWrt-Devel] Description of the old packages repo at git.openwrt.org should be changed to "oldpackages"
On 2016-01-08 13:54, Hannu Nyman wrote: > The git description of the old packages repository is confusingly still > "OpenWrt main package feed", although the repo is currently the unmaintained > "oldpackages" feed. It would be more clear for a casual user if the git > description would match the current contents... > > Description could be something like "oldpackages - unmaintained" > > http://git.openwrt.org/?p=packages.git;a=summary > descriptionOpenWrt main package feed Fixed now, thanks. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: check for stuck DMA on AR724x & fix sirq storm after recovery
On 08/01/16 16:49, Felix Fietkau wrote: Thanks for investigating this further. Please try this patch: Unfortunately, your proposed patch doesn't work. When I trigger the timeout condition, a tx timeout occurs and the interface doesn't recover correctly: [ 249.075582] [ cut here ] [ 249.080296] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x1dc/0x260() [ 249.088800] NETDEV WATCHDOG: eth1 (ag71xx): transmit queue 0 timed out [ 249.095378] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat ath9k_hw ath pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 mac80211 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat fuse sch_fq_pie sch_cake act_ipt em_nbyte sch_teql sch_htb sch_prio sch_pie sch_codel sch_gred em_meta cls_basic em_text sch_tbf sch_red sch_sfq sch_fq act_police em_cmp sch_dsmark act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ledtrig_usbdev ip6t_REJ E CT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables ifb zram lzo_decompress lzo_compress lz4_decompress lz4_compress zsmalloc usb_storage ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 jbd2 mbcache usbcore nls_base usb_common crc16 crypto_hash [ 249.211641] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.13 #1 [ 249.217434] Stack : 80378d20 0001 803c 803b8ab0 803b8743 8035b52c [ 249.217434]80413514 00c8 0004 000a 0100 800a6110 803c7d04 803b [ 249.217434]0003 00c8 8035edb4 803b3c44 0100 800a473c 0006 [ 249.217434] 8041 [ 249.217434] [ 249.217434]... [ 249.253511] Call Trace: [ 249.256003] [<80071f5c>] show_stack+0x50/0x84 [ 249.260417] [<8008150c>] warn_slowpath_common+0xa0/0xd0 [ 249.265693] [<80081568>] warn_slowpath_fmt+0x2c/0x38 [ 249.270694] [<8026240c>] dev_watchdog+0x1dc/0x260 [ 249.275456] [<800ad290>] call_timer_fn.isra.3+0x24/0x80 [ 249.280735] [<800ad498>] run_timer_softirq+0x1ac/0x1ec [ 249.285936] [<80083b30>] __do_softirq+0x16c/0x298 [ 249.290678] [<80083e7c>] irq_exit+0x54/0x70 [ 249.294897] [<80060830>] ret_from_irq+0x0/0x4 [ 249.299313] [<80060a80>] __r4k_wait+0x20/0x40 [ 249.303709] [<800a189c>] cpu_startup_entry+0x114/0x13c [ 249.308904] [<803d5bc4>] start_kernel+0x464/0x484 [ 249.313649] [ 249.315156] ---[ end trace 5936bede9e8ff3e6 ]--- [ 249.319817] eth1: tx timeout [ 260.075531] eth1: tx timeout [ 275.075459] eth1: tx timeout [ 285.075418] eth1: tx timeout Triggering a manual 'ifconfig eth1 down; ifconfig eth1 up; ifup wan' still restores connectivity with your patch, if it helps. Conn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] and what is with RB433UL ?
Nobody has this board? I don't have so much experience with openwrt. Possible somebody have some ideas. I will post here some questions to this board. 1. The board has not a real serial port. (only some pads) 2. In general, the boot sequence will be selected by the Routerbord-OS. A typical choice is "nand only" and "boot from ether once then from nand" The the boot sequence will also reset to nand after once try from ether. 3. Openwrt have no support to sysupgrade jet. 4. For a upgrade (wget2nand) you most boot from tftp/dhcp, because of write errors. 5. You have the choice for tftpboot/dhcpboot. I think with this constellation is not easy to get a secure installation and failsave method. Is there any experience in this case? Thanks for answer. sm Am Wed, 6 Jan 2016 19:23:36 +0100 schrieb : > An other question. > > Is there anybody have experience with the RB433UL ? > This board waiting here hopeful for OpenWRT. > The openwrt should run with this board, but i don't have any success. > > > > > Am Wed, 6 Jan 2016 17:31:02 +0100 > schrieb Damian Kaczkowski : > > > I think it's known problem. rb750gl on dd trunk got booting problems > > too. https://dev.openwrt.org/ticket/21379 > > But rb750gl case is a little bit worse. It doesn't even boot > > initramfs images. > > > > > > On 6 January 2016 at 16:51, wrote: > > > > > Is this problem known? > > > The kernel vmlinux.lzma.elf dos not start from nand. > > > wget2nand works fine but the kernel result no answer while > > > booting. It is strange, because tftp with initrd booting fine. > > > This problem is new in trunk. > > > I have no problems with bb and cc. > > > > > > is there a guru for helping? > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: check for stuck DMA on AR724x & fix sirq storm after recovery
On 08/01/16 18:48, Conn O'Griofa wrote: Unfortunately, your proposed patch doesn't work. When I trigger the timeout condition, a tx timeout occurs and the interface doesn't recover correctly: I'm not able to test recompiles for a few hours at least, but: * After your patch failed, I already tested quick rebuild, changing ag71xx_restart_work_func to use: rtnl_lock(); ag71xx_stop(ag->dev); ag71xx_open(ag->dev); rtnl_unlock(); With that change to your patch, the link adjust was triggered before the tx timeout was triggered (expected), but the sirq storm still occurred. * In ag71xx_hw_enable, netif_start_queue is issued. Since this function is used for the fast restart, that should probably be changed to netif_wake_queue so that the kernel will check for anything pending in the queue to be sent (which is certain to be true). I'll check this as soon as it's possible. Conn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problem with commit to prevent SDK from altering kernel modules
Hi Felix, I think your latest commit will have an unexpected effect. It will come into play whenever CONFIG_SDK=y, which includes when *building* the SDK, not only when *in* the SDK. For my own SDK development I added config IN_SDK bool default y in target/sdk/files/Config.in so that I would have a config option that was true while *in* the SDK, but *not* while building it. Regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar8327: add IGMP Snooping support
On Tue, Jan 05, 2016 at 08:40:37PM +0100, Álvaro Fernández Rojas wrote: > This add support for IGMP Snooping on atheros switches (enabled by default), > which avoids flooding the network with multicast data. > > Tested on TL-WDR4300: disabling IGMP Snooping results in multicast flooding > on each specific port, enabling it back again prevents each port from > receiving all multicast packets. > > Partially based on: http://patchwork.ozlabs.org/patch/418122/ > > Signed-off-by: Álvaro Fernández Rojas Hi, Do you know whether there is some documentation on what the IGMP Snooping of these chips does? For instance I'd be interested in knowing whether it takes Multicast Router Discovery (MRD) into account. Does it perform IGMP querying, too? Is there a maximum number of group entries? Does it know both IGMPv2 and IGMPv3? No MLD support, right? IGMP and IGMP snooping isn't that trivial. The IGMP snooping in the Linux bridge took quite a while until it actually got usable, too. So like Felix suggested in that ticket as well, I'd favor disabling it by default. Especially if it is a blackbox without documentation. Cheers, Linus PS: Thanks for looking into improving the multicast experience with OpenWRT :). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: check for stuck DMA on AR724x & fix sirq storm after recovery
On 08/01/16 19:17, Conn O'Griofa wrote: * In ag71xx_hw_enable, netif_start_queue is issued. Since this function is used for the fast restart, that should probably be changed to netif_wake_queue so that the kernel will check for anything pending in the queue to be sent (which is certain to be true). I'll check this as soon as it's possible. This change wasn't sufficient to fix the problem. After examining your changes a bit further, there's an issue: your ag71xx_hw_disable function calls ag71xx_hw_stop, but the complement function ag71xx_hw_enable doesn't call ag71xx_hw_start. Since you're trying to avoid a link adjust, the ag71xx_hw_start function never gets called during recovery with your patch. I tried replacing netif_start_queue(dev) with ag71xx_hw_start(ag) in ag71xx_hw_enable. With this change, when the DMA stuck issue occurs, there's no longer any tx timeouts logged, but the interface stops responding. Perhaps it's also necessary to call ag71xx_fast_reset (which only gets called during a link adjust)? Conn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with commit to prevent SDK from altering kernel modules
On 2016-01-09 00:13, Daniel Dickinson wrote: > Hi Felix, > > I think your latest commit will have an unexpected effect. It will come > into play whenever CONFIG_SDK=y, which includes when *building* the SDK, > not only when *in* the SDK. > > For my own SDK development I added > > config IN_SDK > bool > default y > > in target/sdk/files/Config.in > > so that I would have a config option that was true while *in* the SDK, > but *not* while building it. The SDK variable is not the same as the CONFIG_SDK variable. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
