Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

swconfig doesn't work #20

Closed
Chadster766 opened this Issue Sep 4, 2014 · 86 comments

Comments

Projects
None yet
6 participants
@Chadster766
Copy link
Owner

commented Sep 4, 2014

swconfig

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Sep 11, 2014

swconfig package compiles but isn't functional because of missing 88E6172 switch driver.

The OpenWRT patch below will need to be analysed and implemented to get a functional switch driver.
patch http://patchwork.openwrt.org/patch/5367/

@Chadster766 Chadster766 changed the title Add VLAN support swconfig package request Sep 11, 2014

@Chadster766 Chadster766 changed the title swconfig package request swconfig doesn't work Sep 18, 2014

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2014

hopefully it's closely related to the 6171. http://patchwork.openwrt.org/patch/5855/ could give some hint on how to refactor all that into something sane.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Sep 27, 2014

Mark let me know if you want me to remove the assignment for this one 😃

You are really doing great work and giving this project momentum. We need more coders like you helping out.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Sep 27, 2014

Thanks. It may be a few days before I can really dig into this.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2014

I'm mostly just reading code and looking patches right now. Getting an understanding of how the drivers and swconfig should interact.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2014

We need to pull some patches from: https://github.com/jimmychungbelkin/Mamba/tree/master/barrier_breaker

We have no dts file for the wrt1900ac (mamba). I believe this is required for switch functionality. The dts will have to go upstream to the kernel also.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2014

Working on pulling in dts related changes.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2014

In the patch, changes to files in arch/arm/mach-mvebu look unnecessary. We just have to backport a modern mach-mvebu to whatever our target kernel version is.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

This patch is reminding me of mrvl_wlan_v7drv. I think there is probably a lot of functionality that is already implemented elsewhere in the kernel. Some of the copyrights are quite old (2011). It looks like the current mvneta driver could have us covered.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Oct 6, 2014

I accidentally caused my entire package directory to rebuild. This takes 24hrs to complete. So my development is going to be a little delayed.
Isn't the wlan driver off topic for swconfig?

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

Yeah, I was just saying the code I'm seeing in the patches has the same crazy style.

@jackbguppy

This comment has been minimized.

Copy link

commented Oct 6, 2014

Ok.. finally fully connected and have single user mode.

Took phone line a wrapped around sewing pin to create very small
"spring" of copper. Slipped over RX amd TX pins only (a bit wide).
Wrapped another piece around a loosen screw holding down the board for
ground. Pulled the two wires tight around the white housing then to
front of borad with ground around that post and back up and out of the
box through a vent hole.

I now have a WRT1900ac with three wires sticking out and boots just
fine. Booted a few times and final got it stop... I now have single
user mode!!!

I have pictures to use on site to document how to do it.

:) Now on to loading the software.

FPU initialized to Run Fast Mode.
USB 0: Host Mode
USB 1: Host Mode
USB 2: Device Mode
Modules Detected:
mvEthE6171SwitchBasicInit finished
Net: mvSysNetaInit enter
set port 0 to rgmii enter
set port 1 to rgmii enter
egiga0 [PRIME], egiga1
modify Phy Status
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot: 0
Marvell>> ls
Scanning JFFS2 FS: done.

Marvell>>

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Oct 6, 2014

Below are some quick tips for the uboot prompt:

printenv - this will print uboot environment variables

setenv - this will set a value to an environment variable (setenv variable 'value')

saveenv - this will save all the environment variables with there current values (careful I don't recommend this until you get a better understanding of the vars and their uses)

U-boot variables used to load firmware:
serverip - ip address of your TFTP server
ipaddr - set the ip address of the router for TFTP upload
firmware_name - file name of the firmware to load from TFTP server

Command that load firmware:
run update_both_images - loads firmware to both the primary and secondary image location in one shot. I use this to be sure I'm working of the right firmware. I've had it change to secondary without me knowing and it confused me because I was seeing the previous firmware instead of the one I just loaded.

run flash_pri_image - load the firmware to the primary image location
run flash_alt_image - load the firmware to the alternate image location

Useful uboot commands:
boot - run primary boot image
run altnandboot - run alternate boot image
reset - reboot router from u-boot

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

And it is closely related to the 88E6171:

        /* specific Switch initialization according to Switch ID */
        switch (qd_dev->deviceId) {
        case GT_88E6161:
        case GT_88E6165:
        case GT_88E6171:
        case GT_88E6351:
        case GT_88E6172:
        case GT_88E6176:
@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

For initial support we'll need to do the following:

  1. create a patch for the devicetree file (dts).
  2. (maybe) create a patch backporting latest arch/arm/mach-mvebu changes.
  3. Take the 6171 driver: http://patchwork.openwrt.org/patch/5855/ and hack it into something that works with the 6172. The current patch: http://patchwork.openwrt.org/patch/5367/ can be used as a reference.

After we initially get this working with swconfig. We'll need to send our working 6172 driver to the OpenWRT devel list. If it's accepted, we'll be in great shape. I believe the devicetree file should go all the way to the kernel. The devicetree file however, depends on the LED driver (references it) so the LED driver would have to go into the kernel before, or at the same time as the devicetree file.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Oct 6, 2014

Did you look for clues in the Linksys WRT1900AC GPL as well?

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

I didn't, is there anything interesting in there?

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Oct 6, 2014

Yes Linksys built there stock firmware from marvel source code including the wlan, LED and switch. IMO they did a good job too but I think they took it too far away from standard IT practices and implemented sysevent.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

I'll take a look

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2014

Do you know where the switch code is? It's not jumping out at me just yet. I poked around some of the source directories and looked at a few of their linux patches. I see they they have 802.1Q turned on in the kernel config, but I haven't stumbled across much else yet.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Oct 6, 2014

Sorry I'm not sure on that. They may have configured the switch directly via /proc. Try a grep for proc in the sbin or etc directories.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2014

In the 3 steps I listed earlier, we may not need 1 and 2. oops.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Oct 7, 2014

That would be good.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2014

So Belkin's patch is reference design code just like the wifi driver. This is the stuff marvell would normally give to the OEMs integrating marvell's chips/boards into products. The upside to that, is there's a lot of code we don't need to implement. The marvell switch code implements the whole stack up to the switching layer in this code, and barely makes any callouts to kernel APIs (pretty much only the minimum). The (other) code that implements swconfig support for the 88E6171 uses kernel APIs and saves a lot of work. Turning that code into something that supports the 88E6172 may be as easy as changing a few #defines. The 88E6171 and 88E6172 are almost identical chips (the '72 supports way more VLANs).

image

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2014

A full datasheet would be so much easier to read than this ref design code. 😝

@mmilburn mmilburn closed this Dec 19, 2014

@mmilburn mmilburn reopened this Dec 19, 2014

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

Need to confirm cpu-ports, but here's the changes so far:

diff --git a/target/linux/mvebu/config-3.14 b/target/linux/mvebu/config-3.14
index 01bd9c1..17a5d64 100644
--- a/target/linux/mvebu/config-3.14
+++ b/target/linux/mvebu/config-3.14
@@ -209,6 +209,7 @@ CONFIG_MVEBU_DEVBUS=y
 CONFIG_MVEBU_MBUS=y
 CONFIG_MVMDIO=y
 CONFIG_MVNETA=y
+CONFIG_MVSW6171_PHY=y
 CONFIG_MV_XOR=y
 CONFIG_NEED_DMA_MAP_STATE=y
 # CONFIG_NEON is not set
@@ -266,6 +267,7 @@ CONFIG_SPI=y
 CONFIG_SPI_MASTER=y
 CONFIG_SPI_ORION=y
 CONFIG_STOP_MACHINE=y
+CONFIG_SWCONFIG=y
 CONFIG_SWIOTLB=y
 # CONFIG_SWP_EMULATE is not set
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
diff --git a/target/linux/mvebu/files/arch/arm/boot/dts/armada-xp-mamba.dts b/target/linux/mvebu/files/arch/arm/boot/dts/armada-xp-mamba.dts
index a3dc012..cae7d14 100644
--- a/target/linux/mvebu/files/arch/arm/boot/dts/armada-xp-mamba.dts
+++ b/target/linux/mvebu/files/arch/arm/boot/dts/armada-xp-mamba.dts
@@ -115,9 +115,9 @@
                                nr-ports = <1>;
                                status = "okay";
                        };
-
-                       mdio {
-                               status = "disabled";
+
+                       mdio: mdio {
+                               status = "okay";
                        };

                        ethernet@70000 {
@@ -274,4 +274,13 @@
                gpio-fan,speed-map = <0    0
                                      4500 1>;
        };
+
+       mvsw6171 {
+               compatible = "marvell,88e6171";
+               status = "okay";
+
+               mii-bus = <&mdio>;
+               cpu-port-0 = <5>;
+               cpu-port-1 = <6>;
+       };
 };
diff --git a/target/linux/mvebu/profiles/100-Generic.mk b/target/linux/mvebu/profiles/100-Generic.mk
index a692311..05d88b5 100644
--- a/target/linux/mvebu/profiles/100-Generic.mk
+++ b/target/linux/mvebu/profiles/100-Generic.mk
@@ -14,7 +14,7 @@ define Profile/Generic
        kmod-rtc-marvell kmod-thermal-armada \
        kmod-gpio-button-hotplug kmod-hwmon-tmp421 \
        kmod-hwmon-gpiofan kmod-leds-tlc59116 \
-       kmod-ledtrig-usbdev
+       kmod-ledtrig-usbdev swconfig
 endef

 define Profile/Generic/Description
@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Dec 19, 2014

Great @mmilburn looking good!

@leitec

This comment has been minimized.

Copy link

commented Dec 19, 2014

Excellent. I forgot to mention this earlier, but I think this is also necessary for VLANs to work under 3.14:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/ethernet/marvell/mvneta.c?id=817dbfa5d1bc276a72c1a577310382008e8aca0a

otherwise you never get tagged packets. It's fixed in 3.18.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2014

@leitec I'll check to see that these changes haven't been backported to 3.14.x (since it's LTS), and create a patch if necessary.

Given the default switch layout and the interface naming, it looks as though the cpu-port settings are correct. Port 5 is grouped with ports 1-3, the interface that has direct access to these ports is eth0. A similar case can be made for port 6. I have not thought of a better way to confirm the settings, but I think this reasoning is sufficient.

@leitec

This comment has been minimized.

Copy link

commented Dec 19, 2014

Whoops, I didn't think to check. Yeah, it looks like it's already fixed in newer 3.14.x.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 22, 2014

Hmm, I can't seem to find it in 3.14.26. Made sure it wasn't applied as an OpenWRT patch with:

make target/linux/{clean,prepare} V=s QUILT=1
quilt push -a

applied platform specific patches are:

platform/001-build_mamba_dts.patch
platform/002-revert_i2c_delay.patch
platform/003-add_leds_tlc59116_driver.patch
platform/008-nand_warn_weak_ecc_strength.patch
platform/009-add_of_mtd_ecc_helpers.patch
platform/010-pxa3xx_nand_print_ECC_strength.patch
platform/011-pxa3xx_nand_clean_error_handling.patch
platform/012-pxa3xx_nand_use_ecc_info_from_dt.patch
platform/018-decouple_phy_id_and_address.patch
platform/019-add_fixed_phy_register.patch
platform/020-of_fixed_link_phy.patch
platform/021-mvneta_support_fixed_links.patch
platform/100-find_active_root.patch

Also:

git rev-parse HEAD
2420d1c6a3af7bcb8994d26ca01f3e6cb0602bc7
@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2014

Since I couldn't find evidence of the patch being applied to 3.14.x kernels, I'm building and testing a backport of the patch.

to be clear, I mean this patch: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/ethernet/marvell/mvneta.c?id=817dbfa5d1bc276a72c1a577310382008e8aca0a

I'll be submitting my backport of the patch tonight to the openwrt-devel mailing list. If I don't get to it tonight, I'll submitting the patch for switch support to the openwrt-devel mailing list tomorrow.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Dec 24, 2014

Awesome!

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2014

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2014

Ok, patch to turn on switch driver going out tomorrow.

@leitec

This comment has been minimized.

Copy link

commented Dec 24, 2014

Great.

The bad news is apparently 802.1q VLANs won't work anyway, since the 6171 driver doesn't handle port state/STU, a requirement of the 6172. Nikita Nazarenko pointed this out to me and posted a working driver:

http://patchwork.ozlabs.org/patch/423418/

The diff itself looks a little broken (long lines). I'll be merging it with the 6171 driver soon.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2014

@leitec I will hold off on pushing the dts and config changes to openwrt-devel.

@leitec

This comment has been minimized.

Copy link

commented Dec 26, 2014

OK, I have four patches that should get things working posted here: http://staticky.com/mvsw/ These are patches against OpenWrt trunk. It shouldn't actually require changes to the DTS, but to keep things clean and consistent you can change mvsw6171 { to whatever you want (mvsw61xx { works, or anything else) and change compatible = "marvell,88e6171"; to compatible = "marvell,88e6172";

Everything works here on my 6171's, but they don't appear to require the STU stuff Nikita posted about. Hopefully this results in working 802.1q VLANs on the 6172.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2015

Kaloz has added the dts changes: https://dev.openwrt.org/changeset/43854/

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Jan 7, 2015

Nice, does that help with your switch driver or is that no longer needed.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2015

CC already has @leitec's original mvsw6171 driver. The only thing left is to test his patches for 802.1q vlans.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2015

Because it's taken me a while to get to this, I had to make a few trivial changes to the first patch:

(20:51:%) diff 0001-mvsw6171-rename-to-mvsw61xx.patch 0001-mvsw6171-rename-to-mvsw61xx.patch.new                                                                                               (2015/01/07)
2305c2305
< - obj-$(CONFIG_AR8216_PHY)    += ar8216.o
---
> - obj-$(CONFIG_AR8216_PHY)    += ar8216.o ar8327.o
2334c2334
< + obj-$(CONFIG_AR8216_PHY)    += ar8216.o
---
> + obj-$(CONFIG_AR8216_PHY)    += ar8216.o ar8327.o
2363c2363
< - obj-$(CONFIG_AR8216_PHY)    += ar8216.o
---
> - obj-$(CONFIG_AR8216_PHY)    += ar8216.o ar8327.o
2392c2392
< + obj-$(CONFIG_AR8216_PHY)    += ar8216.o
---
> + obj-$(CONFIG_AR8216_PHY)    += ar8216.o ar8327.o

after that everything applies cleanly. After I finish building an image, my plan for testing is as follows:

  1. Make sure I can query and change individual port state with swconfig
  2. Setup a dummy VLAN and tcpdump -e -i to confirm tagged frames.

Since I am not an expert on this, please let me know if you have a better way to test this. Or, if you think I am testing incorrectly.

@Chadster766

This comment has been minimized.

Copy link
Owner Author

commented Jan 8, 2015

If this is your driver mod than I will do VLAN testing with my equipment too.

@leitec

This comment has been minimized.

Copy link

commented Jan 8, 2015

Thanks for testing. I will refresh the first patch when I submit it.

Your testing procedure sounds good to me. Here's an excerpt from my config using a '6171 switch. I have tagged packets coming in and out from switch port 4 (WAN, on my hardware) and going tagged into port 6 (eth0 on my hardware) plus untagged on two of the LAN ports.

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

config switch_vlan
        option device 'switch0'
        option vlan '11'
        option ports '0 1 4t 6t'

There's also a corresponding config for eth0.11 There's a further option, option vid under switch_vlan that sets the actual transmitted VID. It defaults to whatever vlan is set to, but in the case you want a VID > 64, you can set option vid '300' or whatever for eth0.300.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2015

Did a simple test, tagging appears:

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

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '4 6t'
tcpdump -eni eth1
...
03:25:02.315780 10:7b:ef:98:af:a4 > 01:00:5e:7f:ff:fa, ethertype 802.1Q (0x8100), length 406: vlan 1, p 0, ethertype IPv4, 192.168.0.1.1900 > 239.255.255.250.1900: UDP, length 360
@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2015

I was also able to set qmode and pvid with swconfig.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2015

@leitec, let me know if I need to do more in depth testing. Things appear to work fine.

@leitec

This comment has been minimized.

Copy link

commented Jan 9, 2015

I think that's it. Thanks a lot for testing!

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2015

No problem. Thanks for all the help Claudio.

@Chadster766 I will close this ticket once Claudio's patches appear in trunk.

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2015

@mmilburn

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2015

Changes applied to trunk. This is in CC now.

Hi Mark,

On Fri, Jan 09, 2015 at 04:21:10PM -0700, Mark Milburn wrote:

Use Claudio's renamed mvsw6171 driver.
Depends upon https://patchwork.ozlabs.org/patch/427183/ patchset.


target/linux/mvebu/config-3.14 | 2 +-
target/linux/mvebu/config-3.18 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

Applied as a part of r43938. Thank you!

Luka

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.