Vorstellung Homerserver auf Banana Pi Basis

Begonnen von cerberus, 14 November 2014, 09:31:26

Vorheriges Thema - Nächstes Thema

kaihs

Zitat von: cerberus am 14 November 2014, 09:31:26
1x Batterie CR2032 für die Echtzeituhr

Kannst du dazu noch was sagen?

An welchen der beiden Batterieanschlüsse muss die Knopfzelle, an BAT oder BAT1?

Muss dann noch softwareseitag was konfiguriert/installiert werden oder läuft das out of the box?

Kai
Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

Curzon

Zitat von: dampf123 am 11 März 2015, 19:56:14
ich habe in der script.bin nur

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>


uart_used = 0   auf 1 geändert, das was hier auch schon vorne so beschrieben was ....


Das hatte ich auch gemacht und bei mir lief es zuerst damit alleine auch nicht.

Da ich mein busware COC, das bisher klaglos auf einem Raspberry Pi B (ohne +) lief, inzwischen auf einem Banana Pi zum laufen gebracht habe und meine Änderungen auch nachvollziehen kann, hier meine Erfahrungen.

Vorab zwei Hinweise:

1. Zum schnellen Test des COC, ohne fhem zu starten, kann man screen benutzen:

screen /dev/ttyS2 38400

und danach mal die Taste V mit Enter eingeben, sollte die Version der COC Firmware auswerfen. screen selbst kann man mit Strg-A k beenden.

2. Das COC wird bei mir wie auf dem Raspberry Pi immer erst zurückgesetzt. An welcher Stelle und wann man das macht, ist egal - es muss nur vor der Benutzung aktiviert werden. Man kann den folgenden Code in /etc/rc.local schreiben oder auch ins fhem Startskript /etc/init.d/fhem einfügen oder als separates Script speichern und ausführen.

Beispiel:

sudo nano /usr/local/bin/coc_reset.sh

Dann den Reset Code eingeben

echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1


und speichern. Zum Schluss die Datei noch ausführbar machen mit

sudo chmod +x /usr/local/bin/coc_reset.sh

und schon kann man jederzeit das COC mit Hilfe von /usr/local/bin/coc_reset.sh aktivieren.




Ich hatte erst mal verschiedene Images ausprobiert und folgendes festgestellt:

  • Mit dem Lemaker Raspian for BananaPi v1412 lief das COC sofort ohne Änderungen auf ttyS2. Dort fehlt aber der mir wichtige lirc raw Treiber sunxi_lirc, der dort vorhandene sunxi_ir läuft nur mit Fernbedienungen mit NEC Code.
  • Beim Debian Wheezy Image 3.4.106 von Igor Pečovnik ist der lirc raw Treiber sunxi_lirc dabei, dafür funktionierte wie bei einigen Postern hier der COC nicht.
    Und genau hier habe ich mit meinen Änderungen angesetzt.

Ich habe die GPIO Konfigurationsdateien beider Systeme verglichen und da es kaum Unterschiede gab, die einzelnen Änderungen vom Lemaker Raspian Image in das Image von Igor nach und nach übernommen.
Beim Lemaker Image stecken die Infos in /boot/script.bin, beim Igor Image in /boot/bananapi.bin. Die Konfigurationsdateien müssen zuerst mit hilfe von bin2fex in ein lese- und editierbares Fex Format gewandelt werden, bei Igors Image heisst die Datei /boot/bananapi.bin

sudo bin2fex /boot/bananapi.bin /boot/bananapi.fex

Mir sind beim Image Igor Pečovnik zwei Dinge aufgefallen, ein Fehler und eine Besonderheit:


  • Besonderheit:
    Wenn man uarts mit uart_used = 1 aktiviert, kann es sein dass der Port nicht mit dem in der Konfigurations unter uart_port angegebenen Nummer übereinstimmt. Man testet danach einfach hoffnungslos ständig auf dem falschen Port.
    Das passiert dann, wenn man Lücken erzeugt, d.h. z.B. man aktiviert Port 0 (ttyS0), aber nicht Port 1 (was ja ttyS1 sein soll) oder 2 (ttyS2) und aktiviert dann aber wie von dampf123 geschrieben Port 3 (was ttyS3 sein sollte). Das System erstellt aber trotz der Angabe uart_port = 3 in unserem Bespiuel hier nur ttyS0  und ttyS1. Die Konfiguration von dampf123 wäre in diesem Fall (uart_used für [uart_para1] und [uart_para2] wären 0) so, dass ttyS0 die interne UART0 Schnittstelle ist und ttyS1 der COC
  • Fehler in der Konfiguration:
    Auch mit der Kenntnis aus 1. konnte ich das COC bei mir immer noch nicht ansprechen! Da das COC für die serielle Kommunikation lediglich den Reset über gpio17 und gpio18 braucht (die gelbe LED blinkt dann im Sekundentakt) und dazu vier Banana Pi Ports benutzt, nämlich PH00 für TX, PH01 für RX, PI19 als gpio17 und PA02 als gpio18, musste der Fehler in der Konfiguration für PH00 oder PH01 zu suchen sein.




Ich habe also den Port für den COC aktiviert und den Fehler in der Konfigurationsdatei beseitigt. Hier meine Vorgehensweise:

1. Das Debian Wheezy Image 3.4.106 von Igor Pečovnik runterladen und auf eine SD-Karte installieren.

2. Nach dem booten auf dem BananaP Pi einloggen.

3. Die Konfigurationsdatei umwandeln

sudo bin2fex /boot/bananapi.bin /boot/bananapi.fex

4. Mit sudo nano /boot/bananapi.fex die Konfiguration bearbeiten.

Hier meine i2C-Bus und uart Konfiguration:

[twi0_para]
twi0_used = 1
twi0_scl = port:PB00<2><default><default><default>
twi0_sda = port:PB01<2><default><default><default>

[twi1_para]
twi1_used = 1
twi1_scl = port:PB18<2><default><default><default>
twi1_sda = port:PB19<2><default><default><default>

[twi2_para]
twi2_used = 1
twi2_scl = port:PB20<2><default><default><default>
twi2_sda = port:PB21<2><default><default><default>

[twi3_para]
twi3_used = 1
twi3_scl = port:PI00<3><default><default><default>
twi3_sda = port:PI01<3><default><default><default>

[uart_para0]
uart_used = 1
uart_port = 0
uart_type = 2
uart_tx = port:PB22<2><1><default><default>
uart_rx = port:PB23<2><1><default><default>

[uart_para1]
uart_used = 0
uart_port = 1
uart_type = 8
uart_tx = port:PA10<4><1><default><default>
uart_rx = port:PA11<4><1><default><default>
uart_rts = port:PA12<4><1><default><default>
uart_cts = port:PA13<4><1><default><default>
uart_dtr = port:PA14<4><1><default><default>
uart_dsr = port:PA15<4><1><default><default>
uart_dcd = port:PA16<4><1><default><default>
uart_ring = port:PA17<4><1><default><default>

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

[uart_para4]
uart_used = 0
uart_port = 4
uart_type = 2
uart_tx = port:PH04<4><1><default><default>
uart_rx = port:PH05<4><1><default><default>

[uart_para5]
uart_used = 0
uart_port = 5
uart_type = 2
uart_tx = port:PH06<4><1><default><default>
uart_rx = port:PH07<4><1><default><default>

[uart_para6]
uart_used = 0
uart_port = 6
uart_type = 2
uart_tx = port:PA12<4><1><default><default>
uart_rx = port:PA13<4><1><default><default>

[uart_para7]
uart_used = 1
uart_port = 7
uart_type = 2
uart_tx = port:PI20<3><1><default><default>
uart_rx = port:PI21<3><1><default><default>


Zusätzlich die Konfiguration für usbc0 mit folgendem ersetzen:

[usbc0]
usb_used = 1
usb_port_type = 2
usb_detect_type = 1
usb_id_gpio = port:PH04<0><1><default><default>
usb_det_vbus_gpio = port:PH05<0><0><default><default>
usb_drv_vbus_gpio = port:PB09<1><0><default><0>
usb_restrict_gpio = port:PH00<1><0><default><0>
usb_host_init_state = 0
usb_restric_flag = 0
usb_restric_voltage = 3550000
usb_restric_capacity = 5


Hier stecken zwei Änderungen:
usb_detect_type sollte  1 sein und usb_restrict_gpio hatte eine Schreibfehler, der wohl zu Ungereimtheiten auf PH00 (das ist der COC TX) führten.

Das ganze mit Strg-o [Enter] und Strg-x speichern und nano beenden.

5. Die Konfiguration ins Binärformat zurückwandeln

sudo fex2bin /boot/bananapi.fex /boot/bananapi.bin


So, nach dem Booten (sudo reboot) sollte das COC mit Hilfe von /usr/local/bin/coc_reset.sh anfangen zu blinken und sich mit screen /dev/ttyS2 38400 (hier mal das große V und [Enter] eingeben, verlassen mit Strg-A k) ansprechen lassen. Achtung, Hinweis von oben beachten: Der Port ist hier nicht, wie die Konfiguration vermuten läßt, mit ttyS3 sondern mit ttyS2 erreichbar. Das kommt daher, das [uart_para1] uart_used = 0 ist - das verschiebt die Portnummerierung, obwohl es dafür das Keyword uart_port gibt.

Wenn das funktioniert, kann man das fest in fhem.cfg eintragen:

define COC CUL /dev/ttyS2@38400 1234


Hoffe, euer COC läuft nun auch mit eurem Banana Pi.


Gruß, Norbert

Waldmensch

#47
Vielen Dank für die Anleitung. Ich habe sie genau 1:1 befolgt und auch den typo gefunden. Leider kommt unter screen nichts wenn ich V + Return eingebe. Beim Reset blitzt mein COC auch nur einmal ganz kurz, statt zu blinken. Das COC funzt an einem Raspberry einwandfrei.

Der Serial relevante Teil in dmesg:

[    0.517099] msgmni has been set to 1441
[    0.524781] alg: No test for stdrng (krng)
[    0.531542] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    0.534498] io scheduler noop registered
[    0.537749] io scheduler deadline registered
[    0.541472] io scheduler cfq registered (default)
[    0.546377] sunxi disp driver loaded (/dev/disp api 1.0)
[    0.551959] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.556814] [uart]: used uart info.: 0x8d
[    0.561553] [uart]: serial probe 0 irq 33 mapbase 0x01c28000
[    0.585210] sunxi-uart.0: ttyS0 at MMIO 0x1c28000 (irq = 33) is a U6_16550A
[    0.590148] [uart]: serial probe 2 irq 35 mapbase 0x01c28800
[    0.613710] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a U6_16550A
[    0.618601] [uart]: serial probe 3 irq 36 mapbase 0x01c28c00
[    0.642158] sunxi-uart.3: ttyS2 at MMIO 0x1c28c00 (irq = 36) is a U6_16550A
[    0.647026] [uart]: serial probe 7 irq 52 mapbase 0x01c29c00
[    0.670572] sunxi-uart.7: ttyS3 at MMIO 0x1c29c00 (irq = 52) is a U6_16550A
[    0.673166] G2D: drv_g2d_init
[    0.676541] G2D: Module initialized.major:250
[    0.685754] brd: module loaded
[    0.691775] loop: module loaded
[    0.694075] nand driver is disabled
[    0.697864] gpio count < =0 ,gpio_count is: 0
[    0.703841] sw_ahci sw_ahci.0: controller can't do PMP, turning off CAP_PMP
[    0.708348] ahci: SSS flag set, parallel bus scan disabled
[    0.715782] sw_ahci sw_ahci.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode

Curzon

Dann schau dir mal deine Fex-Datei genauer an. Irgendeine Device-Einstellung benutzt bei dir den PI19 (=gpio17) und/oder PA02 (gpio18). Wenn ein anderer Gerätetreiber die gleichen Pins wie die für den COC-Betrieb in beschlag nimmt, kannst du reseten bist du schwarz wirst - du legst die beiden Pins gpio17 und 18 zwar mit dem Reset-Script entsprechend, aber ein anderer Treiber setzt diese sofort wieder zurück.
Falls du nicht weiterkommst, schick mal deine Fex (oder Bin) Konfigurationsdatei, ich schau dann gerne mal rein...

Gruß,
Norbert

Waldmensch

#49
Vielen Dank! Die Fex Datei ist im Anhang. Das COC ist die Version mit RTC und onewire. Ich hatte auch schon das bananian Image getestet - war genau das selbe. Das Image ist ganz frisch runtergeladen und nur die Fex Datei ist geändert wie oben beschrieben. Am Banana hängt nichts weiter dran. Der Banana ist ein Banana Pro mit WLAN on Board

Edit: In der Fex Datei haben die Ports alle eine andere Syntax. Ich habe keinen Plan was gpio18/17 übersetzt in diese PXxx sind. Sonst hätte ich auch schonmal gesucht. Es gibt da zwar ein paar Tabellen im Netz, aber nichts woraus ich schlau werde. Das einzige wäre dies http://www.elektronik-kompendium.de/sites/raspberry-pi/1907101.htm woraus ich den gpio17 als PI19 erkenne und sehe, das er am uart_para2 genutzt wird

Curzon

#50
Dein Link mit der PIN-Belegung der BPi ist goldrichtig:

Ich habe wohl das gleich COC - im Schaltplan siehst du, dass das COC folgende PINx verwendet (Spannungsversorgung hab ich hier weggelassen):


COCGPIO LeisteRaspberryPiBananaPI (Angabe in der .Fex)
TXPIN8GPIO 14PH00
RXPIN10GPIO 15PH01
MOD_RESETPIN11GPIO 17PI19
MOD_BSPIN12GPIO 18PH02
I2C Data (SDA)PIN3GPIO 2PB21
I2C Clk (SCL)PIN5GPIO 3PB20

Bei Ansprechen der Ports für den Reset hast du leider die Bezeichnungen vom Raspberry (da eben gpio17 und gpio18), in der .Fex nimmst du Bezug auf die BananaPi Ports - daher kommt die Verwirrung.

Alles was mit in der .Fex PH00, PH01, PI19 und PH02 kolldiert könnte problematisch sein.


Die Fex für deinen Pro hat u.a. auch eine andere Konfiguration für z.B. Wifi

Versuch es mal mit der Änderung die ich anhängt habe. Dort sind genau die Änderungen für meinen BPi drin.

Die COC Schnittstelle sollte hier auf /dev/ttyS2 sein und das COC muss nach dem Reset dauerhaft im Sekundentak blinken. Ansonsten nimm dir auch mal deine boot.cmd vor, ich habe dort alles unnötige mit ttyS1/ttyS2 raus:
(Beachte: Ich habe einen anderen Kernel, den für den BPi, da steht bei dir dann wohl der Pro Kernel)

setenv bootargs console=tty0 consoleblank=0 disp.screen0_output_mode=EDID:1280x720p60 hdmi.audio=EDID:0 root=/dev/mmcblk0p1 rootwait sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 panic=10
ext4load mmc 0 0x43000000 /boot/bananapi.bin
ext4load mmc 0 0x48000000 /boot/vmlinuz-3.4.106-bananapi
bootz 0x48000000


Änderungen an der boot.cmd musst du noch umwandeln mit:

sudo mkimage -C none -A arm -T script -d boot.cmd boot.scr


Im Übrigen hilft die dmesg Ausgabe hier nix, die gibt auch nur das wieder was in der .Fex konfiguriert wurde aber nicht was tatsächlich funktioniert - hier hilft nur der Test mir screen.

Würde mich langsam wundern, wenn es mit der .Fex hier auch nicht funktioniert...

Waldmensch

#51
Ich habe exakt das image, was du verlinkt hast. Meinst Du das hat 2 unterschiedliche configurationen/ kernel eingebaut? In jedem Fall teste ich dein fex heute abend.


Edit: Mit Deiner .fex leider keine Änderung, es bleibt bei 1x kurz aufblitzen beim starten des Reset Script. Entsprechend bei Screen auch keine Ausgabe. Die boot.cmd finde ich nirgendwo, muß ich die erst erstellen?

Edit2: irgendwie habe ich hier im Forum keinen Antworten Button mehr. Ich kann nur meinen bestehenden Beiträge editieren :-/

Edit3: boot.cmd gefunden. Da ist aber nichts drin mit ttyS1 oder 2. Also auch nix zu entfernen

Waldmensch


Curzon

@Waldmensch, du schreibst

Zitat von: Waldmensch am 27 März 2015, 06:18:16
Der Banana ist ein Banana Pro mit WLAN on Board

und

Zitat von: Waldmensch am 27 März 2015, 13:32:36
Ich habe exakt das image, was du verlinkt hast.

Da kann was nicht stimmen  ;D

Ich habe den Banana Pi (nicht Pro!) und hatte in meinem Beitrag auch das Image für den Banana Pi verlinkt.

Das Image für den BPi Pro liegt unter Raspbian For BananaPro v1412, das Image für den BPi unter Lemaker Raspian for BananaPi v1412.

Beide IMages basieren zwar auf der gleichen Version, exakt das Image in meinem BPi ist deines hoffentlich nicht  :).

Also entweder verwendest du das Pro Image, das auf der gleichen Version wie meines basiert oder du verwendest wirklich exakt das gleiche wie das von mir verlinkte.
Dann benutzt du allerdings ein BPi Image auf einen BPi Pro - in dem Fall solltest du vielleicht erst mal das richtige Pro Image runterladen.

Waldmensch

Na ich bin deiner Anleitung gefolgt und da steht unter Eins

Zitat1. Das Debian Wheezy Image 3.4.106 von Igor Pečovnik runterladen und auf eine SD-Karte installieren.

Und das habe ich genau so gemacht. Das Raspbian ist doch was ganz anderes?

Curzon

Du hast recht, sorry. Hab jetzt selbst das Image verwechselt. Das Image von Igor ist natürlich auch für den Pro...
Ich mach jetzt erst mal Pause...  ;)

Waldmensch

Ich habe jetzt das Raspbian für den Pro drauf. Das COC gibt wieder nur einen kurzen "Blitz" beim Reset.

- Beim Raspbian muss man die sunxi tools erst bauen- gemacht.
- Die Datei heißt /boot/script.bin - in script.fex gewandelt

hier der UART Teil (komplette unveränderte fex im Anhang):
[uart_para0]
uart_used = 1
uart_port = 0
uart_type = 2
uart_tx = port:PB22<2><1><default><default>
uart_rx = port:PB23<2><1><default><default>

[uart_para1]
uart_used = 0
uart_port = 1
uart_type = 8
uart_tx = port:PA10<4><1><default><default>
uart_rx = port:PA11<4><1><default><default>
uart_rts = port:PA12<4><1><default><default>
uart_cts = port:PA13<4><1><default><default>
uart_dtr = port:PA14<4><1><default><default>
uart_dsr = port:PA15<4><1><default><default>
uart_dcd = port:PA16<4><1><default><default>
uart_ring = port:PA17<4><1><default><default>

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>

[uart_para3]
uart_used = 0
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

[uart_para4]
uart_used = 1
uart_port = 4
uart_type = 2
uart_tx = port:PH04<4><1><default><default>
uart_rx = port:PH05<4><1><default><default>

[uart_para5]
uart_used = 0
uart_port = 5
uart_type = 2
uart_tx = port:PH06<4><1><default><default>
uart_rx = port:PH07<4><1><default><default>

[uart_para6]
uart_used = 0
uart_port = 6
uart_type = 2
uart_tx = port:PA12<4><1><default><default>
uart_rx = port:PA13<4><1><default><default>

[uart_para7]
uart_used = 1
uart_port = 7
uart_type = 2
uart_tx = port:PI20<3><1><default><default>
uart_rx = port:PI21<3><1><default><default>


Waldmensch

#57
Der [uart_para2] enthält den PI19, also habe ich den deaktiviert. Der PH02 wird von pmu_adaptet genutzt pmu_adpdet = port:PH02<0><default><default><default> wobei ich eher glaube, dass das adapter heißen soll. Ich trau mich aber auch nicht [pmu_para] generell zu deaktivieren.

Also ich bin echt mit meinem Latein am Ende.

Kann es an der COC Firmware liegen, das es auf dem RPI läuft, auf dem BPI aber nicht? Gabs da nochmal Änderungen auf COC Seite? Habe meine alte coc.hex gefunden, die auf dem COC ist, die ist vom 18.1.2014

Waldmensch

Halleluja!!!!!

Neue, aktuelle Firmware auf den COC geflasht (mit dem RPI an dem der COC lief). COC wieder auf den BananaPro gesteckt, Reset script gestartet -> Er blitzt kurz und fängt an zu blinken  :o. Screen aufgerufen, Mist, ist gar nicht installiert. Draufgetüdelt und mit  screen /dev/ttyS2 38400 gestartet. Großes "V" + Return - voila: V 1.63 CSM868

Also, bei wem ein etwas älterer COC nicht will - unbedingt mal die neueste Firmware draufmachen: http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/

Curzon

#59
Zitat von: Waldmensch am 28 März 2015, 22:02:57
Halleluja!!!!!
Großes "V" + Return - voila: V 1.63 CSM868

Also, bei wem ein etwas älterer COC nicht will - unbedingt mal die neueste Firmware draufmachen: http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/

Super, na das ist doch ein Erfolg. :D

Weißt du zufällig, welche COC Firmware vorher bei dir drauf war?

Ich kann von mir bestätigen, dass auch die V 1.62 CSM868 mit dem BPi läuft.