Re: [LEDE-DEV] Syslog-ng Makefile typo

[John Crispin]

Hi,

although the content of the patch looks good the format is incorrect.
you really want to generate the patch using git and then use git
format-patch/send-email to export and mail it. we cannot merge it in
this format i am afraid. please also make sure to add a Signed-off-by line

John

On 16/01/2017 12:24, Milan Kočvara wrote:
> Hello.
> I found typo in syslog-ng makefile.
> 
> I've upgraded to the newest version and I've made correction of the
> typo. Patch bellow.
> 
> Sorry for bad format of everything. I did it never :)
> 
> --- Makefile-orig   2017-01-16 12:06:44.367684776 +0100
> +++ Makefile~   2017-01-16 12:22:47.198478933 +0100
> @@ -1,14 +1,14 @@
>  include  $(TOPDIR)/rules.mk
> 
>  PKG_NAME:=syslog-ng
> -PKG_VERSION:=3.8.1
> -PKG_RELEASE:=3
> +PKG_VERSION:=3.9.1
> +PKG_RELEASE:=1
> 
>  PKG_MAINTAINER:=W. Michael Petullo 
> 
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> 
> PKG_SOURCE_URL:=https://github.com/balabit/syslog-ng/releases/download/$(PKG_NAME)-$(PKG_VERSION)/
> 
> -PKG_MD5SUM:=acf14563cf5ce435db8db35486ce66af
> +PKG_MD5SUM:=1b48da9ef620cf06e55e481b5abb677a
> 
>  PKG_INSTALL:=1
> 
> @@ -41,7 +41,7 @@
>  CONFIGURE_ARGS += \
>$(call autoconf_bool,CONFIG_IPV6,ipv6) \
>   --disable-dependency-tracking \
> - --disable-ampq \
> + --disable-amqp \
>   --disable-tcp-wrapper \
>   --disable-glibtest \
>   --disable-mongodb \
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Syslog-ng Makefile typo

[Milan Kočvara]

Hello,

Sorry for miss and late. Changes bellow. I do not found any other 
"depracated" function. One question about klogd and syslog-ng kernel 
messagess. On Linux, the klogd daemon can be used in addition to 
syslog-ng to read kernel messages and forward them to syslog-ng. klogd 
used to preprocess kernel messages to resolve symbols and so on, but as 
this is deprecated by ksymoops there is really no point in running both 
klogd and syslog-ng in parallel. Also note that running two processes 
reading /proc/kmsg at the same time might result in dead-locks. < Taken 
from manpage of syslog-ng. In LEDE/OpenWRT is klogd part of busybox in 
default.


Thanks


--- syslog-ng.conf-orig 2017-01-18 07:36:35.941285583 +0100
+++ syslog-ng.conf  2017-01-18 08:30:30.416247478 +0100
@@ -1,4 +1,4 @@
-@version:3.8
+@version:3.9

 options {
chain_hostnames(no);

Dne 17.1.2017 v 19:40 Philip Prindeville napsal(a):

Actually, I take that back.

Milan, can you please update the top line of files/syslog-ng.conf also?  It 
needs to read “3.9” instead (assuming there aren’t any syntactic constructs in 
that file that are now deprecated from 3.8 to 3.9… if there were, the file 
would need to be updated as well… like when the log_prefix() filter criteria 
got replaced by program()).

Thanks



On Jan 16, 2017, at 1:45 PM, Philip Prindeville 
 wrote:

Looks good to me.



On Jan 16, 2017, at 4:24 AM, Milan Kočvara  wrote:

Hello.
I found typo in syslog-ng makefile.

I've upgraded to the newest version and I've made correction of the typo. Patch 
bellow.

Sorry for bad format of everything. I did it never :)

--- Makefile-orig   2017-01-16 12:06:44.367684776 +0100
+++ Makefile~   2017-01-16 12:22:47.198478933 +0100
@@ -1,14 +1,14 @@
include  $(TOPDIR)/rules.mk

PKG_NAME:=syslog-ng
-PKG_VERSION:=3.8.1
-PKG_RELEASE:=3
+PKG_VERSION:=3.9.1
+PKG_RELEASE:=1

PKG_MAINTAINER:=W. Michael Petullo 

PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://github.com/balabit/syslog-ng/releases/download/$(PKG_NAME)-$(PKG_VERSION)/
-PKG_MD5SUM:=acf14563cf5ce435db8db35486ce66af
+PKG_MD5SUM:=1b48da9ef620cf06e55e481b5abb677a

PKG_INSTALL:=1

@@ -41,7 +41,7 @@
CONFIGURE_ARGS += \
  $(call autoconf_bool,CONFIG_IPV6,ipv6) \
 --disable-dependency-tracking \
- --disable-ampq \
+ --disable-amqp \
 --disable-tcp-wrapper \
 --disable-glibtest \
 --disable-mongodb \


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx/ath79: mark soft_config as writeable in mach-rb941.c

[John Crispin]

Hi

please fix the subject, git log --oneline target/linux/ar71xx will tell
you the correct format amd ...

On 18/01/2017 01:24, ha...@slashdirt.org wrote:
> From: Thibaut VARENE 
> 
> This is necessary for rbcfg to work.

this description is pointless ;) please add something better

John

> 
> Signed-off-by: Thibaut VARENE 
> ---
>  target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c
> index 5a8c7c0..5da950b 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c
> @@ -99,7 +99,6 @@ static struct mtd_partition rb941_spi_partitions[] = {
>  .name = "soft_config",
>  .offset = RB_SOFT_CFG_OFFSET,
>  .size = RB_SOFT_CFG_SIZE,
> -.mask_flags = MTD_WRITEABLE,
>  }, {
>  .name = "rootfs",
>  .offset = RB_ROOTFS_OFFSET,
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] This patch adds support for the Netgear WN3000RPv3 N300 repeater.

[Rafał Miłecki]

On 17 January 2017 at 23:12,   wrote:
> From: Thibaut VARENE 
>
> It uses the same trick as for the EX2700 to pass the Second Part
> Magic Check from the bootloader (as described here
> https://forum.openwrt.org/viewtopic.php?pid=312577#p312577 )
>
> Specifications:
> - SoC: MediaTek MT7620A (580MHz, ramips)
> - RAM: 32MB
> - Storage: 8MB NOR SPI flash
> - Wireless: builtin MT7620A
> - Ethernet: 1x100M
>
> Stock firmware is based on OpenWRT Kamikaze snapshot. To install
> LEDE, use the factory.bin image. Once LEDE is installed, subsequent
> updates can use the sysupgrade.bin image.
>
> Signed-off-by: Thibaut VARENE 

Please use "git log target/linux/ramips" to get a hint how patch could
be titled. Something like:
ramips: support for the Netgear WN3000RPv3 N300 repeater
could be more appropriate.


> --- /dev/null
> +++ b/target/linux/ramips/dts/WN3000RPV3.dts
> @@ -0,0 +1,148 @@
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include 

Please specify license of this file. If possible please choose
something BSD compatible as it may be required for upstreaming it. We
got such request from Florian for Broadcom DTS files:
https://lkml.org/lkml/2016/5/4/707

You may e.g. choose one of:
1) ISC License
2) BSD 3-clause license
3) BSD 2-clause license
4) Clear BSD license


> + {
> +   state_default: pinctrl0 {
> +   default {
> +   //  spi refclk: pins 37, 38, 39
> +   //   uartf: pins 8, 9, 10, 11, 12, 13, 14
> +   // i2c: pins 1, 2
> +   ralink,group = "i2c", "uartf", "spi refclk";
> +   ralink,function = "gpio";
> +   };
> +   };
> +};

Please use ANSI C comments.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] ramips: Add back sdhci-mt7620 driver to default config

[Rosen Penev]

The driver no longer causes kernel panics and CPU hangs.

Signed-off by: Rosen Penev 
---
 target/linux/ramips/image/mt7621.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/linux/ramips/image/mt7621.mk 
b/target/linux/ramips/image/mt7621.mk
index fd28e19..83c9d6d 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -91,7 +91,7 @@ define Device/pbr-m1
   DTS := PBR-M1
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := PBR-M1
-  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci
+  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += pbr-m1
 
@@ -178,7 +178,7 @@ define Device/witi
   DTS := WITI
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := MQmaker WiTi
-  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci
+  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += witi
 
@@ -209,7 +209,7 @@ define Device/zbt-wg2626
   DTS := ZBT-WG2626
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := ZBT WG2626
-  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci
+  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += zbt-wg2626
 
@@ -217,7 +217,7 @@ define Device/zbt-wg3526
   DTS := ZBT-WG3526
   IMAGE_SIZE := $(ralink_default_fw_size_16M)
   DEVICE_TITLE := ZBT WG3526
-  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci
+  DEVICE_PACKAGES := kmod-usb3 kmod-usb-ledtrig-usbport kmod-ata-core 
kmod-ata-ahci kmod-sdhci-mt7620
 endef
 TARGET_DEVICES += zbt-wg3526
 
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Making staging tree appear on cgit?

[Ted Hess]

On Tue, 2017-01-17 at 11:10 -0800, Florian Fainelli wrote:
> Hi,
> 
> Are there specific instructions not currently documented at:
> https://lede-project.org/docs/guide-developer/the-source-code
> 
> that are needed in order to make one's staging tree appear on cgit?
> 
> Thanks!

There should be nothing special beyond what was already outlined in my easy-use
guide for private repos. There is a problem that just recently appeared where
private repos as disappearing from gitweb due to what I think is recent script
hook changes.

I can manually make your repo re-appear but it will disappear again on your next
push to it. Stay tuned...

/ted


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Any interest in adding runit to OpenWRT?

[Denys Vlasenko via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Tue, Dec 27, 2016 at 1:07 AM, Martin Tippmann
 wrote:
> On Mon, Dec 26, 2016 at 5:32 PM, Rob Landley  wrote:
>> On 12/26/2016 08:05 AM, Martin Tippmann wrote:
>>> On Sun, Dec 25, 2016 at 9:01 PM, Denys Vlasenko
>>> So TL;DR: procd is fine for init but having runit/runsvdir easily
>>> usable would be a nice feature to have!
>
> Some practical example where runit might be useful (if you know how to
> do this with procd, please tell me :)

These are my examples

https://git.busybox.net/busybox/tree/examples/var_service

The README there explains how these are used to configure network.

Now that you mentioned netifd, I googled it up and it seems
my runit scripts managed to do something rather similar.

> - we have on our mesh network a VPN client (vtun) that starts when wan
> is up (via hotplug) but connectivity to the mesh network depends on
> olsr working.
> - at the moment there is some cumbersome cron logic shellscript hell
> that tries to check that a) vtun is working, b) olsr is working

Like
https://git.busybox.net/busybox/tree/examples/var_service/dhcp_if_pinger/run

> - writing a runit sv check script for vtun that checks for the correct
> olsr neighbours and that restarts vtun if no neighbours are found is
> pretty simple with runit. symlink the check for runwhen in the
> /etc/hotplug.d/vtun-wan script and then unlink on ifdown event. runit
> picks up the symlink and does the right thing. So there is the vtun
> connection and the 'sv ./etc/services/vtun check' script that checks
> olsr neighbors
> - This gives you seperation of concerns, it's unixy, it's only shell
> and it's something you can reason about.
>
> So what I'd like to have is something like adding events to runit - if
> netifd realizes there is a link loss on the wan interface I want to
> trigger somewhere sv stop /etc/services/vtun

I do not know how WAN if different from LANs, my needs to detect
ethernet and wifi disconnects are satisfied with this service:

https://git.busybox.net/busybox/tree/examples/var_service/ifplugd_if/run
https://git.busybox.net/busybox/tree/examples/var_service/ifplugd_if/ifplugd_handler

In short, a set of dhcp + wpa_supplicant + ifplugd + vpnc + pppd +
openvpn + ntpd
services under runsv can be made to play very well. I tried it.
Not too difficult.

All is restarted as needed on unplug / replug / loss of wifi / pppd establishing
link, routing and firewalling is reconfigured.

Like NetworkManager, but, you know, without NetworkManager :D

> But marrying runit+ubus+netifd+procd would _really_ solve some real
> world usecases we have in a unixy, reasonable way. I'm open for debate
> and discussion but this would provide a lot of flexibility for a
> rather low cost/overhead - be it memory/flash.

Just for the record, I'm not a runsv zealot.
If procd is good at it too, and if there would be enough
development push behind it so that its use expands from
its current niche to be usable everywhere on Linux, from wristwatches
to routers to desktops to supercomputers, then I'll have no objections.

> Unfortunatly this mail is all talk and no walk and figuring out a sane
> procd/netifd <-> runit interface is some rather hard problem if you
> want a good solution.

So far I don't see a problem needing such interface.

runsvdir/runsv is "just" a service babysitter. Its services
can interface with whatever other programs they need in whatever ways
they find necessary. runsv's will just keep services running
(or stopped, or one-shot, as ordered), they don't do anything else.

The situation looks like people who use procd so far don't see
any pressing need to run yet another service babysitting thing
on their boxes.

I have experience running boxes with runsv,
have no experience with procd, so can't really do a technical
comparison.

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Files across reboot are not persisiting

[Felix Fietkau]

On 2017-01-17 19:41, K.Mani wrote:
> When we create a file on the booted board and reboot the file
> doesn't persist.
> Environment:
> OpenWRT branch "Barrier Breaker" on Annapurna board, with
> ALpine-v1(soc) is having NOR flash(MX25U25635F) 32MB
The version you're asking about is not only old and obsolete, but it is
also apparently modified to support a SoC that stock OpenWrt does not
have any support for. We cannot help you with that.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] forum limitations

[Ted Hess]

On Tue, 2017-01-17 at 09:32 -0800, David Lang wrote:
> currently new users (for some definition of 'new', I have 63 posts starting 
> within a day or two of when the forum was created) are limited to 3 replies in
> a 
> topic.
> 
> This limit is really easy to hit in a technical discussion and is going to
> drive 
> people to create extra topics to work around the limitation.
> 
> 
> example error message via e-mail:
> 
> We're sorry, but your email message to 
> ["forum+reply-83162f79a9a8b8efaf1a2e8dae533...@lede-project.org"] (titled Re: 
> [LEDE Project
> Forum] [Installing and Using LEDE] Wlan 2.4/5Ghz to slow fpr 1080p/60fps?) 
> didn't work.
> 
> Reason:
> 
> We're sorry, but new users are temporarily limited to 3 replies in the same 
> topic.
> 
> If you can correct the problem, please try again.
> 
> 
> 
> David Lang
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Yes, we could increase that limit - However, do you need to add more than 3
replies in a row to a single topic before some else replies to it. You could
more easily just edit/append to one of your existing replies.

See discussion at: 

https://meta.discourse.org/t/why-is-there-a-topic-reply-limit-for-new-users/1151
3

/ted

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Making staging tree appear on cgit?

[Florian Fainelli]

Hi,

Are there specific instructions not currently documented at:
https://lede-project.org/docs/guide-developer/the-source-code

that are needed in order to make one's staging tree appear on cgit?

Thanks!
-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Files across reboot are not persisiting

[K.Mani]

When we create a file on the booted board and reboot the file
doesn't persist.
Environment:
OpenWRT branch "Barrier Breaker" on Annapurna board, with
ALpine-v1(soc) is having NOR flash(MX25U25635F) 32MB

I think mounting of rootfs_data type jffs2 is not happening in Preinit!



[  587.597297] m25p80 spi0.0: found mx25u25635f, expected
spi_flash_jedec_detection
[  587.604693] m25p80 spi0.0: mx25u25635f (32768 Kbytes)
[  587.609753] 5 ofpart partitions found on MTD device spi0.0
[  587.615233] Creating 5 MTD partitions on "spi0.0":
[  587.620016] 0x-0x0020 : "al_boot"
[  587.625421] 0x0020-0x0030 : "device_tree"
[  587.631148] 0x0030-0x00b0 : "Kernel"
[  587.636431] 0x00b0-0x01b0 : "rootfs"
[  587.641697] mtd: device 3 (rootfs) set to be root filesystem
[  587.647420] mtd: partition "rootfs_data" created automatically,
ofs=0xf5, len=0xbb
[  587.655672] 0x00f5-0x01b0 : "rootfs_data"
[  587.661381] 0x01b0-0x0200 : "storage"

.
.

[  588.517726] Freeing unused kernel memory: 10912K (c06af000 - c1157000)
procd: Console is alive
procd: - watchdog -
procd: - preinit -
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
procd: - early -
procd: - watchdog -
procd: - ubus -
procd: - init -
Please press Enter to activate this console.
[  593.780917] configured MAC to RGMII mode:
[  593.785404] al_eth :00:01.0 eth1: using MSI-X per Queue
interrupt mode
[  593.793270] libphy: al mdio bus: probed



Kernel command line: root=/dev/mtdblock3 rootfstype=squashfs,jffs2
noinitrd pci=pcie_bus_perf console=ttyS0,115200

df -h
FilesystemSize  Used Available Use% Mounted on
tmpfs   250.1M 48.0K250.0M   0% /tmp
tmpfs   512.0K 0512.0K   0% /dev

root@OpenWrt:/lib/modules/3.10.20# mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /dev type tmpfs (rw,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)


root@OpenWrt:/lib/modules/3.10.20# free
 total used free   shared  buffers
Mem:51218067192   44498800
-/+ buffers:  67192   444988
Swap:000


root@OpenWrt:/lib/modules/3.10.20# cat /proc/mtd
dev:size   erasesize  name
mtd0: 0020 0001 "al_boot"
mtd1: 0010 0001 "device_tree"
mtd2: 0080 0001 "Kernel"
mtd3: 0100 0001 "rootfs"
mtd4: 00bb 0001 "rootfs_data"
mtd5: 0050 0001 "storage"


Can someone guide me.

Thanks
Mani

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Syslog-ng Makefile typo

[Philip Prindeville]

Actually, I take that back.

Milan, can you please update the top line of files/syslog-ng.conf also?  It 
needs to read “3.9” instead (assuming there aren’t any syntactic constructs in 
that file that are now deprecated from 3.8 to 3.9… if there were, the file 
would need to be updated as well… like when the log_prefix() filter criteria 
got replaced by program()).

Thanks


> On Jan 16, 2017, at 1:45 PM, Philip Prindeville 
>  wrote:
> 
> Looks good to me.
> 
> 
>> On Jan 16, 2017, at 4:24 AM, Milan Kočvara  wrote:
>> 
>> Hello.
>> I found typo in syslog-ng makefile.
>> 
>> I've upgraded to the newest version and I've made correction of the typo. 
>> Patch bellow.
>> 
>> Sorry for bad format of everything. I did it never :)
>> 
>> --- Makefile-orig   2017-01-16 12:06:44.367684776 +0100
>> +++ Makefile~   2017-01-16 12:22:47.198478933 +0100
>> @@ -1,14 +1,14 @@
>> include  $(TOPDIR)/rules.mk
>> 
>> PKG_NAME:=syslog-ng
>> -PKG_VERSION:=3.8.1
>> -PKG_RELEASE:=3
>> +PKG_VERSION:=3.9.1
>> +PKG_RELEASE:=1
>> 
>> PKG_MAINTAINER:=W. Michael Petullo 
>> 
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>> PKG_SOURCE_URL:=https://github.com/balabit/syslog-ng/releases/download/$(PKG_NAME)-$(PKG_VERSION)/
>> -PKG_MD5SUM:=acf14563cf5ce435db8db35486ce66af
>> +PKG_MD5SUM:=1b48da9ef620cf06e55e481b5abb677a
>> 
>> PKG_INSTALL:=1
>> 
>> @@ -41,7 +41,7 @@
>> CONFIGURE_ARGS += \
>>  $(call autoconf_bool,CONFIG_IPV6,ipv6) \
>> --disable-dependency-tracking \
>> - --disable-ampq \
>> + --disable-amqp \
>> --disable-tcp-wrapper \
>> --disable-glibtest \
>> --disable-mongodb \
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

[Felix Fietkau]

On 2017-01-17 19:29, Chris Blake wrote:
> Felix,
> 
> I have been working on moving the LED driver to a package, but have
> some concerns about implementation. Specifically, this would hit the
> same issue I had with the Meraki MR18 LED Driver (NU801) around having
> the LEDs/Reset button available during boot. Specifically, this is a
> concern as the reset button will be unusable for failsafe mode and the
> LEDs will fail to show boot status once system integration [0] is
> cleaned up and sent as a later PR.
> 
> I was curious if you had any feedback, or ideas to get around this. As
> for the other GPIO driver, that should have no issues being packaged.
You can set the AUTOLOAD line like this:
AUTOLOAD:=$(call AutoLoad,41,leds-apu2,1)

The ",1" at the end will cause the module load line to be added to
/etc/modules-boot.d, which gets processed before preinit, so it works
with failsafe as well.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

[Chris Blake]

On Sat, Jan 14, 2017 at 11:13 AM, Felix Fietkau  wrote:
> On 2017-01-14 18:04, Chris Blake wrote:
>> On Sat, Jan 14, 2017 at 10:41 AM, Chris Blake  
>> wrote:
>>> On Sat, Jan 14, 2017 at 10:31 AM, Felix Fietkau  wrote:
 On 2017-01-14 17:20, Chris Blake wrote:
> The following patch adds LED support for the PC Engines APU2/APU3 board
> on LEDE.
>
> Signed-off-by: Chris Blake 
 Has this driver been submitted for upstream inclusion yet?

 - Felix

>>>
>>> Felix,
>>>
>>> This driver has not been submitted upstream to the Linux mailing list
>>> at this time.
>>>
>>> - Chris B
>>
>> Felix,
>>
>> In regards to upstream it seems this driver in particular, APU2 LED,
>> was submitted upstream at https://patches.linaro.org/patch/80049/
>> previously. While this version of the driver varies slightly (better
>> platform detection), would you still prefer this to be re-submitted in
>> package form? Due to the platform specific code I doubt it would have
>> much luck in the upstream lists.
> Yes, since there doesn't seem to be any progress towards getting this
> merged, please re-submit it in package form.
>
> Thanks,
>
> - Felix
>

Felix,

I have been working on moving the LED driver to a package, but have
some concerns about implementation. Specifically, this would hit the
same issue I had with the Meraki MR18 LED Driver (NU801) around having
the LEDs/Reset button available during boot. Specifically, this is a
concern as the reset button will be unusable for failsafe mode and the
LEDs will fail to show boot status once system integration [0] is
cleaned up and sent as a later PR.

I was curious if you had any feedback, or ideas to get around this. As
for the other GPIO driver, that should have no issues being packaged.

Regards,
Chris B

[0]: http://lists.infradead.org/pipermail/lede-dev/2016-October/003535.html

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] forum limitations

[David Lang]

currently new users (for some definition of 'new', I have 63 posts starting 
within a day or two of when the forum was created) are limited to 3 replies in a 
topic.


This limit is really easy to hit in a technical discussion and is going to drive 
people to create extra topics to work around the limitation.



example error message via e-mail:

We're sorry, but your email message to 
["forum+reply-83162f79a9a8b8efaf1a2e8dae533...@lede-project.org"] (titled Re: 
[LEDE Project
Forum] [Installing and Using LEDE] Wlan 2.4/5Ghz to slow fpr 1080p/60fps?) 
didn't work.


Reason:

We're sorry, but new users are temporarily limited to 3 replies in the same 
topic.


If you can correct the problem, please try again.



David Lang

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH netifd] interface-ip: route proto config support (FS#170)

[Hans Dedecker]

On Tue, Jan 17, 2017 at 5:00 PM, Dave Täht  wrote:
> Thank you Hans, this made my day.
>
> On 1/17/17 6:34 AM, Toke Høiland-Jørgensen wrote:
>> Hans Dedecker  writes:
>>
>>> Route proto support is usefull when using route distribution
>>> via a routing daemon.
>>> The route proto parameter can be specified via the route proto
>>> uci config parameter and can hold the string values redirect,
>>> kernel, static, gated, ra, mrt, zebra, bind, dnrouted, xorp,
>>> ntk, dhcp, mrouted, babel or a numerical value
>>>
>>> Signed-off-by: Hans Dedecker 
>>> ---
>>>  interface-ip.c | 21 +
>>>  interface-ip.h |  5 +++--
>>>  system-dummy.c |  6 ++
>>>  system-linux.c | 52 +++-
>>>  system.h   |  1 +
>>>  ubus.c |  3 +++
>>>  6 files changed, 81 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/interface-ip.c b/interface-ip.c
>>> index 24ea054..f8dab84 100644
>>> --- a/interface-ip.c
>>> +++ b/interface-ip.c
>>> @@ -40,6 +40,7 @@ enum {
>>>  ROUTE_SOURCE,
>>>  ROUTE_ONLINK,
>>>  ROUTE_TYPE,
>>> +ROUTE_PROTO,
>>>  __ROUTE_MAX
>>>  };
>>>
>>> @@ -54,7 +55,8 @@ static const struct blobmsg_policy 
>>> route_attr[__ROUTE_MAX] = {
>>>  [ROUTE_VALID] = { .name = "valid", .type = BLOBMSG_TYPE_INT32 },
>>>  [ROUTE_SOURCE] = { .name = "source", .type = BLOBMSG_TYPE_STRING },
>>>  [ROUTE_ONLINK] = { .name = "onlink", .type = BLOBMSG_TYPE_BOOL },
>>> -[ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING }
>>> +[ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING },
>>> +[ROUTE_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
>>>  };
>>>
>>>  const struct uci_blob_param_list route_attr_list = {
>>> @@ -405,6 +407,14 @@ interface_ip_add_route(struct interface *iface, struct 
>>> blob_attr *attr, bool v6)
>>>  route->flags |= DEVROUTE_TYPE;
>>>  }
>>>
>>> +if ((cur = tb[ROUTE_PROTO]) != NULL) {
>>> +if (!system_resolve_rt_proto(blobmsg_data(cur), 
>>> >proto)) {
>>> +DPRINTF("Failed to resolve proto type: %s\n", (char *) 
>>> blobmsg_data(cur));
>>> +goto error;
>>> +}
>>> +route->flags |= DEVROUTE_PROTO;
>>> +}
>>> +
>>>  interface_set_route_info(iface, route);
>>>  vlist_add(>route, >node, route);
>>>  return;
>>> @@ -478,10 +488,13 @@ interface_handle_subnet_route(struct interface 
>>> *iface, struct device_addr *addr,
>>>  memcpy(>addr, >addr, sizeof(r->addr));
>>>  clear_if_addr(>addr, r->mask);
>>>
>>> -r->flags |= DEVADDR_KERNEL;
>>> +if (!system_resolve_rt_proto("kernel", >proto))
>>> +return;
>>> +
>>> +r->flags |= DEVROUTE_PROTO;
>>>  system_del_route(dev, r);
>>>
>>> -r->flags &= ~DEVADDR_KERNEL;
>>> +r->flags &= ~DEVROUTE_PROTO;
>>>  interface_set_route_info(iface, r);
>>>
>>>  system_add_route(dev, r);
>>> @@ -634,7 +647,7 @@ interface_update_proto_route(struct vlist_tree *tree,
>>>  if (node_old && node_new)
>>>  keep = !memcmp(_old->nexthop, _new->nexthop, 
>>> sizeof(route_old->nexthop)) &&
>>>  (route_old->mtu == route_new->mtu) && (route_old->type 
>>> == route_new->type) &&
>>> -!route_old->failed;
>>> +(route_old->proto == route_new->proto) && 
>>> !route_old->failed;
>>>
>>>  if (node_old) {
>>>  if (!(route_old->flags & DEVADDR_EXTERNAL) && 
>>> route_old->enabled && !keep)
>>> diff --git a/interface-ip.h b/interface-ip.h
>>> index bbef62c..01727c9 100644
>>> --- a/interface-ip.h
>>> +++ b/interface-ip.h
>>> @@ -31,8 +31,8 @@ enum device_addr_flags {
>>>  /* route overrides the default interface mtu */
>>>  DEVROUTE_MTU= (1 << 4),
>>>
>>> -/* route automatically added by kernel */
>>> -DEVADDR_KERNEL  = (1 << 5),
>>> +/* route overrides the default proto type */
>>> +DEVROUTE_PROTO  = (1 << 5),
>>>
>>>  /* address is off-link (no subnet-route) */
>>>  DEVADDR_OFFLINK = (1 << 6),
>>> @@ -92,6 +92,7 @@ struct device_route {
>>>  union if_addr nexthop;
>>>  int mtu;
>>>  unsigned int type;
>>> +unsigned int proto;
>>>  time_t valid_until;
>>>
>>>  /* must be last */
>>> diff --git a/system-dummy.c b/system-dummy.c
>>> index 9c734ea..2ea25ac 100644
>>> --- a/system-dummy.c
>>> +++ b/system-dummy.c
>>> @@ -202,6 +202,12 @@ bool system_resolve_rt_type(const char *type, unsigned 
>>> int *id)
>>>  return true;
>>>  }
>>>
>>> +bool system_resolve_rt_proto(const char *type, unsigned int *id)
>>> +{
>>> +*id = 0;
>>> +return true;
>>> +}
>>> +
>>>  bool system_resolve_rt_table(const char *name, unsigned int *id)
>>>  {
>>>  *id = 0;
>>> diff --git a/system-linux.c b/system-linux.c
>>> index 2f15bf1..6e92685 100644
>>> --- a/system-linux.c
>>> +++ 

Re: [LEDE-DEV] [PATCH netifd] interface-ip: route proto config support (FS#170)

[Dave Täht]

Thank you Hans, this made my day.

On 1/17/17 6:34 AM, Toke Høiland-Jørgensen wrote:
> Hans Dedecker  writes:
> 
>> Route proto support is usefull when using route distribution
>> via a routing daemon.
>> The route proto parameter can be specified via the route proto
>> uci config parameter and can hold the string values redirect,
>> kernel, static, gated, ra, mrt, zebra, bind, dnrouted, xorp,
>> ntk, dhcp, mrouted, babel or a numerical value
>>
>> Signed-off-by: Hans Dedecker 
>> ---
>>  interface-ip.c | 21 +
>>  interface-ip.h |  5 +++--
>>  system-dummy.c |  6 ++
>>  system-linux.c | 52 +++-
>>  system.h   |  1 +
>>  ubus.c |  3 +++
>>  6 files changed, 81 insertions(+), 7 deletions(-)
>>
>> diff --git a/interface-ip.c b/interface-ip.c
>> index 24ea054..f8dab84 100644
>> --- a/interface-ip.c
>> +++ b/interface-ip.c
>> @@ -40,6 +40,7 @@ enum {
>>  ROUTE_SOURCE,
>>  ROUTE_ONLINK,
>>  ROUTE_TYPE,
>> +ROUTE_PROTO,
>>  __ROUTE_MAX
>>  };
>>
>> @@ -54,7 +55,8 @@ static const struct blobmsg_policy route_attr[__ROUTE_MAX] 
>> = {
>>  [ROUTE_VALID] = { .name = "valid", .type = BLOBMSG_TYPE_INT32 },
>>  [ROUTE_SOURCE] = { .name = "source", .type = BLOBMSG_TYPE_STRING },
>>  [ROUTE_ONLINK] = { .name = "onlink", .type = BLOBMSG_TYPE_BOOL },
>> -[ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING }
>> +[ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING },
>> +[ROUTE_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
>>  };
>>
>>  const struct uci_blob_param_list route_attr_list = {
>> @@ -405,6 +407,14 @@ interface_ip_add_route(struct interface *iface, struct 
>> blob_attr *attr, bool v6)
>>  route->flags |= DEVROUTE_TYPE;
>>  }
>>
>> +if ((cur = tb[ROUTE_PROTO]) != NULL) {
>> +if (!system_resolve_rt_proto(blobmsg_data(cur), >proto)) 
>> {
>> +DPRINTF("Failed to resolve proto type: %s\n", (char *) 
>> blobmsg_data(cur));
>> +goto error;
>> +}
>> +route->flags |= DEVROUTE_PROTO;
>> +}
>> +
>>  interface_set_route_info(iface, route);
>>  vlist_add(>route, >node, route);
>>  return;
>> @@ -478,10 +488,13 @@ interface_handle_subnet_route(struct interface *iface, 
>> struct device_addr *addr,
>>  memcpy(>addr, >addr, sizeof(r->addr));
>>  clear_if_addr(>addr, r->mask);
>>
>> -r->flags |= DEVADDR_KERNEL;
>> +if (!system_resolve_rt_proto("kernel", >proto))
>> +return;
>> +
>> +r->flags |= DEVROUTE_PROTO;
>>  system_del_route(dev, r);
>>
>> -r->flags &= ~DEVADDR_KERNEL;
>> +r->flags &= ~DEVROUTE_PROTO;
>>  interface_set_route_info(iface, r);
>>
>>  system_add_route(dev, r);
>> @@ -634,7 +647,7 @@ interface_update_proto_route(struct vlist_tree *tree,
>>  if (node_old && node_new)
>>  keep = !memcmp(_old->nexthop, _new->nexthop, 
>> sizeof(route_old->nexthop)) &&
>>  (route_old->mtu == route_new->mtu) && (route_old->type 
>> == route_new->type) &&
>> -!route_old->failed;
>> +(route_old->proto == route_new->proto) && 
>> !route_old->failed;
>>
>>  if (node_old) {
>>  if (!(route_old->flags & DEVADDR_EXTERNAL) && 
>> route_old->enabled && !keep)
>> diff --git a/interface-ip.h b/interface-ip.h
>> index bbef62c..01727c9 100644
>> --- a/interface-ip.h
>> +++ b/interface-ip.h
>> @@ -31,8 +31,8 @@ enum device_addr_flags {
>>  /* route overrides the default interface mtu */
>>  DEVROUTE_MTU= (1 << 4),
>>
>> -/* route automatically added by kernel */
>> -DEVADDR_KERNEL  = (1 << 5),
>> +/* route overrides the default proto type */
>> +DEVROUTE_PROTO  = (1 << 5),
>>
>>  /* address is off-link (no subnet-route) */
>>  DEVADDR_OFFLINK = (1 << 6),
>> @@ -92,6 +92,7 @@ struct device_route {
>>  union if_addr nexthop;
>>  int mtu;
>>  unsigned int type;
>> +unsigned int proto;
>>  time_t valid_until;
>>
>>  /* must be last */
>> diff --git a/system-dummy.c b/system-dummy.c
>> index 9c734ea..2ea25ac 100644
>> --- a/system-dummy.c
>> +++ b/system-dummy.c
>> @@ -202,6 +202,12 @@ bool system_resolve_rt_type(const char *type, unsigned 
>> int *id)
>>  return true;
>>  }
>>
>> +bool system_resolve_rt_proto(const char *type, unsigned int *id)
>> +{
>> +*id = 0;
>> +return true;
>> +}
>> +
>>  bool system_resolve_rt_table(const char *name, unsigned int *id)
>>  {
>>  *id = 0;
>> diff --git a/system-linux.c b/system-linux.c
>> index 2f15bf1..6e92685 100644
>> --- a/system-linux.c
>> +++ b/system-linux.c
>> @@ -52,6 +52,13 @@
>>  #define IFA_FLAGS (IFA_MULTICAST + 1)
>>  #endif
>>
>> +#ifndef RTPROT_MROUTED
>> +#define RTPROT_MROUTED 17
>> +#endif
>> +
>> +#ifndef RTPROT_BABEL
>> +#define RTPROT_BABEL 

[LEDE-DEV] [PATCH] netifd: Add option to configure locktime for each device

[Alin Nastac]

The UCI parameter neighlocktime allows to control the hardware
address to IP mapping lock time in the IPv4 neighbour table.

The IPv6 lock time was not set because it is not used at all in any
kernel versions, hardware address override being controlled in this case
by the override flag present in the NA packet.

Signed-off-by: Alin Nastac 
---
 device.c   | 10 ++
 device.h   |  3 +++
 system-linux.c | 20 
 3 files changed, 33 insertions(+)

diff --git a/device.c b/device.c
index 43881e5..306496c 100644
--- a/device.c
+++ b/device.c
@@ -59,6 +59,7 @@ static const struct blobmsg_policy dev_attrs[__DEV_ATTR_MAX] 
= {
[DEV_ATTR_LEARNING] = { .name ="learning", .type = BLOBMSG_TYPE_BOOL },
[DEV_ATTR_UNICAST_FLOOD] = { .name ="unicast_flood", .type = 
BLOBMSG_TYPE_BOOL },
[DEV_ATTR_SENDREDIRECTS] = { .name = "sendredirects", .type = 
BLOBMSG_TYPE_BOOL },
+   [DEV_ATTR_NEIGHLOCKTIME] = { .name = "neighlocktime", .type = 
BLOBMSG_TYPE_INT32 },
 };
 
 const struct uci_blob_param_list device_attr_list = {
@@ -217,6 +218,8 @@ device_merge_settings(struct device *dev, struct 
device_settings *n)
s->neigh4gcstaletime : os->neigh4gcstaletime;
n->neigh6gcstaletime = s->flags & DEV_OPT_NEIGHGCSTALETIME ?
s->neigh6gcstaletime : os->neigh6gcstaletime;
+   n->neigh4locktime = s->flags & DEV_OPT_NEIGHLOCKTIME ?
+   s->neigh4locktime : os->neigh4locktime;
n->dadtransmits = s->flags & DEV_OPT_DADTRANSMITS ?
s->dadtransmits : os->dadtransmits;
n->multicast = s->flags & DEV_OPT_MULTICAST ?
@@ -314,6 +317,11 @@ device_init_settings(struct device *dev, struct blob_attr 
**tb)
s->flags |= DEV_OPT_NEIGHGCSTALETIME;
}
 
+   if ((cur = tb[DEV_ATTR_NEIGHLOCKTIME])) {
+   s->neigh4locktime = blobmsg_get_u32(cur);
+   s->flags |= DEV_OPT_NEIGHLOCKTIME;
+   }
+
if ((cur = tb[DEV_ATTR_RPS])) {
s->rps = blobmsg_get_bool(cur);
s->flags |= DEV_OPT_RPS;
@@ -1044,6 +1052,8 @@ device_dump_status(struct blob_buf *b, struct device *dev)
blobmsg_add_u32(b, "neigh4gcstaletime", 
st.neigh4gcstaletime);
blobmsg_add_u32(b, "neigh6gcstaletime", 
st.neigh6gcstaletime);
}
+   if (st.flags & DEV_OPT_NEIGHLOCKTIME)
+   blobmsg_add_u32(b, "neigh4locktime", st.neigh4locktime);
if (st.flags & DEV_OPT_DADTRANSMITS)
blobmsg_add_u32(b, "dadtransmits", st.dadtransmits);
if (st.flags & DEV_OPT_MULTICAST_TO_UNICAST)
diff --git a/device.h b/device.h
index 87236d4..feb865f 100644
--- a/device.h
+++ b/device.h
@@ -51,6 +51,7 @@ enum {
DEV_ATTR_UNICAST_FLOOD,
DEV_ATTR_NEIGHGCSTALETIME,
DEV_ATTR_SENDREDIRECTS,
+   DEV_ATTR_NEIGHLOCKTIME,
__DEV_ATTR_MAX,
 };
 
@@ -103,6 +104,7 @@ enum {
DEV_OPT_NEIGHGCSTALETIME= (1 << 19),
DEV_OPT_MULTICAST_FAST_LEAVE= (1 << 20),
DEV_OPT_SENDREDIRECTS   = (1 << 21),
+   DEV_OPT_NEIGHLOCKTIME   = (1 << 22),
 };
 
 /* events broadcasted to all users of a device */
@@ -160,6 +162,7 @@ struct device_settings {
unsigned int neigh6reachabletime;
unsigned int neigh4gcstaletime;
unsigned int neigh6gcstaletime;
+   unsigned int neigh4locktime;
bool rps;
bool xps;
unsigned int dadtransmits;
diff --git a/system-linux.c b/system-linux.c
index 2f15bf1..a77ff5f 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -316,6 +316,11 @@ static void system_set_neigh6gcstaletime(struct device 
*dev, const char *val)
system_set_dev_sysctl("/proc/sys/net/ipv6/neigh/%s/gc_stale_time", 
dev->ifname, val);
 }
 
+static void system_set_neigh4locktime(struct device *dev, const char *val)
+{
+   system_set_dev_sysctl("/proc/sys/net/ipv4/neigh/%s/locktime", 
dev->ifname, val);
+}
+
 static void system_set_dadtransmits(struct device *dev, const char *val)
 {
system_set_dev_sysctl("/proc/sys/net/ipv6/conf/%s/dad_transmits", 
dev->ifname, val);
@@ -484,6 +489,12 @@ static int system_get_neigh6gcstaletime(struct device 
*dev, char *buf, const siz
dev->ifname, buf, buf_sz);
 }
 
+static int system_get_neigh4locktime(struct device *dev, char *buf, const 
size_t buf_sz)
+{
+   return system_get_dev_sysctl("/proc/sys/net/ipv4/neigh/%s/locktime",
+   dev->ifname, buf, buf_sz);
+}
+
 static int system_get_dadtransmits(struct device *dev, char *buf, const size_t 
buf_sz)
 {
return system_get_dev_sysctl("/proc/sys/net/ipv6/conf/%s/dad_transmits",
@@ -1285,6 +1296,11 @@ system_if_get_settings(struct device *dev, struct 
device_settings *s)
s->flags |= DEV_OPT_NEIGHREACHABLETIME;
}
 
+   if (!system_get_neigh4locktime(dev, 

Re: [LEDE-DEV] [PATCH netifd] interface-ip: route proto config support (FS#170)

[Toke Høiland-Jørgensen]

Hans Dedecker  writes:

> Route proto support is usefull when using route distribution
> via a routing daemon.
> The route proto parameter can be specified via the route proto
> uci config parameter and can hold the string values redirect,
> kernel, static, gated, ra, mrt, zebra, bind, dnrouted, xorp,
> ntk, dhcp, mrouted, babel or a numerical value
>
> Signed-off-by: Hans Dedecker 
> ---
>  interface-ip.c | 21 +
>  interface-ip.h |  5 +++--
>  system-dummy.c |  6 ++
>  system-linux.c | 52 +++-
>  system.h   |  1 +
>  ubus.c |  3 +++
>  6 files changed, 81 insertions(+), 7 deletions(-)
>
> diff --git a/interface-ip.c b/interface-ip.c
> index 24ea054..f8dab84 100644
> --- a/interface-ip.c
> +++ b/interface-ip.c
> @@ -40,6 +40,7 @@ enum {
>   ROUTE_SOURCE,
>   ROUTE_ONLINK,
>   ROUTE_TYPE,
> + ROUTE_PROTO,
>   __ROUTE_MAX
>  };
>
> @@ -54,7 +55,8 @@ static const struct blobmsg_policy route_attr[__ROUTE_MAX] 
> = {
>   [ROUTE_VALID] = { .name = "valid", .type = BLOBMSG_TYPE_INT32 },
>   [ROUTE_SOURCE] = { .name = "source", .type = BLOBMSG_TYPE_STRING },
>   [ROUTE_ONLINK] = { .name = "onlink", .type = BLOBMSG_TYPE_BOOL },
> - [ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING }
> + [ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING },
> + [ROUTE_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
>  };
>
>  const struct uci_blob_param_list route_attr_list = {
> @@ -405,6 +407,14 @@ interface_ip_add_route(struct interface *iface, struct 
> blob_attr *attr, bool v6)
>   route->flags |= DEVROUTE_TYPE;
>   }
>
> + if ((cur = tb[ROUTE_PROTO]) != NULL) {
> + if (!system_resolve_rt_proto(blobmsg_data(cur), >proto)) 
> {
> + DPRINTF("Failed to resolve proto type: %s\n", (char *) 
> blobmsg_data(cur));
> + goto error;
> + }
> + route->flags |= DEVROUTE_PROTO;
> + }
> +
>   interface_set_route_info(iface, route);
>   vlist_add(>route, >node, route);
>   return;
> @@ -478,10 +488,13 @@ interface_handle_subnet_route(struct interface *iface, 
> struct device_addr *addr,
>   memcpy(>addr, >addr, sizeof(r->addr));
>   clear_if_addr(>addr, r->mask);
>
> - r->flags |= DEVADDR_KERNEL;
> + if (!system_resolve_rt_proto("kernel", >proto))
> + return;
> +
> + r->flags |= DEVROUTE_PROTO;
>   system_del_route(dev, r);
>
> - r->flags &= ~DEVADDR_KERNEL;
> + r->flags &= ~DEVROUTE_PROTO;
>   interface_set_route_info(iface, r);
>
>   system_add_route(dev, r);
> @@ -634,7 +647,7 @@ interface_update_proto_route(struct vlist_tree *tree,
>   if (node_old && node_new)
>   keep = !memcmp(_old->nexthop, _new->nexthop, 
> sizeof(route_old->nexthop)) &&
>   (route_old->mtu == route_new->mtu) && (route_old->type 
> == route_new->type) &&
> - !route_old->failed;
> + (route_old->proto == route_new->proto) && 
> !route_old->failed;
>
>   if (node_old) {
>   if (!(route_old->flags & DEVADDR_EXTERNAL) && 
> route_old->enabled && !keep)
> diff --git a/interface-ip.h b/interface-ip.h
> index bbef62c..01727c9 100644
> --- a/interface-ip.h
> +++ b/interface-ip.h
> @@ -31,8 +31,8 @@ enum device_addr_flags {
>   /* route overrides the default interface mtu */
>   DEVROUTE_MTU= (1 << 4),
>
> - /* route automatically added by kernel */
> - DEVADDR_KERNEL  = (1 << 5),
> + /* route overrides the default proto type */
> + DEVROUTE_PROTO  = (1 << 5),
>
>   /* address is off-link (no subnet-route) */
>   DEVADDR_OFFLINK = (1 << 6),
> @@ -92,6 +92,7 @@ struct device_route {
>   union if_addr nexthop;
>   int mtu;
>   unsigned int type;
> + unsigned int proto;
>   time_t valid_until;
>
>   /* must be last */
> diff --git a/system-dummy.c b/system-dummy.c
> index 9c734ea..2ea25ac 100644
> --- a/system-dummy.c
> +++ b/system-dummy.c
> @@ -202,6 +202,12 @@ bool system_resolve_rt_type(const char *type, unsigned 
> int *id)
>   return true;
>  }
>
> +bool system_resolve_rt_proto(const char *type, unsigned int *id)
> +{
> + *id = 0;
> + return true;
> +}
> +
>  bool system_resolve_rt_table(const char *name, unsigned int *id)
>  {
>   *id = 0;
> diff --git a/system-linux.c b/system-linux.c
> index 2f15bf1..6e92685 100644
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -52,6 +52,13 @@
>  #define IFA_FLAGS (IFA_MULTICAST + 1)
>  #endif
>
> +#ifndef RTPROT_MROUTED
> +#define RTPROT_MROUTED 17
> +#endif
> +
> +#ifndef RTPROT_BABEL
> +#define RTPROT_BABEL 42
> +#endif
>
>  #include 
>  #include 
> @@ -1782,7 +1789,7 @@ static int system_rt(struct device *dev, struct 
> device_route *route, int cmd)
>   

Re: [LEDE-DEV] LEDE 17.01 branched

[Rich Brown]

> On Jan 16, 2017, at 1:37 PM, Jo-Philipp Wich  wrote:
> 
> this is just a heads-up to inform you that LEDE master has been branched
> into a new branch "lede-17.01" now.

And a hearty congratulations to everyone who helped get us this far. Thanks!

I haven't seen these discussed anywhere, but I think there is a (parallel) 
effort that gains some urgency now that we're coming down to having our 
long-standing vision actually come to fruition:

1) Has anyone been thinking about publicity for the release candidates and 
final? I envision an expanding circle of announcements for our release 
candidates: First to lede-dev and the forum. Later an announcement on the 
OpenWrt forum. And who's going to write the announcement for Slashdot? Do we 
need to buy another server first? :-) 

2) I created a draft (skeleton) for the Release Notes on the web site at: 
https://lede-project.org/playground/draft-release-notes Please look it over and 
add items that should be mentioned. Thanks again.

Rich

PS Kudo's to hauke who found my (up-to-now) secret page and already started 
filling it in!
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH netifd] interface-ip: route proto config support (FS#170)

[Hans Dedecker]

Route proto support is usefull when using route distribution
via a routing daemon.
The route proto parameter can be specified via the route proto
uci config parameter and can hold the string values redirect,
kernel, static, gated, ra, mrt, zebra, bind, dnrouted, xorp,
ntk, dhcp, mrouted, babel or a numerical value

Signed-off-by: Hans Dedecker 
---
 interface-ip.c | 21 +
 interface-ip.h |  5 +++--
 system-dummy.c |  6 ++
 system-linux.c | 52 +++-
 system.h   |  1 +
 ubus.c |  3 +++
 6 files changed, 81 insertions(+), 7 deletions(-)

diff --git a/interface-ip.c b/interface-ip.c
index 24ea054..f8dab84 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -40,6 +40,7 @@ enum {
ROUTE_SOURCE,
ROUTE_ONLINK,
ROUTE_TYPE,
+   ROUTE_PROTO,
__ROUTE_MAX
 };
 
@@ -54,7 +55,8 @@ static const struct blobmsg_policy route_attr[__ROUTE_MAX] = {
[ROUTE_VALID] = { .name = "valid", .type = BLOBMSG_TYPE_INT32 },
[ROUTE_SOURCE] = { .name = "source", .type = BLOBMSG_TYPE_STRING },
[ROUTE_ONLINK] = { .name = "onlink", .type = BLOBMSG_TYPE_BOOL },
-   [ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING }
+   [ROUTE_TYPE] = { .name = "type", .type = BLOBMSG_TYPE_STRING },
+   [ROUTE_PROTO] = { .name = "proto", .type = BLOBMSG_TYPE_STRING },
 };
 
 const struct uci_blob_param_list route_attr_list = {
@@ -405,6 +407,14 @@ interface_ip_add_route(struct interface *iface, struct 
blob_attr *attr, bool v6)
route->flags |= DEVROUTE_TYPE;
}
 
+   if ((cur = tb[ROUTE_PROTO]) != NULL) {
+   if (!system_resolve_rt_proto(blobmsg_data(cur), >proto)) 
{
+   DPRINTF("Failed to resolve proto type: %s\n", (char *) 
blobmsg_data(cur));
+   goto error;
+   }
+   route->flags |= DEVROUTE_PROTO;
+   }
+
interface_set_route_info(iface, route);
vlist_add(>route, >node, route);
return;
@@ -478,10 +488,13 @@ interface_handle_subnet_route(struct interface *iface, 
struct device_addr *addr,
memcpy(>addr, >addr, sizeof(r->addr));
clear_if_addr(>addr, r->mask);
 
-   r->flags |= DEVADDR_KERNEL;
+   if (!system_resolve_rt_proto("kernel", >proto))
+   return;
+
+   r->flags |= DEVROUTE_PROTO;
system_del_route(dev, r);
 
-   r->flags &= ~DEVADDR_KERNEL;
+   r->flags &= ~DEVROUTE_PROTO;
interface_set_route_info(iface, r);
 
system_add_route(dev, r);
@@ -634,7 +647,7 @@ interface_update_proto_route(struct vlist_tree *tree,
if (node_old && node_new)
keep = !memcmp(_old->nexthop, _new->nexthop, 
sizeof(route_old->nexthop)) &&
(route_old->mtu == route_new->mtu) && (route_old->type 
== route_new->type) &&
-   !route_old->failed;
+   (route_old->proto == route_new->proto) && 
!route_old->failed;
 
if (node_old) {
if (!(route_old->flags & DEVADDR_EXTERNAL) && 
route_old->enabled && !keep)
diff --git a/interface-ip.h b/interface-ip.h
index bbef62c..01727c9 100644
--- a/interface-ip.h
+++ b/interface-ip.h
@@ -31,8 +31,8 @@ enum device_addr_flags {
/* route overrides the default interface mtu */
DEVROUTE_MTU= (1 << 4),
 
-   /* route automatically added by kernel */
-   DEVADDR_KERNEL  = (1 << 5),
+   /* route overrides the default proto type */
+   DEVROUTE_PROTO  = (1 << 5),
 
/* address is off-link (no subnet-route) */
DEVADDR_OFFLINK = (1 << 6),
@@ -92,6 +92,7 @@ struct device_route {
union if_addr nexthop;
int mtu;
unsigned int type;
+   unsigned int proto;
time_t valid_until;
 
/* must be last */
diff --git a/system-dummy.c b/system-dummy.c
index 9c734ea..2ea25ac 100644
--- a/system-dummy.c
+++ b/system-dummy.c
@@ -202,6 +202,12 @@ bool system_resolve_rt_type(const char *type, unsigned int 
*id)
return true;
 }
 
+bool system_resolve_rt_proto(const char *type, unsigned int *id)
+{
+   *id = 0;
+   return true;
+}
+
 bool system_resolve_rt_table(const char *name, unsigned int *id)
 {
*id = 0;
diff --git a/system-linux.c b/system-linux.c
index 2f15bf1..6e92685 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -52,6 +52,13 @@
 #define IFA_FLAGS (IFA_MULTICAST + 1)
 #endif
 
+#ifndef RTPROT_MROUTED
+#define RTPROT_MROUTED 17
+#endif
+
+#ifndef RTPROT_BABEL
+#define RTPROT_BABEL 42
+#endif
 
 #include 
 #include 
@@ -1782,7 +1789,7 @@ static int system_rt(struct device *dev, struct 
device_route *route, int cmd)
.rtm_dst_len = route->mask,
.rtm_src_len = route->sourcemask,
.rtm_table = (table < 256) ? table : RT_TABLE_UNSPEC,
-   .rtm_protocol = (route->flags & 

Re: [LEDE-DEV] [PATCH v2 09/14] rt2x00: rt2x00pci: set PCI MWI only if supported

[Daniel Golle]

Hi John,

On Tue, Jan 17, 2017 at 08:34:44AM +0100, John Crispin wrote:
> here is the original thread related to this patch
> 
> http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-November/012227.html

nah, that was me apparently trying to submit this upstream once before
a couple of years ago.
the patch was added by claudio in
https://dev.openwrt.org/changeset/21850
supposedly to fix a build error on kernel 2.6.30
https://dev.openwrt.org/ticket/6538

as the config symbol is undefined in current kernels, I reckon we just
always had MWI disabled from some point on...
Back then RT2X00_LIB_SOC and RT2X00_LIB_MMIO still depended on
RT2X00_LIB_PCI which is no longer the case, ie. everything should be
fine without that ancient even on non-PCI platforms (on which the build
error initially triggered -- rt305x doesn't have PCI at all)
So let's remove it and find out :)


Cheers


Daniel

> 
>   John
> 
> > Cheers
> > 
> > 
> > Daniel
> > 
> >>
> >> Stanislaw

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] cns3xxx: restore mpcore watchdog

[Koen Vandeputte]

Hi Tim,


Koen,

Thanks for submitting this - I agree with Felix that we should add
back the functionality if possible.

The issue mentioned in the commit which removed the driver from
mainline linux [1] regarding 'Nothing ensures the userspace ioctl()
will end-up kicking the watchdog on the right CPU.' is addressed by
the fact that the watchdog register base defined in laguna.c [2] as
the register 'CNS3XXX_TC11MP_TWD_BASE + 0x100' always points to the
CPU0 watchdog as opposed to CNS3XXX_TC11MP_TWD_BASE which would be
aliased to the watchdog of whatever CPU core the process is running.
However, I found after a bit of digging I found that this mainline
driver requires other patches to make the watchdog reliable which
apparently never got accepted upstream [3] [4] [5] [6]. While these
patches were apparently never accepted upstream they were in the
OpenWrt git repo for the 3.10 kernel and below and not surprisingly
got removed when the kernel bumped past 3.10. These patches also need
to be re-added (at least definitely [3]) as without them you'll find
that the timer count is too large and the watchdog will unexpectedly
trip typically within a matter of several minutes.

Thanks for the detailed info.


With these additional patches added I would say that we should also
enable the watchdog in the kernel config.

How do you want to proceed? I could ack your patch (as it adds the
base driver back from mainline but doesn't enable it) then followup
with a patch that adds back the additional patches (to
target/platform/cns3xxx unless there are other targets that use the
arm11mpcore processor and want the twd fixes?) and enables the
watchdog kernel driver. Note that the patches affect other files so we
can't simply merge them all into the files directory.


Feel free to Ack.
My plan was to first provide this baseline, and then add the needed 
customization via a second patch.


Like you have noticed, I deliberately submitted as platform specific (& 
disabled) for now until it's fully finished and thoroughly tested.
If another MPcore based platform would like to use it afterwards, it 
should be easy to share it. (Generic or target specific)


The earliest window I see in my calender to continue working on it is in 
about 2 weeks from now, if nothing else pops up ..
If you (or anyone else) would like to further provide fixes it in the 
meantime, please do. :-)


Koen


Regards,

Tim

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e63a3a294fdf91eaaac1061a9c7a5f53d16ac25
[2] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/laguna.c;h=4a596125ab5c8ab1b3a1d31e00d406097b2412d0;hb=HEAD#l636
[3] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/target/linux/generic/target/linux/generic/patches-3.10/target/linux/generic/patches-3.10/992-mpcore_wdt_fix_watchdog_counter_loading.patch;h=ae81f3f384b5805ee64dcbadcaab38aaea1acf1e
[4] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/target/linux/generic/target/linux/generic/patches-3.10/target/linux/generic/patches-3.10/993-mpcore_wdt_fix_wdioc_setoptions_handling.patch;h=c986ac8f216c2a201875b44fc2fe6a8191680c13
[5] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/target/linux/generic/target/linux/generic/patches-3.10/target/linux/generic/patches-3.10/994-mpcore_wdt_fix_timer_mode_setup.patch;h=ecc2452cabe058990d56052644e3d328e549df01
[6] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/target/linux/generic/target/linux/generic/patches-3.10/target/linux/generic/patches-3.10/995-mpcore_twd_calibrate_single_core.patch;h=70411160fac88aeae42a2696039ab9bb5e9f47ba



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] generic: keep module aliases inside .modinfo

[Yousong Zhou]

On 11 January 2017 at 19:57, Yousong Zhou  wrote:
> It seems module aliases are actually essential info.  E.g. other modules
> may call xt_request_find_match(NFPROTO_IPV{4,6}, "hashlimit", 1) and the
> kernel will request user mode modprobe helper for ipt_hashlimit and
> ip6t_hashlimit respectively which are aliases of xt_hashlimit.ko
>
> Compile-tested for armvirt, there is nearly no size impact.
>

Hi, is there any chance that we include mod alias support in lede-17.01?

It's a clear and straightforward change though was made only recently
and may need more testing feedback.  At the very least, bugfix commits
in ubox repo should be included ;)

   yousong

> Before
>
> -rw-r--r-- 1 yousong yousong 304 Jan 10 17:37 config.seed
> -rw-r--r-- 1 yousong yousong1634 Jan 11 11:07 
> lede-armvirt-default.manifest
> -rw-r--r-- 1 yousong yousong 1533647 Jan 11 11:07 
> lede-armvirt-default-rootfs.tar.gz
> -rw-r--r-- 1 yousong yousong 1802711 Jan 11 11:07 
> lede-armvirt-root.ext4.gz
> -rw-r--r-- 1 yousong yousong 1544597 Jan 11 11:07 
> lede-armvirt-rootfs.cpio.gz
> -rw-r--r-- 1 yousong yousong 1174984 Jan 11 11:07 
> lede-armvirt-root.squashfs.gz
> -rwxr-xr-x 1 yousong yousong 1654712 Jan 11 11:07 lede-armvirt-zImage
> -rwxr-xr-x 1 yousong yousong 2738296 Jan 11 11:07 
> lede-armvirt-zImage-initramfs
> drwxr-xr-x 2 yousong yousong4096 Jan 10 17:35 packages
> -rw-r--r-- 1 yousong yousong 739 Jan 10 17:37 sha256sums
>
> After
>
> -rw-r--r-- 1 yousong yousong 304 Jan 10 17:37 config.seed
> -rw-r--r-- 1 yousong yousong1634 Jan 11 11:10 
> lede-armvirt-default.manifest
> -rw-r--r-- 1 yousong yousong 1533646 Jan 11 11:10 
> lede-armvirt-default-rootfs.tar.gz
> -rw-r--r-- 1 yousong yousong 1802711 Jan 11 11:10 
> lede-armvirt-root.ext4.gz
> -rw-r--r-- 1 yousong yousong 1544593 Jan 11 11:10 
> lede-armvirt-rootfs.cpio.gz
> -rw-r--r-- 1 yousong yousong 1174984 Jan 11 11:10 
> lede-armvirt-root.squashfs.gz
> -rwxr-xr-x 1 yousong yousong 1654736 Jan 11 11:10 lede-armvirt-zImage
> -rwxr-xr-x 1 yousong yousong 2738144 Jan 11 11:10 
> lede-armvirt-zImage-initramfs
> drwxr-xr-x 2 yousong yousong4096 Jan 10 17:35 packages
> -rw-r--r-- 1 yousong yousong 739 Jan 10 17:37 sha256sums
>
> Signed-off-by: Yousong Zhou 
> ---
>  target/linux/generic/patches-3.18/204-module_strip.patch | 8 ++--
>  target/linux/generic/patches-4.1/204-module_strip.patch  | 8 ++--
>  target/linux/generic/patches-4.4/204-module_strip.patch  | 8 ++--
>  3 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/target/linux/generic/patches-3.18/204-module_strip.patch 
> b/target/linux/generic/patches-3.18/204-module_strip.patch
> index dab7799..844c3b5 100644
> --- a/target/linux/generic/patches-3.18/204-module_strip.patch
> +++ b/target/linux/generic/patches-3.18/204-module_strip.patch
> @@ -5,18 +5,14 @@ Signed-off-by: Felix Fietkau 
>  ---
>  --- a/include/linux/module.h
>  +++ b/include/linux/module.h
> -@@ -84,9 +84,10 @@ void trim_init_extable(struct module *m)
> +@@ -84,6 +84,7 @@ void trim_init_extable(struct module *m)
>
>   /* Generic info of form tag = "info" */
>   #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
>  +#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag, tag, info)
>
>   /* For userspace: you can also call me... */
> --#define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> -+#define MODULE_ALIAS(_alias) MODULE_INFO_STRIP(alias, _alias)
> -
> - /* Soft module dependencies. See man modprobe.d for details.
> -  * Example: MODULE_SOFTDEP("pre: module-foo module-bar post: module-baz")
> + #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
>  @@ -127,12 +128,12 @@ void trim_init_extable(struct module *m)
>* Author(s), use "Name " or just "Name", for multiple
>* authors use multiple MODULE_AUTHOR() statements/lines.
> diff --git a/target/linux/generic/patches-4.1/204-module_strip.patch 
> b/target/linux/generic/patches-4.1/204-module_strip.patch
> index 4f5f647..6b5f878 100644
> --- a/target/linux/generic/patches-4.1/204-module_strip.patch
> +++ b/target/linux/generic/patches-4.1/204-module_strip.patch
> @@ -5,18 +5,14 @@ Signed-off-by: Felix Fietkau 
>  ---
>  --- a/include/linux/module.h
>  +++ b/include/linux/module.h
> -@@ -84,9 +84,10 @@ void trim_init_extable(struct module *m)
> +@@ -84,6 +84,7 @@ void trim_init_extable(struct module *m)
>
>   /* Generic info of form tag = "info" */
>   #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
>  +#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag, tag, info)
>
>   /* For userspace: you can also call me... */
> --#define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> -+#define MODULE_ALIAS(_alias) MODULE_INFO_STRIP(alias, _alias)
> -
> - /* Soft module dependencies. See man modprobe.d for details.
> -  * Example: 

Re: [LEDE-DEV] [PATCH v3 0/2] ar71xx: fix making firmwares for Linksys WRT400N

[Yousong Zhou]

Hi,

On 29 December 2016 at 15:26, Yousong Zhou  wrote:
> I believe the situation at the moment for WRT400N is like this
>
>  - factory image is broken and will brick the device because the utility
>wrt400n will truncate the kernel to 1MB.
>  - sysupgrade image is missing from snapshots because the kernel size is too
>big exceeding the size limit imposed by "linux" part of mtdparts
>

Please consider picking these 2 patches into the lede-17.01 branch as
wrt400n firmwares made with current code are bound to fail.  I made a
patchwork bundle in case it may help:
http://patchwork.ozlabs.org/bundle/yousong/wrt400n/

yousong

> Lifting size limits of mtdparts is easy.  I was more interested in figuring 
> out
> where did that 0x10 and 0x2fffc4 limit for factory image come from.
>
> Here are my finding After checking with content of OEM SDK, I believe that 
> only
> crc32sum of the whole firmware was checked and the other 2 crc32sums for 
> kernel
> and rootfs were only written to nvram without actually being checked.  However
> I did find a utility named 'read_fw' using the same limit as the old wrt400n
> here, but it seems that it's just a read-only utility for synthesizing a
> factory from /dev/mtd{2,3}.
>
> Maybe someone with serial console attached to this device can give the patch a
> try.  Bear in mind though it may brick your device and so you MUST prepare
> before hand how to do the unbrick.
>
> Google Drive link for ready-made firmwares:
>
> https://drive.google.com/drive/folders/0B0ollk-mJJJAaTJmb01hb1pjejg
>
> v3 <- v2
>
> - Changed from RFT to PATCH (thanks to Frank Horowitz for testing the 
> RFT v2 version)
> - Rebased on current master (use pad-to instead of append-kernel with 
> blocksize)
> - wrt400n: add size limit check on kernel and rootfs part as required 
> by OEM system
>
> v2 <- v0:
>
> - fix crc32 seed value for crc32sum of whole file
> - fix output file permission bits
> - fix fw_totalsize calculation
> - 0xff as the last byte of ih.magic
>
>
> Yousong Zhou (2):
>   tools: wrt400n: fix making factory images with kernel bigger than 1MB
>   ar71xx: wrt400n: lift size limit on kernel and rootfs part
>
>  .../ar71xx/files/arch/mips/ath79/mach-wrt400n.c|  12 +-
>  target/linux/ar71xx/image/generic.mk   |  22 +
>  target/linux/ar71xx/image/legacy-devices.mk|   5 -
>  target/linux/ar71xx/image/legacy.mk|  11 -
>  tools/firmware-utils/src/wrt400n.c | 463 
> +
>  5 files changed, 221 insertions(+), 292 deletions(-)
>
> --
> 2.6.4
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev