Quallenauge / Easybox-904-XDSL

Fork of openwrt with vendor specific changes from open sourced firmware 3.10.
GNU General Public License v2.0
20 stars 8 forks source link

Add gpio-spi driver for 74hc595 pin extender. #14

Closed kovz closed 5 years ago

kovz commented 5 years ago

This PR adds support for 74hc595 gpio extender. It used by touch driver for reset IC. Additionally this extender is used to control relays to switch filters on DSL line for different annex. Can disconnect DSL line completely - this will cause 1GiB eth link speed on WAN interface.

kovz commented 5 years ago

So, finally I got a time to make investigation on relays. Hope I did everything right. @arnysch and @Quallenauge Please check, if it works for you.

kovz commented 5 years ago

To me it looks like dsl_en_gpio is not defined in function stop_service of file dsl_control. I guess it first needs to be defined, e.g. the same way it is done in the start_service function.

Absolutely correct. Thank you. Added fix for it.

arnysch commented 5 years ago

Ok, in this box I write my success stories. Any suggestions will go into the previous box.

kovz commented 5 years ago

@arnysch regarding you proposal about add all needed kernel modules for this PR to dependencies - absolutely agree. Concerning kernel modules list. I'm not sure only if kmod-gpio-dev is necessary. I thought it adds possibility to export gpios to sysfs needed by dsl_control script. I will check it. But this rises other question in my mind. How can we add LCD and touch buttons modules specific for our device in the same way? Should they placed placed in package directory into main repository, or we can specify some device-dependant feed?

Regarding ADSL annex I(capital i). I tried to follow all possible variants. This picture describes all possible variants for ADSL/ADSL2/ADSL2+. So, from my experience, if it possible - someone will face with it. There was a surprise for me, that VDSL has same, at least annex A and B, variants as well. But in EU(and definitely in Germany) only annex B is allowed for VDSL lines. You wrote, that test with G.992.5 (ADSL2+) was successful. Correct me, if I'm wrong, this is annex L or M, isn't it? Did you try connect analog phone to F or U connector on back side and check if it works? Do you have a possibility to test this? Such test will proof, that my settings for relay work fine.

And one remark about OpenWrt, linux etc. This is first device, that I'm try to work on as a developer in opensource community . I haven't any experience nor in kernel, nor in Openwrt, nor in opensource development. My profile is micro controllers. So if you, or @Quallenauge see some ways, sources or solutions where we can do it better, please, do not hesitate and point me. Will try to do my best.

Quallenauge commented 5 years ago

And one remark about OpenWrt, linux etc. This is first device, that I'm try to work on as a developer in opensource community . I haven't any experience nor in kernel, nor in Openwrt, nor in opensource development. My profile is micro controllers. So if you, or @Quallenauge see some ways, sources or solutions where we can do it better, please, do not hesitate and point me. Will try to do my best.

I haven't recognized it, since it looks better than my results :) You do an very good job!

kovz commented 5 years ago

@arnysch

Question: as currently implemented, in Annex A mode, the DSL line is connected (via filters) with both the N/F jacks, and the Si3050/11? This feels like a conflict. Or do I misunderstand these relays?

A: This is not a conflict. Si3050/11 operates only on POTS(analog) and originally used only for auto answer functionality. For we can use them to bridging any VoIP channel to POTS.

Currently out_6/relay_5 setting goes by annexb true/false. But this does not reflect reality. In Germany we often use DSL Annex B with POTS.

I'm not a specialist in communication standards, but according to this article, if I understood correctly, ISDN is completely digital interface. So there is no reason to connect Si3050 to it. On the other hand annexB in xDSL only about frequency plan and it doesn't describe how to use reserved low-band. Probably some providers use it for POTS, which is look strange to me, because set appropriate annex is just more logical. Solution - control this relay from currently absent ISDN subsystem and set for now by default to Si3050 connected independently from annex.

Currently out_7/relay_4 setting goes by annexa true/false. I understand that in Annex A mode the N/F jacks are connected to the DSL line. This decision looks kind of arbitrary, because you might want to connect an internal phone to the SLIC FXS even when using DSL Annex A (e.g. with a PBX running on the eb904, which uses SIP for outward calls).

This is just a default reason to use annexA/L/M - provide POTS. In any case onboard SLIC has two channels and FXS0 traced directly to U connector. So user can always use PBX functionality on it. We can try add control logic to asterisk_lantiq_channel. In configuration could be specified how many FXS user wants use and switch relay according to this information. Currently there is a possibility to switch relay in ltq-vmmc kernel module. But it done very straight forward - switch provided in dts pins active at probe time.

arnysch commented 5 years ago

Hi kovz, thank you for your very good work. I learnt a lot from you (many "aha moments"). Stuff which I would have never realized on my own. While learning, I scrutinize things. Software development is an iterrative process. By studying your solution, I come up with improvements and suggestions (which might be faulty). Unfortunately this looks like critisism, but it is supposed not to be that. This is why I ironically called it "nitpicking". Because it is based on all this exciting stuff which you found out.

"How can we add LCD and touch buttons modules specific for our device"

Is it a problem to keep this eb904 specific stuff in lede-feeds-easybox904? I know, for buttons and displays, there are also .dts changes needed, so if you change something you possibly need two pull requests (for Easybox-804-XDSL and for lede-feeds-easybox904).

For example, in case that eb904 specific relay setup is needed, we could either add eb904 specific code to exisiting script files in the Easybox-804-XDSL package (like you did with file dsl-control). Or we could add a package in repo Easybox-804-XDSL or in lede-feeds-easybox904 which needs to be installed on the eb904. Every solution has pro and con, I cannot easily propose where to implement something.

Correct me, if I'm wrong, this is annex L or M

No, I am quite sure I have ADSL2+ annex B. The provider neither offers POTS nor ISDN; he only provides SIP. Stupid thing is that the lower frequency bands are not used at all on my line - guess they only contain crosstalk from other lines. AFAIK some providers here in Germany switch to annex J in this case. But most of them don't invest in ADSL any longer; instead they propose to book VDSL (and pay higher fees).

Did you try connect analog phone to F or U connector on back side and check if it works

As I have neither POTS nor ISDN on the outward line: Only thing I can test is using F/N connector with phone attached and running Asterisk with chan_lantiq module (guess this uses SLIC FXS1). Then I can try to make phone calls. Possibly I need to play with the relays a bit to make it going. Maybe I find time next weekend to do this.

So if you, or @Quallenauge see some ways, sources or solutions where we can do it better, please, do not hesitate and point me. Will try to do my best.

Great offer! Some stuff I find difficult (e.g. when and where to turn on/off a certain relay), so I have not pondered about a solution yet. Also I shy away from suggesting something if I am not confident that it works.

arnysch commented 5 years ago

Hi Qauge, these changes submitted by Kovz are big progress. I still think that the relay handling does not cover every situation, but that is of minor concern. I tested what I am able to test, and it looks good. So I vote to merge the pull request.

Quallenauge commented 5 years ago

Thanks for developing and testing. You guys rocks =)