Re: [OpenWrt-Devel] [PATCH] [kernel] Support for new Archer C7 with gd25q128 chip in 15.05.1
Specifically this applies to units manufactured in December of 2015 or
later; serial numbers starting with 215C.
On Sun, Apr 17, 2016 at 7:55 AM, John Marrett <jo...@zioncluster.ca> wrote:
> Recent Archer C7 V2.0 units have changed flash chips to the gd25q128
> chip, this is supported in trunk but not presently in 15.05. I would
> like stable support for this version so I've back ported the required
> fix [1] from the upstream kernel. I've tried to place this patch in
> order with the other flash support patches. I've tested it and I'm
> able to install a build of 15.05.1 on the device with this patch.
> Wireless and other functionality appears to be working properly.
>
> This is my first submitted patch for OpenWrt, please let me know on
> list or off if there are any issues.
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/mtd/spi-nor/spi-nor.c?id=fcc87a95195236b0935183361a72e4a98bf577d8
>
> Signed-off-by: John Marrett <jo...@zioncluster.ca>
>
> diff --git a/target/linux/ar71xx/patches-3.18/414-mtd-gd25q128-support.patch
> b/target/linux/ar71xx/
> new file mode 100644
> index 000..c4a0a94
> --- /dev/null
> +++ b/target/linux/ar71xx/patches-3.18/414-mtd-gd25q128-support.patch
> @@ -0,0 +1,12 @@
> +Index: linux-3.18.29/drivers/mtd/spi-nor/spi-nor.c
> +===
> +--- linux-3.18.29.orig/drivers/mtd/spi-nor/spi-nor.c 2016-04-15
> 20:02:47.709062050 -0400
> linux-3.18.29/drivers/mtd/spi-nor/spi-nor.c2016-04-16
> 07:41:06.071314788 -0400
> +@@ -510,6 +510,7 @@
> + /* GigaDevice */
> + { "gd25q32", INFO(0xc84016, 0, 64 * 1024, 64, SECT_4K) },
> + { "gd25q64", INFO(0xc84017, 0, 64 * 1024, 128, SECT_4K) },
> ++ { "gd25q128", INFO(0xc84018, 0, 64 * 1024, 256, SECT_4K) },
> +
> + /* Intel/Numonyx -- xxxs33b */
> + { "160s33b", INFO(0x898911, 0, 64 * 1024, 32, 0) },
> _______
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--
Kristian Kielhofner
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Bounty: /overlay on x86
Is /overlay supported on x86? Am I missing something here? On Thu, Jun 28, 2012 at 11:23 AM, Kristian Kielhofner k...@kriskinc.com wrote: Hello everyone, I've been struggling to get /overlay to work on x86. I'm using an initramfs filesystem and I want my changes to persist across reboot. For some reason I've been completely unable to get /overlay to work. I've tried asking here before, I've tried asking on the forum, and I've tried it myself - all to no avail. This post to the forum (from October) is a good summary of what I'm trying to do: https://forum.openwrt.org/viewtopic.php?pid=169868 To verify I've tried a native ext2 filesystem and bind. I can't get either to work. I'm offering $500 to someone who can get this configuration to work (bind fs) using openwrt trunk with an initramfs filesystem on x86 as cleanly (/overlay UCI config) as possible. Any changes made to OpenWRT sources (scripts, functions, etc) must be contributed back and accepted into openwrt trunk. Payment to be delivered via PayPal or some other means we can agree upon. Any takers? -- Kristian Kielhofner -- Kristian Kielhofner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Bounty: /overlay on x86
Hello everyone, I've been struggling to get /overlay to work on x86. I'm using an initramfs filesystem and I want my changes to persist across reboot. For some reason I've been completely unable to get /overlay to work. I've tried asking here before, I've tried asking on the forum, and I've tried it myself - all to no avail. This post to the forum (from October) is a good summary of what I'm trying to do: https://forum.openwrt.org/viewtopic.php?pid=169868 To verify I've tried a native ext2 filesystem and bind. I can't get either to work. I'm offering $500 to someone who can get this configuration to work (bind fs) using openwrt trunk with an initramfs filesystem on x86 as cleanly (/overlay UCI config) as possible. Any changes made to OpenWRT sources (scripts, functions, etc) must be contributed back and accepted into openwrt trunk. Payment to be delivered via PayPal or some other means we can agree upon. Any takers? -- Kristian Kielhofner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] packages for updated e1000/e1000e driver from SF
On Thu, Dec 22, 2011 at 10:00 AM, Mark Deneen mden...@gmail.com wrote: +1 We had troubles with the adapter resetting itself in certain situations with the in-tree driver. Outside of the OpenWrt world, of course. Same here, except I was using OpenWRT on x86. Switching to the Intel driver has resolved all of our issues. -- Kristian Kielhofner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] packages/net/freeswitch: Include timerfd support
Recent versions of uclibc, eglibc (and glibc 2.8) along with kernel 2.6.25 or later support timerfd. This patch adds a config option to include mod_timerfd with FreeSWITCH (which can also provide its own internal timing, although it's not as efficient or accurate): http://wiki.freeswitch.org/wiki/Mod_timerfd Signed-off-by: Kristian Kielhofner k...@kriskinc.com -- Kristian Kielhofner packages-freeswitch-timerfd.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] packages/net/asterisk-1.8.x: include timing sources
Asterisk does much better with internal timing. This patch adds support for two timing mechanisms: timerfd and pthread. If timerfd is available (compatible C lib and kernel) Asterisk will automatically prefer it. Otherwise pthread timing will be used. https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces Signed-off-by: Kristian Kielhofner k...@kriskinc.com -- Kristian Kielhofner packages-asterisk-1.8.x-res_timing_pthread-res_timing_timerfd.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Patch: fix zaptel 1.4 kernel modules on 2.6.39
2.6.39 removed the BKL. These patches to zaptel are getting messy;
I'm sure there's a better way to do this but I've got something that
works on 2.6.39. Probably should be tested on other kernel versions.
Signed-off-by: Kristian Kielhofner k...@kriskinc.com
--
Kristian Kielhofner
Index: libs/zaptel-1.4.x/patches/380-2.6.39.patch
===
--- libs/zaptel-1.4.x/patches/380-2.6.39.patch (revision 0)
+++ libs/zaptel-1.4.x/patches/380-2.6.39.patch (revision 0)
@@ -0,0 +1,21 @@
+--- zaptel-1.4.12.1/kernel/zaptel-base.c.orig 2011-10-12 17:32:31.772758001 -0400
zaptel-1.4.12.1/kernel/zaptel-base.c 2011-10-12 17:56:26.929758001 -0400
+@@ -5181,7 +5181,17 @@
+ return zt_chan_ioctl(inode, file, cmd, data, unit);
+ }
+
+-#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,36)
++#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,39)
++static long zt_ioctl_unlocked(struct file *file, unsigned int cmd, unsigned long data)
++{
++ int ret;
++
++ ret = zt_ioctl(file-f_path.dentry-d_inode, file, cmd, data);
++
++ return ret;
++}
++
++#elif LINUX_VERSION_CODE = KERNEL_VERSION(2,6,36)
+ #include linux/smp_lock.h
+ static long zt_ioctl_unlocked(struct file *file, unsigned int cmd, unsigned long data)
+ {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
