[Openhorst-Firmware] Projekt Horstbox mit Asterisk 1.6 od. 1.4 (kein analog)

[pette]

Hi,

Ich habe mir dann mal als Sideshow die Mühe gemacht die aktuelle lcr -Version auf Horst anzupassen (die alte lief mit dem aktuellen Kernel bei mir gar nicht mehr). Der funzt jetzt wieder auf dem aktuellen Asterisk.

Was heisst "funzt jetzt wieder"? Also bei mir hat das noch nie richtig funktioniert. Es gab immer Probleme, wenn ich einen Port im TE Modus und einen im NT Modus konfiguriert hatte (siehe posts in diesem thread).
Funktioniert das nun bei dir?? Wäre ja super!

Gruss,
Pette

 

[horatio42]

Hallo pette,

sorry für diese etwas generelle Aussage mit dem "funzt".
Ich nutze die Box im Moment ausschliesslich im TE Mode nach Extern. Den internen S0 und Analog nutze ich nicht. Funzt bezieht sich also auf TE, der bei mit dem alten lcr aber dem neuen Kernel/Asterisk nicht mehr funktionierte (siehe Post #360 in diesem Thread). Zuvor hatte ich schon einige andere Probleme mit einer älteren aber funktionierenden LCR/Kernel/Asterisk -Kombination ("Gesprächsklau" und hohe CPU-Auslastung) die mit dem neuen LCR anscheinend behoben sind.

Ich kann den NT-Mode (und Mischbetrieb mit TE) aber gerne die Tage mal ausprobieren. Ich würde mir aber wenig Hoffnung machen, weil ich immer mehr den Eindruck gewinne dass bei den Horstbox-HFC-S einige Spezialitäten verwirklicht sind (Kopplung über den lokalen Bus), so dass sie in irgendeiner Form voneinander abhängen, und ich eben nicht wie zwei unabhängige PCI-Boards im PC funktionieren. *Eigentlich* ist diese direkte Kopplung über die HW ja ein Vorteil, aber die normalen PC-Treiber funktionieren dann eben nicht (zapfhc) oder nur eingeschränkt (mISDN) ohne sie anzupassen.

Ich werde vielleicht demnächst mal versuchen den zaphfc aus der FW 5.0 zu portieren, vielleicht hat das mehr Aussicht auf Erfolg.

Gruss,
H.

 

[kombjuder]

Ich würde mir aber wenig Hoffnung machen, weil ich immer mehr den Eindruck gewinne dass bei den Horstbox-HFC-S einige Spezialitäten verwirklicht sind (Kopplung über den lokalen Bus), so dass sie in irgendeiner Form voneinander abhängen, und ich eben nicht wie zwei unabhängige PCI-Boards im PC funktionieren.

Sollte eigentlich kein Problem sein. Zumindest unter zaphfc wurde sogar empfohlen die Hfc-Chips der Karten direkt zu verlinken.
Unter zaphfc gibt es einen Befehl, die Karte in den Master- oder Slavemodus zu versetzen. Hfc im Slave-Modus produzieren dann keine Interrupt-Last.

 

[horatio42]

Sollte eigentlich kein Problem sein. Zumindest unter zaphfc wurde sogar empfohlen die Hfc-Chips der Karten direkt zu verlinken.
Unter zaphfc gibt es einen Befehl, die Karte in den Master- oder Slavemodus zu versetzen. Hfc im Slave-Modus produzieren dann keine Interrupt-Last.

Bei dem alten (nicht-v-)zaphfc -Treiber gibt es in der Tat Optionen fuer das Modul den einen Chip als Master und den anderen als Slave laufen zu lassen etc. (das ist quasi eins der Hauptfeatures des sog. "florz-patch" um nur eine Timing source zu haben). Ich hatte damit rumprobiert, funktioniert hat es aber nicht. Ich hatte auch die Sourcen von vzaphfc entsprechend gehackt um aehnliches da zu erreichen, aber auch ohne Erfolg.
Es sieht auch so aus dass man einige Config-Register des zaphfc wohl entsprechend setzen muss wenn die Chips untereinander verklinkt sind. Das passiert z.B. in zaphfc-Variante die dem FW 5.0 source beiliegt wenn der HSS-Bus genutzt wird.
Ich bin auch unsicher ob es sich bei der HSS-Loesung im Horst tatsaechlich um diesen lokalen Link handelt der in dem HFC-S Datenblatt beschrieben ist. Die Tatsache dass auch der DSP mit am Bus haengt koennte darauf hindeuten dass man hier was anderes vor hatte (eben z.B. die Audiodaten zwecks Echokompensation direkt zum DSP zu schieben).

Generell scheint es eine Menge Moeglichkeiten zu geben einen Treiber fuer die HFC-S Chips zu implementieren, halt ueber die Karten-eigenen Interrupts oder auch Softwarepolling. Bei den Interrupts scheint man auch eine gewisse Auswahl zu haben, die verschiedenen Treiber und ihre Varianten machen das immer teils etwas anders (benutzen verschiedene Interrupts). Zumindest wenn ich das richtig verstehe.
Deshalb halt meine Anregung mal Horsts alten zaphfc zu versuchen, der hat ja zumindest mal mit der gegebenen Hardware funktioniert...

Gruss,
H.

 

[potc]

@horatio42
So, hat ein bisschen gedauert, war im Urlaub.
Die "alten" HSS Treiber funktionieren nicht da sie die Intel Library brauchen, welche nur mit einem sehr alten Kernel gehen, womit alles andere wiederum Instabil wird.
Das neue hss module was ich eingebaut habe funktioniert teilweise.
Das Problem ist das wir noch ein generisches gpio SPI Modul benötigen um mit dem alten Source weiter zu kommen.
Leider ist das alles schon so lange er und alles mögliche andere war schon wieder wichtiger das ich mir das alles erst wieder erarbeiten muss.

Wenigsten kannst du die alten zap Treiber mit erträglichen Aufwand auf das neue hss Modul migrieren.

peter

 

[horatio42]

Hallo peter,

was bedeutet das konkret? Funktioniert das hss-modul so nicht?
Ich habe inzwischen mal einen ersten port des alten zaphfc moduls aus der FW5.0 auf dahdi und die neue HSS-infrastruktur versucht. Ich habe die ixp425_hss_register
-funktion durch die ixp4xx_tdm_register ersetzt, von der ich _annehme_ (mit gesundem bis gefährlichem Halbwissen...) dass dies die neue Version der Funktion ist. In eben dieser Funktion scheint es aber im Moment gnadenlos abzusemmeln (kernel oops).
Kann sein dass ich noch irgendwo einen Bug habe. Oder sind die von Dir erwähnten SPI-Treiber kritisch für die Funktion des HSS-Bus?

UPDATE: ich habe mal versucht zu verstehen wie dieser neue HSS-Kram funktionieren soll, bin aber da nicht wirklich voran gekommen. Mein "mapping" obigen Aufrufs auf den neuen Funktionsnamen ist vielleicht nicht ausreichend. Der Absturz scheint jedenfalls daher zu rühren dass die Sachen überhaupt nicht initialisiert worden sind (der Kernel Oops ist ein Nullpointer-Dereferenzierung). Gibt es da etwas mehr Doku zu?
Ich habe dann mal versucht das Ganze über den zuvor diskutierten khz-timer laufen zu lassen. Mir kam der Code schon beim Ansehen komisch vor (der Timer scheint effektiv gar nicht ausgelöst zu werden...). Der zaphfc.c-Treiber kompilierte auch nicht out of the box ohne das #define ZAPHFC_HSS. Da dies auch bei der Original-Version nicht kompiliert haben dürfte, gehe ich mal davon aus dass diese ganze khz-timer-Geschichte auch im Original (FW5.0) unfertig oder zumindest untested ist. Nach ein paar Fixes kompilierte es dann zumindest, verhält sich aber ansonsten genau wie mit den neueren Versionen von (v)zaphfc: Aktivität auf der Leitung ist vorhanden, der span ist aber down, die Interruptaktivität gering. Jedenfalls zu gering im Vergleich zum PC.

Gruss,
H.

 

[potc]

Hallo Horatio42,
die SPI Treiber brauche ich für die analog interfaces.
Die Digitalen kann ich dir jetzt nicht sagen.
Hänge mir halt mal deinen Code mit den Anpassungen rein oder hohle dir svn zugriff und commitdeinen teil, dann kann ich mal schauen.


ABer das mit den SPI Treiber zu implementieren ist halb so wild. Es gibt im Kernel das SOFT SPI Modul, dem muss man nur die Ports sagen und dann tut es schon

peter

 

[Michael.de]

Hallo Horatio42,

hast Du in IxNpeMicrocode.h die HSS-Sachen aktiviert? Die sind nämlich standardmäßig deaktiviert und somit im Microcode gar nicht enthalten.

Gruß Michael

 

[horatio42]

Hallo zusammen,

@Michael: Das mit dem Microcode wusste ich nicht, danke für den Hinweis. Ich habe dann - wieder mehr oder weniger durch raten anhand des Namens und des kurzen Kommentars im Source - mal das define für NPE-A auf

 #define IX_NPEDL_NPEIMAGE_NPEA_HSS_2_PORT

gesetzt... der Fehler bleibt aber der gleiche... gibt es dazu *irgendeine* Doku!?
So wie ich das mit den NPEs verstehe sind sie für verschiedene Designs jeweils konfigurierbar, d.h. man kann mit ihnen verschiedene Protokolle unterstützen, je nachdem was man physikalisch da dran gehängt hat. Wie sieht diese Konfiguration für Horst aus? Ist man hier ausschliesslich auf das reverse-engineeren der FW 5.0 angewiesen oder gibt es da sonstige Doku zu?

@Peter: ich schau die Tage mal das in einen commitbaren Zustand zu bringen, muss meinen Devel-Tree mal aufräumen, inzwischen habe ich zich branches mit diversen Experimentalversionen (zaphfc,vzpahfc,zaphfc-fw50..., jeweils mit mehreren Versionen von dahdi...). Die Anpassung von dem zaphfc aus der FW5.0 war in der Tat recht trivial (zumindest um es wieder kompilieren zu lassen), der port auf Dahdi beschränkte sich grösstenteils darauf zt_ -prefixes für Funktionen, defines und Variablen durch dahdi_ zu ersetzen Zu der HSS-Funktion hab ich einen data-void-pointer dazu gebastelt um den Aufruf in zaphfc mehr oder weniger so übernehmen zu können... ohne aber wie gesagt überhaupt zu wissen ob die Funktion überhaupt die richtige ist...


Soweit so schlecht. Meine letzten Experimente liefen dann wieder mit vzaphfc weil ich dessen Code noch am besten verstehe. Habe den Kernel auf das allernötigiste runtergestript um ihn mit debug-info zu bauen zu können und etwas ausführlichere Checks und Fehlermeldungen zu kriegen. Jetzt warnt er u.a. über mögliche Probleme mit spinlocks die durch interrupts falsch gesetzt sein könnten... mir scheint es fast als ob ich wieder am Anfang meiner Vermutungen gelandet bin und es in der Tat eine Race-Condition oder inkorrekte locks im Treiber gibt... was insofern "Sinn" machen würde als dass sich die Interrupt-Architektur zwischen meinem funktionierenden x86-build und ARM/XScale deutlich unterscheidet.
Aprospos funktionierendes x86: ich habe jetzt ein "perfekt" funktionierendes vzaphfc im TE-Mode auf einem Ubuntu 10.04.1 (32bit) auf einer einzelnen PCI-Karte (auf meine zweite ebay-Karte warte ich noch...). Da die gleichen Versionen von asterisk/vzaphfc/dahdi auf einem etwas älteren Mandriva vorher äusserst instabil waren, deutet auch das auf ein pot. Timing-Problem im Treiber hin... denke ich jedenfalls. Ich habe jedenfalls identische Sourcen verwendet, lediglich der Kernel auf der Mandiva war etwas älter. Das nur am Rande.

Gruss,
H.

 

[Michael.de]

Hallo horatio42,

Ich habe dann - wieder mehr oder weniger durch raten anhand des Namens und des kurzen Kommentars im Source - mal das define für NPE-A auf ...

IX_NPEDL_NPEIMAGE_NPEA_HSS_2_PORT ist richtig, siehe si3210/ixp425_hss.c. Aber das wird nicht reichen: Der Microcode wird zwar vom Kernel geladen (arch/arm/mach-ixp4xx/ixp4xx_npe.c) aber mehr auch nicht. Jetzt müssen wohl noch
- die Interrupts freigeschaltet werden
- der Queue Manager initialisiert werden
- die HSS-Ports initialisiert werden
... (siehe si3210/ixp425_hss.c)

gibt es dazu *irgendeine* Doku!?

Natürlich gibt es Doku, aber nur zur CPU/API und nicht für die Interna der Horstbox, man muss also den Source-Code analysieren und mit der Doku vergleichen.
Hier die Doku die ich gefunden habe:
- IXP400 Software, Programmers Guide (für Version 2.3, 2.4, 3.0)
- Enabling High Speed Serial Timeslot Switching in VoIP Gateways Incorporating Intel® IXP4XX Product Line of Network Processors
- Intel® IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor

Ich bin gerade dabei den Source-Code von DLink zu analysieren um evtl. die isdn/analog Treiber auf den aktuellen Kernel anzupassen, aber das dauert bei mir halt etwas länger

 

[potc]

Hallo Freunde der Horstbox,

habe mal wieder den devtree im SVN auf aktuellen Stand gebracht.

Damit ist dann auch, wenigstens bei mir, das Problem mit der Amok Laufenden Load bei Start das WEBIF weg.

peter

 

[rmh]

Hallo Peter,

danke für's commit. Habe die SVN210 durchlaufen lassen, komme aber nur bis zur toolchain / busybox, siehe hier:

>>> busybox 1.17.1 Building
PATH="/root/horst-210/buildroot/project_build_armeb/host/bin:/root/horst-210/buildroot/project_build_armeb/host/usr/bin:/root/horst-210/buildroot/project_build_armeb/host/usr/sbin/:/root/horst-210/toolchain/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" PERLLIB="/root/horst-210/buildroot/project_build_armeb/host/usr/lib/perl" CFLAGS="-Os -pipe -Os  -mtune=xscale -march=armv5te -mabi=apcs-gnu -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/include -I/root/horst-210/buildroot/project_build_armeb/../toolchain/include -I/root/horst-210/buildroot/project_build_armeb/toolchain/linux/include" /usr/bin/make -j1 CC="/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/bin/armeb-unknown-linux-uclibc-gcc --sysroot=/root/horst-210/buildroot/project_build_armeb/../toolchain" ARCH=arm PREFIX="/root/horst-210/buildroot/project_build_armeb/target" EXTRA_LDFLAGS="-L/root/horst-210/buildroot/project_build_armeb/../toolchain/lib -L/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/lib" CROSS_COMPILE="/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/bin/armeb-unknown-linux-uclibc-" -C /root/horst-210/buildroot/project_build_armeb/build/busybox-1.17.1
make[2]: Entering directory `/root/horst-210/buildroot/project_build_armeb/build/busybox-1.17.1'
  LINK    busybox_unstripped
Trying libraries: crypt m
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/bin/armeb-unknown-linux-uclibc-gcc --sysroot=/root/horst-210/buildroot/project_build_armeb/../toolchain -Os -pipe -Os -mtune=xscale -march=armv5te -mabi=apcs-gnu -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/include -I/root/horst-210/buildroot/project_build_armeb/../toolchain/include -I/root/horst-210/buildroot/project_build_armeb/toolchain/linux/include -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os -Os -pipe -Os -mtune=xscale -march=armv5te -mabi=apcs-gnu -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr2/new/Source-ast162/build_env/buildroot/output/../toolchain/usr/include -I/usr2/new/Source-ast162/build_env/buildroot/output/../toolchain/include --sysroot=/usr2/new/Source-ast162/build_env/buildroot/output/../toolchain/ -isysroot /usr2/new/Source-ast162/build_env/buildroot/output/../toolchain -I/usr2/new/Source-ast162/build_env/buildroot/output/toolchain/linux/include -L/root/horst-210/buildroot/project_build_armeb/../toolchain/lib -L/root/horst-210/buildroot/project_build_armeb/../toolchain/usr/lib -o busybox_unstripped -Wl,--sort-common -Wl,--sort-section,alignment -Wl,--gc-sections -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group
==========
/root/horst-210/buildroot/toolchain/usr/bin-ccache/../lib/gcc/armeb-unknown-linux-uclibc/4.4.4/../../../../armeb-unknown-linux-uclibc/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [busybox_unstripped] Fehler 1
make[2]: Leaving directory `/root/horst-210/buildroot/project_build_armeb/build/busybox-1.17.1'
make[1]: *** [/root/horst-210/buildroot/project_build_armeb/build/busybox-1.17.1/.stamp_built] Fehler 2
make[1]: Leaving directory `/root/horst-210/buildroot'
make: *** [toolchain_build] Fehler 2
evo:~/horst-210#

Gruß
R.

 

[Michael.de]

Hallo Leute,

ich habe mich mal mit dem HSS-Bus und dem zaphfc-Treiber etwas näher beschäftigt.

Am HSS-Bus sind die hfc's und der/die/das? fxo (si3050) angeschlossen und tauschen darüber ihre Nutzdaten aus. Dabei wird jedem Kanal ein Timeslot zugeordnet, den er zum Senden/Empfangen verwendet. Es können bis zu 32 Timeslots verwendet werden. Diese Timeslots werden nacheinander als Bitstrom gesendet, dieses Protokoll heist wohl HDLC.

Die fxs's (3210) können dies wohl nicht!? und tauschen gewöhnliche pcm-Daten aus.

Beim Umschreiben des zaphfc-Treibers (zaptel auf dahdi) ist mir aufgefallen, das anscheinend eine kleine API-Änderung im HSS-Treiber erfolgt ist.
Die Funktion ixp4xx_tdm_register registriert einen Kanal beim HSS-Bus, als Parameter erwartet sie einen Funktionszeiger und ein uint für den Kanal der im HDLC verwendet werden soll.

Die Funktion (im übergebenen Funktionszeiger) wird aufgerufen wenn Daten zwischen HSS und dahdi ausgetauscht werden sollen. Diese Funktion bekommt 2 Zeiger (sendepuffer, empfangspuffer) und ein uint id übergeben.

zaphfc erwartet aber kein uint sondern einen Zeiger auf dahdi_span, id ist aber eine nummer die anscheinend gleich dem Kanal ist für den Daten anstehen. (Bitte berichtigen)

Werde die Tage mal versuchen das umzuschreiben, nur mit dem Testen wird es nichts da ich immer noch keine zweite Box habe

Stellt sich jemand zur Verfügung und meinen Murx zu Testen?

Gruß Michael

 

[foschi]

Werde die Tage mal versuchen das umzuschreiben, nur mit dem Testen wird es nichts da ich immer noch keine zweite Box habe

Wenn Dir eine gebrauchte Box recht ist dann geb ich Dir gern eine ab. Abwicklung per PM.

 

[rmh]

Seit gestern gibt es buildroot 2010.08-rc2. Diese Version beinhaltet bereits busybox 1.17.2 stable. Ich werde das heute Abend testen und berichten. Bei evtl. Anpassungen der Config busybox1161 könnte ich etwas Hilfe brauchen. Diese ist noch auf dem buildroot stand 2010.05. Danke!


Gruß in die Runde
R.

 

[horatio42]

Hallo Michael.de und peter,

ich habe mal meine sourcen von zaphfc und vzaphfc in das svn-Repository commited. Diese werden im Moment nicht automatisch mitgebaut, sondern muessen explizit ueber ein

 make zaphfc_build

oder ein

 make vzaphfc_build

gebaut werden.

Es handelt sich hier um die zwei zuvor beschriebenen Varianten von zaphfc: vzaphfc ist der recht neue rewrite, zaphfc die von mir aus den FW5.0 sourcen portierte Version. Da ich im Moment selbst hin und her gerissen bin was am Ende vielversprechender ist hab ich beide committed. Bauen sollte man natuerlich immer nur eine Version. Die Config-Dateien hab ich erstmal noch nicht eingecheckt, kann sie aber bei Interesse noch nachreichen.

Ausserdem habe ich noch eine Version von zaphfc die auf dem sogenannten "florz-patch" basiert. Wenn ich die sourcen so richtig deute, wurde das zaphfc in FW5.0. von einer aelteren Version dieser sourcen geforkt. Die florz-Variante scheint noch so einiges an Erweiterungen und patches seit der Zeit des Forks gesehen zu haben, aber enthaelt natuerlich die Horst-spezifischen Anpassungen nicht. Bei Interesse kann ich diese dritte Variante aber auch noch einchecken.

Ich hoffe dass der Source zumindest als gemeinsamer Startpunkt dienen kann.

Ich hatte so etwas ueberlegt wie ich die sourcen einchecken soll. Schlussendlich habe ich zaphfc im source eingecheckt, vaphfc wird gegen die Originalversion auf googlecode gepatcht.

ACHTUNG: Ich hatte dahdi inzwischen auf 2.3.0.1 gezogen, hab das aber erstmal nicht eingecheckt, da es evt. Euren Build bricht. Falls es ok ist das upzudaten kann ich das noch nachreichen. Es fehlt im Moment auch noch ein dahdi-patch ohne das die zaphfc-Variante so erstmal nicht baut, fuerchte ich.

@Michael.de: Das mit den veraenderten Parametern in der hss/tdm -register Funktion war mir auch aufgefallen. Ich habe dann kurzerhand die TDM-Sourcen um den data-pointer erweitert. Sollte hoffentlich so funktionieren und ist eingecheckt, diff einfach mal gegen den alten Tarball.

Gruss,
H.

 

[Michael.de]

Hallo horatio42,

Hast dir ja ne Menge arbeit gemacht mit deinen Versionen

Ich habe auch daran gedacht die TDM-Sourcen um ein User-Datafeld zu erweitern, bin aber wieder davon abgekommen. Sollten die TDM-Sourcen jemals in den Vanilla-Tree aufgenommen werden kommt es zu Kommplikationen mit anderen ixp4xx-Boards.
Aber das lässt sich ja durch bedingte Kompilierung in Ordnung bringen, schreibe meinen Code gerade nochmals um.

Wie hast du den dahdi-code angepasst? Ich überlege gerade ob ich den bri_dchan Patch benutze, oder gibt es eine DAHDI-Version die das schon von Haus aus kann?

Gruß Michael

 

[horatio42]

Hi Michael,

Ich habe auch daran gedacht die TDM-Sourcen um ein User-Datafeld zu erweitern, bin aber wieder davon abgekommen. Sollten die TDM-Sourcen jemals in den Vanilla-Tree aufgenommen werden kommt es zu Kommplikationen mit anderen ixp4xx-Boards.
Aber das lässt sich ja durch bedingte Kompilierung in Ordnung bringen, schreibe meinen Code gerade nochmals um.

Hm, sind diese void-pointer data-fields sind *eigentlich* Standard für die Registrierung von callback-funktionen? Ich meine man kann denen ja auch nen Null-Pointer übergeben wenn man die nicht nutzt... keine Ahnung warum das da rausgeflogen ist.
Aber das mit der bedingten Kompilierung ist keine schlechte Idee. Im Zweifel muss man halt ggf. den späteren Vanilla-Kernel entsprechend patchen.

Wie hast du den dahdi-code angepasst? Ich überlege gerade ob ich den bri_dchan Patch benutze, oder gibt es eine DAHDI-Version die das schon von Haus aus kann?

Die Anpassung auf Dahdi war grösstenteils ein case-insensitive-search-and-replace von "zt_" durch "dahdi_"
Der bri_dchan-patch ist der Patch den ich in meinem vorigen Post als noch nicht committed beschrieben hatte. Hatte den halt auch an dahdi-2.3.0.1 angespasst, von Haus aus scheint das immer noch nicht dabei zu sein.

Gruss,
H.

 

[Michael.de]

@horatio42: Natürlich sind void Pointers kein Standard, maxina hat hier einfach einen Parameter im Intel-Source missbraucht um so einfach an den Channel-Pointer zu kommen. Der TDM-Programmierer hat sauber programmiert. Jetzt muss man sich halt überlegen, wie man aus der id den chan-pointer herzaubert:
1. bedingte Kompilierung in TDM
2. Umwandlung id -> chan-pointer in zaphfc z.B.

for (hfctmp = hfc_cards, i = 0; hfctmp; hfctmp = hfctmp->prev, i = i + 2) {
  if ((i + 1) < id) continue;
  chan = hfctmp->chans[i & 1];
}

bei der Annahme das wir eine feste Kanal-Zuordnung verwenden, für welche Lösung bist Du?

 

[horatio42]

Hi Michael,

ich bin nicht sicher ob ich das richtig verstehe. Ich hatte zunächst auch versucht eine Zuordnung ID -> Channel zu implementieren, war aber unsicher ob das sinnvoll ist. Sind die IDs nicht für den _HSS_ channel? Die channel pointer die die callback Funktionen erwartet sind aber dahdi channels. Das wären doch zwei völlig unterschiedliche Paar Schuhe, oder sehe ich das falsch? Ist dann so ein feste Zuordnung überhaupt möglich? Schliesslich werden die zaphfc - _Chips_ am HSS-Bus registriert, aber von denen hat doch jeder mehrere Dahdi-Channels, oder nicht? Somit wäre eine eindeutige Zuordnung von HSS-ID auf Dahdi-channel doch gar nicht möglich, oder sind diese HSS-IDs beliebig wählbar (will heissen: werden in dem HSS/TDM Zeug nicht benutzt und dienen wie der data-pointer nur dazu dem Callback seinen Kontext zurückzugeben)?
Wie gesagt, mir fehlt wirklicher Einblick in die Funktion des Hss-Bus, deshalb weiss ich auch nicht was diese IDs am Ende sein sollen (Geräteadressen?). Falls Du da mehr Einblick hast wäre obiges natürlich die eleganteste Lösung.

H.

Gruss,
H.