Lantiq: xrx200: Add support for AVM Fritzbox 3390 #3656

cocktailyogi · 2020-12-06T09:57:33Z

All the work has been done some time ago by Andreas Böhler alias @andyboeh and was already documented in this closed Pull-Request: #2662

I have rebased that changes to Kernel 5.x, tested it and are now filing this pull request, because andyboeh did not want to continue this PR. I added some HW-details here:
https://openwrt.org/inbox/toh/avm/avm_fritzbox_3390

Status:
avm_fritz3390 is working with 5 GHz WIFI and tested for a couple of weeks as DSL-Router

2.4GHz not supported
(2.4 Ghz is implemented by a second SOC via "WASP-Interface". andyboeh did basic work on it, but to me it seemed to complicated and I am not interested in 2.4 Ghz WIFI of this box.) For details see https://www.aboehler.at/doku/doku.php/projects:fritz3390

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts

target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds

abajk · 2020-12-06T15:45:27Z

target/linux/lantiq/xrx200/base-files/etc/board.d/02_network

@@ -47,6 +47,9 @@ lantiq_setup_interfaces()
 	avm,fritz7430)
 		ucidef_add_switch "switch0" \
 			"2:lan:3" "3:lan:4" "4:lan:1" "5:lan:2" "6t@eth0"
+	avm,fritz3390)
+		ucidef_add_switch "switch0" \
+			"0:lan:3" "1:lan:4" "2:lan:2" "4:lan:1" "5:lan:5" "6t@eth0"


Is port number 5 connected to WiFi?

Yes, from what I understood it seems to be the connection to the second SOC (also know as WASP-interface)

I would remove LAN5 entirely for now, as it causes more confusion than it serves - see my other comments.

target/linux/lantiq/xrx200/base-files/etc/board.d/02_network

abajk · 2020-12-06T15:48:47Z

Maybe squash some commits

cocktailyogi · 2020-12-06T16:50:52Z

Okay, I have integrated your suggestions.
But I was not able to squash my commits. I googled how to squash commits on Github, but I am not sure if I understand how to do it. I am afriad that I might bring in this more mess, than it helps. So could someone guide me?

Yogi

jschwartzenberg · 2020-12-06T16:58:12Z

But I was not able to squash my commits. I googled how to squash commits on Github, but I am not sure if I understand how to do it. I am afriad that I might bring in this more mess, than it helps.

You have to do this using Git (not GitHub). First rebase using:
git rebase -i <parent commit>

Then in your text editor you can use squash/fixup.

Then:
git push -f

You have to use -f for a forced push as you're rewriting history. (The alternative would be a new branch & new PR, but GitHub handles squashes & forced pushes to existing branches well in PRs.)

In case you want to keep the original commit set around as a precaution, create another branch first and then switch back to this one before you squash & push.

target/linux/lantiq/image/vr9.mk

cocktailyogi · 2020-12-06T21:26:02Z

Maybe squash some commits

Done :-)

Thx to @jschwartzenberg

adschm · 2020-12-06T23:02:47Z

This should be tidied up:

Create commit by what they do, not by their history (e.g. one commit for fixing arch-wide gpio, one commit for adding devices, one commit for another separate subject)
Add missing commit messages
Take care to properly show/document authorship
There is no kernel 4.19 support anymore

Apart from that, be aware that the last PR was closed due to lack of interest, so it's probably that this one will meet the same fate and your work might be in vain (apart from individuals using the PR as is)

cocktailyogi · 2020-12-07T05:41:57Z

* There is no kernel 4.19 support anymore

I know, but what does this mean here. I did not include anything regarding Kernel 4.19

* Take care to properly show/document authorship

Is done, I think

* I just had squasehd my commits, because it was recommented. Now ther eis ne commit, what I did:

Rebasing the work somebody else has done. Basically this is one step.

andyboeh · 2020-12-07T09:08:27Z

Why are you basing your work on my avm_fritz3390_wifi branch instead of the avm_fritz3390 branch? The _wifi branch has all the infrastructure in place to bring up WiFi, whereas the other branch only includes the stuff you are actually trying to get included.

The problem here is that your commits first add a lot of stuff that you remove afterwards. So basically, your PR should come up with two commits:

One that adds the gpio-ranges define for all VR9 devices
One that adds device support

See #2662 for reference, where exactly this is done.

andyboeh · 2020-12-07T09:10:14Z

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts

+			gpios = <&gpio 34 GPIO_ACTIVE_HIGH>;
+		};
+	};
+


This export is only required if you bring up the secondary WiFi SoC. Personally, I would remove it for now - please wait for other reviewer's comments before doing so.

Okay, we should decide about this.

Also I woud prefer to remove this node.

andyboeh · 2020-12-07T09:11:55Z

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts

+				speed = <1000>;
+				full-duplex;
+			};
+		};


This node is only required for the WiFI SoC. On 4.19, this had no effect without a further patch because the xrx200 driver did not support fixed-link nodes. I don't know about 5.4 so please verify that.

andyboeh · 2020-12-07T09:12:57Z

target/linux/lantiq/xrx200/base-files/etc/board.d/02_network

@@ -47,6 +47,9 @@ lantiq_setup_interfaces()
 	avm,fritz7430)
 		ucidef_add_switch "switch0" \
 			"2:lan:3" "3:lan:4" "4:lan:1" "5:lan:2" "6t@eth0"
+	avm,fritz3390)
+		ucidef_add_switch "switch0" \
+			"0:lan:3" "1:lan:4" "2:lan:2" "4:lan:1" "5:lan:5" "6t@eth0"


I would remove LAN5 entirely for now, as it causes more confusion than it serves - see my other comments.

cocktailyogi · 2020-12-07T09:18:45Z

Why are you basing your work on my avm_fritz3390_wifi branch instead of the avm_fritz3390 branch? The _wifi branch has all the infrastructure in place to bring up WiFi, whereas the other branch only includes the stuff you are actually trying to get included.

The problem here is that your commits first add a lot of stuff that you remove afterwards. So basically, your PR should come up with two commits:
* One that adds the `gpio-ranges` define for all VR9 devices

* One that adds device support
See #2662 for reference, where exactly this is done.

Hi Andy, thx for your reply.
The answer is easy: Because I am beginner and not used to this big Github-Community. Is just wanted to use my Fritzbox3390 on Openwrt and make your work available for everyone in the future. This is easier, when it is fully comitted into Openwrt. I had it, if work is done and nobody respects it. Sorry that is used your wrong branch.
Do you think, I should close this PR and redo the job based on your other branch and file an new clean PR? I can do this, if this helps.

Yogi

andyboeh · 2020-12-07T09:37:10Z

The answer is easy: Because I am beginner and not used to this big Github-Community. Is just wanted to use my Fritzbox3390 on Openwrt and make your work available for everyone in the future. This is easier, when it is fully comitted into Openwrt. I had it, if work is done and nobody respects it. Sorry that is used your wrong branch.

No worries, it just would have saved you a lot of work.

Do you think, I should close this PR and redo the job based on your other branch and file an new clean PR? I can do this, if this helps.

No, just squash it properly - same effect.

cocktailyogi · 2020-12-07T10:22:06Z

Okay, I squashed it more. Now it looks like the Wifi-Stuff was never in here.

adschm · 2020-12-07T12:12:05Z

I know, but what does this mean here. I did not include anything regarding Kernel 4.19

target/linux/lantiq/files-4.19/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts ?

adschm · 2020-12-07T12:16:32Z

Okay, I squashed it more. Now it looks like the Wifi-Stuff was never in here.

As both andyboeh and me stated: This needs only two commits: one for the gpio-ranges, and one for device support.

Keeping somebody elses work does not mean you cannot change it anymore, you just need to document what you changed in the commit message ...

adschm · 2020-12-15T19:53:37Z

One of the commits still doesn't have a commit message.

Which one? On my screen they both have commit-messages.

lantiq: VR9: fix gpio-hog by defining the GPIO ranges

cocktailyogi · 2020-12-16T09:06:42Z

One of the commits still doesn't have a commit message.

Which one? On my screen they both have commit-messages.

lantiq: VR9: fix gpio-hog by defining the GPIO ranges

added more text ;-)

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts

abajk · 2020-12-19T15:45:54Z

One of the commits still doesn't have a commit message.

Which one? On my screen they both have commit-messages.

lantiq: VR9: fix gpio-hog by defining the GPIO ranges

added more text ;-)

It would be good to explain in the commit description that this change is needed by gpio-hog on Fritzbox 3390.

cocktailyogi · 2020-12-19T16:13:27Z

One of the commits still doesn't have a commit message.

Which one? On my screen they both have commit-messages.

lantiq: VR9: fix gpio-hog by defining the GPIO ranges

added more text ;-)

It would be good to explain in the commit description that this change is needed by gpio-hog on Fritzbox 3390.

done

The FRITZ!Box 3390 actually contains two SoCs, one Lantiq with a 5GHz WiFi and one AR9342 with a 2.4GHz WiFi. Only the Lantiq has access to the flash memory, the Atheros runs fully from RAM. Specifications -------------- - Lantiq 500 MHz - 128MiB RAM - 128MiB NAND - 256k Flash - AR9580 5GHz WiFi - AR9342 560 MHz - 64MiB RAM - AR9328 2.4GHz WiFi Remarks ------- This commit only adds support for the Lantiq side of things and prepares the drivers for communication with the Atheros SoC. Thus, only 5GHz WiFi works by default, the 2.4GHz WiFi will be added via another target. Some kernel patches will be required to add support for the Atheros SoC. Installation ------------ Use the eva_ramboot.py script to boot the initramfs image. Then, transfer the sysupgrade image to the device and run sysupgrade to flash it to the NAND. Signed-off-by: Andreas Böhler <dev@aboehler.at> ----------------------------------------------------------- Rebased support for AVM Fritzbox 3390 Tested as DSL-Router with 5 GHz Wifi. 2.4GHz Wifi is not functiional. 2.4Ghz is implemented in HW via 2nd SOC, which is booted via internal Ethernet, called WASP-Interface, which is not covered by this Commits Changed wpad-basic-wolfssl as default add "pinctrl-0" nand settings. Now it is similar to Fritzbox 3370 with Micron-NAND, which has similar architecture and Nand remove gpio-setting for WASP-reset removed unused nand-device changed ethernet mode to rgmii Corrected NAND Bank width according to specs Signed-off-by: Joachim Cerny <cocktail_yogi@web.de>

@abajk

defined gpio-ranges according to Reference: https://github.com/torvalds/linux/blob/master/drivers/pinctrl/pinctrl-xway.c#L864 This change is needed by gpio-hog on Fritzbox 3390 thx to @abajk Signed-off-by: Joachim Cerny <cocktail_yogi@web.de>

abajk · 2020-12-20T09:46:10Z

Acked-by: Aleksander Jan Bajkowski A.Bajkowski@stud.elka.pw.edu.pl

cocktailyogi · 2020-12-21T18:16:08Z

Okay, whats next? I have done all requested changes. Now its time to finish things.

jschwartzenberg · 2020-12-21T20:39:27Z

Okay, whats next? I have done all requested changes. Now its time to finish things.

At least one more code review is necessary, but to obtain the best quality it never hurts to have even more people look at the changes. Maybe you could ask in #openwrt on Freenode, ask through the mailing list or the forum?

Hopefully a second reviewer can at least join in!

cocktailyogi · 2020-12-23T07:31:26Z

@adschm
Could you please have a look at the final changes? You have done a lot of review-work and helped a lot. It would be nice, if you could approve this.

Yogi

cocktailyogi · 2020-12-24T12:45:38Z

Okay, whats next? I have done all requested changes. Now its time to finish things.

At least one more code review is necessary, but to obtain the best quality it never hurts to have even more people look at the changes. Maybe you could ask in #openwrt on Freenode, ask through the mailing list or the forum?

Hopefully a second reviewer can at least join in!

Why cannot you do the codereview?

jschwartzenberg · 2020-12-24T12:53:26Z

Why cannot you do the codereview?

I'm not an OpenWRT developer. I just hope to see this merged because Fritzboxes are also commonly used where I live.

People that are part of the OpenWRT GitHub organization need to review & approve I think.

cocktailyogi · 2020-12-25T08:51:17Z

Why cannot you do the codereview?

I'm not an OpenWRT developer. I just hope to see this merged because Fritzboxes are also commonly used where I live.

People that are part of the OpenWRT GitHub organization need to review & approve I think.

Merry Christmas,

you are a helpful guy and have good knowledge. they should promote you into developer status. In our area people are using plenty of AVM-devices. Lets hack them :-)

jschwartzenberg · 2020-12-25T10:02:29Z

Merry Christmas,

Merry Christmas to you too and/or Merry Grav-Mass ;)
Hope everybody can enjoy these days!

you are a helpful guy and have good knowledge. they should promote you into developer status. In our area people are using plenty of AVM-devices. Lets hack them :-)

Haha not really. I know Git and while I am a software developer, C is not a language I know well and I know little about OpenWRT as well. Even if they would promote me so that I could approve a PR like this, I would never do it.

We need to be patient here. OpenWRT and also the Linux kernel could only be where they are now because people took care to make sure changes going in were of high quality. Code reviews are an important part of software development. At work I am known for stating that while a feature might already implemented and in the code review phase, that could still mean it is far from done as during the code review it might turn out to be necessary to rewrite the entire implementation of it.

Do not be discouraged! Having one approval for this is already a major milestone. It is not unlikely you will be asked to change some things before there will be a second approval. This can be a long process, but it is only so much for the better once your changes end up in OpenWRT. As all changes go through these processes, it ensures that once this router model is supported it will continue to work in the future as others bring in their changes. Having well-understood code also helps new developers to step in and contribute.

With typical proprietary firmware, the vendors have access to all hardware to be supported so they can actually test each and every release they put out on all their models. OpenWRT does not have this, so code quality is much more important.

So get this further going, I would recommend asking around in the OpenWRT community as I suggested. Being acquainted there will also create trust. Even when changes are merged in, it is possible some after-care is needed too. Showing interest and being involved with the OpenWRT community also creates the necessary trust that you will be around when such after-care is needed. It is not possible to expect OpenWRT project members to reach out to contributors when facing issues. They rely on being able to understand issues themselves, but having original contributors in reach is ideal. Can they expect you to monitor their bug tracker from time to time and reply to Fritzbox 3390 issues for example?

A second thing I recommend doing is contacting your ISP and/or AVM. Explain them the benefits you see in them supplying resources. If AVM as a vendor would at least provide minimal resources to OpenWRT development, it would already be great.

I hope this helps! Good luck!!

cocktailyogi · 2021-01-08T09:54:52Z

Hi, I have tested it three weeks ago. On my Box Fritzbox 3390 it is needed. Without GPIO-Ranges, GPIO-numbers are getting messed up. Am Do., 7. Jan. 2021 um 21:36 Uhr schrieb Aleksander Bajkowski < notifications@github.com>:

…

@cocktailyogi <https://github.com/cocktailyogi> It looks like gpio-ranges is no more needed since kernel 5.0. [1] ***@***.*** <abajk/linux@9b4924d> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3656 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABX5OZWPCIOLMB5JGWJS6V3SYYLONANCNFSM4UPGOUZA> .

hauke · 2021-04-03T17:19:23Z

Thank you for the pull request, I applied it to master.

jschwartzenberg · 2021-04-03T18:38:33Z

Great to see progress on the AVM boxes!! Thanks a lot everybody!

Gisi0 · 2021-05-09T13:57:44Z

Great to have an image for this, I tried to install the snapshot and get this error using eva_ramboot.py
I hope somebody can help me.

SETENV memsize 0x07ae4000 Traceback (most recent call last): File "./eva_ramboot.py", line 40, in <module> adam('SETENV memsize 0x%08x'%(addr)) File "./eva_ramboot.py", line 33, in adam resp = ftp.sendcmd(cmd) File "/usr/lib/python3.7/ftplib.py", line 273, in sendcmd return self.getresp() File "/usr/lib/python3.7/ftplib.py", line 246, in getresp raise error_perm(resp) ftplib.error_perm: 500 'SETENV memsize 0x07ae4000': command not understood.

sfritz2 · 2021-05-22T18:48:01Z

Works fine for me. If it is not working for you, flash a 3370 image (https://openwrt.org/toh/avm/fritz.box.wlan.3370?s[]=3370 ), use the micron version. After make a sysupgrade to 3390.

sfritz2 · 2021-05-22T20:12:27Z

also try to set first the ip to 192.168.178.5 and make a ping on boot, ttl should be 250. if not, you're not in bootloader and restart the fritzbox.

Gisi0 · 2021-05-23T09:49:00Z

Got it to run, forgot a switch between the box and my pc. Network was to late up.

cocktailyogi mentioned this pull request Dec 6, 2020

lantiq: add support for AVM FRITZ!Box 3390 #2662

Closed

cocktailyogi changed the title ~~Lantiq: Add support for AVM Fritzbox 3390~~ Lantiq: xrx200: Add support for AVM Fritzbox 3390 Dec 6, 2020

abajk suggested changes Dec 6, 2020

View reviewed changes

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts Outdated Show resolved Hide resolved

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts Outdated Show resolved Hide resolved

abajk suggested changes Dec 6, 2020

View reviewed changes

abajk reviewed Dec 6, 2020

View reviewed changes

target/linux/lantiq/image/vr9.mk Outdated Show resolved Hide resolved

abajk reviewed Dec 6, 2020

View reviewed changes

target/linux/lantiq/image/vr9.mk Outdated Show resolved Hide resolved

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch 6 times, most recently from 1dea752 to 06b9bd7 Compare December 6, 2020 21:24

adschm added needs changes target/lantiq pull request/issue for lantiq target labels Dec 6, 2020

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch from 06b9bd7 to 8be7b69 Compare December 7, 2020 05:37

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch from 8be7b69 to 34747e7 Compare December 7, 2020 09:00

andyboeh reviewed Dec 7, 2020

View reviewed changes

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch from 34747e7 to 591b54b Compare December 7, 2020 10:10

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch from fe4a0fb to a9c6359 Compare December 16, 2020 09:05

cocktailyogi requested a review from adschm December 19, 2020 10:27

abajk suggested changes Dec 19, 2020

View reviewed changes

target/linux/lantiq/files/arch/mips/boot/dts/lantiq/vr9_avm_fritz3390.dts Outdated Show resolved Hide resolved

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch from a9c6359 to 8ed293b Compare December 19, 2020 16:13

andyboeh and others added 2 commits December 20, 2020 09:11

cocktailyogi force-pushed the avm_fritz3390_wifi_rebased branch from 8ed293b to 1345a03 Compare December 20, 2020 08:18

abajk approved these changes Dec 20, 2020

View reviewed changes

jschwartzenberg mentioned this pull request Dec 30, 2020

lantiq: add basic support for AVM FRITZ!Box 7490 #2738

Closed

hauke closed this Apr 3, 2021

cocktailyogi deleted the avm_fritz3390_wifi_rebased branch April 6, 2021 17:46

Lantiq: xrx200: Add support for AVM Fritzbox 3390 #3656

Lantiq: xrx200: Add support for AVM Fritzbox 3390 #3656

Conversation

cocktailyogi commented Dec 6, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abajk commented Dec 6, 2020

cocktailyogi commented Dec 6, 2020

jschwartzenberg commented Dec 6, 2020

cocktailyogi commented Dec 6, 2020

adschm commented Dec 6, 2020

cocktailyogi commented Dec 7, 2020

andyboeh commented Dec 7, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cocktailyogi commented Dec 7, 2020

andyboeh commented Dec 7, 2020

cocktailyogi commented Dec 7, 2020 • edited

adschm commented Dec 7, 2020

adschm commented Dec 7, 2020

adschm commented Dec 15, 2020

cocktailyogi commented Dec 16, 2020

abajk commented Dec 19, 2020

cocktailyogi commented Dec 19, 2020

abajk commented Dec 20, 2020

cocktailyogi commented Dec 21, 2020

jschwartzenberg commented Dec 21, 2020

cocktailyogi commented Dec 23, 2020 • edited

cocktailyogi commented Dec 24, 2020

jschwartzenberg commented Dec 24, 2020

cocktailyogi commented Dec 25, 2020

jschwartzenberg commented Dec 25, 2020

cocktailyogi commented Jan 8, 2021 via email

hauke commented Apr 3, 2021

jschwartzenberg commented Apr 3, 2021

Gisi0 commented May 9, 2021

sfritz2 commented May 22, 2021 • edited

sfritz2 commented May 22, 2021 • edited

Gisi0 commented May 23, 2021

cocktailyogi commented Dec 6, 2020 •

edited

cocktailyogi commented Dec 7, 2020 •

edited

cocktailyogi commented Dec 23, 2020 •

edited

sfritz2 commented May 22, 2021 •

edited

sfritz2 commented May 22, 2021 •

edited