[snip]
I'm using an i210 w/ mdio to connect to cascaded mv88e6390 switches on
an Intel platform. I have patches based on patches sent in 2014 that
allow use of mdio and configuration with device-tree. I'd like to get
them upstreamed but there are some unresolved problems. For one I have
no way of
> > The current boot sequence is below:
> > 1. i210 driver loads
> > 2. Device Tree overlay installed (in addition to ACPI)
> >- Includes DSA switch and ports, but master port was incorrectly
> > specified as the EMACLite IP module, which had a DT node
> >- No DT node for the i210
> > 3. MF
> The current boot sequence is below:
> 1. i210 driver loads
> 2. Device Tree overlay installed (in addition to ACPI)
>- Includes DSA switch and ports, but master port was incorrectly
> specified as the EMACLite IP module, which had a DT node
>- No DT node for the i210
> 3. MFD driver reads
Subject: Re: DSA
> On Mon, 30 Apr 2018 14:50:30 +0200, Andrew Lunn wrote:
>
> > On Fri, Apr 27, 2018 at 06:10:55PM +, Dave Richards wrote:
> > > Hello,
> > >
> > > I am building a prototype for a new product based on a Lanner,
Inc. embedded PC.
> &g
> > Take a look at arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> >
> > &pcie {
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_pcie>;
> > reset-gpio = <&gpio7 12 GPIO_ACTIVE_LOW>;
> > status = "okay";
> >
> > host@0 {
> > reg = <0 0 0 0 0
On Tue, 2021-03-09 at 17:46 +0100, Andrew Lunn wrote:
>
> > I have a board that uses the Intel i210, and I'd like it be the DSA
> > master. I'm looking for suggestions on how to proceed.
> >
> > My configuration is an Intel E3950 CPU running Linux 4.19.62,
>
> Hi Chris
>
> That is old. Can you up
> I have a board that uses the Intel i210, and I'd like it be the DSA
> master. I'm looking for suggestions on how to proceed.
>
> My configuration is an Intel E3950 CPU running Linux 4.19.62,
Hi Chris
That is old. Can you update to 5.10.22? If you plan submitting any
kernel patches, you will n
--
Chris Wyse
Embedded Software Development
(203) 888-7914 ext 203
Canoga Perkins
100 Bank St,
Seymour, CT 06483
On Mon, 2018-04-30 at 14:50 +0200, Andrew Lunn wrote:
> On Fri, Apr 27, 2018 at 06:10:55PM +, Dave Richards wrote:
>
> Hello,
>
> I am building a prototype for a new product bas
Hi Peter
> Maybe I can get some information from our support if
> DSA_TAG_PROTO_EDSA is supported for the port config (0x4) register
> on the 6341 switch after all or if it should be omitted.
It would be nice to hear what Marvell says about this. It does seem an
odd thing to remove, so it could b
On Tue, Dec 01, 2020 at 09:49, Peter Vollmer wrote:
> On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
>> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
>> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
>> > requests (only the requests) are also se
On Thu, Nov 26, 2020 at 11:23:59PM +0100, Andrew Lunn wrote:
> > > I tested setting .tag_protocol=DSA_TAG_PROTO_DSA for the 6341 switch
> > > instead, resulting in a register setting of 04 Port control for port 5
> > > = 0x053f (i.e. EgressMode=Unmodified mode, frames are transmitted
> > > unmodifi
On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
> > requests (only the requests) are also seen on client1 connected to
> > lan1
>
> This is the expec
> > I tested setting .tag_protocol=DSA_TAG_PROTO_DSA for the 6341 switch
> > instead, resulting in a register setting of 04 Port control for port 5
> > = 0x053f (i.e. EgressMode=Unmodified mode, frames are transmitted
> > unmodified), which looks correct to me. It does not fix the above
> > problem
On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
> Hi,
> I am still investigating the leaking packets problem we are having
> with a setup of an armada-3720 SOC and a 88E6341 switch ( connected
> via cpu port 5 , SGMII ,C_MODE=0xB, 2500 BASE-x). I now jumped to the
> net-next kernel (5.10.0-rc4
Hi,
I am still investigating the leaking packets problem we are having
with a setup of an armada-3720 SOC and a 88E6341 switch ( connected
via cpu port 5 , SGMII ,C_MODE=0xB, 2500 BASE-x). I now jumped to the
net-next kernel (5.10.0-rc4) and can now use the nice mv88e6xxx_dump
tool for switch regis
On 15/11/2020 17:27, Andrew Lunn wrote:
> So check if you have an IGMP querier in the network. If not, try
> turning it on in the bridge,
>
> ip link set br0 type bridge mcast_querier
Thankfully it turns out this is totally unrelated to Linux - our TP-Link
Jetstream T1600G-PS has some unfortunat
On 15/11/2020 17:27, Andrew Lunn wrote:
> So check if you have an IGMP querier in the network. If not, try
> turning it on in the bridge,
>
> ip link set br0 type bridge mcast_querier 1
Thanks Andrew - that does indeed seem to have solved the issue.
I'm relieved this isn't a hardware or driver
> Using tcpdump I *think* enp2s0 (wired link direct into lan1 on 'good')
> always showed the laptop sending multicast listener report v2 packets on
> a regular cadence of about 60-100 seconds as well as the DHCPv6
> solicit/renews and that cadence matched when the timers on the output of
> "bridge
[On 15/11/2020 16:02, Andrew Lunn wrote:
> What might be interesting is running
>
> ip monitor
>
> and
>
> bridge monitor
>
> Look for neighbours being timed out do to inactivity.
Funny you write that! This afternoon I've narrowed it down although I
still don't understand the 'why'.
Watching
> At some point, with absolutely nothing showing in any Mox log in the
> meantime, additional renewals will fail.
What might be interesting is running
ip monitor
and
bridge monitor
Look for neighbours being timed out do to inactivity.
Andrew
On 14/11/2020 18:49, Vladimir Oltean wrote:
> On Sat, Nov 14, 2020 at 03:39:28PM +, Tj (Elloe Linux) wrote:
>> MV88E6085 switch not passing IPv6 multicast packets to CPU.
> Is there a simple step-by-step reproducer for the issue, that doesn't
> require a lot of configuration? I've got a Mox wi
On Sat, Nov 14, 2020 at 03:39:28PM +, Tj (Elloe Linux) wrote:
> MV88E6085 switch not passing IPv6 multicast packets to CPU.
>
> Seems to be related to interface not being in promiscuous mode.
>
> This issue has been ongoing since at least July 2020. Latest v5.10-rc3
> still suffers the issue on
On Sat, 14 Nov 2020 16:06:33 +
"Tj (Elloe Linux)" wrote:
> On 14/11/2020 15:56, Andrew Lunn wrote:
> >> 1) with isc-dhcp-server configured with very short lease times (180
> >> seconds). After mox reboot (or systemctl restart systemd-networkd)
> >> clients successfully obtain a lease and a co
On 14/11/2020 15:56, Andrew Lunn wrote:
>> 1) with isc-dhcp-server configured with very short lease times (180
>> seconds). After mox reboot (or systemctl restart systemd-networkd)
>> clients successfully obtain a lease and a couple of RENEWs (requested
>> after 90 seconds) but then all goes silent
> 1) with isc-dhcp-server configured with very short lease times (180
> seconds). After mox reboot (or systemctl restart systemd-networkd)
> clients successfully obtain a lease and a couple of RENEWs (requested
> after 90 seconds) but then all goes silent, Mox OS no longer sees the
> IPv6 multicast
MV88E6085 switch not passing IPv6 multicast packets to CPU.
Seems to be related to interface not being in promiscuous mode.
This issue has been ongoing since at least July 2020. Latest v5.10-rc3
still suffers the issue on a Turris Mox with mv88e6085. We've not been
able to reproduce it on the Tur
On Wed, 4 Nov 2020 03:58:34 +0200 Vladimir Oltean wrote:
> The only problem?
> Throughput is actually a few Mbps worse, and this is 100% reproducible,
> doesn't appear to be measurement error.
Is there any performance scaling enabled? IOW CPU freq can vary?
> My untrained eye tells me that in the 'after patch' case (the worse
> one), there are less branch misses, and less cache misses. So by all
> perf metrics, the throughput should be better, but it isn't. What gives?
Maybe the frame has been pushed out of the L1 cache. The classify code
is pulling
On 2/10/20 1:36 am, Andrew Lunn wrote:
>>> Can you run 1000Base-X over these links?
>> With some reading "1000base-x" does seem the right thing to say here.
>> It's even what is reflected in the CMODE field for those ports.
> One more thing you might need is
>
> managed = "in-band-status";
>
>>> I
> > Can you run 1000Base-X over these links?
> With some reading "1000base-x" does seem the right thing to say here.
> It's even what is reflected in the CMODE field for those ports.
One more thing you might need is
managed = "in-band-status";
> > If you can, it is probably
> > worth chatting t
On Wed, Sep 30, 2020 at 09:19:56PM +0200, Andrew Lunn wrote:
> > What would be the best way to debug this ? Is there a way to dump the
> > ATU MAC tables to see what's going on with the address learning ?
>
> If you jump to net-next, and use
>
> https://github.com/lunn/mv88e6xxx_dump
>
> You can
On 1/10/20 2:24 pm, Andrew Lunn wrote:
>> port@8 {
>> reg = <8>;
>> label = "internal8";
>> phy-mode = "rgmii-id";
>> fixed-link {
>>
> port@8 {
> reg = <8>;
> label = "internal8";
> phy-mode = "rgmii-id";
> fixed-link {
> speed = <100
> What would be the best way to debug this ? Is there a way to dump the
> ATU MAC tables to see what's going on with the address learning ?
If you jump to net-next, and use
https://github.com/lunn/mv88e6xxx_dump
You can dump the full ATU from the switch.
bridge fdb show
can give you some idea
On Wed, Sep 30, 2020 at 01:28:35PM +0300, Vladimir Oltean wrote:
> On Wed, Sep 30, 2020 at 12:09:03PM +0200, Peter Vollmer wrote:
> > lan0..lan3 are members of the br0 bridge interface.
>
> and so is eth0, I assume?
No, eth0 is a dedicated interface with its own IP. We have routing between eth0
a
On Wed, Sep 30, 2020 at 12:09:03PM +0200, Peter Vollmer wrote:
> lan0..lan3 are members of the br0 bridge interface.
and so is eth0, I assume?
> The problem is that for ICMP ping lan0-> eth0, ICMP ping request
> packets are leaking (i.e. flooded) to all other ports lan1..lan3,
> while the ping r
> As another thought do you know what DHCPv6 client/server is being
> used.
> There was a fairly recent bugfix for busybox that was needed because
>the v6 code was using the wrong MAC address.
I'm the customer experiencing this issue. It appears unrelated to the
DHCP server software. On the Turris
On 7/23/20 2:27 PM, Chris Packham wrote:
> Hi Marek,
>
> On 24/07/20 2:46 am, Marek Behún wrote:
>> Hi,
>>
>> a customer of ours filed a ticket saying that when using upstream kernel
>> (5.8.0-rc6 on Debian 10) on Turris MOX (88e6190 switch) with DSA with
>> default configuration, the switch is lo
Hi Marek,
On 24/07/20 2:46 am, Marek Behún wrote:
> Hi,
>
> a customer of ours filed a ticket saying that when using upstream kernel
> (5.8.0-rc6 on Debian 10) on Turris MOX (88e6190 switch) with DSA with
> default configuration, the switch is losing DHCPv6 solicit packets /
> IPv6 multicast packe
On 09/07/2020 14:35, Andrew Lunn wrote:
Two questions if you do not mind:
1) does the above apply to all stable kernel releases or only => 5.4?
Because with 4.14 there are reports that dynamic addresses of clients
roaming from a switch port to an bridge port (upstream of the switch,
e.g. WLan AP
> Two questions if you do not mind:
>
> 1) does the above apply to all stable kernel releases or only => 5.4?
> Because with 4.14 there are reports that dynamic addresses of clients
> roaming from a switch port to an bridge port (upstream of the switch,
> e.g. WLan AP provided by the router) facin
On 09/07/2020 13:53, Andrew Lunn wrote:
On Thu, Jul 09, 2020 at 11:32:00AM +, ѽ҉ᶬḳ℠ wrote:
"kernel":"5.4.50", "system":"ARMv7 Processor rev 1
(v7l)","model":"Turris
Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13719-66e04abb
On Thu, Jul 09, 2020 at 11:32:00AM +, ѽ҉ᶬḳ℠ wrote:
> "kernel":"5.4.50", "system":"ARMv7 Processor rev 1
> (v7l)","model":"Turris
> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13719-66e04abbb6","target":"mvebu/cortexa9","}
>
> C
> The very last line is wrong.
> ifconfig eth0 192.168.1.4 up
Typo. It was fixed after few hours I created the gist.
> You should put the IP address on the bridge, not the master
> device eth0.
> ip addr add 192.168.1.4/24 dev br0
Noted. Thank you.
> FYI: ifconfig has been deprecated for maybe
> I wrote my (very first) public GIST about that. Please, could you
> review it, and point to the any logical bugs in there?
> https://gist.github.com/ZoranStojsavljevic/423b96e2ca3bd581f7ce417cb410c465
The very last line is wrong.
ifconfig eth0 192.168.1.4 up
You should put the IP address on th
Hello Andrew,
I see dead people... Really i do! After your reply.
> This happens when the driver is missing a resource during probe. It
> returns the error -EPROBE_DEFER, and the linux driver core will try
> the probe again later. Probably the second time all the resources it
> needs will be pre
On Sat, Sep 28, 2019 at 01:00:43AM +0200, Zoran Stojsavljevic wrote:
> Hello Andrew,
>
> > You should not need any kernel patches for switch side RGMII
> > delays. rgmii-id in the DT for the switch CPU port should be enough.
> > Some of the vf610-zii platforms use it.
>
> It should, but it does N
Hello Andrew,
> You should not need any kernel patches for switch side RGMII
> delays. rgmii-id in the DT for the switch CPU port should be enough.
> Some of the vf610-zii platforms use it.
It should, but it does NOT work. IT is clearly stated in port.c, in f-n:
static int mv88e6xxx_port_set_rgmi
On Thu, Sep 26, 2019 at 03:23:48PM +0200, Zoran Stojsavljevic wrote:
> Hello Andrew,
>
> I would like to thank you for the reply.
>
> I do not know if this is the right place to post such the questions,
> but my best guess is: yes.
>
> Since till now I did not make any success to make (using DSA
Hello Andrew,
I would like to thank you for the reply.
I do not know if this is the right place to post such the questions,
but my best guess is: yes.
Since till now I did not make any success to make (using DSA driver)
make mv88e6190 single switch to work with any kernel.org. :-(
I did ugly wo
> We have the configuration problem with the Marvell 88E6190 switch.
> What the our problem is... Is the switch is NOT configured with the
> EEPROM (24C512), which does not exist on the board.
That is pretty normal. If there is a EEPROM, i generally recommend it
is left empty. We want Linux to con
On 9/23/2019 5:56 AM, Jan Lübbe wrote:
> Adding TC maintainers... (we're trying to find a mainline-acceptable
> way to configure and offload strict port-based priorities in the
> context of DSA/switchdev).
>
> On Thu, 2019-09-19 at 10:12 -0700, Florian Fainelli wrote:
>> On 9/19/19 1:44 AM, Sas
Adding TC maintainers... (we're trying to find a mainline-acceptable
way to configure and offload strict port-based priorities in the
context of DSA/switchdev).
On Thu, 2019-09-19 at 10:12 -0700, Florian Fainelli wrote:
> On 9/19/19 1:44 AM, Sascha Hauer wrote:
> > On Wed, Sep 18, 2019 at 10:41:58
On 9/19/19 1:44 AM, Sascha Hauer wrote:
> Hi Florian,
>
> On Wed, Sep 18, 2019 at 10:41:58AM -0700, Florian Fainelli wrote:
>> On 9/18/19 7:36 AM, Vladimir Oltean wrote:
>>> Hi Sascha,
>>>
>>> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
Hi All,
We have a customer using a
Hi Andrew,
thanks for your detail explanation!
On Thu, 2019-09-19 at 15:34 +0200, Andrew Lunn wrote:
> On Thu, Sep 19, 2019 at 10:00:51AM +0200, Sascha Hauer wrote:
> > Hi Vladimir,
> >
> > On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> > > Hi Sascha,
> > >
> > > On Wed, 18
On Wed, 2019-09-18 at 10:41 -0700, Florian Fainelli wrote:
> > > The other part of the problem seems to be that the CPU port has no
> > > network device
> > > representation in Linux, so there's no interface to configure the egress
> > > limits via tc.
> > > This has been discussed before, but it
On Thu, Sep 19, 2019 at 10:00:51AM +0200, Sascha Hauer wrote:
> Hi Vladimir,
>
> On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> > Hi Sascha,
> >
> > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> > >
> > > Hi All,
> > >
> > > We have a customer using a Marvell 88e6240 sw
Hi Jan,
On Thu, 19 Sep 2019 at 16:21, Jan Lübbe wrote:
>
> Hi,
>
> On Wed, 2019-09-18 at 10:41 -0700, Florian Fainelli wrote:
> > > Technically, configuring a match-all rxnfc rule with ethtool would
> > > count as 'default priority' - I have proposed that before. Now I'm not
> > > entirely sure h
Hi,
On Wed, 2019-09-18 at 10:41 -0700, Florian Fainelli wrote:
> > Technically, configuring a match-all rxnfc rule with ethtool would
> > count as 'default priority' - I have proposed that before. Now I'm not
> > entirely sure how intuitive it is, but I'm also interested in being
> > able to confi
Hi Florian,
On Wed, Sep 18, 2019 at 10:41:58AM -0700, Florian Fainelli wrote:
> On 9/18/19 7:36 AM, Vladimir Oltean wrote:
> > Hi Sascha,
> >
> > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> >>
> >> Hi All,
> >>
> >> We have a customer using a Marvell 88e6240 switch with Ethercat on one
Hi Uwe,
On Thu, 19 Sep 2019 at 11:36, Uwe Kleine-König
wrote:
>
> On Thu, Sep 19, 2019 at 10:00:51AM +0200, Sascha Hauer wrote:
> > Hi Vladimir,
> >
> > On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> > > Hi Sascha,
> > >
> > > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
On Thu, Sep 19, 2019 at 11:18:24AM +0300, Vladimir Oltean wrote:
> On Thu, 19 Sep 2019 at 11:00, Sascha Hauer wrote:
> >
> > Hi Vladimir,
> >
> > On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> > > Hi Sascha,
> > >
> > > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> > > >
On Thu, Sep 19, 2019 at 10:00:51AM +0200, Sascha Hauer wrote:
> Hi Vladimir,
>
> On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> > Hi Sascha,
> >
> > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> > >
> > > Hi All,
> > >
> > > We have a customer using a Marvell 88e6240 sw
On Thu, 19 Sep 2019 at 11:00, Sascha Hauer wrote:
>
> Hi Vladimir,
>
> On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> > Hi Sascha,
> >
> > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> > >
> > > Hi All,
> > >
> > > We have a customer using a Marvell 88e6240 switch with E
Hi Vladimir,
On Wed, Sep 18, 2019 at 05:36:08PM +0300, Vladimir Oltean wrote:
> Hi Sascha,
>
> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> >
> > Hi All,
> >
> > We have a customer using a Marvell 88e6240 switch with Ethercat on one port
> > and
> > regular network traffic on another por
On 9/18/19 12:39 PM, Vladimir Oltean wrote:
> Hi Florian,
>
> On Wed, 18 Sep 2019 at 20:42, Florian Fainelli wrote:
>>
>> On 9/18/19 7:36 AM, Vladimir Oltean wrote:
>>> Hi Sascha,
>>>
>>> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
Hi All,
We have a customer using a Mar
Hi Florian,
On Wed, 18 Sep 2019 at 20:42, Florian Fainelli wrote:
>
> On 9/18/19 7:36 AM, Vladimir Oltean wrote:
> > Hi Sascha,
> >
> > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> >>
> >> Hi All,
> >>
> >> We have a customer using a Marvell 88e6240 switch with Ethercat on one
> >> port
On 9/18/19 7:36 AM, Vladimir Oltean wrote:
> Hi Sascha,
>
> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
>>
>> Hi All,
>>
>> We have a customer using a Marvell 88e6240 switch with Ethercat on one port
>> and
>> regular network traffic on another port. The customer wants to configure two
>>
On 9/18/19 8:03 AM, Dave Taht wrote:
> On Wed, Sep 18, 2019 at 7:37 AM Vladimir Oltean wrote:
>>
>> Hi Sascha,
>>
>> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
>>>
>>> Hi All,
>>>
>>> We have a customer using a Marvell 88e6240 switch with Ethercat on one port
>>> and
>>> regular network t
On Wed, Sep 18, 2019 at 7:37 AM Vladimir Oltean wrote:
>
> Hi Sascha,
>
> On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
> >
> > Hi All,
> >
> > We have a customer using a Marvell 88e6240 switch with Ethercat on one port
> > and
> > regular network traffic on another port. The customer wants
Hi Sascha,
On Wed, 18 Sep 2019 at 17:03, Sascha Hauer wrote:
>
> Hi All,
>
> We have a customer using a Marvell 88e6240 switch with Ethercat on one port
> and
> regular network traffic on another port. The customer wants to configure two
> things
> on the switch: First Ethercat traffic shall be
> Hi Andrew,
> I've searched the netdev mailing list for DSA and traffic, but can't find
> anything
> about rate limiting till 2016. Do you have a hint, how I can find it?
I will try to find it later today.
> Do you know if the patchset was for Marvell or maybe for another company?
It was anot
>> Hi all,
>> is there a possibility to set the rate limiting for the 6390 with linux
>> tools?
>> I've seen that the driver will init all to zero, so rate limiting is
>> disabled,
>> but there is no solution for it in the ip tool?
>>
>> The only thing I found for rate limiting is the tc tool,
On Mon, Jul 29, 2019 at 12:30:20PM +0200, Benjamin Beckmeyer wrote:
> Hi all,
> is there a possibility to set the rate limiting for the 6390 with linux tools?
> I've seen that the driver will init all to zero, so rate limiting is
> disabled,
> but there is no solution for it in the ip tool?
>
>
>> thanks for your reply. You're right, both PHYs are 10/100.
>>
>> I already added a fixed-link like this:
>>
>> port@0 {
>> reg = <0>;
>> label = "cpu";
>> ethernet = <&fec1>;
>>
>> I captured a ping from my device to my computer to look if outgoing is
>> working
>> (captured on both devices). Here is the output from my device where i
>> started the:
>>
>> 00:24:24.752057 ARP, Request who-has 192.168.10.2 tell 192.168.10.1, length
>> 28
>> 0x: 0001 0800 0604
> I captured a ping from my device to my computer to look if outgoing is working
> (captured on both devices). Here is the output from my device where i started
> the:
>
> 00:24:24.752057 ARP, Request who-has 192.168.10.2 tell 192.168.10.1, length 28
> 0x: 0001 0800 0604 0001 6a2a ad79
> On Tue, Jun 11, 2019 at 09:36:16AM +0200, Benjamin Beckmeyer wrote:
So all ports are now in forwarding mode (Switch port register 0x4 of all
ports
are 0x7f), but I don't reach it over ping.
>>> Hi
>>>
>>> The most common error for people new to DSA is forgetting to bring
>>> the
On Tue, Jun 11, 2019 at 09:36:16AM +0200, Benjamin Beckmeyer wrote:
> >> So all ports are now in forwarding mode (Switch port register 0x4 of all
> >> ports
> >> are 0x7f), but I don't reach it over ping.
> > Hi
> >
> > The most common error for people new to DSA is forgetting to bring
> > the ma
>> So all ports are now in forwarding mode (Switch port register 0x4 of all
>> ports
>> are 0x7f), but I don't reach it over ping.
> Hi
>
> The most common error for people new to DSA is forgetting to bring
> the master interface up.
>
> The second thing to understand is that by default, all inte
> So all ports are now in forwarding mode (Switch port register 0x4 of all
> ports
> are 0x7f), but I don't reach it over ping.
Hi
The most common error for people new to DSA is forgetting to bring
the master interface up.
The second thing to understand is that by default, all interfaces are
s
On 06.06.19 15:59, Andrew Lunn wrote:
> On Thu, Jun 06, 2019 at 03:47:06PM +0200, Benjamin Beckmeyer wrote:
>> On 06.06.19 15:35, Andrew Lunn wrote:
>From our hardware developer I know now that we are using a "mini" SFF
which has no i2c eeprom.
>>> O.K. Does this mini SFF have LOS, TX
On Thu, Jun 06, 2019 at 03:47:06PM +0200, Benjamin Beckmeyer wrote:
>
> On 06.06.19 15:35, Andrew Lunn wrote:
> >> >From our hardware developer I know now that we are using a "mini" SFF
> >> which has no i2c eeprom.
> > O.K. Does this mini SFF have LOS, TX-Disable, etc? Are these connected
> > t
On 06.06.19 15:35, Andrew Lunn wrote:
>> >From our hardware developer I know now that we are using a "mini" SFF
>> which has no i2c eeprom.
> O.K. Does this mini SFF have LOS, TX-Disable, etc? Are these connected
> to GPIOs? I assume the SFF is fibre? And it needs the SERDES to speak
> 1000Base
> >From our hardware developer I know now that we are using a "mini" SFF
> which has no i2c eeprom.
O.K. Does this mini SFF have LOS, TX-Disable, etc? Are these connected
to GPIOs? I assume the SFF is fibre? And it needs the SERDES to speak
1000BaseX, not SGMII?
> Switch
On 06.06.19 14:24, Andrew Lunn wrote:
> On Thu, Jun 06, 2019 at 10:49:08AM +0200, Benjamin Beckmeyer wrote:
I removed all phy-handle for the internal ports and in the mdio part
is only port 2 and 6 by now. But the Serdes ports are still not be
recognized. So maybe there is still s
>> I removed all phy-handle for the internal ports and in the mdio part
>> is only port 2 and 6 by now. But the Serdes ports are still not be
>> recognized. So maybe there is still something wrong?
> What do you mean by SERDES? Do you mean they are connected to an SFP
> cage? If so, you need to ad
> I removed all phy-handle for the internal ports and in the mdio part
> is only port 2 and 6 by now. But the Serdes ports are still not be
> recognized. So maybe there is still something wrong?
What do you mean by SERDES? Do you mean they are connected to an SFP
cage? If so, you need to add an S
>> Here is my device tree
>>
>> mdio {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> switch0: switch0@0 {
>> compatible = "marvell,mv88e6085";
>> reg = <0x0>;
>> pinctrl-0
> Here is my device tree
>
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> switch0: switch0@0 {
> compatible = "marvell,mv88e6085";
> reg = <0x0>;
> pinctrl-0 = <&lcd
>> I got the devicetree from somebody that is why German is in it. But
>> first I wanted to get it running before I tidy it up. The switch is
>> strapped to single mode (so I can read SMI addresses 0x10-0x16 and
>> 0x1b-0x1e directly).
> Hi Benjamin
>
> You have miss-understood what reg means.
>
>
> I got the devicetree from somebody that is why German is in it. But
> first I wanted to get it running before I tidy it up. The switch is
> strapped to single mode (so I can read SMI addresses 0x10-0x16 and
> 0x1b-0x1e directly).
Hi Benjamin
You have miss-understood what reg means.
There are
Hey Andrew,
thanks for you reply.
I got the devicetree from somebody that is why German is in it. But first I
wanted to get it running before I tidy it up.
The switch is strapped to single mode (so I can read SMI addresses 0x10-0x16
and 0x1b-0x1e directly). Do I have to
tell this the devicetree?
On Tue, Jun 04, 2019 at 03:07:25PM +0200, Benjamin Beckmeyer wrote:
> Hi all,
>
> I'm working on a custom board with a 88E6321 and an i.MX28. Port 5 is
> directly connected per RMII to the CPU.
> The switch is running in CPU attached mode. On Port 2 and 6 we have 2
> external Micrel KSZ9031 PHY
> thanks for your reply. You're right, both PHYs are 10/100.
>
> I already added a fixed-link like this:
>
> port@0 {
> reg = <0>;
> label = "cpu";
> ethernet = <&fec1>;
>
On 22.05.19 18:32, Andrew Lunn wrote:
> On Wed, May 22, 2019 at 10:33:29AM +0200, Benjamin Beckmeyer wrote:
>> Hi all,
>>
>> I'm currently working on a custom board with the imx6ull processor and the
>> 6390
>> switching chip. This is our hardware setup.
>>
>> -
On Wed, May 22, 2019 at 10:33:29AM +0200, Benjamin Beckmeyer wrote:
> Hi all,
>
> I'm currently working on a custom board with the imx6ull processor and the
> 6390
> switching chip. This is our hardware setup.
>
> - -MAC
> | i.MX
On Fri, May 17, 2019 at 11:10:10AM -0700, Florian Fainelli wrote:
> On 5/17/19 11:03 AM, Russell King - ARM Linux admin wrote:
> > On Fri, May 17, 2019 at 05:37:00PM +, Ioana Ciornei wrote:
> >>> Subject: Re: dsa: using multi-gbps speeds on CPU port
> >>>
>
On 5/17/19 11:03 AM, Russell King - ARM Linux admin wrote:
> On Fri, May 17, 2019 at 05:37:00PM +, Ioana Ciornei wrote:
>>> Subject: Re: dsa: using multi-gbps speeds on CPU port
>>>
>>> Hi everyone,
>>>
>>> On Wed, 15 May 2019 09:09:26 -0700
&g
On Fri, May 17, 2019 at 05:37:00PM +, Ioana Ciornei wrote:
> > Subject: Re: dsa: using multi-gbps speeds on CPU port
> >
> > Hi everyone,
> >
> > On Wed, 15 May 2019 09:09:26 -0700
> > Florian Fainelli wrote:
> >
> > >On 5/15/19
1 - 100 of 220 matches
Mail list logo
