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

[Michael.de]

@horatio42:

...war aber unsicher ob das sinnvoll ist

Ich glaube das es sinvoll ist, schließlich haben pointer von zaphfc in TDM nichts verloren!

Welchen TDM-Kanal ein chan benutzt ist eigentlich egal. Im alten Code wurde beispielsweise nur jeder zweite Timeslot zwischen TS1 und TS16 benutzt (si3210/ixp425_hss_port0_cfg.h). Der neue TDM-code benutzt die Timeslots TS1-TS8 durchgehend (mach/ixp4xx_tdm_cfg.h)

Ja, die Callback-Funktion benötigt einen chan-pointer, bekommt ja aber nur ein int id (original TDM), deshalb der code im vorigen post der aus der id einen chan-pointer aus hfc_card holt und den benötigten pointer setzt. Dabei habe ich vorrausgesetzt das die erste hfc-Karte TS0 und TS1 benutzt, die zweite Karte TS2 und TS3 ... (um analog kümmern wir uns später)

Gruß Michael

 

[horatio42]

Hallo Michael,

ok, das mit den Timeslots wusste ich nicht.

Dazu hab ich noch ein paar Fragen:

- Die Timeslots/HSS-Channels sind schon vorab allokiert? Denn wenn ich mir die ixp4xx_tdm_register -Funktion anschaue, muss genau das der Fall sein wenn Du die Channel ID beim Registrieren des Callback vorgibst. Ist das was Du einem früheren Post schon mal meintest bzgl. der noch fehlenden Initialisierungen des HSS-Bus?

- Ist es nicht auch unsauber die Slot-Allokierung von der Dahdi-Channel Nummer abhängig zu machen? Im Endeffekt leakst Du hier auch Implementierungsdetails von dahdi in das HSS-Setup ohne dass da ein tatsächlicher Zusammenhang bestünde. Aber möglich dass mir wie gesagt das Verständnis abgeht was ein HSS-Timeslot genau ist.

Ich stimme mit Dir überein dass diese data-pointer-Geschichte etwas unsauber ist. Ich habe sie aber wie gesagt schon öfter in Callback-Architekturen gesehen, eben um den Kontext an den Callback zurückgeben zu können für den er angelegt wurde. Der Vorteil war für mich schlicht dass ich bei dem data-pointer *sicher* sein konnte nicht mit irgendwelchen Imlementierungsdetails des HSS-Bus zu kollidieren, da er eben von diesem nicht benutzt wird. Wenn Du Dir aber sicher bist was die Funktion des HSS-Bus angeht, ist es sicher besser den ixp-code unangetastet zu lassen.

Gruss,
H.

 

[Michael.de]

@horatio42:

Die Timeslots werden in ixp4xx_tdm.c erstellt und Speicher für HSS wird in ixp4xx_hss.c alokiert (glaube ich, habe es vor Kurzem dort irgendwo gesehen).

Man muss also nur die Module laden:

insmod /lib/modules/ixp4xx_hdlc.ko
insmod /lib/modules/ixp4xx_hss.ko
insmod /lib/modules/ixp4xx_tdm.ko

Bin mir jetzt nicht sicher ob noch eins fehlt oder die Reihenfolge so richtig ist, habe es noch nicht ausprobiert.

Ist es nicht auch unsauber die Slot-Allokierung von der Dahdi-Channel Nummer abhängig zu machen?

Die Speicher-Allokierung erfolgt beim Laden des hss/tdm Moduls. Das TDM-Modul stellt uns dann 8 TS-Kanäle zur Verfügung. Jetzt müssen wir eine Zuordnung treffen welche Hardware welche TS's benutzt. Ich sehe da keine Abhängigkeit. Was wir mit den Kanälen machen ist doch Anwendungs-Sache, oder?

Habe gerade dahdi gepatcht, mal sehen ob es kompiliert.

Gruß

 

[horatio42]

@Michael.de:

Die Module hatte ich zuvor schon geladen (allerdings heisst das erste nur hdlc.ko, und ixp4xx_tdm.ko exisitiert nicht da es im Moment in den Kernel fest einkompiliert wird).
Der Effekt war aber der zuvor schonmal erwähnte kernel oops, der sich über eine Null-Pointer Derefenzierung beschwerte. Ich hab das dann so gedeuted dass die Datenstrukturen eben noch nicht allokiert waren. Ich hatte als ID -1 übergeben um das HSS-Modul den Channel auswählen zu lassen, die einzigen Pointer die dann da dereferenziert werden sind port oder chan_devices).

Gruss,
H.

 

[Michael.de]

@horatio42:

Das ist in TDM etwas unglüglich gemacht: Man erlaubt die automatische Vergabe des Kanals (durch Übergabe eines negativen ints), ermöglicht es aber andererseits nicht die Kanal-Nummer herauszufinden, denn man bekommt ja nicht den Kanal sondern das startbit (das ist die Identifikation des Kanals im Bitstrom) zurück. Ich möchte aber auch nicht aus dem startbit den Kanal berechnen, wer weis ob die mal in TDM geändert werden.

Um keine feste Kanal-Zuordnung verwenden zu müssen, könnte ich mir noch einen parameter mit vorgabewert in ixp4xx_tdm_register vorstellen. Dieser Parameter wird dann bei der Registrierung mit der Kanalnummer gesetzt sofern der Parameter kein NULL-Zeiger (Vorgabe) ist.

Deine Meinung?

 

[horatio42]

@Michael.de

Also quasi als zusätzlicher Rückgabewert der Funktion?
Generell fände ich das mit der festen Kanalzuordnung kein Problem, solange wir sicher sind dass der Kanal nicht belegt ist. Und das dürfte in Horst ja unter unserer Kontrolle sein. Schlimmstenfalls müsste man halt überprüfen ob man -1 als Rückgabewert bekommen hat und einen anderen Kanal versuchen.
Dann müsste man aber eine map dahdi_chan<->hss-chan maintainen und könnte das nicht mehr mit der for-schleife lösen. Keine Ahnung was da günstiger ist. Wie kritisch sind Deiner Ansicht nach Änderungen am HSS/TDM-API? Gäbe es ne Chance dass die mit in Kernel-Sourcen kämen oder müssten wir den zusätzlichen Rückgabewert dann reinpatchen?
Ansonsten erscheinen mir die Lösungen gleichwertig.

Gruss,
H.

 

[Michael.de]

@horatio42:

Habe jetzt einfach eine neue Funktion zu TDM hinzugefügt, welche die id zu einem startbit zurückgibt. Das dürfte wohl die wenigsten Probleme bereiten.

Anbei code, übrigens habe ich die khz-timer Geschichte völlig rausgeschmissen.

Gruß Michael

 

[horatio42]

Hallo Michael,

sieht gut aus, bis auf ein paar Kleinigkeiten:

- Ich hatte in zaphfc.c noch die Funktionsheader der Interrupthandler ändern müssen weil die bei mir nicht kompilierten, da sind wohl ein paar Parameter im Kernel rausgeflogen. Hattest Du das so kompilieren können? Ich bin allerdings auch schon vor einigen Wochen auf 2.6.35 gewechselt, keine Ahnung wann die Funktionen geändert wurden.

- Ausserdem gab es wohl einige Änderungen in dahdi so das das chans[] array im struct hfc_card etwas geändert werden musste. Es gibt jetzt zusätzlich _chans[] um die Kompatibiltät zu dahdi wiederherzustellen. Diesen Code hab ich mehr oder weniger aus der zuvor erwähnten "dritten Variante", dem florz-geptchten zaphfc entnommen der auch schon auf dahdi portiert war.

Am Besten diffst Du Deine Version mal gegen das was ich heute morgen eingecheckt hatte, dann siehst Du was ich meine.

Den khz-timer rauszuschmeissen ist absolut in Ordnung, wie zuvor schonmal erwähnt glaube ich nicht dass der jemals funktioniert hat. Wo die aus dem Kernel einen auch nur halbwegs präzisen 1KHz Timer herzaubern wollten soll mir mal jemand erklären...

Die Änderungen im ixp_tdm sehen ok aus, nur (mehr als Frage): sind port und chan_devices[] auf alle Fälle nicht-null? Mir wird immer etwas warm wenn so pointer-Ketten im Code auftauchen die nicht zuvor auf Null getestet werden. Das ist allerdings im Rest des Treibers auch der Fall, aber in der register-Funktion bin ich dadurch ja auch mal direkt in ein Kernel-Oops reingerannt... Sind die auf jeden Fall vorab existent?

Gruss,
H.

 

[Michael.de]

@horatio42:

...sind port und chan_devices[] auf alle Fälle nicht-null

port ist eine globale variable und wird in __devinit hss_init_one mit Leben gefüllt, port->chan_devices wird durch die Funktion hss_create_channels die ebenfalls von __devinit hss_init_one aus aufgerufen wird, initialisiert wird.
Wenn da was schief läuft wird das Modul nicht geladen!

Bei mir ist der Code durch gelaufen:
Kernel 2.6.33.5
DAHDI 2.2.1 mit angepasstem bri_dchan Patch

Deine Änderungen in Bezug auf DAHDI schau ich mit morgen mal an.

Gruß Michael

 

[horatio42]

@Michael.de

Es kann sein dass die Änderungen an dahdi (das mit dem _chans[]) erst mit der 2.3.0.1 -Version notwendig waren. Ich hab hier inzwischen so einen Haufen an dahdi/zaphfc/asterisk/kernel -Versionen und -Kombination dass ich selbst nicht mehr durchblicke
Ich habe halt jetzt eine Kombination (bis auf den Kernel) genommen die auf einem Ubuntu-PC mit PCI-Karten stabil läuft (mit vzaphfc). Dann hab ich zumindest irgendeinen funktionierenden Vergleich.

Die Änderungen an dahdi sind Wie gesagt momentan nicht eingecheckt, ich werde aber mal den patch für 2.3.0.1 als neues File comitten, dann kannst Du es Dir mal ansehen.

Gruss,
H.

 

[potc]

@rmh
Probiere mal den aktuellen svn aus. Im buildroot ist ein Problem mit doppeltem sysroot bei gcc, sollte gefixt sein.

@horatio42
Der neue dahdi macht Probleme zusammen mit dem web_meetme da sie das timer modul geändert haben, darum noch die alte Version. Wer meetme nicht braucht kann das neue dahdi nehmen.

peter

 

[rmh]

Im buildroot ist ein Problem mit doppeltem sysroot bei gcc, sollte gefixt sein.

Habe ich auch gelesen, der build läuft gerade. Danke sehr!

EDIT 01.09.: Läuft noch immer nicht durch, Fehlermeldung ähnlich wie oben. Habe verschiedene Versionen von busybox, auch busybox-snapshot, versucht. Liegt wohl doch noch am buildroot, bzw. gcc.

[...]
==========
/root/horst-215/buildroot/toolchain/usr/bin/../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-215/buildroot/project_build_armeb/build/busybox-snapshot'
make[1]: *** [/root/horst-215/buildroot/project_build_armeb/build/busybox-snapshot/.stamp_built] Fehler 2
make[1]: Leaving directory `/root/horst-215/buildroot'
make: *** [toolchain_build] Fehler 2
evo:~/horst-215#

Gruß
R.

 

[horatio42]

Hi Michael.de,

@horatio42:
...
port ist eine globale variable und wird in __devinit hss_init_one mit Leben gefüllt, port->chan_devices wird durch die Funktion hss_create_channels die ebenfalls von __devinit hss_init_one aus aufgerufen wird, initialisiert wird.
Wenn da was schief läuft wird das Modul nicht geladen!
...

Das hier hat mich an was erinnert: meine letzten Experimente mit zaphfc liefen genau in die Richtung zu checken warum diese Null-Pointer-Deref passierte (also der Ooops). Dabei bin ich auch auf diese Funktionen gestossen. Die Module werden aber geladen. Mein Eindruck ist eher, dass die entsprechende Hardware nicht detektiert wird, kann das sein? Sind dafuer nicht diese _init_one Funktionen da? Das tdm_hss modul laedt bei mir jedenfalls ohne irgendwelche Ausgaben auf der console oder dem syslog.
Ich hatte dann vermutet dass das mit den von Dir erwaehnten fehlenden Initialisierungen zusammenhing, da aber noch nicht weiter nachgeforscht.

Gruss,
H.

 

[potc]

@horatio42 u. michael.de

Wenn ihr euch auf die hss module aus dem tdm paket bezieht könnt ihr euch gerne an den Autor Davide wenden.
Der ist auch mit einer Horstbox versehen und hat von seinem Chef die Erlaubnis da was zu machen.

peter

 

[potc]

@rmh
Hast du dir den letzten svn checkout geholt ?
Ich habe da gestern nämlich noch auf meinem Rechner getestet. Dort gab es den selben Fehler.

Dann habe ich einen patch für das buildroot mit eingebaut und dann lief alles durch.

Den patch habe ich dann gestern auch noch ins svn gestellt

peter

 

[Michael.de]

@horatio42:

Habe gestern nacht mal meine Horstbox vom Netz getrennt und die Module zu testen.

Alle Module laden incl. dahdi und zaphfc.

Aber ich habe auch eine Ausgabe seitens TDM vermisst. Also habe ich die Module nochmals mit debug-code neu gebaut. Du scheinst recht zu haben, das Modul TDM wird zwar geladen aber die Funktion hss_init_one wird gar nicht aufgerufen!??? Weiterhin ist mir aufgefallen, das keine Firmware geladen wird, habe diesbezüglich auch debug-code in hotplug eingebaut.

Ob es nun an ixp4xx_hss, ixp4xx_tdm oder evtl. an einer geänderten Kernel-API liegt muss ich noch klären.

Gruß Michael

 

[Michael.de]

NFS-Boot Horst

Hallo Leute,

ich wollte mir letzte Nacht beim Testen neuer Firmware das ewige Flashen ersparen und kam auf die Idee über NFS zu booten.

Also Kernel vorbereiten und los. Pech gehabt:
-Wenn man eth im Kernel einkompiliert, lädt der Kernel keine Firmware freiwillig (das image war im kernel)
- also Kernel gepatcht, damit er gleich beim boot die Firmware lädt
- Erfolg, die Firmware wird geladen
- Pech, NFS geht nicht, die Initialisierung von eth geht schief

Also NFS im Kernel verworfen und initramfs gebaut
- in redboot initramfs geladen
- Kernel geladen
- Pech, Kernel findet initramfs aber meckert kein rootfs

Hat jemand schon mal probiert die Horstbox über NFS zu booten?

Gruß Michael

 

[rmh]

@potc, habe den aktuellen svn stand (r215) inklusive dem neuen patch verwendet.
Zu Anfang des builds erfolgte ein Hinweis, dass die builroot config bereits vorhanden ist. Eben wegen dem Patch habe ich mit YES geantwortet und diese vermutlich überschrieben. Heute Abend kann ich das noch einmal durchlaufen lassen und bei deser Abfrage mit NO (=default) bestätigen.

EDIT: Wollte eben neu auschecken, aber euer Server antwortet nicht.

 

[potc]

Hallo Michael.de,
hast du das init vom kernel auch richtig gesetzt ?
Theoretisch kannst du ja sogar netzwerkboot vom redboot aus machen....
Dort ist aber auch beschrieben wie ein nfs boot gemacht wird, schau mal ins doc Verzeichnis rein.
Vielleicht hilft es ja weiter

Evtl. hilft auch mal ein quote der Kernel Meldungen beim boot.

peter

 

[horatio42]

Hallo Peter,

gab's da nicht irgendein Problem mit der Redboot-Konfiguration bzgl. NPEs und ETH PHY der effektiv verhindert dass ethernet im Redboot funktioniert? Irgendwo hatte ich mal was gelesen dass man erst einen gefixten Redboot in seinen Horst flashen muss damit das geht (was ja nicht ganz ungefaehrlich sein duerfte...)
Oder verwechsel ich da was?

Gruss,
H.