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

[cstux]

Evtl fehlt dir ein Pakete. Hier die benötigten Pakete für Debian/Ubuntu:

http://gforge.willwebhosting.de/gf/project/horstbox/wiki/?pagename=Horstbox+Build+Dependencies

 

[horatio42]

Hallo potc,
ich habe diesen Thread mit grossem Interesse verfolgt und Eure Firmware bauen können und auch erfolgreich eingesetzt , vielen Dank für Eure ganz Mühe!
Allerdings habe ich dann selbst angefangen den Kernel "auszubauen" und dabei anscheinend Horst gehimmelt... Es gehen beim Einschalten sämtliche LEDs auf "dauer-an". Habe daraufhin eine serielle Konsole angeschlossen, auf der passiert aber auch so rein gar nix (kann auch sein dass ich sie falsch angeklemmt habe, hab die erst probiert nachdem Horst sich nicht mehr muckte...) ssh login ist nicht mehr möglich, auf ping reagiert er aber noch. Irgendwelche Ideen? Bin für jede Hilfe dankbar.

Vielen Dank,
H.

 

[Michael.de]

Ich würde erstmal Herta von Horst trennen und dann ping wiederholen. Bekommst du immer noch antwort, kannst du sicher sein das diese von Horst und nicht von Herta kommt.
Kommt die Antwort von Horst hast du beim seriellen Anschluss etwas falsch gemacht, denn wenn Horst auf pings antwortet bootet er auch und ist noch nicht im Himmel angekommen .
Dazu müsstest du aber ein LAN-Kabel durchscheiden und an die Stiftleiste von Horst anschliesen. siehe http://www.ip-phone-forum.de/showthread.php?t=192974

Gruß Michael

 

[horatio42]

Hi Michael,
danke für Deine Antwort, auf die Idee dass natürlich Herta auf die pings antwortet hätte ich auch selber kommen können ...
Ich überprüfe gerade meine "verbliebenen Optionen", die Scheidung von Herta und Horst sehe ich da eher als eine letzte Möglichkeit wenn die Familienberatung über die Serial Console zu nix führt ;-)
Hierzu ein paar Fragen:
- Ich komme aus der OpenWRT-Ecke und habe bisher mit einem Asus500gP rumgespielt. Der war recht tolerant was flashen von schwachsinniger Firmware anging; es lief zumindest immer noch ein Bootloader (CFE) der über TFTP ein neues Image einflashen konnte. Wenn ich mir hier die dumps der serial console ansehe, *scheint* da nix entsprechendes zu laufen (weder in der Stock Firmware noch in diesem Mod)? Also einmal mist nach mtd/2 geflasht und das war's?
- Was soll das 12-sekündige-Drücken der Reset-Taste bewirken ("Rücksetzen auf Werkseinstellungen")? Werden da nur die Variablen im nvram gelöcht, oder läuft da auch so eine Art Notfallmodus über den man in die Kiste reinkäme?
- Bzgl. der seriellen Konsole: wie gesagt da tut sich gar nix. Ab *wann* sollte man da was zu sehen bekommen, sobald der Kernel die serielle konsole oben hat? Beim erwähnten Asus produziert auch schon der Bootloader output auf der seriellen Konsole, also lange vorm Kernel.
- Die LEDs sind wie gesagt dauer an. Wann sollten die ausgehen, wenn der Kernel gebootet ist und init läuft? Könnte man daraus irgend etwas ablesen (so eine Art POST für Horst)?

Sorry für mein Fragenbomardement, ich bin halt etwas aufgewühlt durch die Tatsache das Horst von mir gegangen ist. Herta scheint es jedenfalls gut zu verkraften, nach einiger Zeit aktiviert sie sogar ihr WLAN... was mich etwas wundert, sollte sie die Konfiguration dafür nicht von Horst bekommen? Oder speichert sie die Werte dafür in ihrem eigenen nvram?

Danke für die Hilfe,
H.

 

[horatio42]

Hallo zusammen,

kurz vor Horstens Ableben habe ich noch etwas mit der isdn-konfiguration von Horst experimentiert. Dabei ist mir ein Problem im aktuellen build aufgefallen:
asterisk läuft unter einem gleichnamigen user, der von seinem init-skript gestartete lcr aber als root. Dadurch kann chan_lcr in asterisk sich nicht an den von lcr erstellten socket connecten (/var/run/LCR.socket) da dessen Rechte nur user-Zugriff erlauben. Ich habe mir mit einem 'chown asterisk:nvram /var/run/LCR.socket' ganz am Ende der 'start' option im lcr-init-skript beholfen, danach ging es.

H.

 

[kombjuder]

Habe daraufhin eine serielle Konsole angeschlossen, auf der passiert aber auch so rein gar nix (kann auch sein dass ich sie falsch angeklemmt habe, hab die erst probiert nachdem Horst sich nicht mehr muckte...)

In einem der Texte von Foschi zur Horstbox ist die Belegung beschrieben.

 

[kombjuder]

Hallo,

ich habe gerade mal mit Asterisk 1.6.0.15 kompiliert. Nach Anpassung der relevanten Files an die neue Asterisk-Version lief der Kompiliervorgang problemlos. Allerdings bricht er bei mir beim Erstellen der Files für Horst ab.
Das Main-Fs ist zu groß.
Bleibt also nur einiges auslagern, evtl. die Sprachbausteine.

 

[kombjuder]

asterisk läuft unter einem gleichnamigen user, der von seinem init-skript gestartete lcr aber als root.

Kann ich bestätigen, obwohl in /mnt/asterisk/chanlcr/options.conf der Parameter socketrights 0777 gesetzt ist.

 

[potc]

Kann es sein, dass bei Dir das Ganze läuft, _weil_ Du durch frühere/ältere build runs die .po's vorliegen hast. Einige der andere notwendigne po werden bei mir ja auch erstellt. Nur halt nicht die in der error message angemahnten. :-(

Da muss ich dich enttäuschen.
Bevor ich irgendwelche Dinge ins SVN stelle lösche ich alles so das das System sich komplett neu bauen muss, inklusive aller Downloads.

Mach doch mal bitte nur ein make chanlcr_clean
und danach ein make chanlcr_build poste mal die ausgaben.

peter

 

[Michael.de]

Hallo horatio42,

ich glaube dein Post ist hier of Topic, du solltest einen neuen Thread aufmachen bzw. einen Moderator bitten diesen Teil zu verschieben!

Nun zu deinen Fragen:

...der über TFTP ein neues Image einflashen konnte

Der Bootloader von Horst heist redboot und kann in der Version von DLink kein TFTP. Es gibt aber eine geänderte Version von hehol welche ein rootfs über TFTP laden kann siehe hier: http://www.ip-phone-forum.de/showpost.php?p=846071&postcount=11
Um diese Version zu flashen brauchst du aber erstmal die serielle Konsole!

... oder läuft da auch so eine Art Notfallmodus über den man in die Kiste reinkäme

Beim reseten gibt es keinen speziellen Notfallmodus, du musst redboot verwenden sofern du nicht mehr anderweitig Zugriff hast (ssh). Um ein rootfs unter redboot aufzuspielen siehe: http://www.ip-phone-forum.de/showpost.php?p=786522&postcount=20

Ab *wann* sollte man da was zu sehen bekommen...

Die serielle schnittstelle wird schon vom Bootloader aufgemacht, um also herauszufinden ob dein Horst noch lebt ist die serielle Schnittstelle die erste Wahl. Hier ein Tip wie du deine serielle Verbindung teilweise testen kannst: Am Horst ist Pin3 RxD, Pin5 TxD und Pin9 GND. Zwischen GND und TxD (Horst) müssen -3 bis -15V anliegen. Nach Anschluss des Nullmodemkabel müssen diese -3 bis -15V also zwischen Pin2 und Pin5 (GND) der Buchse am Ende des Nullmodemkabels messbar sein. Belegung Buchse siehe: http://de.wikipedia.org/wiki/EIA-232

...so eine Art POST für Horst

Die Leds werden zu Beginn des Init-Prozesses aber nach dem Starten des Kernels vom Init-Script /etc/init.d/dirs angeschalten und nach erfolgreichen Booten vom Script /etc/init.d/ready wieder abgeschaltet. Es kann aber auch unabhängig dabvon sein, das der Grundzustand der GPIOs nach dem Anlegen der Betriebsspannung die LEDs leuchten lässt. Ein POST ala BIOS wird nicht unterstützt.

sollte sie die Konfiguration dafür nicht von Horst bekommen?

Herta speichert seine eigene Konfiguration, und wird von Horst nur bei Änderungen dazu veranlasst die Konfiguration anzupassen.

Gruß Michael

 

[horatio42]

Hi Michael.de,

1000 Dank für die ganzen Infos werde mich da mal durchwühlen...! Wie ich mir schon dachte ist die serielle Konsole wohl der Knackpunkt bei der ganzen Geschichte. Werde mal die (etwas widersprüchlichen?) Vorschläge aus dem entsprechenden Thread durchgehen.
Bzgl. OT: war mir nicht sicher ob ich hier "richtig" bin mit meinem Problem, da ich nicht überschauen konnte ob an dieser modifizierten Firmware eventuell auch Änderungen am Bootloader/Notfallmodus gemacht worden sind. In der Tat scheint es aber nun nicht so zu sein.

Vielen Dank jedenfalls für die Hilfe,
H.

 

[kombjuder]

cp: reguläre Datei „../build_env/image/rootfs/www/cgi-bin/.svn/format“ kann nicht angelegt werden: Permission denied
[/CODE]

Nachdem ich heute das ganze auf einen neu installierten Ubuntu aufgesetzt hatte, ist der Fehler bei mir auch aufgetreten.

Ursache ist, dass die selben drei Dateien einmal aus herta-dlink-webif und einmal aus horstbox-webif kopiert werden, das erste mal als ro. Damit ist im zweiten Durchgang ein Überschreiben nicht möglich. Nachdem ich die Dateien auf rw gesetzt hatte ging es.

Der Fehler ist unter debian nicht aufgetreten.

 

[horatio42]

Ok, Horst ist wieder flott, danke für die Hilfestellungen!
Mir ist aufgefallen dass der EHCI-Treiber keine USB 2.0 Geräte erkennen will, es kommen immer Fehlermeldungen vom Kaliber device descriptor read/64, error 18 oder auch device descriptor read/8, error -61, schlussendlich dann ein unable to enumerate USB device on port 1 und ein fallback auf den OHCI-Treiber. Habe diverse Hardware durchprobiert (HUBs, USB-Sticks) immer mit demselben (obigen) Resultat... ist es bisher jemandem gelungen dass USB 2.0 - Hardware den EHCI-Treiber nutzt? Auch unter OHCI laufen die USB-Sticks äusserst instabil; überträgt man grössere Mengen daten (z.B. über samba oder scp), stellen sich nach einiger Zeit IO-errors ein und derstick wird read-only remounted... einen Defekt der Sticks kann ich aber ausschliessen.

 

[pnxs]

Hi!

Ich möchte in der neuen SW gerne den Analoganschluss und Int/Ext S0 nutzen. Ich hab mir die Quellen über SVN geholt und durchkompiliert. Im Si3210 sehe ich Umstellungen auf DAHDI aber zum kompilieren fehlt dem Modul die Intel Access Library. Im Source-5 von Dlink ist die IAL 2.3 drin. Hat es einen Grund, das die Library fehlt? In config.mk wird INTEL_SRC auf $(PWD)/linux-2.6.30.3/drivers/ixp400/ixp400_xscale_sw/ gesetzt. Im Kernel existiert diese Pfad bei mir aber nicht.
Wenn ich ein bisschen Background zu den geplanten Umstellungen bekommen könnte, kann ich evtl. Si3210 und Zaphfc anpassen.

Viele Grüße,
pnxs

 

[potc]

@pnxs
Das Thema wurde zwar schon mal behandelt aber gut.
Die IntelLib unterstützt nur einen Kernel bis 2.14, mit etwas gewürge geht 2.16 für die IXP425 Plattform.
Leider war das ganze sehr instabil.

Da wir das HB ohne analog benötigen haben wir alles renoviert und auf aktuellen Stand gebracht, as den Vorteil hat das wir die aktuellsten Kernel Patches verwenden konnten und die Plattform damit Out of the Box mit aktuellem Kernel funktioniert.

Der analog Treiber benötigt das dsp und hss device zur Konvertierung, dieses ist aber noch nicht komplett implementiert und hat eine andere api als unter der Intel Lib.

Der aktuelle Hauptentwickler für die ixp Plattformen hat zwar auch schon was in der Pipeline, dieses ist aber noch nicht im Standard Kernel und der zaphfc müsste dann auch immer noch angepasst werden.

Das mit dem INTEL_SRC hat nichts zu besagen, ist nur rein historisch drin, werde es noch bereinigen

peter

 

[thirsch]

Da muss ich dich enttäuschen.
Bevor ich irgendwelche Dinge ins SVN stelle lösche ich alles so das das System sich komplett neu bauen muss, inklusive aller Downloads.

Mach doch mal bitte nur ein make chanlcr_clean
und danach ein make chanlcr_build poste mal die ausgaben.

peter

Hallo Peter,
danke für die Rückmeldung.
Und sorry - wollte Dir da natürlich kein 'unsauberes' Arbeiten unterstellen.
Der Fehler liegt/lag - natürlich - bei mir bzw. an fehlenden dependencies.
Ich musste das Ganze natürlich unter meinem CentOS 5.3 versuchen, und hier sind die dependencies natürlich 'anders' zu installieren/zu beschaffen.
bin auch - bis auf die mtd-utils - dann ganz gut vorangekommen.
Ein schneller Gegentest mit einem Ubuntu ging dann problemlos im ersten Durchlauf!
Werde in Zukunft für die HB-builds also brav ein Ubuntu einsetzen....
Nochmals vielen Dank für deine bisherige Arbeit und die Unterstützung.

Gruß
Thomas

 

[horatio42]

Hallo, ich habe inzwischen selbst festgestellt warum USB 2.0 nicht geht. In den Original-Patches (FW 5.0) für kernel-2.6 gibt es einen patch für ehci-pci.c, den ihr anscheinend nicht in Euer patchfile (archive/patch.kernel-2.6) übernommen habt. Zieht man das patch nach, funktioniert ehci wieder.
Gab es einen Grund weswegen Ihr dieses patch rausgeschmissen hattet?

 

[potc]

@horatio24
Es gibt keine speziellen Grund.
Wir haben alles weggeworfen und auf den reinen Standard gesetzt.
Da kann dann schon mal was auf der Strecke belieben gerade da wir USB erst viel später wieder benötigten.
Werde mal nächste Woche den patch testen.

Am einfachsten wäre du stellst den patch hier noch mal rein.
Am besten auf den aktuellen Kernel angepasst

Danke

peter

 

[horatio42]

Kernel Patch für USB 2.0 EHCI

Hallo Peter,
na dann bin ich ja beruhigt Ich hatte schon befürchtet Ihr hättet den Patch rausgeschmissen weil er Probleme mit anderer Hardware macht (irgendwo hatte ich mal einen Beitrag gelesen dass sich usb und die isdn-chips in die quere kommen könnten...)
Ok, hier der patch:

diff -Burw linux-2.6.30.5_org/drivers/usb/host/ehci-pci.c linux-2.6.30.5/drivers/usb/host/ehci-pci.c
--- linux-2.6.30.5_org/drivers/usb/host/ehci-pci.c      2009-08-16 23:19:38.000000000 +0200
+++ linux-2.6.30.5/drivers/usb/host/ehci-pci.c  2009-09-20 09:52:39.000000000 +0200
@@ -71,6 +71,12 @@
        u32                     temp;
        int                     retval;

+#ifdef CONFIG_MACH_HORSTBOX
+       /* @HM: modification for our "stupid" usb device here */
+       ehci_info(ehci, "controller configured manually\n");
+       pci_write_config_dword(pdev, 0xe0, 0x6cb03385);
+#endif
+
        switch (pdev->vendor) {
        case PCI_VENDOR_ID_TOSHIBA_2:
                /* celleb's companion chip */

Ich habe den geänderten Code mal "original" aus der FW 5.0 übernommen (inkl. Kommentar) und auf den aktuellen Source von ehci-pci.c appliziert. Sieht nach einer zusätzlichen Initialisierung eines PCI-Config-Registers aus, ohne den der ehci-Treiber wohl nicht funktioniert. Vielleicht gibt's dafür aber auch ne elegantere Lösung.

 

[potc]

Hallo horatio24,
habe deinen patch eingecheckt und konnte keine negativen Auswirkungen in unserem Szenario feststellen.
Durch den patch wurde die Stabilität des usb handling erheblich verbessert. Ohne den patch hatte mein Transfertest auf einen usbstick nur Fehler produziert mit dem patch ging es einwandfrei.

evtl. fixed das auch komjuder sein umts Problem

danke

peter