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

2017-10-14 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 Thu, 12 Oct 2017 03:11:21 +0300 Sergey Ryazanov  
wrote:

> > 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.

Thank you. Another question about wifi - there is no /etc/config/wireless
file, and even if I create it and reboot the device, wifi is not working
and there is no wlan0 interface. ath5k module is loaded.

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-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

___
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-11 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 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

--- 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-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
___
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-11 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 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


--- 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-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

___
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-11 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 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

--- 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-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

___
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-11 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 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
MemAvailable:   3316 kB
Buffers: 648 kB
Cached: 2384 kB
SwapCached:0 kB
Active: 3012 kB
Inactive:796 kB
Active(anon):804 kB
Inactive(anon):   20 kB
Active(file):   2208 kB
Inactive(file):  776 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal: 0 kB
SwapFree:  0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages:   792 kB
Mapped: 1680 kB
Shmem:48 kB
Slab:   4436 kB
SReclaimable:848 kB
SUnreclaim: 3588 kB
KernelStack: 280 kB
PageTables:  136 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:6116 kB
Committed_AS:   2456 kB
VmallocTotal:1015808 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
root@LEDE:/# lsmod
ath16602  1 ath5k
ath5k 177618  0 
cfg80211  231978  3 ath5k,ath,mac80211
cmac2157  0 
compat 11563  3 ath5k,mac80211,cfg80211
crc_ccitt   1035  1 ppp_async
crypto_hash10802  2 mac80211,cmac
ip_tables   9079  3 iptable_nat,iptable_mangle,iptable_filter
ip6_tables  8885  2 ip6table_mangle,ip6table_filter
ip6t_REJECT  972  2 
ip6table_filter  734  1 
ip6table_mangle 1054  1 
ipt_MASQUERADE   754  1 
ipt_REJECT   938  2 
iptable_filter   796  1 
iptable_mangle   924  1 
iptable_nat 1073  1 
mac80211  405550  1 ath5k
nf_conntrack   46856  8 
nf_conntrack_ipv6,xt_state,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_e
nf_conntrack_ipv4   5251 10 
nf_conntrack_ipv6   5500  5 
nf_conntrack_rtcache2482  0 
nf_defrag_ipv4   924  1 nf_conntrack_ipv4
nf_defrag_ipv6  9209  1 nf_conntrack_ipv6
nf_log_common   2191  2 nf_log_ipv4,nf_log_ipv6
nf_log_ipv4 2998  0 
nf_log_ipv6 3223  0 
nf_nat  8675  4 
xt_nat,nf_nat_redirect,nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_nat_ipv4 3367  1 iptable_nat
nf_nat_masquerade_ipv41517  1 ipt_MASQUERADE
nf_nat_redirect  955  1 xt_REDIRECT
nf_reject_ipv4  1795  1 ipt_REJECT
nf_reject_ipv6  2088  1 ip6t_REJECT
ppp_async   6445  0 
ppp_generic20137  3 pppoe,ppp_async,pppox
pppoe   7959  0 
pppox   1319  1 pppoe
slhc3922  1 ppp_generic
x_tables   10587 22 
ipt_REJECT,ipt_MASQUERADE,xt_time,xt_tcpudp,xt_state,xt_nat,xt_multiport,xt_mark,xt_s
xt_LOG   899  0 
xt_REDIRECT  885  0 
xt_TCPMSS   2664  2 
xt_comment   555125 
xt_conntrack2424 14 
xt_limit1129 20 
xt_mac   711  0 
xt_mark  768  0 
xt_multiport1332  0 
xt_nat  1405  0 
xt_state 841  0 
xt_tcpudp   1816 10 
xt_time 1702  0 


--- 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-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

___
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-11 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 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


--- 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-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

___
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-11 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 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

--- 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-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

___
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-11 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 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

--- 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-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

___
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 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] [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
___
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-09-29 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 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

> # ls -l */*/phy_id

-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:01/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:10/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:11/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:12/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:13/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:14/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:15/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:16/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:17/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:18/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:19/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1a/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1b/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1c/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1d/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1e/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1f/phy_id

> # cat */*/phy_id

0x8201
0x088e6060
0x01410c87
0x01410c87
0x01410c87
0x01410c87
0x
0x
0x
0x0602
0x0602
0x0602
0x0602
0x0602
0x0602
0x
0x

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-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

___
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-07-27 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 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

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

2017-07-27 Thread Sergey Ryazanov 
Hello Nerijus,

Friday, July 21, 2017, 7:47:56 PM, you wrote:
> 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
>

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.

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

Did you try to use tcpdump to see what RXed by the interface?

> How do I configure vlan?

Skip  the  UCI and use interface configuration utilities. E.g. you can
create vlan interface with help of ip utility:
root@lede:~# ip link add link eth0 name eth0.1 type vlan id 1
root@lede:~# ip link add link eth0 name eth0.2 type vlan id 2

In  the  another  mail,  you asked do you need the swconfig utility or
not.  No  you  do  not  need swconfig to control this driver. mwswitch
looks like the last driver which do not have any control knobs. Almost
all  it  configuration  is  hardcoded inside the code. It just accepts
VLAN tagged frame from the upper layer and then use VLAD Id from it to
select  egress  port. And the VLANID<->Port mapping table is hardcoded
inside the driver.

-- 
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-07-23 Thread Nerijus Baliūnas 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 ---

2017-07-23 21:38, Florian Fainelli rašė:


Does not work. Do I need to have swconfig installed in order to
get the switch working? Because by default it is not installed.


Yes, it is necessary with this switch driver to have swconfig installed, 
otherwise nothing would

push CLEAN configurations to the mv88e6060 switch.


How do I add it? I added swconfig to target/linux/ixp4xx/Makefile:
DEFAULT_PACKAGES += ixp4xx-microcode fconfig swconfig

but still no swconfig in generated lede-ixp4xx-generic-squashfs.img.

Thanks,
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-07-21 Thread Nerijus Baliūnas 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 ---

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


--- 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-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


___
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-07-20 Thread Nerijus Baliūnas 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 ---

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


--- 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-07-19 Thread Nerijus Baliūnas 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 ---

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


--- 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-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

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