swconfig doesn't work

[Chadster766]

swconfig

[Chadster766]

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/

[mmilburn]

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]

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

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

[mmilburn]

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

[mmilburn]

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

[mmilburn]

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]

Working on pulling in dts related changes.

[mmilburn]

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

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]

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

[jackbguppy]

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]

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]

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]

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]

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

[mmilburn]

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

[Chadster766]

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]

I'll take a look

[mmilburn]

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]

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]

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

[Chadster766]

That would be good.

[mmilburn]

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

[mmilburn]

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

[mmilburn]

Added this to make it a little easier for people to follow along. https://github.com/mmilburn/marvell-switch

[Chadster766]

Is that code from the Linksys GPL?

[mmilburn]

It's not from their firmware GPL tarball, if that's what you're asking. It's what I extracted from that patch: http://patchwork.openwrt.org/patch/5367/ .

[mmilburn]

I wasn't able to find that code in their tarball.

[Chadster766]

Thanks for looking.

[mmilburn]

I looked around a little bit more, I know what they did for VLANs in their firmware:

$ pwd
/home/mark/linksys/WRT1900AC_FW_v1.1.8.161917_SP2/src/linux/patches

$ grep 'diff -N' *.patch | cut -f2 -d\: | cut -f4 -d' ' | less
...
linux-3.2.40/net/8021q/vlan.c
linux-3.2.40/net/bridge/br_fdb.c
linux-3.2.40/net/bridge/br_if.c
linux-3.2.40/net/bridge/br_private.h
linux-3.2.40/net/core/datagram.c
linux-3.2.40/net/core/dev.c
linux-3.2.40/net/core/iovec.c
linux-3.2.40/net/core/Makefile
linux-3.2.40/net/core/mv_nfp.c
linux-3.2.40/net/core/neighbour.c
linux-3.2.40/net/core/skbuff.c
linux-3.2.40/net/dsa/Kconfig
linux-3.2.40/net/dsa/Makefile
linux-3.2.40/net/dsa/mv88e6171R.c
...

They used "DSA" (distributed switch architecture) and the vlan support built into the kernel. That last file should tell you how closely related the 88E6171 is to the 88E6172. :smile:

This is why we can't use DSA and get swconfig working: http://wiki.openwrt.org/doc/techref/swconfig#distributed.switch.architecture.vs.swconfig

They're two competing APIs.

[mmilburn]

The upside of making me look more: I'm drowning in evidence suggesting I can take http://patchwork.openwrt.org/patch/5855/, change the device id, and have swconfig running.

[mmilburn]

doing a build with a hacked up mvsw6171 driver.

[mmilburn]

I thought I'd be clever and build it as a module. I guess modules don't get built if they aren't defined under the package/kernel package. I need to work out an efficient way of building and testing modules under the OpenWRT build system.

[mmilburn]

Hah! I'm being punished for being on an ancient kernel.

[Chadster766]

For package development you can use the below command.

make package/your-package-dir/clean make package/your-package-dir/compile V=s

[mmilburn]

Thanks, I made it past that. Now I'm seeing a build error that I didn't catch earlier. The switch driver is making a callout to of_mdio_find_bus, which apparently just missed getting into kernel 3.2. Now I'm trying to decide what makes more sense: bump up to 3.10 or rework the driver just for 3.2 (and probably rework it again later). I think I'll sleep on it.

[Chadster766]

I recommend rework for 3.2

[rainlake]

http://patchwork.openwrt.org/patch/5367/ should work. you just have to set it up by echo parameters to /sys/devices/platform/neta/switch/reg_w still trying to figure out how these parameters work. there is a configuration script in offical firmware: "/usr/sbin/vlan_setup"

[mmilburn]

You're right, it should. My thinking in trying to use http://patchwork.openwrt.org/patch/5855/ was that it would minimize refactoring, and we could submit it upstream almost immediately. The problem I'm having with 5855 is the fact that it was a patch against 3.10, and we're currently using 3.2. The kernel APIs are different.

5367 is also a 3.10 patch, the switch driver itself will not need changing, but we'll need to backport mvneta (the tie in point) again the potential problem of changed kernel APIs still applies. The other thing that worries me about 5367 is that it doesn't use swconfig, so we'd never be able to push our patch upstream to OpenWRT (since our long term plan is full OpenWRT support for this device).

I'm weighing the options... 5367 would get the switch working in the short-term, if we backport the mvneta driver. If backporting 5855 doesn't suck too much, it could get the switch working in a pretty short timeframe too. We could push the patch upstream in short order.

But there's still more to think about. mvneta is the driver for the ethernet interface on the armada xp SoC... We're going to need it eventually. It shouldn't affect swconfig support and the switch itself... but yeah..

Thoughts?

[mmilburn]

I'm currently pursuing a rework of 5855 to change to 3.2 compatible API calls simply because there's a total of 2 calls to change. mvneta is a larger driver, I haven't looked at it enough to say how many calls would need to be changed, my gut says it would be an order of magnitude more.

Eventually we're going to have to address all the problems that being on 3.2 brings though.

[rainlake]

I'm working on trunk version. by using belkin version. we could easily merge upstream changes in the feature. we do not have to use swconfig to setup vlan. belkin's way is quite easy. but we have to figure out how to do it. On Oct 9, 2014 3:16 PM, "Mark" notifications@github.com wrote:

You're right, it should. My thinking in trying to use http://patchwork.openwrt.org/patch/5855/ was that it would minimize refactoring, and we could submit it upstream almost immediately. The problem I'm having with 5855 is the fact that it was a patch against 3.10, and we're currently using 3.2. The kernel APIs are different.

5367 is also a 3.10 patch, the switch driver itself will not need changing, but we'll need to backport mvneta (the tie in point) again the potential problem of changed kernel APIs still applies. The other thing that worries me about 5367 is that it doesn't use swconfig, so we'd never be able to push our patch upstream to OpenWRT (since our long term plan is full OpenWRT support for this device).

I'm weighing the options... 5367 would get the switch working in the short-term, if we backport the mvneta driver. If backporting 5855 doesn't suck too much, it could get the switch working in a pretty short timeframe too. We could also push it upstream in short order.

But there's still more to think about. mvneta is the driver for the ethernet interface on the armada xp SoC... We're going to need it eventually. It shouldn't affect swconfig support and the switch itself... but yeah..

Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/Chadster766/McWRT/issues/20#issuecomment-58562516.

[mmilburn]

I get it. I know the belkin patch works.

"we could easily merge upstream changes in the feature." You're correct. The reason why I'm going down the path that I am, is that this repo is intended to be temporary. I personally don't want to be pulling down changes and merging them every OpenWRT release until the end of time. We want to push our changes upstream to OpenWRT, and get that "status" column on this page: http://wiki.openwrt.org/toh/start#linksys to say "supported" for the WRT1900AC.

I'm just trying to go about that the best way I know how. I guess you just have to believe me: I can't use Belkin's code and get us OpenWRT support.

If you want to help us get official OpenWRT support, by all means, pitch in. We could use the help.

[mmilburn]

@rainlake, take a look at #43 if you want to help us out.

[rainlake]

Sorry Mark, I kind of busy on weekends.

I’m currently working on hostapd on trunk. I merged a patch found online. however, got Segmentation fault.

On Oct 10, 2014, at 11:23 PM, Mark <notifications@github.com mailto:notifications@github.com> wrote:

@rainlake https://github.com/rainlake, take a look at #43 https://github.com/Chadster766/McWRT/issues/43 if you want to help us out.

— Reply to this email directly or view it on GitHub https://github.com/Chadster766/McWRT/issues/20#issuecomment-58736503.

http://schema.org/ http://schema.org/ http://schema.org/ http://schema.org https://github.com/Chadster766/McWRT/issues/20#issuecomment-58736503 https://github.com/Chadster766/McWRT/issues/20#issuecomment-58736503 https://github.com/Chadster766/McWRT/issues/20#issuecomment-58736503 https://github.com/Chadster766/McWRT/issues/20#issuecomment-58736503=

[leitec]

A little late, it seems, but hopefully still useful:

The mvsw6171 driver I submitted to OpenWrt works fine on the 6172. As somebody noted before, the 6172 lets you do 4096 VLANs, but this driver (and the 6171) let you use VLAN ID's in the whole 4k space. You just are limited to 64 individual VLANs. I doubt many people will run into that.

https://dev.openwrt.org/changeset/43487 shows the required stanza in the dts file for the driver to probe. That will be much more helpful against the mainline Chaos Calmer mvebu port using mvneta than the proprietary Belkin code with Marvell's out-of-tree driver, as it depends on the Linux PHY subsystem.

[Chadster766]

Thanks for the advise. We will look into it.

[mmilburn]

Not late at all. I haven't touched this in a while. I've been preoccupied with the wifi chip. I think the 4096 VLANs is a non-issue for this device, simply because splitting even the aggregate bandwidth available 4096 ways is absurd. If I'm thinking correctly, we'll only have to add the device id to the driver itself, and then add the stanza to our dts. Since mvsw6171 is in CC, there shouldn't be much resistance. Thanks for the driver Claudio!

[Chadster766]

@mmilburn did you want to switch projects and implement this sooner rather than later?

[leitec]

Glad to help.

The driver that was committed already would probe a 6172. Imre Kaloz tested it on the WRT1900 using the mainline mvebu port. It tests for & 0xffc0 == 1700, which works for 171x and 172x (where x is the chip submodel/revision)

I'm working on a patch to rename this mvsw617x for this reason.

You just need to know the PHY address. I'm fairly sure it's operating in indirect mode, like the EA4500 example. After that, just set the CPU ports such that cpu-port-0 maps to eth0 and port-1 to eth1.