Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Thu, Oct 12, 2017 at 2:05 AM, Nerijus Baliunas
 wrote:
> On Thu, 12 Oct 2017 01:30:35 +0300 Sergey Ryazanov  
> wrote:
>
>> Try this patch, it should reduce the memory demand of the ethernet
>> driver, so it will have the change to get started on your router.
>>
>> Just put it to target/linux/ixp4xx/patches-4.4 along with the previous
>> one and rebuild your firmware.
>
> I rebuilt the image with ppp and ipv6 excluded, but it did not help,
> after boot only 624 kB MemFree. But with your patch it works.

Current ethernet driver code allocates 64 rxbuffers by 14KB each, what
causes two issues:
1. this require ~800KB (RxBuffers + {Rx|Tx}Descriptors) of RAM to start
2. this require allocation of 64 blocks of 14KB each, so even there
are 800KB of free memory but it is fragmented then allocation could
fail (as in your case).

> I assume the new board type should be added to the config file,
> for which this patch should be enabled?

I do not think so. These two patches are just a quick hacks to fix
common underlying issues.

The first patch completes the work of adding phy(s) without the
standard MDIO interface, so it should be merged to existing patches.

The second patch fixes the issue, which was introduced by
304-ixp4xx_eth_jumboframe.patch, which adds JumboFrames support. So we
either should completely remove jumboframe support patch. Or, if
someone really use jumboframe feature, then we should to rework this
patch to avoid memory issues when using a regular MTU.

I can try to make normal (and formal) fixes in a couple of days. It
would be nice if you could test them when they will be ready.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Nerijus Baliunas 
On Thu, 12 Oct 2017 01:30:35 +0300 Sergey Ryazanov  
wrote:

> Try this patch, it should reduce the memory demand of the ethernet
> driver, so it will have the change to get started on your router.
> 
> Just put it to target/linux/ixp4xx/patches-4.4 along with the previous
> one and rebuild your firmware.

I rebuilt the image with ppp and ipv6 excluded, but it did not help,
after boot only 624 kB MemFree. But with your patch it works.
Thanks a lot!
I assume the new board type should be added to the config file,
for which this patch should be enabled?

Regards,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Thu, Oct 12, 2017 at 12:29 AM, Nerijus Baliunas
 wrote:
> On Thu, 12 Oct 2017 00:15:15 +0300 Sergey Ryazanov  
> wrote:
>> Can you boot in failsafe mode again, check free memory while the
>> interface is Up, then bring it Down and check free memory again? That
>> will show which amount of memory it needs.
>
> # cat /proc/meminfo
> MemTotal:  12232 kB
> MemFree:1108 kB
> # ifconfig eth0 down
> # cat /proc/meminfo
> MemTotal:  12232 kB
> MemFree:2136 kB
>

Try this patch, it should reduce the memory demand of the ethernet
driver, so it will have the change to get started on your router.

Just put it to target/linux/ixp4xx/patches-4.4 along with the previous
one and rebuild your firmware.

-- 
Sergey


99a-ixp4xx-reduce-rxbuf-size.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Nerijus Baliunas 
On Thu, 12 Oct 2017 00:15:15 +0300 Sergey Ryazanov  
wrote:

> >> As a quick test, can you unload all kernel modules and try to set eth0 UP 
> >> again?
> >
> > Unfortunately rmmod with a list of modules does not work:
> > # rmmod ip_tables ip6_tables ip6t_REJECT ...
> > Usage:
> > rmmod module
> > so I had to unload one by one. I unloaded until there was
> > # cat /proc/meminfo
> > MemTotal:  12232 kB
> > MemFree:1304 kB
> >
> > but still does not work:
> > # ifconfig eth0 up
> > ifconfig: SIOCSIFFLAGS: Out of memory
> 
> Can you boot in failsafe mode again, check free memory while the
> interface is Up, then bring it Down and check free memory again? That
> will show which amount of memory it needs.

# cat /proc/meminfo 
MemTotal:  12232 kB
MemFree:1108 kB
# ifconfig eth0 down
# cat /proc/meminfo 
MemTotal:  12232 kB
MemFree:2136 kB
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Wed, Oct 11, 2017 at 11:44 PM, Nerijus Baliunas
 wrote:
> On Wed, 11 Oct 2017 23:28:00 +0300 Sergey Ryazanov  
> wrote:
>
>> > root@LEDE:/# cat /proc/meminfo
>> > MemTotal:  12232 kB
>> > MemFree: 996 kB
>>
>> Looks like this ^^^ is the cause of the "ifconfig up" failure. Your
>> board really have not free RAM.
>>
>> As a quick test, can you unload all kernel modules and try to set eth0 UP 
>> again?
>
> Unfortunately rmmod with a list of modules does not work:
> # rmmod ip_tables ip6_tables ip6t_REJECT ...
> Usage:
> rmmod module
> so I had to unload one by one. I unloaded until there was
> # cat /proc/meminfo
> MemTotal:  12232 kB
> MemFree:1304 kB
>
> but still does not work:
> # ifconfig eth0 up
> ifconfig: SIOCSIFFLAGS: Out of memory
>

Can you boot in failsafe mode again, check free memory while the
interface is Up, then bring it Down and check free memory again? That
will show which amount of memory it needs.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Nerijus Baliunas 
On Wed, 11 Oct 2017 23:28:00 +0300 Sergey Ryazanov  
wrote:

> > root@LEDE:/# cat /proc/meminfo
> > MemTotal:  12232 kB
> > MemFree: 996 kB
> 
> Looks like this ^^^ is the cause of the "ifconfig up" failure. Your
> board really have not free RAM.
> 
> As a quick test, can you unload all kernel modules and try to set eth0 UP 
> again?

Unfortunately rmmod with a list of modules does not work:
# rmmod ip_tables ip6_tables ip6t_REJECT ...
Usage:
rmmod module
so I had to unload one by one. I unloaded until there was
# cat /proc/meminfo 
MemTotal:  12232 kB
MemFree:1304 kB

but still does not work:
# ifconfig eth0 up
ifconfig: SIOCSIFFLAGS: Out of memory

Regards,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Wed, Oct 11, 2017 at 11:01 PM, Nerijus Baliunas
 wrote:
> On Wed, 11 Oct 2017 22:50:40 +0300 Sergey Ryazanov  
> wrote:
>
>> Khm, according to wikidevi your router is equipped with 16MB of RAM,
>> the ethernet driver for xscale SoCs attempts to allocate almost a 1 MB
>> of memory for buffers, so may be there are really no free memory for
>> them.
>
> Yes, RAM is 16 MB.
>
>> Check, please, memory information and list of loaded kernel modules:
>> # cat /proc/meminfo
>> # lsmod
>
> root@LEDE:/# free
>  total   used   free sharedbuffers cached
> Mem: 12232  11352880 40632   2420
> -/+ buffers/cache:   8300   3932
> Swap:0  0  0
> root@LEDE:/# cat /proc/meminfo
> MemTotal:  12232 kB
> MemFree: 996 kB

Looks like this ^^^ is the cause of the "ifconfig up" failure. Your
board really have not free RAM.

As a quick test, can you unload all kernel modules and try to set eth0 UP again?

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Wed, Oct 11, 2017 at 7:17 PM, Nerijus Baliunas
 wrote:
> On Wed, 11 Oct 2017 18:53:40 +0300 Sergey Ryazanov  
> wrote:
>
>> A-ha! The interface survives the down/up circle but does not survive
>> the init procedure.
>>
>> Try to completely avoid bridge usage, e.g.:
>> 1. boot in normal mode
>> 2. disable bridge usage on "lan":
>> # uci delete network.lan.type
>> # uci commit
>> 3. reboot
>> 4. after reboot is completed, check whether IP address has been
>> assigned to eth0.
>> 5. ping
>
> Yes, after reboot eth0 has 192.168.1.1, but it does not ping.
> dmesg:
> [4.970623] init: - preinit -
> [6.462015] random: jshn: uninitialized urandom read (4 bytes read, 10 
> bits of entropy available)
> [6.532512] random: jshn: uninitialized urandom read (4 bytes read, 10 
> bits of entropy available)
> [6.748641] NPE-B: firmware's license can be found in 
> /usr/share/doc/LICENSE.IPL
> [6.756083] NPE-B: firmware functionality 0x2, revision 0x2:1
> [6.764113] eth0: link up, speed 100 Mb/s, full duplex
> [   10.330454] jffs2: notice: (733) jffs2_build_xattr_subsystem: complete 
> building xattr subsystem, 0 of xdatum (0 u.
> [   10.348884] mount_root: switching to jffs2 overlay
> [   10.401588] urandom-seed: Seeding with /etc/urandom.seed
> [   10.553168] eth0: link down
>

Khm, according to wikidevi your router is equipped with 16MB of RAM,
the ethernet driver for xscale SoCs attempts to allocate almost a 1 MB
of memory for buffers, so may be there are really no free memory for
them.

Check, please, memory information and list of loaded kernel modules:
# cat /proc/meminfo
# lsmod

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Nerijus Baliunas 
On Wed, 11 Oct 2017 18:53:40 +0300 Sergey Ryazanov  
wrote:

> A-ha! The interface survives the down/up circle but does not survive
> the init procedure.
> 
> Try to completely avoid bridge usage, e.g.:
> 1. boot in normal mode
> 2. disable bridge usage on "lan":
> # uci delete network.lan.type
> # uci commit
> 3. reboot
> 4. after reboot is completed, check whether IP address has been
> assigned to eth0.
> 5. ping

Yes, after reboot eth0 has 192.168.1.1, but it does not ping.
dmesg:
[4.970623] init: - preinit -
[6.462015] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.532512] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.748641] NPE-B: firmware's license can be found in 
/usr/share/doc/LICENSE.IPL
[6.756083] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.764113] eth0: link up, speed 100 Mb/s, full duplex
[   10.330454] jffs2: notice: (733) jffs2_build_xattr_subsystem: complete 
building xattr subsystem, 0 of xdatum (0 u.
[   10.348884] mount_root: switching to jffs2 overlay
[   10.401588] urandom-seed: Seeding with /etc/urandom.seed
[   10.553168] eth0: link down
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Wed, Oct 11, 2017 at 3:17 PM, Nerijus Baliunas
 wrote:
> On Wed, 11 Oct 2017 14:53:16 +0300 Sergey Ryazanov  
> wrote:
>> Ok. At least we know now that the switch functioning (even without a
>> dedicated driver). One question left: what happens to the Ethernet
>> driver?
>>
>> Can you boot your router in failsafe mode again, and try to toggle
>> eth0 down/up? E.g.:
>> # ifconfig eth0 down
>> # ifconfig eth0 up
>
> root@(none):/# ifconfig eth0 down
> [   42.063281] eth0: link down
> root@(none):/# ifconfig eth0 up
> [   49.665365] eth0: link up, speed 100 Mb/s, full duplex
> root@(none):/# ifconfig eth0 down
> [   62.063281] eth0: link down
> root@(none):/# ifconfig eth0 up
> [   68.295374] eth0: link up, speed 100 Mb/s, full duplex
>

A-ha! The interface survives the down/up circle but does not survive
the init procedure.

Try to completely avoid bridge usage, e.g.:
1. boot in normal mode
2. disable bridge usage on "lan":
# uci delete network.lan.type
# uci commit
3. reboot
4. after reboot is completed, check whether IP address has been
assigned to eth0.
5. ping

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Nerijus Baliunas 
On Wed, 11 Oct 2017 14:53:16 +0300 Sergey Ryazanov  
wrote:

> Ok. At least we know now that the switch functioning (even without a
> dedicated driver). One question left: what happens to the Ethernet
> driver?
> 
> Can you boot your router in failsafe mode again, and try to toggle
> eth0 down/up? E.g.:
> # ifconfig eth0 down
> # ifconfig eth0 up

root@(none):/# ifconfig eth0 down
[   42.063281] eth0: link down
root@(none):/# ifconfig eth0 up
[   49.665365] eth0: link up, speed 100 Mb/s, full duplex
root@(none):/# ifconfig eth0 down
[   62.063281] eth0: link down
root@(none):/# ifconfig eth0 up
[   68.295374] eth0: link up, speed 100 Mb/s, full duplex

ping stops replying after down and replies after up.

> To figure out, is taking down the interface enough to break it, or
> something else happened during the initialization, what prevent us to
> bring it up again.

Regards,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Sergey Ryazanov 
On Wed, Oct 11, 2017 at 12:43 PM, Nerijus Baliunas
 wrote:
> This works:
> = FAILSAFE MODE active 
> # ifconfig -a
> eth0  Link 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: fe80::218:39ff:fe21:dae/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>
> Ping to 192.168.1.1 answers, after pinging:
>   RX packets:5 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:14 errors:0 dropped:0 overruns:0 carrier:0

Ok. At least we know now that the switch functioning (even without a
dedicated driver). One question left: what happens to the Ethernet
driver?

Can you boot your router in failsafe mode again, and try to toggle
eth0 down/up? E.g.:
# ifconfig eth0 down
# ifconfig eth0 up

To figure out, is taking down the interface enough to break it, or
something else happened during the initialization, what prevent us to
bring it up again.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-11 Thread Nerijus Baliunas 
On Wed, 11 Oct 2017 02:07:00 +0300 Sergey Ryazanov  
wrote:

> Ok. I am starting to run out of ideas. Let's start guessing.
> 
> eth0 works at least during preinit. You could check your switch
> functioning in the failsafe mode:
> 1. Power on router
> 2. When the "Press the [f] key and hit [enter]" line will be printed
> on serial console then press the "f" and hit [enter] :)
> 3. You could check which IP address configured on eth0 with ifconfig
> and if there are not address, then configure it manually
> 4. Try to pinging in order to check switch functioning

This works:
= FAILSAFE MODE active 
# ifconfig -a
eth0  Link 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: fe80::218:39ff:fe21:dae/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

Ping to 192.168.1.1 answers, after pinging:
  RX packets:5 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14 errors:0 dropped:0 overruns:0 carrier:0

> Another guess is to try to disable bridge before bringing eth0 up:
> 1. Boot your router in normal mode
> 2. Check whether eth0 is added to the bridge or not:
>   # brctl show
> 3. Disable the bridge and configure eth0 for standalone working:
>  # brctl delif br-lan eth0
>  # ifconfig br-lan down
>  # ifconfig eth0 192.168.0.10 up
> 4. Try to pinging

This does not:
# brctl show
bridge name bridge id   STP enabled interfaces
br-lan  7fff.001839210dae   no  eth0
# brctl delif br-lan eth0
# ifconfig br-lan down
# ifconfig eth0 192.168.0.10 up
ifconfig: SIOCSIFFLAGS: Out of memory
# brctl show
bridge name bridge id   STP enabled interfaces
br-lan  7fff.001839210dae   no
# 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
  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:0 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:0 (0.0 B)  TX bytes:1551 (1.5 KiB)

Ping to neither 192.168.1.1 nor 192.168.0.10 does not answer.

Regards,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-10 Thread Sergey Ryazanov 
On Mon, Oct 9, 2017 at 1:58 AM, Nerijus Baliunas
 wrote:
> 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
>

Ok. I am starting to run out of ideas. Let's start guessing.

eth0 works at least during preinit. You could check your switch
functioning in the failsafe mode:
1. Power on router
2. When the "Press the [f] key and hit [enter]" line will be printed
on serial console then press the "f" and hit [enter] :)
3. You could check which IP address configured on eth0 with ifconfig
and if there are not address, then configure it manually
4. Try to pinging in order to check switch functioning

Another guess is to try to disable bridge before bringing eth0 up:
1. Boot your router in normal mode
2. Check whether eth0 is added to the bridge or not:
  # brctl show
3. Disable the bridge and configure eth0 for standalone working:
 # brctl delif br-lan eth0
 # ifconfig br-lan down
 # ifconfig eth0 192.168.0.10 up
4. Try to pinging

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Nerijus Baliunas 
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Nerijus Baliunas 
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-08 Thread Nerijus Baliunas 
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-10-02 Thread Sergey Ryazanov 
Hello Nerijus,

On Fri, Sep 29, 2017 at 7:32 PM, Nerijus Baliunas
 wrote:
> On Fri, 8 Sep 2017 22:50:13 +0300 Sergey Ryazanov  
> wrote:
>> >> >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
>> >> >> messages   log?  If  not then the mwswitch driver did not attached and
>> >> >> you  should  fix  this  first.  And  only  then  go  to  the interface
>> >> >> configuration.
>> >> >
>> >> > No, dmesg|grep 6060 does not show anything. How do I fix it?
>> >>
>> >> Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
>> >> scans to detect connected PHYs.
>> >
>> > I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
>> > # dmesg|grep -i MII|grep -v took
>> > ...
>> > [0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
>> > [0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
>> > [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602
>>
>> Looks like mvswitch driver tries to check chip here and got an
>> expected value 0x060X from register 3. So on the one hand the driver
>> is functioning, but on the other hand it can not detect switch IC.
>>
>> Can you go to the /sys/class/mdio_bus/ and for each bus check driver
>> and ID of the each detected device. E.g.:
>> # cd /sys/class/mdio_bus
>> # ls -l */*/driver
>
> lrwxrwxrwx1 root root 0 Jul 22 21:31 
> ixp4xx-eth-0/ixp4xx-eth-0:01/driver -> 
> ../../../../../bus/mdio_bus/drivers/Generic PHY
> lrwxrwxrwx1 root root 0 Jul 22 21:31 
> ixp4xx-eth-0/ixp4xx-eth-0:10/driver -> 
> ../../../../../bus/mdio_bus/drivers/Marvell 88E6060
>

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.

-- 
Sergey


999-ixp4xx-fix-nophy-link-status.patch
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-09-08 Thread Sergey Ryazanov 
On Fri, Jul 28, 2017 at 1:03 AM, Nerijus Baliunas
 wrote:
> On Thu, 27 Jul 2017 23:43:19 +0300 Sergey Ryazanov  
> wrote:
>
>> >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
>> >> messages   log?  If  not then the mwswitch driver did not attached and
>> >> you  should  fix  this  first.  And  only  then  go  to  the interface
>> >> configuration.
>> >
>> > No, dmesg|grep 6060 does not show anything. How do I fix it?
>>
>> Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
>> scans to detect connected PHYs.
>
> I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
> # dmesg|grep -i MII|grep -v took
> ...
> [0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
> [0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
> [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602

Looks like mvswitch driver tries to check chip here and got an
expected value 0x060X from register 3. So on the one hand the driver
is functioning, but on the other hand it can not detect switch IC.

Can you go to the /sys/class/mdio_bus/ and for each bus check driver
and ID of the each detected device. E.g.:
# cd /sys/class/mdio_bus
# ls -l */*/driver
# ls -l */*/phy_id
# cat */*/phy_id

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-09-08 Thread Nerijus Baliunas 
On Fri, 28 Jul 2017 01:03:16 +0300 Nerijus Baliunas 
 wrote:

> On Thu, 27 Jul 2017 23:43:19 +0300 Sergey Ryazanov  
> wrote:
> 
> > >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
> > >> messages   log?  If  not then the mwswitch driver did not attached and
> > >> you  should  fix  this  first.  And  only  then  go  to  the interface
> > >> configuration.
> > >
> > > No, dmesg|grep 6060 does not show anything. How do I fix it?
> > 
> > Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
> > scans to detect connected PHYs.

Is this the info which was needed or should I provide something else?

> I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
> # dmesg|grep -i MII|grep -v took
> [0.971141] IXP4xx MII Bus #0: MII read failed
> [0.971173] IXP4xx MII Bus #0: MII read [2] -> 0x
> [0.971268] IXP4xx MII Bus #0: MII read failed
> [0.971299] IXP4xx MII Bus #0: MII read [3] -> 0x
> [0.971400] IXP4xx MII Bus #1: MII read [2] -> 0x0
> [0.971500] IXP4xx MII Bus #1: MII read [3] -> 0x8201
> [0.973099] IXP4xx MII Bus #2: MII read failed
> [0.973132] IXP4xx MII Bus #2: MII read [2] -> 0x
> [0.973227] IXP4xx MII Bus #2: MII read failed
> [0.973258] IXP4xx MII Bus #2: MII read [3] -> 0x
> [0.973354] IXP4xx MII Bus #3: MII read failed
> [0.973385] IXP4xx MII Bus #3: MII read [2] -> 0x
> [0.973479] IXP4xx MII Bus #3: MII read failed
> [0.973511] IXP4xx MII Bus #3: MII read [3] -> 0x
> [0.973606] IXP4xx MII Bus #4: MII read failed
> [0.973637] IXP4xx MII Bus #4: MII read [2] -> 0x
> [0.973731] IXP4xx MII Bus #4: MII read failed
> [0.973762] IXP4xx MII Bus #4: MII read [3] -> 0x
> [0.973857] IXP4xx MII Bus #5: MII read failed
> [0.973888] IXP4xx MII Bus #5: MII read [2] -> 0x
> [0.973982] IXP4xx MII Bus #5: MII read failed
> [0.974014] IXP4xx MII Bus #5: MII read [3] -> 0x
> [0.974109] IXP4xx MII Bus #6: MII read failed
> [0.974140] IXP4xx MII Bus #6: MII read [2] -> 0x
> [0.974235] IXP4xx MII Bus #6: MII read failed
> [0.974266] IXP4xx MII Bus #6: MII read [3] -> 0x
> [0.974361] IXP4xx MII Bus #7: MII read failed
> [0.974392] IXP4xx MII Bus #7: MII read [2] -> 0x
> [0.974486] IXP4xx MII Bus #7: MII read failed
> [0.974517] IXP4xx MII Bus #7: MII read [3] -> 0x
> [0.974613] IXP4xx MII Bus #8: MII read failed
> [0.974644] IXP4xx MII Bus #8: MII read [2] -> 0x
> [0.974739] IXP4xx MII Bus #8: MII read failed
> [0.974770] IXP4xx MII Bus #8: MII read [3] -> 0x
> [0.974865] IXP4xx MII Bus #9: MII read failed
> [0.974896] IXP4xx MII Bus #9: MII read [2] -> 0x
> [0.974990] IXP4xx MII Bus #9: MII read failed
> [0.975021] IXP4xx MII Bus #9: MII read [3] -> 0x
> [0.975118] IXP4xx MII Bus #10: MII read failed
> [0.975149] IXP4xx MII Bus #10: MII read [2] -> 0x
> [0.975245] IXP4xx MII Bus #10: MII read failed
> [0.975276] IXP4xx MII Bus #10: MII read [3] -> 0x
> [0.975372] IXP4xx MII Bus #11: MII read failed
> [0.975403] IXP4xx MII Bus #11: MII read [2] -> 0x
> [0.975498] IXP4xx MII Bus #11: MII read failed
> [0.975530] IXP4xx MII Bus #11: MII read [3] -> 0x
> [0.975626] IXP4xx MII Bus #12: MII read failed
> [0.975657] IXP4xx MII Bus #12: MII read [2] -> 0x
> [0.975752] IXP4xx MII Bus #12: MII read failed
> [0.975784] IXP4xx MII Bus #12: MII read [3] -> 0x
> [0.975879] IXP4xx MII Bus #13: MII read failed
> [0.975911] IXP4xx MII Bus #13: MII read [2] -> 0x
> [0.976006] IXP4xx MII Bus #13: MII read failed
> [0.976037] IXP4xx MII Bus #13: MII read [3] -> 0x
> [0.976133] IXP4xx MII Bus #14: MII read failed
> [0.976165] IXP4xx MII Bus #14: MII read [2] -> 0x
> [0.976261] IXP4xx MII Bus #14: MII read failed
> [0.976292] IXP4xx MII Bus #14: MII read [3] -> 0x
> [0.976388] IXP4xx MII Bus #15: MII read failed
> [0.976419] IXP4xx MII Bus #15: MII read [2] -> 0x
> [0.976514] IXP4xx MII Bus #15: MII read failed
> [0.976545] IXP4xx MII Bus #15: MII read [3] -> 0x
> [0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
> [0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
> [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602
> [0.979235] IXP4xx MII Bus #17: MII read [2] -> 0x141
> [0.979336] IXP4xx MII Bus #17: MII read [3] -> 0xC87
> [0.981110] IXP4xx MII Bus #18: MII read [2] -> 0x141
> [0.981211] IXP4xx MII Bus #18: MII read [3] -> 0xC87
> [0.982664] IXP4xx MII Bus #19: MII read [2] -> 0x141
> [0.982765] IXP4xx MII Bus #19: MII read [3] -> 0xC87
> [0.984184] IXP4xx MII Bus #20: MII read [2] -> 0x141
> [0.984285] IXP4xx MII Bus #20: MII read [3] -> 0xC87
> [0.985770] IXP4xx MII Bus #21: MII read [2] -> 0x0
> [0.985870] IXP4xx

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-27 Thread Nerijus Baliunas 
On Thu, 27 Jul 2017 23:43:19 +0300 Sergey Ryazanov  
wrote:

> >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
> >> messages   log?  If  not then the mwswitch driver did not attached and
> >> you  should  fix  this  first.  And  only  then  go  to  the interface
> >> configuration.
> >
> > No, dmesg|grep 6060 does not show anything. How do I fix it?
> 
> Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
> scans to detect connected PHYs.

I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
# dmesg|grep -i MII|grep -v took
[0.971141] IXP4xx MII Bus #0: MII read failed
[0.971173] IXP4xx MII Bus #0: MII read [2] -> 0x
[0.971268] IXP4xx MII Bus #0: MII read failed
[0.971299] IXP4xx MII Bus #0: MII read [3] -> 0x
[0.971400] IXP4xx MII Bus #1: MII read [2] -> 0x0
[0.971500] IXP4xx MII Bus #1: MII read [3] -> 0x8201
[0.973099] IXP4xx MII Bus #2: MII read failed
[0.973132] IXP4xx MII Bus #2: MII read [2] -> 0x
[0.973227] IXP4xx MII Bus #2: MII read failed
[0.973258] IXP4xx MII Bus #2: MII read [3] -> 0x
[0.973354] IXP4xx MII Bus #3: MII read failed
[0.973385] IXP4xx MII Bus #3: MII read [2] -> 0x
[0.973479] IXP4xx MII Bus #3: MII read failed
[0.973511] IXP4xx MII Bus #3: MII read [3] -> 0x
[0.973606] IXP4xx MII Bus #4: MII read failed
[0.973637] IXP4xx MII Bus #4: MII read [2] -> 0x
[0.973731] IXP4xx MII Bus #4: MII read failed
[0.973762] IXP4xx MII Bus #4: MII read [3] -> 0x
[0.973857] IXP4xx MII Bus #5: MII read failed
[0.973888] IXP4xx MII Bus #5: MII read [2] -> 0x
[0.973982] IXP4xx MII Bus #5: MII read failed
[0.974014] IXP4xx MII Bus #5: MII read [3] -> 0x
[0.974109] IXP4xx MII Bus #6: MII read failed
[0.974140] IXP4xx MII Bus #6: MII read [2] -> 0x
[0.974235] IXP4xx MII Bus #6: MII read failed
[0.974266] IXP4xx MII Bus #6: MII read [3] -> 0x
[0.974361] IXP4xx MII Bus #7: MII read failed
[0.974392] IXP4xx MII Bus #7: MII read [2] -> 0x
[0.974486] IXP4xx MII Bus #7: MII read failed
[0.974517] IXP4xx MII Bus #7: MII read [3] -> 0x
[0.974613] IXP4xx MII Bus #8: MII read failed
[0.974644] IXP4xx MII Bus #8: MII read [2] -> 0x
[0.974739] IXP4xx MII Bus #8: MII read failed
[0.974770] IXP4xx MII Bus #8: MII read [3] -> 0x
[0.974865] IXP4xx MII Bus #9: MII read failed
[0.974896] IXP4xx MII Bus #9: MII read [2] -> 0x
[0.974990] IXP4xx MII Bus #9: MII read failed
[0.975021] IXP4xx MII Bus #9: MII read [3] -> 0x
[0.975118] IXP4xx MII Bus #10: MII read failed
[0.975149] IXP4xx MII Bus #10: MII read [2] -> 0x
[0.975245] IXP4xx MII Bus #10: MII read failed
[0.975276] IXP4xx MII Bus #10: MII read [3] -> 0x
[0.975372] IXP4xx MII Bus #11: MII read failed
[0.975403] IXP4xx MII Bus #11: MII read [2] -> 0x
[0.975498] IXP4xx MII Bus #11: MII read failed
[0.975530] IXP4xx MII Bus #11: MII read [3] -> 0x
[0.975626] IXP4xx MII Bus #12: MII read failed
[0.975657] IXP4xx MII Bus #12: MII read [2] -> 0x
[0.975752] IXP4xx MII Bus #12: MII read failed
[0.975784] IXP4xx MII Bus #12: MII read [3] -> 0x
[0.975879] IXP4xx MII Bus #13: MII read failed
[0.975911] IXP4xx MII Bus #13: MII read [2] -> 0x
[0.976006] IXP4xx MII Bus #13: MII read failed
[0.976037] IXP4xx MII Bus #13: MII read [3] -> 0x
[0.976133] IXP4xx MII Bus #14: MII read failed
[0.976165] IXP4xx MII Bus #14: MII read [2] -> 0x
[0.976261] IXP4xx MII Bus #14: MII read failed
[0.976292] IXP4xx MII Bus #14: MII read [3] -> 0x
[0.976388] IXP4xx MII Bus #15: MII read failed
[0.976419] IXP4xx MII Bus #15: MII read [2] -> 0x
[0.976514] IXP4xx MII Bus #15: MII read failed
[0.976545] IXP4xx MII Bus #15: MII read [3] -> 0x
[0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
[0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
[0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602
[0.979235] IXP4xx MII Bus #17: MII read [2] -> 0x141
[0.979336] IXP4xx MII Bus #17: MII read [3] -> 0xC87
[0.981110] IXP4xx MII Bus #18: MII read [2] -> 0x141
[0.981211] IXP4xx MII Bus #18: MII read [3] -> 0xC87
[0.982664] IXP4xx MII Bus #19: MII read [2] -> 0x141
[0.982765] IXP4xx MII Bus #19: MII read [3] -> 0xC87
[0.984184] IXP4xx MII Bus #20: MII read [2] -> 0x141
[0.984285] IXP4xx MII Bus #20: MII read [3] -> 0xC87
[0.985770] IXP4xx MII Bus #21: MII read [2] -> 0x0
[0.985870] IXP4xx MII Bus #21: MII read [3] -> 0x0
[0.987322] IXP4xx MII Bus #22: MII read [2] -> 0x0
[0.987422] IXP4xx MII Bus #22: MII read [3] -> 0x0
[0.988983] IXP4xx MII Bus #23: MII read [2] -> 0x0
[0.989084] IXP4xx MII Bus #23: MII read [3] -> 0x0
[0.990553] IXP4xx MII Bus #24: MII read [2] -> 0x0
[0.990653] IXP4xx MII Bus #24:

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-21 Thread Nerijus Baliūnas 

2017-07-21 01:41, Sergey Ryazanov rašė:

You   should   disable   CONFIG_NET_DSA_MV88E6060   and   select  only
CONFIG_MVSWITCH_PHY=y  option.  This  two different drivers, the first
one is mainstream Linux driver, and the second one is OpenWRT specific
driver, which is mach more simple and small.


This driver uses VLAN tags to determine which port the frame should be
sent from. Try to create couple of VLAN sub-interfaces on eth0 with ID
1 and 2 and work with them.


I'll try.


Yes,  use  the  latest version of LEDE, please, to avoid facing with
long-forgotten bugs.


Tried the latest LEDE. Now I see in the boot log:
[6.507617] NPE-B: firmware's license can be found in 
/usr/share/doc/LICENSE.IPL

[6.515168] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.523171] eth0: link up, speed 0 Mb/s, full duplex

and now I see RX and TX packets on eth0 (they were 0 before).

How do I configure vlan? Here I changed eth0 to eth0.1:

config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'

And just copy/pasted from another router:

config switch
option name 'rt305x'
option reset '1'
option enable_vlan '1'

config switch_vlan
option device 'rt305x'
option vlan '1'
option ports '0 1 2 3 5 6t'

config switch_vlan
option device 'rt305x'
option vlan '2'
option ports '4 6t'

But still RX and TX packets are on eth0, not eth0.1:
# 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: fd63:bf56:4b8::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
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:1 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:241 (241.0 B)  TX bytes:1551 (1.5 KiB)

eth0.1Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE
  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)

eth1  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AF
  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:100
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

loLink encap:Local Loopback

Thanks,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-20 Thread Sergey Ryazanov 
Hello Nerijus,

Friday, July 21, 2017, 12:49:29 AM, you wrote:
> 2017-07-21 00:36, Sergey Ryazanov rašė:
>>> No received/sent packets on br-lan and eth0 before and after modprobe
>>> mv88e6060.ko.
>> 
>> Did  you  saw  the  "Marvel 88E6060 PHY driver attached" string in the
>> kernel messages? If so then at least the driver detects switch chip.
>
> No. BTW, do I understand correctly - I have to use mv88e6060.ko which
> should use CONFIG_MVSWITCH_PHY or is CONFIG_MVSWITCH_PHY alone enough?

You   should   disable   CONFIG_NET_DSA_MV88E6060   and   select  only
CONFIG_MVSWITCH_PHY=y  option.  This  two different drivers, the first
one is mainstream Linux driver, and the second one is OpenWRT specific
driver, which is mach more simple and small.

>> This driver uses VLAN tags to determine which port the frame should be
>> sent from. Try to create couple of VLAN sub-interfaces on eth0 with ID
>> 1 and 2 and work with them.
>
> I'll try.
>
>> And BTW do you use OpenWRT or LEDE and which version?
>
> Actually I use barrier breaker, as the device has only 16 MB RAM so
> I thought an earlier version will use less resources. But I can try
> later versions.

Yes,  use  the  latest version of LEDE, please, to avoid facing with
long-forgotten bugs.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-20 Thread Nerijus Baliūnas 

2017-07-21 00:36, Sergey Ryazanov rašė:

No received/sent packets on br-lan and eth0 before and after modprobe
mv88e6060.ko.


Did  you  saw  the  "Marvel 88E6060 PHY driver attached" string in the
kernel messages? If so then at least the driver detects switch chip.


No. BTW, do I understand correctly - I have to use mv88e6060.ko which
should use CONFIG_MVSWITCH_PHY or is CONFIG_MVSWITCH_PHY alone enough?


This driver uses VLAN tags to determine which port the frame should be
sent from. Try to create couple of VLAN sub-interfaces on eth0 with ID
1 and 2 and work with them.


I'll try.


And BTW do you use OpenWRT or LEDE and which version?


Actually I use barrier breaker, as the device has only 16 MB RAM so
I thought an earlier version will use less resources. But I can try
later versions.

Thanks,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-20 Thread Sergey Ryazanov 
Hello Nerijus,

Wednesday, July 19, 2017, 1:00:43 PM, you wrote:
> 2017-07-19 04:02, Sergey Ryazanov rašė:
>>> Linksys WRT300N v2.0 has Marvell 88e6060 switch. But ixp4xx arch does not
>>> have
>>> its driver enabled (ar71xx has it). I added CONFIG_NET_DSA_MV88E6060=m,
>>> but when I modprobe mv88e6060.ko, nothing happens. It seems driver does not 
>>> hook
>>> on any hardware:
>> 
>> This happened because this driver is quite useless on their own. It
>> requires some assistance to properly detects switch IC either from
>> arch code via platform device data or via DTS.
>> 
>> Try to use OpenWRT/LEDE specific driver, which is used by ath25 and
>> ar7 platforms by enabling CONFIG_MVSWITCH_PHY option in the kernel.
>
> I enabled CONFIG_MVSWITCH_PHY=y. But still no ethernet. When booting:
>
> [1.049060] libphy: IXP4xx MII Bus: probed
> [1.056182] eth0: MII PHY 32 on NPE-B
> [1.062966] eth1: MII PHY 1 on NPE-C
>
> [   43.178831] NPE-B: firmware functionality 0x2, revision 0x2:1
> [   43.209983] device eth0 entered promiscuous mode
> [   43.49] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
>
> While on a working system as I found in Chinese forum ir should probably be:
> eth0: MII PHY 16 on NPE-B
> eth0: MII PHY 17 on NPE-B
> eth0: MII PHY 18 on NPE-B
> eth0: MII PHY 19 on NPE-B
> eth1: MII PHY 1 on NPE-C
>
> NPE-B: firmware functionality 0x2, revision 0x2:1
> eth0: link down
> device eth0 entered promiscuous mode
> firmware: requesting NPE-C
> NPE-C: firmware functionality 0x5, revision 0x2:1
>
> No received/sent packets on br-lan and eth0 before and after modprobe 
> mv88e6060.ko.

Did  you  saw  the  "Marvel 88E6060 PHY driver attached" string in the
kernel messages? If so then at least the driver detects switch chip.

This driver uses VLAN tags to determine which port the frame should be
sent from. Try to create couple of VLAN sub-interfaces on eth0 with ID
1 and 2 and work with them.

And BTW do you use OpenWRT or LEDE and which version?

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-19 Thread Nerijus Baliūnas 

2017-07-19 04:02, Sergey Ryazanov rašė:


Linksys WRT300N v2.0 has Marvell 88e6060 switch. But ixp4xx arch does not 
have

its driver enabled (ar71xx has it). I added CONFIG_NET_DSA_MV88E6060=m,
but when I modprobe mv88e6060.ko, nothing happens. It seems driver does not 
hook

on any hardware:


This happened because this driver is quite useless on their own. It
requires some assistance to properly detects switch IC either from
arch code via platform device data or via DTS.

Try to use OpenWRT/LEDE specific driver, which is used by ath25 and
ar7 platforms by enabling CONFIG_MVSWITCH_PHY option in the kernel.


I enabled CONFIG_MVSWITCH_PHY=y. But still no ethernet. When booting:

[1.049060] libphy: IXP4xx MII Bus: probed
[1.056182] eth0: MII PHY 32 on NPE-B
[1.062966] eth1: MII PHY 1 on NPE-C

[   43.178831] NPE-B: firmware functionality 0x2, revision 0x2:1
[   43.209983] device eth0 entered promiscuous mode
[   43.49] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready

While on a working system as I found in Chinese forum ir should probably be:
eth0: MII PHY 16 on NPE-B
eth0: MII PHY 17 on NPE-B
eth0: MII PHY 18 on NPE-B
eth0: MII PHY 19 on NPE-B
eth1: MII PHY 1 on NPE-C

NPE-B: firmware functionality 0x2, revision 0x2:1
eth0: link down
device eth0 entered promiscuous mode
firmware: requesting NPE-C
NPE-C: firmware functionality 0x5, revision 0x2:1

No received/sent packets on br-lan and eth0 before and after modprobe 
mv88e6060.ko.


Thanks,
Nerijus
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-18 Thread Sergey Ryazanov 
Forgot CC lede-dev

> Linksys WRT300N v2.0 has Marvell 88e6060 switch. But ixp4xx arch does not have
> its driver enabled (ar71xx has it). I added CONFIG_NET_DSA_MV88E6060=m,
> but when I modprobe mv88e6060.ko, nothing happens. It seems driver does not 
> hook
> on any hardware:

This happened because this driver is quite useless on their own. It
requires some assistance to properly detects switch IC either from
arch code via platform device data or via DTS.

Try to use OpenWRT/LEDE specific driver, which is used by ath25 and
ar7 platforms by enabling CONFIG_MVSWITCH_PHY option in the kernel.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MV88E6060 switch

2017-07-18 Thread Sergey Ryazanov 
On Mon, Jul 17, 2017 at 5:29 PM, Nerijus Baliunas
 wrote:
> Linksys WRT300N v2.0 has Marvell 88e6060 switch. But ixp4xx arch does not have
> its driver enabled (ar71xx has it). I added CONFIG_NET_DSA_MV88E6060=m,
> but when I modprobe mv88e6060.ko, nothing happens. It seems driver does not 
> hook
> on any hardware:

This happened because this driver is quite useless on their own. It
requires some assistance to properly detects switch IC either from
arch code via platform device data or via DTS.

Try to use OpenWRT/LEDE specific driver, which is used by ath25 and
ar7 platforms by enabling CONFIG_MVSWITCH_PHY option in the kernel.

-- 
Sergey
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel