[d11b]

Kurios: Der erste reboot-Vorgang hat geklappt. Dann habe ich die Rocrail-Dateien wieder zurückkopiert und der nächste Neustart (über reboot) hat den BPi nicht mehr ordentlich hochgefahren. Nach kurzem Strom abschalten und wieder einschalten, hat er gebootet. Und jetzt reagiert er schon wieder nicht auf reboot. Die SSH-Connection bleibt auf und er startet nicht neu.

Viele Grüße
Daniel

Edit: Ich schreib nochmal ein kleines Update. Will dich/euch damit nicht all zu sehr nerven. Aber lustigerweise scheint der BPi zumindest herunterzufahren (mit reboot-Befehl), wenn ich das wake-up-links88-Skript aus dem init.d-Ordner entferne. Vernünftig booten tut er dann zwar trotzdem nicht, aber er schließt wenigstens schonmal die SSH-Connection und schaltet den BPi aus.

[bertr2d2]

Hallo Daniel,

Zitat

---

Edit: Ich schreib nochmal ein kleines Update. Will dich/euch damit nicht all zu sehr nerven. Aber lustigerweise scheint der BPi zumindest herunterzufahren (mit reboot-Befehl), wenn ich das wake-up-links88-Skript aus dem init.d-Ordner entferne. Vernünftig booten tut er dann zwar trotzdem nicht, aber er schließt wenigstens schonmal die SSH-Connection und schaltet den BPi aus.

---

ich konnte den Fehler im Zusamenhang mit wake-up-links88 reproduzieren. Bitte ändere die Zeile in /etc/init.d/wake-up-links88 von

1
 

	wake-up-links88 -c "B3=1" -i can0
 

in

1
 

	wake-up-links88 -dc "B3=1" -i can0
 

Den Parameter zum Bus musst Du ggf. anpassen.

Ansonsten bleibt der Startprozedur hängen und die Stoppprozedur kann nicht gestartet werden. Im neuen Image habe ich den Fehler behoben.

Gruß

Gerd

[d11b]

Hallo Gerd,

mir ist eben aufgefallen, dass die Rocrail-Updates auf 15000 (trotz Anzeige, dass er auf 15069 updatet) hängen bleiben. Ist dir da ein Problem bekannt?

VG
Daniel

[bertr2d2]

Hallo Daniel,

Zitat

---

Hallo Gerd,

mir ist eben aufgefallen, dass die Rocrail-Updates auf 15000 (trotz Anzeige, dass er auf 15069 updatet) hängen bleiben. Ist dir da ein Problem bekannt?

---

wie sehen die Meldungen auf der Console bei Dir aus ? Das Update dauert einige Minuten und sieht ggf. nur nach Hängenbleiben aus. Hier ein Log von mir:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 

root@Modellbahn-BPi:~# opkg update
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/Packages.gz
Updated list of available packages in /var/opkg-lists/reboot_railroad
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/Packages.sig
Signature check passed.
 
root@Modellbahn-BPi:~# opkg list-upgradable
rocrail-cs-mcs2 - 15049 - 15069
rocrail-cs-mbus - 15049 - 15069
rocrail-cs-srcp - 15049 - 15069
rocrail-cs-mgbox - 15049 - 15069
rocrail - 15049 - 15069
rocrail-cs-all-other - 15049 - 15069
rocweb - 15049 - 15069
rocrail-cs-ddx - 15049 - 15069
rocrail-cs-wmz21 - 15049 - 15069
rocrail-cs-p50 - 15049 - 15069
can2udp - 1.60 - 1.61
rocnetnode - 15049 - 15069
rocrail-cs-rclink - 15049 - 15069
 
root@Modellbahn-BPi:~# time opkg install can2udp rocnetnode rocrail rocweb
Upgrading can2udp on root from 1.60 to 1.61...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/can2udp_1.61_arm_cortex-a8_vfpv3.ipk
Terminated
Upgrading rocnetnode on root from 15049 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocnetnode_15069_arm_cortex-a8_vfpv3.ipk
Upgrading rocrail on root from 15049 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail_15069_arm_cortex-a8_vfpv3.ipk
Upgrading rocweb on root from 15049 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocweb_15069_arm_cortex-a8_vfpv3.ipk
Configuring rocrail.
Configuring rocweb.
Configuring can2udp.
RTNETLINK answers: Resource busy
Configuring rocnetnode.
real	4m 1.60s
user	3m 51.62s
sys	0m 10.83s
 

Das Update hat mehr als 4 Minuten gebraucht.

Gruß

Gerd

[d11b]

Guten Abend Gerd,

die Updates liefen alle problemlos durch (dauerte wie immer auch so um die 5 Minuten). Ich habe dann später nur durch Zufall festgestellt, dass mir unter Rocview eine Version 15000 für den Rocrail-Server angezeigt wird.

Ich habe jetzt gerade nochmal ein älteres Image geupdatet und danach mir unter Rocview die Rocrail-Server-Version angeschaut:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 

 opkg update
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/Packages.                                                                   gz.
Updated list of available packages in /var/opkg-lists/reboot_railroad.
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/Packages.                                                                   sig.
Signature check passed.
root@Modellbahn-BPi:~# opkg list-upgradable
rocrail-cs-mcs2 - 14923 - 15069
rocrail-cs-srcp - 14923 - 15069
rocrail-cs-mgbox - 14923 - 15069
rocrail - 14923 - 15069
rocrail-cs-all-other - 14923 - 15069
rocweb - 14923 - 15069
rocrail-cs-ddx - 14923 - 15069
rocrail-cs-p50 - 14923 - 15069
can2udp - 1.57 - 1.61
rocnetnode - 14923 - 15069
rocrail-cs-rclink - 14923 - 15069
root@Modellbahn-BPi:~# opkg upgrade rocrail-cs-mcs2 rocrail-cs-srcp rocrail-cs-m
gbox rocrail rocrail-cs-all-other rocweb rocrail-cs-ddx rocrail-cs-p50 can2udp r
ocnetnode rocrail-cs-rclink
Upgrading rocrail-cs-mcs2 on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-c                                                                   s-mcs2_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail-cs-srcp on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-c                                                                   s-srcp_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail-cs-mgbox on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-c                                                                   s-mgbox_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail_1                                                                   5069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail-cs-all-other on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-c                                                                   s-all-other_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocweb on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocweb_15                                                                   069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail-cs-ddx on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-cs-ddx_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail-cs-p50 on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-cs-p50_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading can2udp on root from 1.57 to 1.61...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/can2udp_1.61_arm_cortex-a8_vfpv3.ipk.
Terminated
Upgrading rocnetnode on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocnetnode_15069_arm_cortex-a8_vfpv3.ipk.
Upgrading rocrail-cs-rclink on root from 14923 to 15069...
Downloading http://lnxpps.de/bpi/packages/arm_cortex-a8_vfpv3/railroad/rocrail-cs-rclink_15069_arm_cortex-a8_vfpv3.ipk.
Configuring rocrail.
Configuring rocrail-cs-mcs2.
Configuring rocrail-cs-srcp.
Configuring rocrail-cs-mgbox.
Configuring rocrail-cs-all-other.
Configuring rocweb.
Configuring rocrail-cs-ddx.
Configuring rocrail-cs-p50.
Configuring can2udp.
RTNETLINK answers: Resource busy
Configuring rocnetnode.
Configuring rocrail-cs-rclink.
Collected errors:
 * resolve_conffiles: Existing conffile /opt/rocrail/plan.xml is different from the conffile in the new package. The new conffile will be placed at /opt/rocrail/plan.xml-opkg.
 * resolve_conffiles: Existing conffile /opt/rocrail/rocrail.ini is different from the conffile in the new package. The new conffile will be placed at /opt/rocrail/rocrail.ini-opkg.
 * resolve_conffiles: Existing conffile /etc/init.d/can2lan is different from the conffile in the new package. The new conffile will be placed at /etc/init.d/can2lan-opkg.
 
 

Nach dem Update-Vorgang wird mir kurioserweise unter Rocview die Rocrail-Server-Version 14923 angezeigt. Nachdem ich jetzt

1
 

rocrail restart
 

nochmal manuell angestoßen habe, zeigt er mir die richtige Version an. Also lag es wohl - mal wieder - nur an meiner Unwissenheit. Ich bin bisher davon ausgegangen, dass sich Rocrail nach dem Update neustartet und aktualisiert ist. Sorry!

VG
Daniel

[DeMorpheus]

Hallo,

das Thema führt mich zu einer weiteren Frage: wie sieht es mit Updates für das zugrundeliegende Lede aus, kommen die bei Bedarf über den gleichen Weg oder muss dafür ein neues Image her? Das stand hier bestimmt schon mal irgendwo, aber ich werde nicht fündig.

[bertr2d2]

Hallo Moritz,

Zitat

---

Hallo,

das Thema führt mich zu einer weiteren Frage: wie sieht es mit Updates für das zugrundeliegende Lede aus, kommen die bei Bedarf über den gleichen Weg oder muss dafür ein neues Image her? Das stand hier bestimmt schon mal irgendwo, aber ich werde nicht fündig.

---

aktualisierte Images auf Lede (17.01) basierend biete ich hier immer noch an:
http://lnxpps.de/bpi/#BPi_Software
Die Images werden bis auf weiteres immer noch gepflegt und von Zeit zu Zeit upgedated. Basis ist der Linux Kernel 4.4, der wahrscheinlich auch noch 20 Jahre gepflegt wird. BTW: CS2 verwendet ein Linux Kernel 2.x - das schon X-Jahre aus der Wartung ist ...

Wie der Zufall es will habe ich in den letzten Tagen schon geschaut, wie ich den BPi auf eine aktuelles Linux bringen kann. Dazu habe ich ein aktuelles (HEAD) OpenWRT genommen und auf Linux 4.19.x gestellt. Das Ergebnis als Image (mit allen üblichen Softwarepaketen) ist hier zu finden: http://lnxpps.de/bpi/bin/openwrt-sunxi-c...-sdcard.img.zip (Entpacken vor dem Schreiben nicht vergessen )
Update Möglichkeit für Rocrail/can2lan etc. pp. habe ich aber noch nicht eingerichtet - aber es kann getestet werden. Resonanz ist ausdrücklich erwünscht.
Nachtrag:
Das root Passwort lautet: knaller

Ich muss noch mit Rainer Müller sprechen, ob der SPI Treiber so funktioniert wie er es für seine Software (im Image enthalten) braucht. Wenn dann OpenWRT Team entscheidet ein Tag (19.0.x) zu setzen, werde ich auf diese Version mit Linux Kernel 4.19.x umschwenken.
Das Update von Lede -> OpenWRT ist aber leider nur über ein komplett Udpate möglich. Datensicherung muss man vorher machen.
Das ist aber mit wenigen Handgriffen einfach möglich. Beschreibung folgt.

Gruß

Gerd

[ricky]

Hallo Gerd

Ich hab den jetzt die MBus als Zentrale drin ist dir da was bekannt das der S88 Bus auf dem Banana mit deinem Image und Rocrail Server auf Banana nicht läuft wenn ich den Server auf dem PC laufen lassen hab rennt der S88 über den Banana wie gewohnt.


Gruß Reiner

[bertr2d2]

Hallo Reiner,

Zitat

---

Hallo Gerd

Ich hab den jetzt die MBus als Zentrale drin ist dir da was bekannt das der S88 Bus auf dem Banana mit deinem Image und Rocrail Server auf Banana nicht läuft wenn ich den Server auf dem PC laufen lassen hab rennt der S88 über den Banana wie gewohnt.

---

ich konnte selbst noch nicht mit MBus als Zentrale testen - daher nur Vermutungen. Ich weiß jetzt nicht wie Du MBus als Zentrale konfiguriert hast.
Laufen sollte es wenn Du weiterhin can2lan verwendest und MBus mit TCP (localhost) konfigurierst. Oder Du nutzt MBus (SocketCAN) und eine weitere "Zentrale" für die S88 Meldungen, die von s88udp-bpi per UDP Broadcast Port 15730 versendet werden. Ggf. muss man den Port (Option -p) anpassen.
Vielleicht muss man aber noch etwas nachbessern - Rocrails MBus ist brandneu. Bin gespannt auf Deine Tests ...

Gruß

Gerd

[Rainer Müller]

Hallo Gerd,

Zitat

---

Ich muss noch mit Rainer Müller sprechen, ob der SPI Treiber so funktioniert wie er es für seine Software (im Image enthalten) braucht. Wenn dann OpenWRT Team entscheidet ein Tag (19.0.x) zu setzen, werde ich auf diese Version mit Linux Kernel 4.19.x umschwenken.
...

Gruß

Gerd

---

nachdem ich auf meinem Entwicklungs-BPi "Linux bananapi 4.19.20-sunxi #5.75 SMP " zur Zeit zum Testen benutze, sollte die Kernelumstellung bezüglich SPI kein Problem sein. Der vor eineinhalb Jahren von dir unter Lede benutzte SPI-Treiber konnte leider nur bis 63 Byte SPI-Transfers machen, deshalb hast du laut meiner Erinnerung den neueren rückportiert, der damals schon im Armbian war; der konnte dann mehr als 64, und der basrcpd braucht dreistellige Werte. Seither hat den "spi-sun4i" keiner mehr angerührt, so dass er auch heute (!) noch weniger als 64 und mehr als 64 Bytes transferieren kann, nur eben nicht GENAU 64 (siehe unten).

Vermutlich wird das SPI-Device dann auch bei Lede anstatt "/dev/spidev32766.0" wie früher "/dev/spidev0.0" heißen, das muss dann bei Bedarf in der scrpd.conf nachgezogen werden.

Gruß
Rainer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 

spitest vom Feb 22 2019
Len         76922 Baud               137932 Baud               160000 Baud
  60:   6340 =>   6445µs (  16‰)  3572 =>   3618µs (  12‰)  3100 =>   3106µs (   1‰)
  61:   6444 =>   6507µs (   9‰)  3636 =>   3612µs (  -6‰)  3148 =>   3156µs (   2‰)
  62:   6548 =>   6612µs (   9‰)  3692 =>   3678µs (  -3‰)  3196 =>   3200µs (   1‰)
  63:   6652 =>   6709µs (   8‰)  3748 =>   3725µs (  -6‰)  3244 =>   3254µs (   3‰)
  64: Error SPI Transfer ioctl: Connection timed out (errno = 110).
    Error SPI Transfer ioctl: Connection timed out (errno = 110).
    Error SPI Transfer ioctl: Connection timed out (errno = 110).
  65:   6860 =>   6975µs (  16‰)  3868 =>   3900µs (   8‰)  3348 =>   3371µs (   6‰)
  66:   6964 =>   6997µs (   4‰)  3924 =>   3922µs (   0‰)  3396 =>   3408µs (   3‰)
  67:   7068 =>   7095µs (   3‰)  3980 =>   3939µs ( -10‰)  3444 =>   3441µs (   0‰)
  68:   7172 =>   7201µs (   4‰)  4036 =>   3988µs ( -11‰)  3500 =>   3478µs (  -6‰)
  69:   7276 =>   7301µs (   3‰)  4100 =>   4045µs ( -13‰)  3548 =>   3529µs (  -5‰)
  70:   7380 =>   7406µs (   3‰)  4156 =>   4146µs (  -2‰)  3596 =>   3617µs (   5‰)
 
 

[ricky]

Hallo Gerd

Danke für deine Antwort
Die Config ist über SocketCan eingestellt der Rest funzt einwandfrei da könnt ich mir schon vorstellen das es dabei eine Port Kollision
gibt den es läuft doch alles über can2lan,
über den TCP Port hab ich noch nicht getestet muß ich mal nachholen wie es dabei aussieht.

Wenn der Server ganz normal über über den PC läuft tut alles wie geplant also Node über Banana und den Rocrail Server über den PC
und im Banana gestoppt.


Werde drüber berichten

Gruß Reiner

[bertr2d2]

Hallo Reiner,

Zitat

---

Hallo Gerd

Danke für deine Antwort
Die Config ist über SocketCan eingestellt der Rest funzt einwandfrei da könnt ich mir schon vorstellen das es dabei eine Port Kollision
gibt den es läuft doch alles über can2lan,
über den TCP Port hab ich noch nicht getestet muß ich mal nachholen wie es dabei aussieht.

Wenn der Server ganz normal über über den PC läuft tut alles wie geplant also Node über Banana und den Rocrail Server über den PC
und im Banana gestoppt.

---

ich habe den Test durchgeführt. Es funktioniert auch ohne can2lan auf dem BPi als Rocrail Server wenn man zwei MBus Zentralen nutzt:
- einmal mbus mit SocketCAN (Sub-Bibliothek can)
- einmal mit UDP (Sub-Bibliothek udp)



Sicherlich sind auch noch andere Kombinationen möglich.

Gruß

Gerd

PS: Das s88udp hat jetzt noch eine kleine Erweiterung zum Testen bekommen. Mit der Modulanzahl 0 (Option -m 0) wird alle 0,9 Sekunden ein S88 Event gesendet.

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1944173 time=1550842938 user_id=1332]
Hallo Gerd,

nachdem ich auf meinem Entwicklungs-BPi "Linux bananapi 4.19.20-sunxi #5.75 SMP " zur Zeit zum Testen benutze, sollte die Kernelumstellung bezüglich SPI kein Problem sein. Der vor eineinhalb Jahren von dir unter Lede benutzte SPI-Treiber konnte leider nur bis 63 Byte SPI-Transfers machen, deshalb hast du laut meiner Erinnerung den neueren rückportiert, der damals schon im Armbian war; der konnte dann mehr als 64, und der basrcpd braucht dreistellige Werte.
[/quote]wie gut, das man Wissen extern auslagern kann Das hatte ich vergessen. Der SPI Code hat im neuesten Image dann auch den gleichen Stand.

Zitat

---

Seither hat den "spi-sun4i" keiner mehr angerührt, so dass er auch heute (!) noch weniger als 64 und mehr als 64 Bytes transferieren kann, nur eben nicht GENAU 64 (siehe unten).

---

Schon komisch. Scheint immer noch nicht gefixt zu sein. Aber Du umgehst es ja letztendlich in Deinem Programm.

Zitat

---

Vermutlich wird das SPI-Device dann auch bei Lede anstatt "/dev/spidev32766.0" wie früher "/dev/spidev0.0" heißen, das muss dann bei Bedarf in der scrpd.conf nachgezogen werden.

---

Danke für den Hinweis. Werde ich berücksichtigen.

Zitat

---

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 

spitest vom Feb 22 2019
Len         76922 Baud               137932 Baud               160000 Baud
  60:   6340 =>   6445µs (  16‰)  3572 =>   3618µs (  12‰)  3100 =>   3106µs (   1‰)
  61:   6444 =>   6507µs (   9‰)  3636 =>   3612µs (  -6‰)  3148 =>   3156µs (   2‰)
  62:   6548 =>   6612µs (   9‰)  3692 =>   3678µs (  -3‰)  3196 =>   3200µs (   1‰)
  63:   6652 =>   6709µs (   8‰)  3748 =>   3725µs (  -6‰)  3244 =>   3254µs (   3‰)
  64: Error SPI Transfer ioctl: Connection timed out (errno = 110).
    Error SPI Transfer ioctl: Connection timed out (errno = 110).
    Error SPI Transfer ioctl: Connection timed out (errno = 110).
  65:   6860 =>   6975µs (  16‰)  3868 =>   3900µs (   8‰)  3348 =>   3371µs (   6‰)
  66:   6964 =>   6997µs (   4‰)  3924 =>   3922µs (   0‰)  3396 =>   3408µs (   3‰)
  67:   7068 =>   7095µs (   3‰)  3980 =>   3939µs ( -10‰)  3444 =>   3441µs (   0‰)
  68:   7172 =>   7201µs (   4‰)  4036 =>   3988µs ( -11‰)  3500 =>   3478µs (  -6‰)
  69:   7276 =>   7301µs (   3‰)  4100 =>   4045µs ( -13‰)  3548 =>   3529µs (  -5‰)
  70:   7380 =>   7406µs (   3‰)  4156 =>   4146µs (  -2‰)  3596 =>   3617µs (   5‰)
 
 

---

Welches Programm nutzt Du für diesen Test ?

Gruß

Gerd

[Rainer Müller]

Hallo Gerd,

Zitat

---

Hallo Rainer,
[quote="Rainer Müller" post_id=1944173 time=1550842938 user_id=1332]
Hallo Gerd,

nachdem ich auf meinem Entwicklungs-BPi "Linux bananapi 4.19.20-sunxi #5.75 SMP " zur Zeit zum Testen benutze, sollte die Kernelumstellung bezüglich SPI kein Problem sein. Der vor eineinhalb Jahren von dir unter Lede benutzte SPI-Treiber konnte leider nur bis 63 Byte SPI-Transfers machen, deshalb hast du laut meiner Erinnerung den neueren rückportiert, der damals schon im Armbian war; der konnte dann mehr als 64, und der basrcpd braucht dreistellige Werte.

---

wie gut, das man Wissen extern auslagern kann Das hatte ich vergessen. Der SPI Code hat im neuesten Image dann auch den gleichen Stand.
[/quote]
da mein Lager immer weniger freien Speicher bietet, muss ich wohl mal an Preisanpassung denken .

Zitat

---

Zitat

---

Seither hat den "spi-sun4i" keiner mehr angerührt, so dass er auch heute (!) noch weniger als 64 und mehr als 64 Bytes transferieren kann, nur eben nicht GENAU 64 (siehe unten).

---

Schon komisch. Scheint immer noch nicht gefixt zu sein. Aber Du umgehst es ja letztendlich in Deinem Programm.

---

derzeit gibts beim basrcpd keine so kurzen Pakete. Bisher wollte ich mich aber auch raushalten, Kernel-Treiber zu verbessern. Ich habe da die Zeile 325 des spi-sun4i.c in Verdacht:
sollte anstatt "(tx_len > SUN4I_FIFO_DEPTH)" wohl eher "(tx_len >= SUN4I_FIFO_DEPTH)" heissen.

Zitat

---

Welches Programm nutzt Du für diesen Test ?

Gruß

Gerd

---

Das ist ein kurzes Testprogramm mit dem ich die Eignung des SPI auf dem BPi angetestet habe, schreibt mit drei unterschiedlichen Baudraten (jeweils eine Zeile) unterschiedlich lange Pakete raus und misst die Transferzeit. Wenn das nicht geht, brauche ich gar nicht erst dn Tastkopf anlemmen. Bei Länge 64 gibt schon der ioctl-Aufruf in Zeile 50 den Fehlercode 110 zurück.

Gruß
Rainer

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1945561 time=1551120980 user_id=1332]
derzeit gibts beim basrcpd keine so kurzen Pakete. Bisher wollte ich mich aber auch raushalten, Kernel-Treiber zu verbessern. Ich habe da die Zeile 325 des spi-sun4i.c in Verdacht:
sollte anstatt "(tx_len > SUN4I_FIFO_DEPTH)" wohl eher "(tx_len >= SUN4I_FIFO_DEPTH)" heissen.
...
Das ist ein kurzes Testprogramm mit dem ich die Eignung des SPI auf dem BPi angetestet habe, schreibt mit drei unterschiedlichen Baudraten (jeweils eine Zeile) unterschiedlich lange Pakete raus und misst die Transferzeit. Wenn das nicht geht, brauche ich gar nicht erst dn Tastkopf anlemmen. Bei Länge 64 gibt schon der ioctl-Aufruf in Zeile 50 den Fehlercode 110 zurück.
[/quote]
mit der von Dir vorgeschlagenen Änderung sieht es besser aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 

root@Modellbahn-BPi:~# uname -a
Linux Modellbahn-BPi 4.19.25 #0 SMP PREEMPT Mon Feb 25 23:16:22 2019 armv7l GNU/Linux
root@Modellbahn-BPi:~# spitest 
spitest vom Feb 25 2019
           76922 Baud               137932 Baud               160000 Baud     
  60:   6340 =>   6484µs (  22‰)  3572 =>   3561µs (  -3‰)  3100 =>   3101µs (   0‰)
  61:   6444 =>   6518µs (  11‰)  3636 =>   3617µs (  -5‰)  3148 =>   3142µs (  -1‰)
  62:   6548 =>   6603µs (   8‰)  3692 =>   3669µs (  -6‰)  3196 =>   3206µs (   3‰)
  63:   6652 =>   6721µs (  10‰)  3748 =>   3733µs (  -4‰)  3244 =>   3251µs (   2‰)
  64:   6756 =>   6806µs (   7‰)  3804 =>   3783µs (  -5‰)  3300 =>   3303µs (   0‰)
  65:   6860 =>   6924µs (   9‰)  3868 =>   3842µs (  -6‰)  3348 =>   3346µs (   0‰)
  66:   6964 =>   7022µs (   8‰)  3924 =>   3897µs (  -6‰)  3396 =>   3398µs (   0‰)
  67:   7068 =>   7120µs (   7‰)  3980 =>   3962µs (  -4‰)  3444 =>   3447µs (   0‰)
  68:   7172 =>   7240µs (   9‰)  4036 =>   4014µs (  -5‰)  3500 =>   3498µs (   0‰)
  69:   7276 =>   7345µs (   9‰)  4100 =>   4084µs (  -3‰)  3548 =>   3556µs (   2‰)
  70:   7380 =>   7469µs (  12‰)  4156 =>   4133µs (  -5‰)  3596 =>   3598µs (   0‰)
 

Ich nehme den "Patch" einfach mal mit auf

Gruß

Gerd

PS: Dein neues srcpd nehme ich später noch mit in meinem Git auf

[Rainer Müller]

Hallo Gerd,

Zitat

---

PS: Dein neues srcpd nehme ich später noch mit in meinem Git auf

---

habs gesehen, danke fürs Übernehmen.

Zitat

---

...
Dazu habe ich ein aktuelles (HEAD) OpenWRT genommen und auf Linux 4.19.x gestellt. Das Ergebnis als Image (mit allen üblichen Softwarepaketen) ist hier zu finden: http://lnxpps.de/bpi/bin/openwrt-sunxi-c...-sdcard.img.zip (Entpacken vor dem Schreiben nicht vergessen )
Update Möglichkeit für Rocrail/can2lan etc. pp. habe ich aber noch nicht eingerichtet - aber es kann getestet werden. Resonanz ist ausdrücklich erwünscht.

Gruß

Gerd

---

Wenn Du aber Resonanz erwartest, solltest du den root nicht mit Passwort so verrammeln, dass man weder über Browser noch über SCP drankommt. Nach Löschen des Passworts:

1
2
3
4
5
6
7
 

OpenWrt SNAPSHOT, r9415-73c60ef239
--------------------------------------------------
root@Modellbahn-BPi:~# uname -a
Linux Modellbahn-BPi 4.19.23 #0 SMP PREEMPT Tue Feb 19 14:22:28 2019 armv7l GNU/Linux
root@Modellbahn-BPi:~# ls /dev/sp*
/dev/spidev0.0
 
 

Wie ich schon vermutet hatte, heisst das Gerät jetzt also spidev0.0, was man unter /etc/srcpd.conf korrigieren muss.

Prinzipiell läuft der basrcpd, gibt aber beim Start auffallend viele Meldungen über "Interrupted system call" aus. Bei usleep ist das eher als Schönheitsfehler einzustufen, aber beim MCS-Gateway triffts ein select, und da habe ich wohl die Fehlerbehandlung vermurkst: oft friert der Thread ein.

Nach dem Start läuft die Bedienung mit SRCP-Client (und manchmal auch mit MCS-Client) und die Gleissignalerzeugung korrekt, sprich ich konnte damit die Anlage betreiben.
Insgesamt sieht das aus meiner Sicht gut aus für einen aktuellen Kernel, ich muss halt noch ein klein wenig korrigieren bis es Ernst wird.

Gruß
Rainer

[ricky]

Hallo Gerd

So der Mbus läuft mit s88 und dem Rest habe jetzt in jetzt alleine über UDP als localhost drin da siehst so aus das alles angesprochen wird.
Das Problem mit S88 taucht nur über Socket Can auf.
Was etwas komisch ist das die Loks mit MFX Decoder mit zum teil mit vierstelligen Adressen angemeldet werden.


Wenn der Mbus alles erstes in der Zentralenliste ist werden alle Geräte in der Geräteliste Reiter Programmierung cbus/mbus angezeigt,
sonst braucht man eine Geräte ID.

Gruß Reiner

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1946666 time=1551386199 user_id=1332]
Wenn Du aber Resonanz erwartest, solltest du den root nicht mit Passwort so verrammeln, dass man weder über Browser noch über SCP drankommt.
[/quote]
ups, Entschuldigung. Das root Passwort lautet: knaller. Ich habe den obigen Eintrag ergänzt.

Zitat

---

Wie ich schon vermutet hatte, heisst das Gerät jetzt also spidev0.0, was man unter /etc/srcpd.conf korrigieren muss.

---

Ich habe das Makefile soweit ergänzt das die entsprechende Config Datei aufgenommen wird.

Es freut mich, das es ansonsten soweit funktioniert Ich hoffe, das das OpenWRT Team bald das Tag setzt. Dann werde ich auch alles auf das neue Image umsetzen.

Gruß

Gerd

[Rainer Müller]

Hallo Gerd,

Zitat

---

...
Das Ergebnis als Image (mit allen üblichen Softwarepaketen) ist hier zu finden: http://lnxpps.de/bpi/bin/openwrt-sunxi-c...-sdcard.img.zip (Entpacken vor dem Schreiben nicht vergessen )
Update Möglichkeit für Rocrail/can2lan etc. pp. habe ich aber noch nicht eingerichtet - aber es kann getestet werden. Resonanz ist ausdrücklich erwünscht.
...
Gruß

Gerd

---

manchmal stößt man beim Testen auf seltsame Dinge die man gar nicht testen wollte.

So musste ich feststellen, dass solange der BaPi mit obigem Image lief, ich die Weboberfläche meiner Fritzbox (Internetzugang, DHCP-Server, DNS) nicht mehr über "fritz.box" sondern nur noch über die IP-Adresse von meinem Win10-PC erreichen konnte.

Der BaPi hatte in meinem IPv4-Netz dem Win einen IPv6-DNS-Eintrag untergejubelt, den der PC bevorzugte. Somit gingen die Namensanfragen vom PC über IPv6 an den BaPi und von dort mit IPv4 zur Fritzbox und ins Internet und entsprechend zurück. Lediglich die Anfragen zur lokalen Fritzbox wurden von OpenWrt verworfen und das im Systemprotokoll protokolliert:

1
 

daemon.warn dnsmasq[3663]: possible DNS-rebind attack detected: fritz.box
 

Abhilfe brachte "service dnsmasq stop". Damit hatte der Spuk ein Ende.
Nun die Frage: macht der dnsmasq auch was sinnvolles in unserem Anwendungsfall oder kann der ganz weg?

Gruß
Rainer

[d11b]

Hallo zusammen,

auch ich muss mich nochmal einklinken. Ich bekomme unter Rocrail leider immer noch die Meldungen

1
2
 

17:18:50 Identified: rocnetid=2 class=Accessory vid=70 revision=14845 nrio=128 subip=13.221 nickname=[New RocNetNode]
17:18:50 Identified: rocnetid=2 class=Accessory vid=70 revision=14845 nrio=128 subip=13.221 nickname=[New RocNetNode]
 

Das endet halt immer in einem kurzen

1
 

power off, freeze clock
 

Ansonsten läuft aber alles ohne Unterbrechungen durch.

Im Rocrail-Forum hatte Rob gemeint, dass es mit meinem Linux (Ubuntu) zusammenhängen würde. Auf meinem Windows-PC bekomme ich in der Tat die Fehlermeldungen nicht. Mein Rocrail (Server und Client) ist aktuell (ich habe da oben die alte Meldung kopiert). Hat da jemand einen Tipp?

VG
Daniel

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1948231 time=1551722325 user_id=1332]
Der BaPi hatte in meinem IPv4-Netz dem Win einen IPv6-DNS-Eintrag untergejubelt, den der PC bevorzugte. Somit gingen die Namensanfragen vom PC über IPv6 an den BaPi und von dort mit IPv4 zur Fritzbox und ins Internet und entsprechend zurück. Lediglich die Anfragen zur lokalen Fritzbox wurden von OpenWrt verworfen und das im Systemprotokoll protokolliert:

1
 

daemon.warn dnsmasq[3663]: possible DNS-rebind attack detected: fritz.box
 

Abhilfe brachte "service dnsmasq stop". Damit hatte der Spuk ein Ende.
Nun die Frage: macht der dnsmasq auch was sinnvolles in unserem Anwendungsfall oder kann der ganz weg?
[/quote]
DNS Masqerading und DHCP (dnsmasq) sind normalerweise Teil von OpenWRT Images. Als reiner DHCP-Client natürlich überflüssig. ich habe vergessen es abzuwählen. Sorry. Ist behoben und im neuen Image nicht mehr vorhanden.

Gruß

Gerd

[bertr2d2]

Hallo Daniel,

Zitat

---

Hallo zusammen,

auch ich muss mich nochmal einklinken. Ich bekomme unter Rocrail leider immer noch die Meldungen

1
2
 

17:18:50 Identified: rocnetid=2 class=Accessory vid=70 revision=14845 nrio=128 subip=13.221 nickname=[New RocNetNode]
17:18:50 Identified: rocnetid=2 class=Accessory vid=70 revision=14845 nrio=128 subip=13.221 nickname=[New RocNetNode]
 

Das endet halt immer in einem kurzen

1
 

power off, freeze clock
 

Ansonsten läuft aber alles ohne Unterbrechungen durch.

Im Rocrail-Forum hatte Rob gemeint, dass es mit meinem Linux (Ubuntu) zusammenhängen würde. Auf meinem Windows-PC bekomme ich in der Tat die Fehlermeldungen nicht. Mein Rocrail (Server und Client) ist aktuell (ich habe da oben die alte Meldung kopiert). Hat da jemand einen Tipp?

---

die Meldung stammen aus dem RocNetNode Modul. Deaktiviere bitte die Zentralen aus dem Bereich. Dann sollten die Fehlermeldung nicht mehr auftreffen.

Die genaue Ursache ist mir immer noch ein Rätsel ...

Gruß

Gerd

[bertr2d2]

Hallo,

nicht Rocrail-Nutzer können diesen Beitrag getrost überspringen.

Der (Haupt)-Entwickler von Rocrail Rob Versluis hat die Sourcen aufgeräumt. Stand heute sind die Bibliotheken mcs2 und mgbox nicht mehr verfügbar. Stattdessen ist jetzt mbus Standard Bibliothek zur Nutzung der Gleisbox. Ich habe es getestet: es funktioniert alles wie vorher. Ich habe eine Beispiel-Konfiguration dem Image und dem Rocrail Paket beigelegt. Ich nutze dabei weiterhin can2lan über TCP Port 15731 um möglichst kompatibel zu anderen Modellbahn-Software zu bleiben.
Wer nur Rocrail nutzen will kann can2lan auch terminieren:

1
2
 

/etc/init.d/can2lan stop
/etc/init.d/can2lan disable
 

und Rocrail auf SocketCAN umstellen.

Gruß

Gerd

PS: Wer Rocrail nutzen will startet den Service über:

1
2
3
4
5
 

/etc/init.d/rocnetnode enable
/etc/init.d/rocnetnode start
/etc/init.d/rocrail enable
/etc/init.d/rocrail start # dauert ein paar Sekunden
 
 

Das Kopieren aus dem Root-Verzeichnis ist nicht mehr notwendig.

[Rainer Müller]

Hallo Gerd,

Zitat

---

Wie der Zufall es will habe ich in den letzten Tagen schon geschaut, wie ich den BPi auf eine aktuelles Linux bringen kann. Dazu habe ich ein aktuelles (HEAD) OpenWRT genommen und auf Linux 4.19.x gestellt. Das Ergebnis als Image (mit allen üblichen Softwarepaketen) ist hier zu finden: http://lnxpps.de/bpi/bin/openwrt-sunxi-c...-sdcard.img.zip (Entpacken vor dem Schreiben nicht vergessen )
Update Möglichkeit für Rocrail/can2lan etc. pp. habe ich aber noch nicht eingerichtet - aber es kann getestet werden. Resonanz ist ausdrücklich erwünscht.
...
Gruß

Gerd

---

in der Zwischenzeit habe ich deine OpenWRT-Version vom 9.6.19 im Test und bin erst mal begeistert davon, dass da jetzt ein gcc samt aller benötigter Abhängigkeiten mit drin ist, das erleichtert einfache Änderungen auf der Zielplattform.

Ich hab auch noch ein paar Kleinigkeiten anzumerken, die aber wohl außer mich niemand stören und auch mich nicht wirklich, also niedere Priorität. Eigentlich nur, dass die Punkte mal aufgeschrieben sind, weil ich auch immer vergesslicher werde.

Der basrcpd versucht (derzeit zwar nicht mehr, aber ab der geplanten Version 1907 wieder) den Neuanmeldezähler in "/etc/srcpd.regcount" zu speichern (was jedoch dem read-only-Prinzip entgegensteht). Allerdings läuft der basrcpd unter dem User "daemon", der im /etc-Verzeichnis nicht schreiben darf. Man muss die Datei also händisch anlegen und dem daemon die erforderlichen Schreibrechte geben, beispielsweise:

1
2
3
4
 

touch /etc/srcpd.regcount
chown daemon /etc/srcpd.regcount
 
 

Die Möglichkeit einer Fernsteuerung würde ich sehr begrüßen, doch hat uns der Maecan-Server wohl etwas verwirrt. Die ältere js-Version lässt die Loksteuerung (für mich Hauptmekmal) schon zu, die neuere C-Version dagegen noch nicht, obwohl sie mir vom Design her fortschrittlicher erscheint. Im aktuellen Image ist nun die C-Version (/usr/bin/maecanserver) drin, aber die alte nicht mehr, dafür wird im "can2lan"-Initskript versucht, den alten Server samt dem dafür notwendigen "can2udp" zu starten. Beide Alternativen können aber gar nicht laufen, weil die statischen Teile (Maecan-html-Zweige) sowie ein Verweis darauf in der httpd-Konfigurationsdatei fehlen.
Falls Maxi mitliest: sind die html-Zweige beider Serverversionen kompatibel oder muss man die beim Serverwechsel mit austauschen?

Zuletzt noch zu einem Punkt, der wohl schon länger so ist: kommt über ie IP-Schnittstelle ein verpacktes CAN-Paket mit der "Anforderung lokstat", sucht can2lan nach einer Datei "lokomotive.sr2", im Image heisst die entsprehende Datei aber "lokstat.sr2". Bei den anderen .sr2-Dateien ist das entsprechend. Ist das Absicht?


Gruß
Rainer

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1987791 time=1562009340 user_id=1332]
Hallo Gerd,

Zitat

---

Wie der Zufall es will habe ich in den letzten Tagen schon geschaut, wie ich den BPi auf eine aktuelles Linux bringen kann. Dazu habe ich ein aktuelles (HEAD) OpenWRT genommen und auf Linux 4.19.x gestellt. Das Ergebnis als Image (mit allen üblichen Softwarepaketen) ist hier zu finden: http://lnxpps.de/bpi/bin/openwrt-sunxi-c...-sdcard.img.zip (Entpacken vor dem Schreiben nicht vergessen )
Update Möglichkeit für Rocrail/can2lan etc. pp. habe ich aber noch nicht eingerichtet - aber es kann getestet werden. Resonanz ist ausdrücklich erwünscht.
...
Gruß

Gerd

---

in der Zwischenzeit habe ich deine OpenWRT-Version vom 9.6.19 im Test und bin erst mal begeistert davon, dass da jetzt ein gcc samt aller benötigter Abhängigkeiten mit drin ist, das erleichtert einfache Änderungen auf der Zielplattform.
[/quote]im neuesten Image habe ich noch ein paar Bibliotheken hinzugefügt.

Zitat

---

Ich hab auch noch ein paar Kleinigkeiten anzumerken, die aber wohl außer mich niemand stören und auch mich nicht wirklich, also niedere Priorität. Eigentlich nur, dass die Punkte mal aufgeschrieben sind, weil ich auch immer vergesslicher werde.

Der basrcpd versucht (derzeit zwar nicht mehr, aber ab der geplanten Version 1907 wieder) den Neuanmeldezähler in "/etc/srcpd.regcount" zu speichern (was jedoch dem read-only-Prinzip entgegensteht). Allerdings läuft der basrcpd unter dem User "daemon", der im /etc-Verzeichnis nicht schreiben darf. Man muss die Datei also händisch anlegen und dem daemon die erforderlichen Schreibrechte geben, beispielsweise:

1
2
3
4
 

touch /etc/srcpd.regcount
chown daemon /etc/srcpd.regcount
 
 

---

Ist jetzt im neuesten Image mit drin.

Zitat

---

Die Möglichkeit einer Fernsteuerung würde ich sehr begrüßen, doch hat uns der Maecan-Server wohl etwas verwirrt. Die ältere js-Version lässt die Loksteuerung (für mich Hauptmekmal) schon zu, die neuere C-Version dagegen noch nicht, obwohl sie mir vom Design her fortschrittlicher erscheint. Im aktuellen Image ist nun die C-Version (/usr/bin/maecanserver) drin, aber die alte nicht mehr, dafür wird im "can2lan"-Initskript versucht, den alten Server samt dem dafür notwendigen "can2udp" zu starten. Beide Alternativen können aber gar nicht laufen, weil die statischen Teile (Maecan-html-Zweige) sowie ein Verweis darauf in der httpd-Konfigurationsdatei fehlen.
Falls Maxi mitliest: sind die html-Zweige beider Serverversionen kompatibel oder muss man die beim Serverwechsel mit austauschen?

---

Da habe ich auch den Überblick verloren ... Hoffen wir das Maxi nochmal antwortet. Ich habe jetzt mal den alten Server drin.

Zitat

---

Zuletzt noch zu einem Punkt, der wohl schon länger so ist: kommt über ie IP-Schnittstelle ein verpacktes CAN-Paket mit der "Anforderung lokstat", sucht can2lan nach einer Datei "lokomotive.sr2", im Image heisst die entsprehende Datei aber "lokstat.sr2". Bei den anderen .sr2-Dateien ist das entsprechend. Ist das Absicht?

---

Ein Fehler meinerseits den ich korrigiert habe. Vielen Dank für den Hinweis. IMHO ist das nur für ein CS2 Kopplung notwendig. Das ist aber bisher nicht genutzt worden und wahrscheinlich deswegen nicht aufgefallen. Irgendwann, wenn ich mal viel Zeit habe, werde ich auch mal die Dateien mit Leben füllen

Gruß

Gerd