@alle: ich habe noch HBX Professional (und die etwas seltenere Carrier-Variante) abzugeben, wobei ich mich über ein paar EUR freuen würde ;-)
Bei Interesse bitte einfach PM.
[Openhorst-Firmware] Projekt Horstbox mit Asterisk 1.6 od. 1.4 (kein analog)
- Ersteller potc
- Erstellt am
@alle: ich habe noch HBX Professional (und die etwas seltenere Carrier-Variante) abzugeben, wobei ich mich über ein paar EUR freuen würde ;-)
Bei Interesse bitte einfach PM.
rmh
Aktives Mitglied
- Mitglied seit
- 6 Jul 2008
- Beiträge
- 1,934
- Punkte für Reaktionen
- 28
- Punkte
- 48
Noch einmal zum Thema/Problem SVN 215 und Abbruch des builds beim Bau der busybox. Bei mir tritt das Problem trotz des neuen buildroot patches auf. Kann jemand bestätigen, dass der Build von SVN 215 durchläuft?
Ändeurngen nach dem checkout sind nano (make toolchain_config) und das alternative script webif_rw.mk mit passendem Makefile. Das ist aber sicherlich nicht das Problem. Ich raff's nicht. :noidea:
Ändeurngen nach dem checkout sind nano (make toolchain_config) und das alternative script webif_rw.mk mit passendem Makefile. Das ist aber sicherlich nicht das Problem. Ich raff's nicht. :noidea:
@rmh
Bei mir baut es, allerdings hab ich so einige Änderungen auf meinem buildtree die ich selbst maintaine (aber nix im Bereich busybox/buildroot/compiler). Ich hatte aber mit Peters Änderungen vor dem fix den gleichen Fehler wie Du. Ich hatte mir temporär damit beholfen Peters' lokale Pfade aus den configs busybox1161 und uclibc.config-0.9.31 durch meine eigenen zu ersetzen, dann funktionierte es.
Nach Übernahme von Peters fix hab ich das aber wieder reverted um nicht (und wohlmöglich dann ohne es zu merken) lokal in Abhängigkeiten auf diese Directories zu rennen wenn ich auf einem anderen Builddir bin.
Wie gesagt ist das Problem seit dem Fix bei mir gelöst.
Gruss,
H.
Bei mir baut es, allerdings hab ich so einige Änderungen auf meinem buildtree die ich selbst maintaine (aber nix im Bereich busybox/buildroot/compiler). Ich hatte aber mit Peters Änderungen vor dem fix den gleichen Fehler wie Du. Ich hatte mir temporär damit beholfen Peters' lokale Pfade aus den configs busybox1161 und uclibc.config-0.9.31 durch meine eigenen zu ersetzen, dann funktionierte es.
Nach Übernahme von Peters fix hab ich das aber wieder reverted um nicht (und wohlmöglich dann ohne es zu merken) lokal in Abhängigkeiten auf diese Directories zu rennen wenn ich auf einem anderen Builddir bin.
Wie gesagt ist das Problem seit dem Fix bei mir gelöst.
Gruss,
H.
@horatio42:
It's not abug, it's a feuture.
Das TDM-Modul beinhaltet einen Platform Treiber, und die haben ihre eigenen
init Funktionen zusätzlich zum Modul-init. Wenn ich das richtig verstanden habe, sollte diese init-Funktion erst ausgeführt werden wenn die Hardware dazu gefunden/geöffnet wird.
Also habe ich mal die Module hdlc,hss,tdm,dahdi,zaphfc geladen und dahdi_cfg (zum öffnen der devices) ausgeführt. Allerdings habe ich dann auch die von dir schon erwähnten NULL-Pointer geerntet.
Was mich aber dabei stört, laut Log wird immer noch keine Firmware geladen und die platform init-Funktion wird auch nicht aufgerufen.
Muss man die evtl. per Hand aufrufen oder per Hotplug irgendwas erledigen?
Gruß Michael
It's not abug, it's a feuture.
Das TDM-Modul beinhaltet einen Platform Treiber, und die haben ihre eigenen
init Funktionen zusätzlich zum Modul-init. Wenn ich das richtig verstanden habe, sollte diese init-Funktion erst ausgeführt werden wenn die Hardware dazu gefunden/geöffnet wird.
Also habe ich mal die Module hdlc,hss,tdm,dahdi,zaphfc geladen und dahdi_cfg (zum öffnen der devices) ausgeführt. Allerdings habe ich dann auch die von dir schon erwähnten NULL-Pointer geerntet.
Was mich aber dabei stört, laut Log wird immer noch keine Firmware geladen und die platform init-Funktion wird auch nicht aufgerufen.
Muss man die evtl. per Hand aufrufen oder per Hotplug irgendwas erledigen?
Gruß Michael
rmh
Aktives Mitglied
- Mitglied seit
- 6 Jul 2008
- Beiträge
- 1,934
- Punkte für Reaktionen
- 28
- Punkte
- 48
Servus und danke für die Infos. Leider ist der Server schon wieder nicht erreichbar, gestern gegen 20:30 auch nicht, daher muss ich das ganze auf Sonntag verschieben. Peter, was treibt ihr da? 
Gruß in die Runde
R.
Gruß in die Runde
R.
@rmh
Der Server ist down gewesen weil der Hetzner gerade einen Teil seines Serverzentrums in Nürnberg umzieht.
Dummerweise war der Server einmal fehlerhaft aus und letzten Abend müsste er an dem neuen Standort angekommen sein.
Sorry dafür das eine für dich kostenlose Ressource kurzzeitig nicht verfügbar war.
Wg. der Buildprobleme werde ich das ganze jetzt nochmal an einem jungfräulichen ubuntu 9 probieren
peter
Der Server ist down gewesen weil der Hetzner gerade einen Teil seines Serverzentrums in Nürnberg umzieht.
Dummerweise war der Server einmal fehlerhaft aus und letzten Abend müsste er an dem neuen Standort angekommen sein.
Sorry dafür das eine für dich kostenlose Ressource kurzzeitig nicht verfügbar war.
Wg. der Buildprobleme werde ich das ganze jetzt nochmal an einem jungfräulichen ubuntu 9 probieren
peter
Fehlt da ein Smiley?
Wie wäre es wenn ihr überlegt, das ganze auf sourceforge umzuziehen? Ich hatte dort in der Vergangenheit ein Projekt HorstBox angelegt, und der 'project space' steht zur Verfügung (ich geb auch gern die Verwaltung an euch ab).
@horatio42:
Habe mit angehängtem Patch den Kernel neu gebaut. Mit:
wird man im Log belohnt:
Leider habe ich danach beim Laden von dahdi/zaphfc und Ausführen von dahdi_cfg einen Seg-Fault. Muss mir wohl zaphfc noch mal vornehmen.
Gruß Michael
Habe mit angehängtem Patch den Kernel neu gebaut. Mit:
Code:
insmod /lib/modules/hdlc.ko
insmod /lib/modules/ixp4xx_hss.ko
insmod /lib/modules/ixp4xx_tdm.ko
Code:
Jan 1 01:00:26 (none) user.info kernel: HDLC support module revision 1.22
Jan 1 01:00:35 (none) user.info kernel: hdlc0: HSS-0
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: __init init_module
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: __devinit hss_init_one
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: hss_npeInit
Jan 1 01:01:09 (none) user.info kernel: ixp4xx_tdm ixp4xx_tdm.0: firmware: requesting NPE-A
Jan 1 01:01:09 (none) user.info kernel: NPE-A: firmware functionality 0x9, revision 0x0:0
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: NPE initialized succesfully
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: hss_create_channels
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: hss_qmgrInit
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: 8 channels configured as TDMMAP_VOICE64K
Jan 1 01:01:09 (none) user.warn kernel: ixp4xx_tdm: hss_config_load
Jan 1 01:01:09 (none) user.info kernel: ixp4xx_tdm: HSS-0 configured
Jan 1 01:01:09 (none) user.notice root: Firmware found (/usr/lib/hotplug/firmware//NPE-A)Gruß Michael
Zuletzt bearbeitet:
rmh
Aktives Mitglied
- Mitglied seit
- 6 Jul 2008
- Beiträge
- 1,934
- Punkte für Reaktionen
- 28
- Punkte
- 48
Peter, hoffentlich hast du mich nicht falsch verstanden. Ich wollte mich keinesfalls beschweren sondern nur scherzhaft anmerken, dass der Server nicht erreichbar ist. Nichts für ungut und danke für die Infos!
:keks:
:keks:
@horatio42
Du hast recht das es der redboot nicht kann.,
Da gab es zwar einen alternativen redboot aber der ging bei mir auch nicht richtig.
Das beste wäre ja auf u-boot umzusteigen, aber der Aufriss den redboot zu ersetzen ist sehr hoch, leider.
Ich wollte damit nur sagen das die sich auch in Bezug auf nfs kernel usw. ausgelassen hatten.
peter
Du hast recht das es der redboot nicht kann.,
Da gab es zwar einen alternativen redboot aber der ging bei mir auch nicht richtig.
Das beste wäre ja auf u-boot umzusteigen, aber der Aufriss den redboot zu ersetzen ist sehr hoch, leider.
Ich wollte damit nur sagen das die sich auch in Bezug auf nfs kernel usw. ausgelassen hatten.
peter
Hallo,
wieder mal ein kleines Update:
Kernel auf 2.6.35.4
Dahadi auf 2.4
Komprimierung des Kernels auf lzma geändert damit sind wir nun auf 750kBytes und haben wieder 250kBytes Luft
peter
wieder mal ein kleines Update:
Kernel auf 2.6.35.4
Dahadi auf 2.4
Komprimierung des Kernels auf lzma geändert damit sind wir nun auf 750kBytes und haben wieder 250kBytes Luft
peter
Hallo zusammen
Ist der Zusatz "kein Analog" für die Openhorst Firmware eigentlich noch immer gültig
Merci und Gruss
Mario
Ist der Zusatz "kein Analog" für die Openhorst Firmware eigentlich noch immer gültig
Merci und Gruss
Mario
Leider ja, keiner hatte bisher Zeit sich diesem Thema komplett anzunehmen.
Die Treiber sind da, nur muss das ganze getestet und integriert werden.
peter
Die Treiber sind da, nur muss das ganze getestet und integriert werden.
peter
Dr.InfernO
Neuer User
- Mitglied seit
- 7 Jan 2006
- Beiträge
- 67
- Punkte für Reaktionen
- 0
- Punkte
- 0
Wenn noch jemand Zeit hätte aserisk auf die SD zu Portieren, wäre es klasse!
Nein, im ernst mit eurem Open horst projekt könnte doch die Pro box doch eine Alternative zur fritzbox werden!
Schade das es keine Versuche für die SD gegeben hat oder diese nicht umsetzbar sind/waren.
Nein, im ernst mit eurem Open horst projekt könnte doch die Pro box doch eine Alternative zur fritzbox werden!
Schade das es keine Versuche für die SD gegeben hat oder diese nicht umsetzbar sind/waren.
Hallo zusammen,
ich habe mal die (v)zaphfc Treiber auf dahdi 2.4.0 angepasst (zaphfc to be reviewed...) und die patches von Michael.de eingebaut.
@potc
Mir ist gerade aufgefallen dass ich aus patch.dahdi-2.4.0 das Bauen von dahdi_dummy "rausgemerged" hatte, werde das heute abend fixen (komme im Moment nicht an die Sourcen), sorry.
Hattest Du mal versucht das auf die "interne" Timing source (ich nehme an dahdi_dummy wird nur dafuer gebraucht) in neueren Asterisk umzustellen? Ich hatte das bei mir schon vor einiger Zeit gemacht. Dann kann das Modul ganz weg und dahdi wird fuer den standard build ueberhaupt nicht mehr gebraucht. Oder waren das die Probleme mit meetme die Du angesprochen hattest? Ich benutze meetme nicht und der interne Timer scheint mit dem zaphfc Zeug genauso gut (bzw. schlecht) zu funktionieren wie mit dahdi_dummy.
@Michael.de:
Danke fuer die ganzen patches, hab erst wenig Zeit gehabt die zu probieren, und beim Laden von ixp4xx_tdm.ko einen Absturz... reiche die genaue Fehlermeldung noch nach. Hab sie aber mal (s.o.) in die SVN-sourcen eingebaut.
Gruss,
H.
ich habe mal die (v)zaphfc Treiber auf dahdi 2.4.0 angepasst (zaphfc to be reviewed...) und die patches von Michael.de eingebaut.
@potc
Mir ist gerade aufgefallen dass ich aus patch.dahdi-2.4.0 das Bauen von dahdi_dummy "rausgemerged" hatte, werde das heute abend fixen (komme im Moment nicht an die Sourcen), sorry.
Hattest Du mal versucht das auf die "interne" Timing source (ich nehme an dahdi_dummy wird nur dafuer gebraucht) in neueren Asterisk umzustellen? Ich hatte das bei mir schon vor einiger Zeit gemacht. Dann kann das Modul ganz weg und dahdi wird fuer den standard build ueberhaupt nicht mehr gebraucht. Oder waren das die Probleme mit meetme die Du angesprochen hattest? Ich benutze meetme nicht und der interne Timer scheint mit dem zaphfc Zeug genauso gut (bzw. schlecht) zu funktionieren wie mit dahdi_dummy.
@Michael.de:
Danke fuer die ganzen patches, hab erst wenig Zeit gehabt die zu probieren, und beim Laden von ixp4xx_tdm.ko einen Absturz... reiche die genaue Fehlermeldung noch nach. Hab sie aber mal (s.o.) in die SVN-sourcen eingebaut.
Gruss,
H.
@horatio42:
Ich habe zaphfc, ixp425_spi, si3050 und si3210 auf dahdi-4.0 portiert. Leider hatte ich noch keine Zeit um das zu Testen. Den Code wollte ich erst posten wenn das Erfolgreich war. Wird wohl noch ein paar Tage dauern.
Der Absturz von ixp4xx_tdm.ko ist wohl meine Schuld. Im Code für die Platform-Enumeration (arch/arm/mach-ixp4xx/coyote-setup.c) muß es richtig heisen:
Das zweite HSS-Device kann entfallen, da das TDM-Modul sowieso nur Strukturen für einen HSS-Port anlegt. Da am HSS-Port2 nur der DSP hängt und ich den Code für DSP-Support nicht anpassen wollte, habe ich auch gleich den kompletten DSP-Code entfernt.
Wenn ich das noch richtig in Erinnerung habe, benötige ich wohl noch einen Patch für Asterisk, wenn dahdi mit bri_dchan gepatcht wurde. Weist Du da Näheres?
Gruß Michael
Ich habe zaphfc, ixp425_spi, si3050 und si3210 auf dahdi-4.0 portiert. Leider hatte ich noch keine Zeit um das zu Testen. Den Code wollte ich erst posten wenn das Erfolgreich war. Wird wohl noch ein paar Tage dauern.
Der Absturz von ixp4xx_tdm.ko ist wohl meine Schuld. Im Code für die Platform-Enumeration (arch/arm/mach-ixp4xx/coyote-setup.c) muß es richtig heisen:
Code:
static struct platform_device ixdp425_tdm[] = {
{
.name = "ixp4xx_tdm",
.id = 0,
.dev.platform_data = NULL,
}
};
static struct platform_device *coyote_devices[] __initdata = {
&coyote_flash,
&coyote_uart,
&ixdp425_eth[0],
&ixdp425_eth[1],
&ixdp425_tdm[0],
};Wenn ich das noch richtig in Erinnerung habe, benötige ich wohl noch einen Patch für Asterisk, wenn dahdi mit bri_dchan gepatcht wurde. Weist Du da Näheres?
Gruß Michael
Hallo Michael.de,
danke fuer das patch, werde es am Wochenende ausprobieren. Klingt als hättest Du ne Menge Arbeit in die Horstbox-Telefonie gesteckt, da bin ich ja mal gespannt
Deine Frage kann ich leider auch nicht sicher beantworten, ich blicke bei dem ganzen Wust aus asterisk/dahdi/libpri/zaphfc/ -Versionen samt patches auch kaum noch durch, hier nur was ich bisher gesehen habe:
- Die neueste zaphfc-Version (ohne "v") die ich probiert hatte, besaß die patches auf dahdi und zaphfc Seite noch (dessen patches für dahdi hab ich auch in das SVN eingecheckt). Das ganze funktionierte recht instabil auf meinem Ubuntu-Referenzsystem. Aber es funktionierte. Der span ging up. Der Asterisk war komplett ungepatcht, plain vanilla von asterisk.org.
- vzaphfc benoetigt die Patches NICHT mehr um auf meiner Ubuntu-Kiste perfekt zu funktionieren (sie schaden aber auch nicht, d.h. ein für zaphfc gepatchtes dahdi funktioniert auch mit vzaphfc). Das einzige was ich hier noch aus dem Patchset von obiger zaphfc-version übernommen hatte war der oslec echo canceller (ebenfalls eingecheckt). Soweit ich weiss nutzt vzaphfc standardmäßig "hardware assisted" signalling auf dem d-channel, es ist jedenfalls zwingend erforderlich in der dahdi system.conf die option "hardhdlc" statt "dchan" fuer den d-channel zu setzen damit es funktioniert.
Soweit ich der Diskussion in diesem Thread folgen konnte, scheint es in libpri wohl einige Anpassungen bzgl. BRI-support gegeben zu haben. Ob und in wie weit die manuelles Patchen überflüssig machen weiß ich aber nicht. Ich hab das wie gesagt mehr "empirisch ermittelt"
UPDATE: ich hab nochmal ein bisschen gebuddelt, und es scheint in der Tat so zu sein dass die Änderungen die die bristuff -Patches an chan_dahdi gamacht haben inzwischen im asterisk upstream integriert sind. Ein Patch sollte also (hoffentlich) nicht nötig sein.
Gruß,
H.
danke fuer das patch, werde es am Wochenende ausprobieren. Klingt als hättest Du ne Menge Arbeit in die Horstbox-Telefonie gesteckt, da bin ich ja mal gespannt
Deine Frage kann ich leider auch nicht sicher beantworten, ich blicke bei dem ganzen Wust aus asterisk/dahdi/libpri/zaphfc/ -Versionen samt patches auch kaum noch durch, hier nur was ich bisher gesehen habe:
- Die neueste zaphfc-Version (ohne "v") die ich probiert hatte, besaß die patches auf dahdi und zaphfc Seite noch (dessen patches für dahdi hab ich auch in das SVN eingecheckt). Das ganze funktionierte recht instabil auf meinem Ubuntu-Referenzsystem. Aber es funktionierte. Der span ging up. Der Asterisk war komplett ungepatcht, plain vanilla von asterisk.org.
- vzaphfc benoetigt die Patches NICHT mehr um auf meiner Ubuntu-Kiste perfekt zu funktionieren (sie schaden aber auch nicht, d.h. ein für zaphfc gepatchtes dahdi funktioniert auch mit vzaphfc). Das einzige was ich hier noch aus dem Patchset von obiger zaphfc-version übernommen hatte war der oslec echo canceller (ebenfalls eingecheckt). Soweit ich weiss nutzt vzaphfc standardmäßig "hardware assisted" signalling auf dem d-channel, es ist jedenfalls zwingend erforderlich in der dahdi system.conf die option "hardhdlc" statt "dchan" fuer den d-channel zu setzen damit es funktioniert.
Soweit ich der Diskussion in diesem Thread folgen konnte, scheint es in libpri wohl einige Anpassungen bzgl. BRI-support gegeben zu haben. Ob und in wie weit die manuelles Patchen überflüssig machen weiß ich aber nicht. Ich hab das wie gesagt mehr "empirisch ermittelt"
UPDATE: ich hab nochmal ein bisschen gebuddelt, und es scheint in der Tat so zu sein dass die Änderungen die die bristuff -Patches an chan_dahdi gamacht haben inzwischen im asterisk upstream integriert sind. Ein Patch sollte also (hoffentlich) nicht nötig sein.
Gruß,
H.
Zuletzt bearbeitet:
@horatios42
Jupp, das meetme brauch das dahdi_dummy.
Evtl. mal das meetme umbauen, ist aber nicht prio
Jupp, das meetme brauch das dahdi_dummy.
Evtl. mal das meetme umbauen, ist aber nicht prio
So,
habe mal an dem ganzen ein bisschen gearbeitet, alle Pakete auf Stand gebracht und den Build auf Opensuse 11.2/11.3 und Ubuntu 10.4 LTS einmal komplett durchlaufen lassen.
Das Ubuntu war recht nackig und benötigte folgende Pakete extra:
bison,flex,texinfo,subversion,unzip,automake,libtool,openjdk-6-jdk,libsox-fmt-mp3
Ich denke mir wenn man das alles installiert mit apt-get sollte es gehen.
Das spandsp Problem war schon recht nervig und dann einfach nur die Option m beim tar schuld daran. Damit wurde die Zeit modifiziert und er meinte unter ubuntu alles neu machen zu müssen, SuSE ist das egal gewesen.
Kann sein das der Merge mit Horatio seinen sachen evtl. kleinere Probleme erzeugt aber ich denke mir das sollte kein Problem sein.
peter
habe mal an dem ganzen ein bisschen gearbeitet, alle Pakete auf Stand gebracht und den Build auf Opensuse 11.2/11.3 und Ubuntu 10.4 LTS einmal komplett durchlaufen lassen.
Das Ubuntu war recht nackig und benötigte folgende Pakete extra:
bison,flex,texinfo,subversion,unzip,automake,libtool,openjdk-6-jdk,libsox-fmt-mp3
Ich denke mir wenn man das alles installiert mit apt-get sollte es gehen.
Das spandsp Problem war schon recht nervig und dann einfach nur die Option m beim tar schuld daran. Damit wurde die Zeit modifiziert und er meinte unter ubuntu alles neu machen zu müssen, SuSE ist das egal gewesen.
Kann sein das der Merge mit Horatio seinen sachen evtl. kleinere Probleme erzeugt aber ich denke mir das sollte kein Problem sein.
peter
@Michael.de:
ich hatte den patch angepasst (ist auch schon im SVN) aber nach wie vor nen segfault wenn ich dahdi_cfg ausführe. Ich werde mal versuchen etwas weiter zu bohren wo der herkommt, ansonsten poste ich die Fehlermeldung noch.
@potc:
ich hatte gesehen dass Du chanlcr aus Deinem build rausgeworfen hattest weil es Probleme machte... ich hab daraufhin mal meine patches eingecheckt die bei mir problemlos bauen. Vielleicht koennen die Leute die am NT-Mode Interesse haben das mal damit testen... bei mir funktioniert lcr 1.7 zumindest deutlich besser als die Vorgaengerversion, ich nutze aber nur TE.
Gruss,
H.
ich hatte den patch angepasst (ist auch schon im SVN) aber nach wie vor nen segfault wenn ich dahdi_cfg ausführe. Ich werde mal versuchen etwas weiter zu bohren wo der herkommt, ansonsten poste ich die Fehlermeldung noch.
@potc:
ich hatte gesehen dass Du chanlcr aus Deinem build rausgeworfen hattest weil es Probleme machte... ich hab daraufhin mal meine patches eingecheckt die bei mir problemlos bauen. Vielleicht koennen die Leute die am NT-Mode Interesse haben das mal damit testen... bei mir funktioniert lcr 1.7 zumindest deutlich besser als die Vorgaengerversion, ich nutze aber nur TE.
Gruss,
H.
Neueste Beiträge
-
[Frage] Smarthome im Mesh > 100 Geräte
- Letzte: Netzonline
-
[Problem] F!B 6591 Bootloop
- Letzte: porcupine
-
Installation Freetz / Freetz-NG
- Letzte: blackstar
-
Empfehlung Switch für Entertain TV & Sonos
- Letzte: BeeHaa
-
FRITZ!Box 7590 AX / FRITZ!OS 7.80 vom 30.01.2024- Letzte: Exodus88
-
Telekom FTTH-"Ausbau" bei bestehender FTTH-Anbindung
- Letzte: Lurtz
-
Wlan Mesh Problem- Letzte: frank_m24
