[LEDE-DEV] [PATCH] [BUG] XRX200 VPE support is broken since conflicting SMP support was introduced
daniel at makrotopia.org
Tue Feb 28 12:02:05 PST 2017
On Tue, Feb 28, 2017 at 07:37:08PM +0100, Stefan Koch wrote:
> 2017-02-22 17:11 GMT+01:00 Daniel Golle <daniel at makrotopia.org>:
> > 4) Write a proper, platform agnostic driver to connect the SLIC via
> > SPI, PCM, I2C or whatever and add a simple DAHDI driver for it. Then
> > have asterisk do the transcoding (maybe some ASM optimization to make
> > it even take advantage of MIPS DSP instructions) and rely in the kernel
> > scheduler to share the load nicely between the two CPUs.
> > That'd be much cleaner and will even be reusable on other targets like
> > ramips or ar71xx (where we also got devices with SLICs) plus we can
> > support non-Infenion SLIC and escape the (intentional?) vendor-lock of
> > that shady Lantiq implementation.
> I think It would be a nice thing to have a native Linux SLIC driver.
> For FXS it may be easier than to implement DECT and other things that
> the firmware does support.
> Does the SLIC support the DECT functionality or is it somewhere else?
Nah, SLICs a rather simple AD/DA things with on-hook/off-hook
detection plus some high-voltage AC stuff going on to ring the bell.
Not crazily complicated, but also not exactly trivial. Caller-ID, ADSI,
DTMF and all that is taken care of purely in software by DAHDI.
Support for SLICs mostly depends on platform support for high-speed SPI
and PCM from what I understand, the rest should not be that hard...
Datasheets are also not hard to find.
DECT is a completely different story: Most devices I've seen so far
use Dialog's SC14452 connected via SPI and PCM. Sometimes a small FPGA
is used, supposedly serving as a PCM de-multiplexer, so SLICs and DECT
can be used simultanously on the same PCM bus. Supporting that might
give us a serious headache unless someone finds a good way to hack that
into the kernel (obviously, we'll have to reverse-engineer this first
by sniffing the PCM bus before and after it hits the FPGA)
For the more simple cases and/or more up-to-date boards, I put some
effort into porting Osmocom's DECT stack to OpenWrt long time ago:
But at the time there was no support for hardware-supported SPI on
Lantiq nor any support for PCM/I2S stuff, thus I was stuck with that
really old PCMCIA gear
It'd be great if someone could actually forward-port and test-run this
on some x86-32 gear with a PCMCIA slot and the COM-ON-AIR card flying
around in at Raumfahrtagentur in Berlin.
Some weird devices actually use a Cologne Chip HFC-4S connected via SPI
and then drive the analog ports and DECT indirectly via BRI. Those
boxes are more like a low-end ISDN PBX with built-in DECT and analog
ports. Supporting them should not be too difficult as datasheets as
well as drivers (as part of DAHDI) for Cologne Chip HFC are publicly
> I have never detected the VPE specific command line at AVM
> Fritz!Boxes. Do you know how they do it?
> The Easybox 904 uses the same VPE approach by loading the firmware,
> reduce system memory and so on. But this one is a bit more simplified.
No idea what AVM is doing. I mostly looked at Arcadyan and AudioCodes
More information about the Lede-dev