>> 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,
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, but I guess this is
only
>> Hi Andrew,
>> I got it working a little bit better. When I'm fast enough I can read
>> the registers I want but it isn't a solution.
> Why do you need to read registers?
>
> What you actually might be interested in is the debugfs patches in
> Viviens github tree.
>
>> Here is an output of the tr
> I think you are going to have to parse the register writes/reads to
> figure out what switch registers it is accessing. That should
> hopefully make it clearer why it is making so many accesses.
Hi Andrew,
I got it working a little bit better. When I'm fast enough I can read
the registers I want
>> &mdio0 {
>> interrupt-parent = <&gpio1>;
>> interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
>>
>> switch0: switch0@2 {
>> compatible = "marvell,mv88e6190";
>> reg = <2>;
>> pinctrl-0 = <&pinctrl_gpios>;
>> reset-gpios
> On Thu, Jul 04, 2019 at 10:54:47AM +0200, Benjamin Beckmeyer wrote:
>> On 03.07.19 17:55, Andrew Lunn wrote:
>>> On Wed, Jul 03, 2019 at 03:10:34PM +0200, Benjamin Beckmeyer wrote:
>>>> Hey folks,
>>>>
>>>> I'm having a problem wi
On 03.07.19 17:55, Andrew Lunn wrote:
> On Wed, Jul 03, 2019 at 03:10:34PM +0200, Benjamin Beckmeyer wrote:
>> Hey folks,
>>
>> I'm having a problem with a custom i.mx6ul board. When DSA is loaded I can't
>> get access to the switch via MDIO, but the D
On 03.07.19 17:55, Andrew Lunn wrote:
> On Wed, Jul 03, 2019 at 03:10:34PM +0200, Benjamin Beckmeyer wrote:
>> Hey folks,
>>
>> I'm having a problem with a custom i.mx6ul board. When DSA is loaded I can't
>> get access to the switch via MDIO, but the D
fferent custom board we have another switching chip in single chip
addressing mode the MDIO access works like a charm with activated DSA.
Currently I'm on linux-4.14.118. Other kernels (4.19.55, 5.1.14) I've
tested stuck at or reboot while DSA is loading. Same devicetree there.
Let me know if you need some more input.
Thanks in advance for your help.
Best regards,
Benjamin Beckmeyer
>> 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
> 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
>> 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
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
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
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
>>>&
>> 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
>> Here is my device tree
>>
>> mdio {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> switch0: switch0@0 {
>> compatible = "marvell,mv88e6085";
>> reg = <0x0>;
>> pinctrl-0
>> 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.
>
>
, 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
(mii_bus:phy_addr=fixed-0:00, irq=-1)
On the other board it was at least recognized but now I don't get anything
about the switch.
Here I'm running 4.9.109. I've tested newer kernels but then the MDIO bus can
not be accessed anymore.
I've tested 4.19.47 and 4.14.179.
@Andrew Lunn I haven't forgotten to answer your the last mail. But this product
has a higher
priority so I will come back later to the other custom board again.
Thanks in advance.
Cheers,
Benjamin Beckmeyer
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
>> swit
D 0x0. Before
we setup the P0 port to RMII PHY MODE (before it was set to RGMII, what is
wrong)
it was recognized. But when I read the phy_id from /ssys/bus/mdio_bus it was
only correct to the half. It should be 0x0007C131 but I got 0xC131 or
sometimes 0x0007.
When DSA is loaded our MII tool is not recognizing the switch on ID 2 (or at
least with some odd values). The KSZ is recognized correctly with its Phy ID.
Does the DSA driver do something here?
I know it's a lot of information but maybe somebody can help me to get the DSA
working properly..
Thanks in advance.
Cheers,
Benjamin Beckmeyer
23 matches
Mail list logo
