Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Nerijus Baliunas 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 Mon, 9 Oct 2017 01:31:29 +0300 Sergey Ryazanov  
wrote:

> > Just tried:
> > # ifconfig eth0 192.168.0.10 up
> > ifconfig: SIOCSIFFLAGS: Out of memory
> > # dmesg|grep eth
> > [0.998445] eth0: MII PHY 32 on NPE-B
> > [1.005134] eth1: MII PHY 1 on NPE-C
> > [6.540687] eth0: link up, speed 100 Mb/s, full duplex
> > [9.323993] eth0: link down
> > [   36.266247] device eth0 entered promiscuous mode
> 
> Check please, is there any new kernel messages after 'ifconfig ... up'
> failure (may be not directly related to eth0). Just run dmesg without
> grep.

I don't see anything suspicious. The full serial console log (dmesg included) 
is here -
https://paste.fedoraproject.org/paste/P5sDjdpJr1hFZ-hp~Prwcw

> It is also stranger that something bring eth0 up and then putting it
> back to down. Is these strings (eth0: link up/eth0: link down) appear
> in the kernel log during preinit procedure?

Seems so:
[4.981198] init: - preinit -
[6.473760] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.544511] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.761251] NPE-B: firmware's license can be found in 
/usr/share/doc/LICENSE.IPL
[6.768796] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.776745] eth0: link up, speed 100 Mb/s, full duplex
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
[   10.310754] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
[   10.359891] urandom-seed: Seed file not found (/etc/urandom.seed)
[   10.492841] eth0: link down

Regards,
Nerijus

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

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Sergey Ryazanov 
On Mon, Oct 9, 2017 at 12:00 AM, Nerijus Baliunas
 wrote:
> On Sun, 8 Oct 2017 23:44:58 +0300 Sergey Ryazanov  
> wrote:
>> > I assigned IP with a command
>> > ip a a 192.168.0.10/24 dev eth0
>> >
>> > but ping from PC does not answer.
>>
>> Have you bring eth0 UP? I mean, could you do "ifconfig eth0
>> 192.168.0.10 up" and try pinging again?
>
> Just tried:
> # ifconfig eth0 192.168.0.10 up
> ifconfig: SIOCSIFFLAGS: Out of memory
> # dmesg|grep eth
> [0.998445] eth0: MII PHY 32 on NPE-B
> [1.005134] eth1: MII PHY 1 on NPE-C
> [6.540687] eth0: link up, speed 100 Mb/s, full duplex
> [9.323993] eth0: link down
> [   36.266247] device eth0 entered promiscuous mode

Check please, is there any new kernel messages after 'ifconfig ... up'
failure (may be not directly related to eth0). Just run dmesg without
grep.

It is also stranger that something bring eth0 up and then putting it
back to down. Is these strings (eth0: link up/eth0: link down) appear
in the kernel log during preinit procedure?

-- 
Sergey

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

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Nerijus Baliunas 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 Sun, 8 Oct 2017 23:44:58 +0300 Sergey Ryazanov  
wrote:

> > I assigned IP with a command
> > ip a a 192.168.0.10/24 dev eth0
> >
> > but ping from PC does not answer.
>
> Have you bring eth0 UP? I mean, could you do "ifconfig eth0
> 192.168.0.10 up" and try pinging again?

Just tried:
# ifconfig eth0 192.168.0.10 up
ifconfig: SIOCSIFFLAGS: Out of memory
# dmesg|grep eth
[0.998445] eth0: MII PHY 32 on NPE-B
[1.005134] eth1: MII PHY 1 on NPE-C
[6.540687] eth0: link up, speed 100 Mb/s, full duplex
[9.323993] eth0: link down
[   36.266247] device eth0 entered promiscuous mode
# ifconfig eth0 192.168.0.10 up
ifconfig: SIOCSIFFLAGS: Out of memory
# ifconfig -a
br-lanLink encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fde1:e263:bcc::1/60 Scope:Global
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:2 errors:0 dropped:0 overruns:0 frame:0
  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:92 (92.0 B)  TX bytes:1551 (1.5 KiB)

Ping still does not answer.

Regards,
Nerijus

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

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Sergey Ryazanov 
On Sun, Oct 8, 2017 at 11:12 PM, Nerijus Baliunas
 wrote:
> I assigned IP with a command
> ip a a 192.168.0.10/24 dev eth0
>
> but ping from PC does not answer.
>
> ifconfig -a shows a few RX and TX packets:
> eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE
>   inet addr:192.168.0.10  Bcast:0.0.0.0  Mask:255.255.255.0
>   BROADCAST MULTICAST  MTU:1500  Metric:1
>   RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>
> but the packet count does not increase after pinging.

Have you bring eth0 UP? I mean, could you do "ifconfig eth0
192.168.0.10 up" and try pinging again?

-- 
Sergey

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

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Nerijus Baliunas 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, 3 Oct 2017 03:27:21 +0300 Sergey Ryazanov  
wrote:

> After these lines, I carefully examine available data about WRT300Nv2
> and related code and found several interesting things.
> 
> Usually SoC in the router have only one ethernet interface and vendors
> pair it with manageable switch IC. This swith IC accepts packets from
> LAN and WAN ports, then it tags them and forward to the SoC. Thus,
> using VLAN tags, SoC can distinguish from which port the packet was
> received and handle it appropriately. So the firmware should contains
> a driver for switch IC to be able to properly configure ports and
> VLANs inside the switch.
> 
> In case of WRT300Nv2 the SoC contains two ethernet adapters: NPE-C
> (eth1), which has own phy and acted as a WAN port and NPE-B (eth0),
> which is connected to switch IC, each port of which is acting as LAN
> port. So since all ports of switch are equal then the switch themself
> requires a minimal (if any) configuration. And this router can
> possibly act without any special driver for switch IC.
> 
> Also I found why the switch is properly detected on the MDIO bus but
> not used as phy-device. This happened because PHY ID for eth0 is
> hardcoded inside WRT300Nv2 setup code.
> 
> To check whether your board can act without dedicated driver for 88E6060:
> * revert any earlier modifications to LEDE if you do any
> * disable any drivers for 88E6060 (e.g. disable both
> CONFIG_NET_DSA_MV88E6060 and CONFIG_MVSWITCH_PHY)
> * place attached patch to the target/linux/ixp4xx/patches-4.4
> * rebuild and boot new firmware
> * check dmesg for "eth0: link up" message
> * check eth0 functioning: check packets receiving with tcpdump or
> manually assign IP address to the eth0 interface (without any VLAN's
> and so on) and try to ping.

I did this, and now when booting I see
[0.999140] eth0: MII PHY 32 on NPE-B
[1.005714] eth1: MII PHY 1 on NPE-C
...
[6.531972] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.540066] eth0: link up, speed 100 Mb/s, full duplex
[9.070970] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
[9.118732] urandom-seed: Seed file not found (/etc/urandom.seed)
[9.250596] eth0: link down

I assigned IP with a command
ip a a 192.168.0.10/24 dev eth0
but ping from PC does not answer.
ifconfig -a shows a few RX and TX packets:
eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.0.10  Bcast:0.0.0.0  Mask:255.255.255.0
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:5 errors:0 dropped:0 overruns:0 frame:0
  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0

but the packet count does not increase after pinging.

Regards,
Nerijus

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

Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9

2017-10-08 Thread Arjen de Korte 

Citeren Paul Blazejowski :


Will this also work on WNDR3700v4?


I guess so, the image for the WNDR3700v4 is the same as for the  
WNDR4300v1. I can confirm the version from Hauke's staging tree works  
on the latter, so it is likely that it will also work for the first too.



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

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

2017-10-08 Thread Joe Mullally 
One usecase not currently supported is managing dnsmasq ipset lists 
through LuCI, which enables anyone to maintain them. With ipset-dns 
this is easy to do using LuCI "dhcp.@dnsmasq[0].server" entries.


If it was added, I think ipset-dns could be deprecated.


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

Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address

2017-10-08 Thread Hauke Mehrtens 
On 10/08/2017 09:25 PM, p.wa...@gmx.at wrote:
> Hi Hauke,
> 
>> When the kernel gets uncompressed and is bigger than
>> BZ_TEXT_START - LOADADDR it overwrote the loader which was currently 
>> uncompressing
>> it and made the board crash.
> 
> Currently, BZ_TEXT_START - LOADADDR = 0x8040 - 0x80001000 = 3FF000 = 
> 4190208 bytes
> Today's trunk brcm47xx kernel is 4069124 bytes. So increasing the address is 
> actually
> just a preventive countermeasure for future kernels.(?)
> The WRT54GL CFEs seem to use a memory area about half the size of your 
> WRT54GS'
> So I guess, the actual problem for the WRT54GL was that the stack was smashed?
> 
> Once my compiling machine finishes your ar71xx with kernel 4.9, I'll test 
> this one here :-)
> 
> Happy to see, that this problem seems to be solved.

Hi,

The stack was not a problem with my kernel, I just added it to prevent
later problems, now I debugged this, I do not want to debug this again
in 2 years.

My vmlinux kernel file is 4277380 bytes, so bigger than the available
size you calculated. The stack starts at 0x8043BF30 so there are 4435760
bytes available till my image would overwrite the stack.

It does not matter where CFE is located as we do not need it any more
after the loader started, we will never jump back into it and use the
memory region used for CFE later also for Linux.

With both patches there is now almost 6 MB space available.

Hauke

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

Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address

2017-10-08 Thread Arjen de Korte 

Citeren p.wa...@gmx.at:


Hi Hauke,


When the kernel gets uncompressed and is bigger than
BZ_TEXT_START - LOADADDR it overwrote the loader which was  
currently uncompressing

it and made the board crash.


Currently, BZ_TEXT_START - LOADADDR = 0x8040 - 0x80001000 =  
3FF000 = 4190208 bytes
Today's trunk brcm47xx kernel is 4069124 bytes. So increasing the  
address is actually

just a preventive countermeasure for future kernels.(?)


The change from 4.4 to 4.9, will add approximately 500 kbytes to the  
kernel (assuming the increase will be similar as for ar71xx), so this  
won't fit anymore. So this preventive measure may be needed sooner  
than you think.


The WRT54GL CFEs seem to use a memory area about half the size of  
your WRT54GS'
So I guess, the actual problem for the WRT54GL was that the stack  
was smashed?


Once my compiling machine finishes your ar71xx with kernel 4.9, I'll  
test this one here :-)


Happy to see, that this problem seems to be solved.

Regards,
P. Wassi

___
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] brcm47xx: relocate loader to higher address

2017-10-08 Thread p . wassi 
Hi Hauke,

> When the kernel gets uncompressed and is bigger than
> BZ_TEXT_START - LOADADDR it overwrote the loader which was currently 
> uncompressing
> it and made the board crash.

Currently, BZ_TEXT_START - LOADADDR = 0x8040 - 0x80001000 = 3FF000 = 
4190208 bytes
Today's trunk brcm47xx kernel is 4069124 bytes. So increasing the address is 
actually
just a preventive countermeasure for future kernels.(?)
The WRT54GL CFEs seem to use a memory area about half the size of your WRT54GS'
So I guess, the actual problem for the WRT54GL was that the stack was smashed?

Once my compiling machine finishes your ar71xx with kernel 4.9, I'll test this 
one here :-)

Happy to see, that this problem seems to be solved.

Regards,
P. Wassi

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

Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9

2017-10-08 Thread Hannu Nyman 

Thanks.

I compiled kernel 4.9 for my old WNDR3700v2 and WNDR3800. Both routers booted 
ok and seem to work ok at the first glance.




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

Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9

2017-10-08 Thread Arjen de Korte 

Citeren Hauke Mehrtens :


On 10/08/2017 01:31 PM, Andrey Jr. Melnikov wrote:

Arjen de Korte  wrote:

Citeren Hauke Mehrtens :



This adds support for kernel 4.9.
Please test this, I am lacking especially NAND devices.

The most recent version of these patches can be found here:
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx

Hauke Mehrtens (4):
  ar71xx: Copy kernel 4.4 code for kernel 4.9
  ar71xx: make the target compile with kernel 4.9
  ar71xx: fix section mismatches
  ar71xx: switch to kernel 4.9 by default



I checked the above patches on a WNDR4300 (a NAND device). No issues
when building, but the device entered a bootloop after flashing with
sysupgrade. Since this is a production system, I didn't have time to
dig into what is exactly causing this.


ar934x NAND driver missing cmd_ctrl() function - so NAND devices  
not work at all.


[3.575549] nand: chip.cmd_ctrl() callback is not provided
[3.581103] ar934x-nfc ar934x-nfc: nand_scan_ident failed, err:-22
[3.587515] ar934x-nfc: probe of ar934x-nfc failed with error -22


Hi,

Thanks for testing and reporting back.

I tried to fix this problem, can you please try the most recent version
from my git tree. This now has this additional change:
https://git.lede-project.org/?p=lede/hauke/staging.git;a=commitdiff;h=42a49cbca96875be43913688da60d637cbdff604


Tested your staging tree on a WNDR4300, looking well. I'll keep an eye  
on it over the next few days.


Regards, Arjen


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

Re: [LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address

2017-10-08 Thread Florian Fainelli 


On 10/08/2017 08:29 AM, Hauke Mehrtens wrote:
> On 10/08/2017 05:06 PM, Hauke Mehrtens wrote:
>> The boot process on a WRT54GL works the following way:
>> 1. CFE gets loaded by the boot rom from flash
>> 2. CFE loads the loader from the flash and gzip uncompresses it
>> 3. CFE starts the loader
>> 4. The loader stores the FW arguments and relocates itself to
>>BZ_TEXT_START (now 0x8060)
>> 5. The loader reads the Linux image from flash
>> 6. The loader lzma decompresses the Linux image to LOADADDR (0x80001000)
>> 7. The loader executes the uncompress Linux image at LOADADDR
>>
>> The BZ_TEXT_START was set to 0x8040 before. When the kernel gets
>> uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote
>> the loader which was currently uncompressing it and made the board
>> crash. Increase the BZ_TEXT_START my 2 MB to have more space for the
>> kernel. Even on 16MB RAM devices the memory goes till 0x80FF so this
>> should not be a problem.
>>
>> Signed-off-by: Hauke Mehrtens 
>> ---
>>  target/linux/brcm47xx/image/lzma-loader/src/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile 
>> b/target/linux/brcm47xx/image/lzma-loader/src/Makefile
>> index 3320e565d0..444039c558 100644
>> --- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile
>> +++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile
>> @@ -18,7 +18,7 @@
>>  #
>>  
>>  TEXT_START  := 0x80001000
>> -BZ_TEXT_START   := 0x8040
>> +BZ_TEXT_START   := 0x8060
>>  
>>  OBJCOPY := $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R 
>> .note -R .comment -R .mdebug -S
> 
> 
> This makes my WRT54GS boot a kernel 4.9 with CONFIG_KALLSYMS. Without
> this patch it is not booting up.
> 
> The FW arguments are more or less useless, I got these in Linux from CFE
> forwarded by the loader:
> fw_arg0: 0x803401a0, fw_arg1: 0x0, fw_arg2: 0x803029c8, fw_arg3: 0x43464531

Yes, those do not really matter on brcm47xx since the CFE environment
and all associated services (cfe_getenv, cfe_write) are not available
anyway...

> 
> They are pointing somewhere into CFE:
> 
> Total memory used by CFE:  0x8030 - 0x8043DF30 (1302320)
> Initialized Data:  0x803381A0 - 0x8033A550 (9136)
> BSS Area:  0x8033A550 - 0x8033BF30 (6624)
> Local Heap:0x8033BF30 - 0x8043BF30 (1048576)
> Stack Area:0x8043BF30 - 0x8043DF30 (8192)
> Text (code) segment:   0x8030 - 0x803381A0 (229792)
> Boot area (physical):  0x0043E000 - 0x0047E000
> Relocation Factor: I: - D:
> 
> See section 8.2.3 "Registers passed to boot loaders" for details on what
> these arguments mean:
> http://melbourne.wireless.org.au/files/wrt54/cfe.pdf
> 
> Our image does not use them anyway so this is also save.
> 
> 
> Hauke
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

-- 
Florian

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

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

2017-10-08 Thread Jason A. Donenfeld 
Hi Stijn,

That was quick. Thanks!

Jason

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

[LEDE-DEV] [PATCH] brcm47xx: relocate the stack in loader

2017-10-08 Thread Hauke Mehrtens 
By default we are reusing the stack provided by CFE, like it is intended
by CFE. On my WRT54GS it is located at 0x8043BF30, so a big kernel image
could overwrite it. Relocate it to a different memory region which is
still under the 8MB RAM, but in the higher area. We only need this
memory region for the stack of the loader, Linux will set up this
for its own.

Signed-off-by: Hauke Mehrtens 
---
 target/linux/brcm47xx/image/lzma-loader/src/Makefile | 5 +++--
 target/linux/brcm47xx/image/lzma-loader/src/head.S   | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile 
b/target/linux/brcm47xx/image/lzma-loader/src/Makefile
index 444039c558..a08fc05b9f 100644
--- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile
+++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile
@@ -19,6 +19,7 @@
 
 TEXT_START := 0x80001000
 BZ_TEXT_START  := 0x8060
+BZ_STACK_START := 0x8070
 
 OBJCOPY:= $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R 
.note -R .comment -R .mdebug -S
 
@@ -28,9 +29,9 @@ CFLAGS= -D__KERNEL__ -Wall 
-Wstrict-prototypes -Wno-trigraphs -Os \
  -mabi=32 -march=mips32 -Wa,-32 -Wa,-march=mips32 -Wa,-mips32 
-Wa,--trap
 CFLAGS += -DLOADADDR=$(TEXT_START) -D_LZMA_IN_CB
 
-ASFLAGS= $(CFLAGS) -D__ASSEMBLY__ 
-DBZ_TEXT_START=$(BZ_TEXT_START)
+ASFLAGS= $(CFLAGS) -D__ASSEMBLY__ 
-DBZ_TEXT_START=$(BZ_TEXT_START) -DBZ_STACK_START=$(BZ_STACK_START)
 
-SEDFLAGS   := s/BZ_TEXT_START/$(BZ_TEXT_START)/;s/TEXT_START/$(TEXT_START)/
+SEDFLAGS   := 
s/BZ_TEXT_START/$(BZ_TEXT_START)/;s/BZ_STACK_START/$(BZ_STACK_START)/;s/TEXT_START/$(TEXT_START)/
 
 OBJECTS:= head.o data.o
 
diff --git a/target/linux/brcm47xx/image/lzma-loader/src/head.S 
b/target/linux/brcm47xx/image/lzma-loader/src/head.S
index 930c9ba277..50c159ce57 100644
--- a/target/linux/brcm47xx/image/lzma-loader/src/head.S
+++ b/target/linux/brcm47xx/image/lzma-loader/src/head.S
@@ -38,6 +38,7 @@
.text
LEAF(startup)
.set noreorder
+   li  sp, BZ_STACK_START
addisp, -48
sw  a0, 16(sp)
sw  a1, 20(sp)
-- 
2.11.0


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

Re: [LEDE-DEV] Kernel version in next major release

2017-10-08 Thread Stijn Tintel 
On 07-10-17 14:43, Hauke Mehrtens wrote:
> What is your opinion on this topic? Am I missing some arguments?
> Currently I would prefer solution 3 going with kernel 4.9 and 4.14.
I actually preferred to have a 2nd major release in 2017, using only
kernel 4.9, and then a 3rd major release early 2018 using only kernel
4.14. Unfortunately we seem to lack the manpower to get this done, so I
am fine with exploring option 3. My only concern with this, is that it
will increase the workload for service releases.

Either way, as I said on IRC, I think we should give option 3 a try for
our next major release, and revert back to supporting a single kernel
version per release if that proves to be too difficult to maintain.

For > 4.9, please have a look at
https://git.lede-project.org/?p=lede/stintel/staging.git;a=shortlog;h=refs/heads/kernel
This was in perfect shape, but I messed up when reworking after the
split of patches directory to {backport,hack,pending}. Nonetheless it
should be easier to start from there than to redo everything from scratch.

Stijn


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

Re: [LEDE-DEV] [PATCH] scripts/download.pl: fail loudly if provided hash is unsupported

2017-10-08 Thread Stijn Tintel 
On 25-09-17 18:43, Stijn Tintel wrote:
> On 25-09-17 00:20, Baptiste Jonglez wrote:
>> On 24-09-17, Stijn Tintel wrote:
>>> My bad. When we update a package, we bump the version in the Makefile
>>> and remove the current hash, then run "make package/foo/dowload; make
>>> package/foo/check FIXUP=1". This downloads the tarbal for the new
>>> version, and FIXUP writes its hash to the Makefile. This is what's
>>> broken since the change.
>> Ok, I see the issue now.
>>
>> As mentioned in the commit message, we definitely should add an explicit
>> option to download.pl to skip hash verification, and then implement
>> something like this:
>>
>> $ make package/foo/download SKIPHASH=1
>>
>> What do you think?
> We were thinking in that direction on #lede-dev, not sure why we
> couldn't agree. Let's wait a bit if anybody else chimes in?
Maybe just send an RFC patch with the suggested change, as nobodoy seems
to be responding.

Thanks,
Stijn


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

[LEDE-DEV] [PATCH] brcm47xx: relocate loader to higher address

2017-10-08 Thread Hauke Mehrtens 
The boot process on a WRT54GL works the following way:
1. CFE gets loaded by the boot rom from flash
2. CFE loads the loader from the flash and gzip uncompresses it
3. CFE starts the loader
4. The loader stores the FW arguments and relocates itself to
   BZ_TEXT_START (now 0x8060)
5. The loader reads the Linux image from flash
6. The loader lzma decompresses the Linux image to LOADADDR (0x80001000)
7. The loader executes the uncompress Linux image at LOADADDR

The BZ_TEXT_START was set to 0x8040 before. When the kernel gets
uncompressed and is bigger than BZ_TEXT_START - LOADADDR it overwrote
the loader which was currently uncompressing it and made the board
crash. Increase the BZ_TEXT_START my 2 MB to have more space for the
kernel. Even on 16MB RAM devices the memory goes till 0x80FF so this
should not be a problem.

Signed-off-by: Hauke Mehrtens 
---
 target/linux/brcm47xx/image/lzma-loader/src/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/brcm47xx/image/lzma-loader/src/Makefile 
b/target/linux/brcm47xx/image/lzma-loader/src/Makefile
index 3320e565d0..444039c558 100644
--- a/target/linux/brcm47xx/image/lzma-loader/src/Makefile
+++ b/target/linux/brcm47xx/image/lzma-loader/src/Makefile
@@ -18,7 +18,7 @@
 #
 
 TEXT_START := 0x80001000
-BZ_TEXT_START  := 0x8040
+BZ_TEXT_START  := 0x8060
 
 OBJCOPY:= $(CROSS_COMPILE)objcopy -O binary -R .reginfo -R 
.note -R .comment -R .mdebug -S
 
-- 
2.11.0


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

[LEDE-DEV] mktplinkfw2 cleanup tests (was [PATCH 1/3] mktplinkfw2: use hw rev for board detection too)

2017-10-08 Thread Sergey Ryazanov 
Hello Mathias,

On Thu, Oct 5, 2017 at 9:13 AM, Mathias Kresin  wrote:
> At the moment I'm reviewing https://github.com/lede-project/source/pull/1399

[skipped]

> The PR drops any hardcoded board params from mktplinkfw2.c in favour of
> commandline arguments, to provide only one way of creating tp-link images.
> It has the nice benefit that this file most likely doesn't need to be
> touched any more if new tp-link boards gets added.
>
> Would be nice if you can give the PR a try to test for regressions.

It's better late than never.

I had tested these patches, which already landed to the tree. All work
as expected. I had not test upgrading from vendor firmware to LEDE,
but sysupgrade works well with the new image on TP-Link Archer C20v1.
So image generation is still alive after these change.



P.S. I noticed that the old configuration is not preserved during the
sysupgrade. sysupgrade.tgz archive is generated and appended to the
jffs2 partition, as expected. But the archive is disappears (with all
the old configs) during the first boot after sysupgrade. It seems that
preserving the config has never worked with C20/C20i so latest changes
in mktplink2 had nothing to do with this.

-- 
Sergey

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

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

2017-10-08 Thread Stijn Tintel 
On 08-10-17 16:20, Jason A. Donenfeld wrote:
> On Sun, Oct 8, 2017 at 3:04 PM, Jason A. Donenfeld  wrote:
>> In that case, I'll take a closer look at the patches LEDE ships for
>> the package and merging them into the upstream repo.
> If you don't wind up removing that, future packages won't need to
> include that patch any longer:
> https://git.zx2c4.com/ipset-dns/commit/?id=ade2cf88e933f4f90451e0a6171f0aa4a523f989
Updated in my staging tree: https://git.lede-project.org/ffd778ea

Thanks,
Stijn

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

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

2017-10-08 Thread Jason A. Donenfeld 
On Sun, Oct 8, 2017 at 3:04 PM, Jason A. Donenfeld  wrote:
> In that case, I'll take a closer look at the patches LEDE ships for
> the package and merging them into the upstream repo.

If you don't wind up removing that, future packages won't need to
include that patch any longer:
https://git.zx2c4.com/ipset-dns/commit/?id=ade2cf88e933f4f90451e0a6171f0aa4a523f989

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

Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9

2017-10-08 Thread Hauke Mehrtens 
On 10/08/2017 01:31 PM, Andrey Jr. Melnikov wrote:
> Arjen de Korte  wrote:
>> Citeren Hauke Mehrtens :
> 
>>> This adds support for kernel 4.9.
>>> Please test this, I am lacking especially NAND devices.
>>>
>>> The most recent version of these patches can be found here:
>>> https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx
>>>
>>> Hauke Mehrtens (4):
>>>   ar71xx: Copy kernel 4.4 code for kernel 4.9
>>>   ar71xx: make the target compile with kernel 4.9
>>>   ar71xx: fix section mismatches
>>>   ar71xx: switch to kernel 4.9 by default
> 
>> I checked the above patches on a WNDR4300 (a NAND device). No issues  
>> when building, but the device entered a bootloop after flashing with  
>> sysupgrade. Since this is a production system, I didn't have time to  
>> dig into what is exactly causing this.
> 
> ar934x NAND driver missing cmd_ctrl() function - so NAND devices not work at 
> all.
> 
> [3.575549] nand: chip.cmd_ctrl() callback is not provided
> [3.581103] ar934x-nfc ar934x-nfc: nand_scan_ident failed, err:-22
> [3.587515] ar934x-nfc: probe of ar934x-nfc failed with error -22

Hi,

Thanks for testing and reporting back.

I tried to fix this problem, can you please try the most recent version
from my git tree. This now has this additional change:
https://git.lede-project.org/?p=lede/hauke/staging.git;a=commitdiff;h=42a49cbca96875be43913688da60d637cbdff604

Hauke

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

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

2017-10-08 Thread Jason A. Donenfeld 
On Sun, Oct 8, 2017 at 3:02 PM, Florian Fainelli  wrote:
> Still using ipset-dns here, thanks for the reminder, I should probably
> migrate to dnsmasq now to achieve the same goals. There may be other
> users out there though ;)

Cool, okay, good to know!

In that case, I'll take a closer look at the patches LEDE ships for
the package and merging them into the upstream repo.

Jason

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

Re: [LEDE-DEV] ipset-dns - does anybody actually use this?

2017-10-08 Thread Florian Fainelli 
Hi,

On 10/07/2017 04:48 PM, Jason A. Donenfeld wrote:
> Hey,
> 
> I'm upstream on the ipset-dns project:
> https://git.zx2c4.com/ipset-dns/about/
> 
> It's a part of a core LEDE repo:
> https://git.lede-project.org/?p=source.git;a=tree;f=package/network/services/ipset-dns
> 
> Pretty soon after I wrote ipset-dns, I thought it was kind of a
> hassle, and so I rewrote the whole thing instead as a patch to
> dnsmasq, submitted it upstream to Simon, and it was accepted. This
> seems to work much more easily than my original ipset-dns, and I
> imagine it's what most people use for that kind of thing on LEDE.
> Funny enough, when I look at the git repo for ipset-dns, on February
> 15, 2013, I made the "initial commit." On the 23rd, 8 days later, I
> added a note telling people to use dnsmasq instead.
> 
> In spite of this, it went into LEDE, and I assume people used it in
> between then and whenever my patch inside of dnsmasq was released in a
> version that was inside of LEDE.
> 
> But this was all years ago.
> 
> So, I'm wondering: does anybody actually use ipset-dns? Does it have
> any utility? As cool as it is having a piece of my code in the core
> LEDE repo, I can't help wondering if it should be removed...

Still using ipset-dns here, thanks for the reminder, I should probably
migrate to dnsmasq now to achieve the same goals. There may be other
users out there though ;)
-- 
Florian

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

Re: [LEDE-DEV] Kernel version in next major release

2017-10-08 Thread Piotr Dymacz 

Hello Hauke,

On 07.10.2017 13:43, Hauke Mehrtens wrote:

[...]


What is your opinion on this topic? Am I missing some arguments?
Currently I would prefer solution 3 going with kernel 4.9 and 4.14.


I prefer option 3 as well.

--
Cheers,
Piotr

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

[LEDE-DEV] build problem in layerscape target

2017-10-08 Thread Hauke Mehrtens 
Hi Yangbo,

I am seeing the following build problem in the layerscape target in the
master tree.
I fixed the missing config symbol problem, found by the build bots, but
they will run into this in the next run. I saw this on the 64bit and the
32 bit build.

--
  CC [M]  drivers/usb/host/ehci-fsl.o
In file included from drivers/usb/host/ehci-fsl.c:45:0:
drivers/usb/host/ehci.h: In function 'ehci_readl':
drivers/usb/host/ehci.h:757:9: error: implicit declaration of function
'readl' [-Werror=implicit-function-declaration]
  return readl(regs);
 ^
drivers/usb/host/ehci.h: In function 'ehci_writel':
drivers/usb/host/ehci.h:784:3: error: implicit declaration of function
'writel' [-Werror=implicit-function-declaration]
   writel(val, regs);
   ^
In file included from drivers/usb/host/ehci-fsl.c:26:0:
drivers/usb/host/ehci-fsl.c: In function 'hcd_to_ehci_fsl':
./include/linux/kernel.h:836:27: error: 'struct ehci_fsl' has no member
named 'ehci'
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
   ^
drivers/usb/host/ehci-fsl.c:100:8: note: in expansion of macro
'container_of'
 return container_of(ehci, struct ehci_fsl, ehci);
^
./include/linux/kernel.h:836:48: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/usb/host/ehci-fsl.c:100:8: note: in expansion of macro
'container_of'
 return container_of(ehci, struct ehci_fsl, ehci);
^
In file included from ./include/linux/compiler.h:58:0,
 from ./include/linux/linkage.h:4,
 from ./include/linux/kernel.h:6,
 from drivers/usb/host/ehci-fsl.c:26:
./include/linux/compiler-gcc.h:159:2: error: 'struct ehci_fsl' has no
member named 'ehci'
  __builtin_offsetof(a, b)
  ^
./include/linux/stddef.h:16:32: note: in expansion of macro
'__compiler_offsetof'
 #define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^
./include/linux/kernel.h:837:29: note: in expansion of macro 'offsetof'
  (type *)( (char *)__mptr - offsetof(type,member) );})
 ^
drivers/usb/host/ehci-fsl.c:100:8: note: in expansion of macro
'container_of'
 return container_of(ehci, struct ehci_fsl, ehci);
^
drivers/usb/host/ehci-fsl.c: At top level:
drivers/usb/host/ehci-fsl.c:126:8: error: redefinition of 'struct ehci_fsl'
 struct ehci_fsl {
^
drivers/usb/host/ehci-fsl.c:85:8: note: originally defined here
 struct ehci_fsl {
^
drivers/usb/host/ehci-fsl.c:146:8: error: unknown type name 'strut'
 static strut ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
^
drivers/usb/host/ehci-fsl.c:146:23: error: expected '=', ',', ';', 'asm'
or '__attribute__' before '*' token
 static strut ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
   ^
drivers/usb/host/ehci-fsl.c: In function 'fsl_ehci_drv_probe':
drivers/usb/host/ehci-fsl.c:259:3: error: implicit declaration of
function 'clrsetbits_be32' [-Werror=implicit-function-declaration]
   clrsetbits_be32(hcd->regs + FSL_SOC_USB_CTRL,
   ^
drivers/usb/host/ehci-fsl.c:265:3: error: implicit declaration of
function 'iowrite32be' [-Werror=implicit-function-declaration]
   iowrite32be(USB_CTRL_USB_EN, hcd->regs + FSL_SOC_USB_CTRL);
   ^
drivers/usb/host/ehci-fsl.c: In function 'usb_phy_clk_valid':
drivers/usb/host/ehci-fsl.c:333:8: error: implicit declaration of
function 'in_be32' [-Werror=implicit-function-declaration]
  if (!(in_be32(non_ehci + FSL_SOC_USB_CTRL) & PHY_CLK_VALID))
^
drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_setup_phy':
drivers/usb/host/ehci-fsl.c:361:4: error: implicit declaration of
function 'clrbits32' [-Werror=implicit-function-declaration]
clrbits32(non_ehci + FSL_SOC_USB_CTRL,
^
drivers/usb/host/ehci-fsl.c:387:31: error: too few arguments to function
'usb_phy_clk_valid'
pdata->have_sysif_regs && !usb_phy_clk_valid(hcd)) {
   ^
drivers/usb/host/ehci-fsl.c:327:13: note: declared here
 static bool usb_phy_clk_valid(struct usb_hcd *hcd,
 ^
drivers/usb/host/ehci-fsl.c:415:9: error: implicit declaration of
function 'ioread32be' [-Werror=implicit-function-declaration]
   if (!(ioread32be(non_ehci + FSL_SOC_USB_CTRL) &
 ^
drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_drv_suspend':
drivers/usb/host/ehci-fsl.c:747:30: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
  struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
  ^
drivers/usb/host/ehci-fsl.c: In function 'ehci_fsl_drv_resume':
drivers/usb/host/ehci-fsl.c:791:30: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
  struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
  ^

[LEDE-DEV] [PATCH] kernel: bump 4.4 to 4.4.91

2017-10-08 Thread Kevin Darbyshire-Bryant 
Refresh patches.

Compile-tested for: ar71xx Archer C7 v2
Run-tested on: ar71xx Archer C7 v2

Signed-off-by: Kevin Darbyshire-Bryant 
---
 include/kernel-version.mk  |  4 ++--
 target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch  |  2 +-
 .../680-NET-skip-GRO-for-foreign-MAC-addresses.patch   | 10 +-
 target/linux/generic/pending-4.4/721-phy_packets.patch |  2 +-
 .../oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch  |  2 +-
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 75a1e1d..ab2eaeb 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,11 +3,11 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .71
-LINUX_VERSION-4.4 = .90
+LINUX_VERSION-4.4 = .91
 LINUX_VERSION-4.9 = .53
 
 LINUX_KERNEL_HASH-3.18.71 = 
5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240
-LINUX_KERNEL_HASH-4.4.90 = 
6826ccd213ac79bbfd47e63912e89ef7ec70324b7aa3684a4d4560fc2b436331
+LINUX_KERNEL_HASH-4.4.91 = 
cb9d2b8c1afe58414de5bc7d65429cc9f5f37c80fc229d0e83c55c5c3c254ffb
 LINUX_KERNEL_HASH-4.9.53 = 
32915a33bb0b993b779257748f89f31418992edba53acbe1160cb0f8ef3cb324
 
 ifdef KERNEL_PATCHVER
diff --git a/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch 
b/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch
index 23b8e86..d43e8c7 100644
--- a/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch
+++ b/target/linux/ar71xx/patches-4.4/930-chipidea-pullup.patch
@@ -58,7 +58,7 @@
return;
 +  }
  
-   if (hw_read_otgsc(ci, OTGSC_BSV))
+   if (hw_read_otgsc(ci, OTGSC_BSV) && !ci->vbus_active)
usb_gadget_vbus_connect(>gadget);
 --- a/include/linux/usb/chipidea.h
 +++ b/include/linux/usb/chipidea.h
diff --git 
a/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch
 
b/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch
index 0616eaa..b7ba384 100644
--- 
a/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch
+++ 
b/target/linux/generic/pending-4.4/680-NET-skip-GRO-for-foreign-MAC-addresses.patch
@@ -17,7 +17,7 @@ Signed-off-by: Felix Fietkau 
 
 --- a/net/core/dev.c
 +++ b/net/core/dev.c
-@@ -4256,6 +4256,9 @@ static enum gro_result dev_gro_receive(s
+@@ -4259,6 +4259,9 @@ static enum gro_result dev_gro_receive(s
enum gro_result ret;
int grow;
  
@@ -27,7 +27,7 @@ Signed-off-by: Felix Fietkau 
if (!(skb->dev->features & NETIF_F_GRO))
goto normal;
  
-@@ -5422,6 +5425,48 @@ static void __netdev_adjacent_dev_unlink
+@@ -5425,6 +5428,48 @@ static void __netdev_adjacent_dev_unlink
   _dev->adj_list.lower);
  }
  
@@ -76,7 +76,7 @@ Signed-off-by: Felix Fietkau 
  static int __netdev_upper_dev_link(struct net_device *dev,
   struct net_device *upper_dev, bool master,
   void *private)
-@@ -5493,6 +5538,7 @@ static int __netdev_upper_dev_link(struc
+@@ -5496,6 +5541,7 @@ static int __netdev_upper_dev_link(struc
goto rollback_lower_mesh;
}
  
@@ -84,7 +84,7 @@ Signed-off-by: Felix Fietkau 
call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev,
  _info.info);
return 0;
-@@ -5619,6 +5665,7 @@ void netdev_upper_dev_unlink(struct net_
+@@ -5622,6 +5668,7 @@ void netdev_upper_dev_unlink(struct net_
list_for_each_entry(i, _dev->all_adj_list.upper, list)
__netdev_adjacent_dev_unlink(dev, i->dev, i->ref_nr);
  
@@ -92,7 +92,7 @@ Signed-off-by: Felix Fietkau 
call_netdevice_notifiers_info(NETDEV_CHANGEUPPER, dev,
  _info.info);
  }
-@@ -6159,6 +6206,7 @@ int dev_set_mac_address(struct net_devic
+@@ -6162,6 +6209,7 @@ int dev_set_mac_address(struct net_devic
if (err)
return err;
dev->addr_assign_type = NET_ADDR_SET;
diff --git a/target/linux/generic/pending-4.4/721-phy_packets.patch 
b/target/linux/generic/pending-4.4/721-phy_packets.patch
index 89ffdc5..a7a2327 100644
--- a/target/linux/generic/pending-4.4/721-phy_packets.patch
+++ b/target/linux/generic/pending-4.4/721-phy_packets.patch
@@ -86,7 +86,7 @@
help
 --- a/net/core/dev.c
 +++ b/net/core/dev.c
-@@ -2743,10 +2743,20 @@ static int xmit_one(struct sk_buff *skb,
+@@ -2746,10 +2746,20 @@ static int xmit_one(struct sk_buff *skb,
if (!list_empty(_all) || !list_empty(>ptype_all))
dev_queue_xmit_nit(skb, dev);
  
diff --git a/target/linux/oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch 
b/target/linux/oxnas/patches-4.4/250-add-plxtech-vendor-prefix.patch
index d6c5c62..a94ac22 100644
---

Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9

2017-10-08 Thread Andrey Jr. Melnikov 
Arjen de Korte  wrote:
> Citeren Hauke Mehrtens :

> > This adds support for kernel 4.9.
> > Please test this, I am lacking especially NAND devices.
> >
> > The most recent version of these patches can be found here:
> > https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx
> >
> > Hauke Mehrtens (4):
> >   ar71xx: Copy kernel 4.4 code for kernel 4.9
> >   ar71xx: make the target compile with kernel 4.9
> >   ar71xx: fix section mismatches
> >   ar71xx: switch to kernel 4.9 by default

> I checked the above patches on a WNDR4300 (a NAND device). No issues  
> when building, but the device entered a bootloop after flashing with  
> sysupgrade. Since this is a production system, I didn't have time to  
> dig into what is exactly causing this.

ar934x NAND driver missing cmd_ctrl() function - so NAND devices not work at 
all.

[3.575549] nand: chip.cmd_ctrl() callback is not provided
[3.581103] ar934x-nfc ar934x-nfc: nand_scan_ident failed, err:-22
[3.587515] ar934x-nfc: probe of ar934x-nfc failed with error -22



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

Re: [LEDE-DEV] [PATCH 0/4] ar71xx: add support for kernel 4.9

2017-10-08 Thread Arjen de Korte 

Citeren Hauke Mehrtens :


This adds support for kernel 4.9.
Please test this, I am lacking especially NAND devices.

The most recent version of these patches can be found here:
https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/ar71xx

Hauke Mehrtens (4):
  ar71xx: Copy kernel 4.4 code for kernel 4.9
  ar71xx: make the target compile with kernel 4.9
  ar71xx: fix section mismatches
  ar71xx: switch to kernel 4.9 by default


I checked the above patches on a WNDR4300 (a NAND device). No issues  
when building, but the device entered a bootloop after flashing with  
sysupgrade. Since this is a production system, I didn't have time to  
dig into what is exactly causing this.



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