Flashen per Commandline

AuronX · March 14, 2013 at 14:19

Hallo,

so wie ich das sehe, kann ich mein Brick doch bisher nur über den Brickv flashen, richtig?

Es wäre großartig, wenn dieser Teil auch über ein Commandline-Interface (neues Tool) verfügbar wäre.

So in der Art:

SHELL> flash-tool COM1 myImage.img

Das würde eine Integration in eine beliebige IDE, CI usw ermöglichen.

ArcaneDraconum · March 14, 2013 at 14:53

Der Umweg über den BrickV ist mir persönlich relativ egal. Ich finde nur sehr hinderlich, dass der Brick dabei per USB am Rechner hängen muss. Wenn das über's Netz gehen würde fände ich das ein echtes Must-Have. Schon wegen der Ausbauerei vom Stapel aus engen Gehäusen.

Equinox · March 14, 2013 at 15:14

Da kann ich ArcaneDraconum nur zustimmen. Für mich würde es auch reichen, wenn man den BrickV so erweitert, dass er auch über WLAN flashen kann und der MasterBrick nicht mehr von Hand in einen speziellen Flash-Modus versetzt werden muss.

borg · March 14, 2013 at 15:35

Flashen über Commandline ist definitiv sinnvoll, sollten wir auf Dauer anbieten.

Zum Thema flashen über WIFI siehe hier: http://www.tinkerunity.org/forum/index.php/topic,1440.0.html

Loetkolben · March 14, 2013 at 16:07

Applaus, auch dieses Thema ist wieder da: "Tinkerforge: Flashen per Kommandozeile ist auf der TODO Liste."

Zu dem Thema im englischen Beitrag:

Warum kann der Updater nicht im Ram laufen und sich Byteblock fuer Byteblock (der gerade geflasht werden soll) vom entfernten Updatetool (Brickv) holen?

Wie sieht es mit einem Bricklet mit 4mbit I2C EEPROM aus, bzw. ein Breakoutbricklet mit EEPROM?

Da koennte man 3 Fliegen mit einer Klappe schlagen. Zum einen kann man das Bricklet zum updaten nehmen (FW zwischenspeichern), zum zweiten als Datenspeicher nutzen (beiOnDeviceprogrammen) und zum dritten koennte man dort eigenen Brickletcode unterbringen wenn man am Breakout noch HW (wie Sensoren) anschliesst.

Wenn es unbeding noch einen Tastendruck am Brick geben muss (Resetimpuls), dann kommt auf das Breakoutbricklet noch ein Transistor der diesen Resetimpuls (like Monoflop) gibt.

Ich bin mir sicher das es da eine Loesung gibt.

Der Loetkolben

borg · March 14, 2013 at 16:21

Warum kann der Updater nicht im Ram laufen und sich Byteblock fuer Byteblock (der gerade geflasht werden soll) vom entfernten Updatetool (Brickv) holen?

Zum einen bin ich mir nicht sicher ob der komplette WIFI Code + der ganze Code den ich zum flashen brauche überhaupt in den RAM passt. Zum anderen wäre das extremst anfällig. In diesem Modus müsste ich auf jedenfall alle globalen Variablen und Buffer usw im RAM überschreiben, d.h. es gibt kein zurück aus dem Modus! Ein Verbindungsabbruch o.ä. würde sofortig zu einem gebricktem Brick führen .

Eine Firmware über Funk updaten kann man eigentlich nur ohne Risiko machen wenn man die komplette Firmware einmal irgendwo zwischenspeichern kann. Ansonsten macht das mehr Probleme als es löst.

Loetkolben · March 14, 2013 at 16:39

Hallo Borg.

würde sofortig zu einem gebricktem Brick führen

Zum Glueck nicht wirklich. Dann bliebe ja noch die manuelle Wiederbelebung per USB, oder?

Eine Firmware über Funk updaten kann man eigentlich nur ohne Risiko machen wenn man die komplette Firmware einmal irgendwo zwischenspeichern kann.

Yep, siehe Vorschlag 2. Breakoutbricklet-Plus: 4MBit fuer Remoteupdate und weitere Experimente. Loete ich auch gerne selbst wenn ihr sagt wie die Beschaltung sein muss.

Auch so, an dieser Stelle nochmals die Frage: Kann man auch Programmcode aus einem per I2C angeschlossenen EEPROM laufen lassen?

Ich bin mir sicher, dass es da eine Loesung geben wird. Waere das mal was fuer einen Betatest?

Der Loetkolben

borg · March 14, 2013 at 16:48

würde sofortig zu einem gebricktem Brick führen
Zum Glueck nicht wirklich. Dann bliebe ja noch die manuelle Wiederbelebung per USB, oder?

Jo, über USB kannst du immer flashen.

Yep, siehe Vorschlag 2. Breakoutbricklet-Plus: 4MBit fuer Remoteupdate und weitere Experimente. Loete ich auch gerne selbst wenn ihr sagt wie die Beschaltung sein muss.

Naja in Theorie geht sowas sicherlich. Es würde sich vermutlich anbieten die SD Card Extension die wir fürs On-Device-Logging machen wollen dafür zu nehmen.

Aber du musst halt überlegen wie viel Aufwand das ist und welchen nutzen es hat. Ich denke es haben ca. 5% unserer Kunden eine WIFI Extension, wenn wir großzügig sind und sagen, dass 20% davon nochmal Geld ausgeben würden für ein "Zwischenspeicher-Bricklet" mit dem man dann über WIFI flashen kann. Dazu kommt der ganz schön große Aufwand das umzusetzen. Es ist halt schwierig das zu rechtfertigen, wenn noch so viele TODOs offen sind die fast alle TF Nutzer betreffen .

Auch so, an dieser Stelle nochmals die Frage: Kann man auch Programmcode aus einem per I2C angeschlossenen EEPROM

Das ist mit dem Microcontroller den wir verwenden nicht möglich.

Equinox · March 14, 2013 at 17:01

Es würde sich vermutlich anbieten die SD Card Extension die wir fürs On-Device-Logging machen wollen dafür zu nehmen.

Dann wäre es ja keine eigene Neuentwicklung und man könnte "Synergie"-Effekte nutzen. Ich würde das super finden!

... mit dem man dann über WIFI flashen kann.

Es wäre ja nicht nur WiFi, sondern auch über Ethernet. Und wenn das mit der SD-Card kombiniert wird, die ja praktisch von allen gebraucht wird, die OnDevice nutzen wollen (und das soll ja die Mehrheit sein), dann würde sich das schon lohnen.

Loetkolben · March 14, 2013 at 17:07

Hallo borg,

danke fuer die Antworten, aber bei der Berechnung fehlen die "anderen" Remoteupdater.

Aber du musst halt überlegen wie viel Aufwand das ist und welchen nutzen es hat. Ich denke es haben ca. 5% unserer Kunden eine WIFI Extension, wenn wir großzügig sind und sagen, dass 20% davon nochmal Geld ausgeben würden für ein "Zwischenspeicher-Bricklet" mit dem man dann über WIFI flashen kann.

Deinen Ausfuehrungen kann ich soweit zustimmen, dass es sich rechnen muss. Ein "Support"-Bricklet fuer das Flashen muesste auch noch andere Aufgaben uebernehmen koennen, ansonsten waere es sichlich unwirtschaftlich.

Bei dem Remote-Updatern geht es aber nicht nur um die WLAN Fraktion.

Auch wenn das Brick in der Ferne an einem PC/Raspberry/Linux haengt waere ein Remoteupdate mehr als wuenschenswert.

BTW: "SD Card Extension"? Ich dachte das wird ein "SD Card Bricklet". 4 Draehte und los gehts. Das ihr "Software" koennt ist unbestritten!

Der Loetkolben

borg · March 14, 2013 at 17:23

Vielleicht wird es auch ein SD Card Bricklet, ich habe da so eine ganz bestimmte "auto-logging Funktionsweise" im Kopf. Dafür wäre die SD Karte ein Interface, genauso wie USB, WIFI oder RS485.

Das ist aber noch nicht zuende gedacht, liegt ja auch noch in ferner Zukunft. Erstmal brauchen wir überhaupt On Device Programming .

benatweb · March 14, 2013 at 17:52

Bei dem Remote-Updatern geht es aber nicht nur um die WLAN Fraktion.
Auch wenn das Brick in der Ferne an einem PC/Raspberry/Linux haengt waere ein Remoteupdate mehr als wuenschenswert.

Mit einem möglichen Flashen per Commandline wär das kein Problem mehr, der Brick hängt ja in dem Fall an USB, muss man sich bloß noch per SSH auf den entfernten Rechner verbinden. Drauf drücken muss man natürlich trotzdem noch, schätze das lässt sich nicht vermeiden...

borg · March 14, 2013 at 18:07

Mh, also wer sich daran schonmal versuchen will bevor wir dazu gekommen sind: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/samba.py

Was gemacht werden müsste:

* Alles was mit Qt zu tun hat rausschmeißen

* Aus flash(self, firmware, imu_calibration, lock_imu_calibration_pages, progress) alles entfernen was mit "progress" zu tun hat (ist GUI kram).

* Flash aufrufen mit firmware=geladene Firmware, imu_calibration=None und lock_imu_calibration_pages=None

Loetkolben · March 14, 2013 at 18:14

Hallo benatweb,

hier nicht boese gemeinte Antworten, sondern nur Hinweise woran es scheitern koennte.

sich bloß noch per SSH

Bei Tante Erna am PC?

Drauf drücken muss man natürlich trotzdem noch, schätze das lässt sich nicht vermeiden...

Who is man? Tante Erna? Soll dort dann noch Treiber installiert werden?

Apropos Resetknopf: Man koente aber eine der 4 Status LED "misbrauchen" um mit einem Highpegel den Resetknopf zu druecken.

Mein Ziel ist es remote zu updaten ohne dass jemand im Normalfall, sagen wir mal 90%, eingreifen muss.

@borg: Super! - Das wird bestimmt eine spannende Sache.

@all: Vielleicht kann das jemand mal uebersetzen, da mir das notwendige Wissen fehlt. Gerne fuer Debian 32 bit.

Der Loetkolben

AuronX · March 14, 2013 at 19:42

@Loeti: Es muss ja nicht SSH sein. Du musst halt irgendwie aus der Ferne dieses Tool aufrufen und ihm die passende Datei liefern. Das bringt auf jeden Fall schonmal neue Möglichkeiten, auch wenn es noch nicht vollkommen von TF bequem angeboten wird. Beim Drücken des Knopfes bin ich allerdings auch überfragt ^^ Aber ich vermute mal jemand Lötfreudiges wie du kann doch sicherlich "mal eben" nen IO4 mit dem Reset-Taster verbinden oder? Dann kannst du mit dem IO4 nen Brick-Suizid begehen...

Dass es den Commandline-Wunsch schonmal gab ist mir übrigens glatt entgangen ^^

@borg: Wenn ich die samba-lib modifiziere und Unsinn mache kann mein Brick trotzdem nicht gebrickt werden oder? ^^

borg · March 14, 2013 at 22:20

@borg: Wenn ich die samba-lib modifiziere und Unsinn mache kann mein Brick trotzdem nicht gebrickt werden oder? ^^

Der eigentliche Bootloader ist read only und sobald du den Erase Knopf drückst während du USB rein steckst kommst du auf jeden Fall in den Bootloader. Sollte also nichts passieren können .

AuronX · March 15, 2013 at 14:13

Erster Draft:

https://github.com/Tinkerforge/brickv/pull/7

Habe es noch nciht ausprobiert, könnte also auch noch vom Interpreter abgelehnt werden. Ich muss zunächst noch die requirements installieren und es dann wirklich ausprobieren ^^

Loetkolben · April 12, 2013 at 19:00

Hallo zusammen,

so langsam komme ich auf die Protokoll v2 Zielgerade und wollte fragen ob es zum Commandline flashing schon etwas neues gibt?

Ich selbst bin nicht in der Lage das Tool zu "bauen".

Viele Gruesse

Der Loetkolben

AuronX · April 13, 2013 at 10:34

Habe in dem Thread gar nix mehr geschrieben ^^

Also mein Pull Request ist jetzt im offiziellen Brickv-Repo enthalten, das heißt es liegt jetzt an TF das eventuell auch in Binärform zu veröffentlichen.

Bis dahin kannst du dir auf Github den Source-Code als ZIP-Datei herunterladen, das entpacken und im Verzeichnis src/brickv das Python script flash-brick-cli.py ausführen:

> python flash-brick-cli.py --help
usage: flash-brick-cli.py [-h] -p PORT -f FILE

Used to flash firmware onto a brick

optional arguments:
  -h, --help            show this help message and exit
  -p PORT, --port PORT  the name of the serial-port the brick is connected to
  -f FILE, --file FILE  The path to the firmware-file

Hoffe das hilft dir schonmal weiter. Derzeit unterstützt das Tool halt nur das flashen einer Datei aufs Brick, das Herunterladen des Images müsstest du noch selbst erledigen...

Loetkolben · April 18, 2013 at 18:06

Hallo AuronX,

vielen Dank fuer Deine Muehen!

Nachdem ich mir mehrere Python-Fragezeichen aus dem Gesicht gewischt habe und

apt-get install python-serial
apt-get install python-argparse

nachinstalliert habe konnte ich mit folgendem Aufruf

# /usr/bin/python flash-brick-cli.py -p /dev/bus/usb/002/002 -f brick_master_firmware_2_0_6.bin
(Error) Could not connect to Brick: No Brick in Bootloader found

recht weit kommen.

Ist die Angabe des /devices in dieser Schreibweise richtig?

Ich kann den Livetest erst spaeter machen, da man immer noch nicht remote flaschen kann! - Tinkerforge sollten einen Port/Bit zum Reset/Erase Knopf umbauen, z.B. eine der LEDs.

Der Loetkolben

AuronX · April 18, 2013 at 18:50

Ich würde vermuten, dass ein serieller Port unter linux so aussehen kann

edit: Und wie sich herausstellt, ist diese Vermutung falsch!

Bei mir (Windows) habe ich an diese Stelle COM1 geschrieben ^^

Das mit python-serial und argparse habe ich schon wieder vergessen, sorry. Bei mir war argparse glaube ich vor-installiert (mit python zusammen), serial musste ich mir im Netz suchen... da lobe ich mir das gute alte apt-get

photron · April 19, 2013 at 07:49

# /usr/bin/python flash-brick-cli.py -p /dev/bus/usb/002/002 -f brick_master_firmware_2_0_6.bin
(Error) Could not connect to Brick: No Brick in Bootloader found

/dev/bus/usb/002/002 ist das USB Device an sich. Das ist hier nicht richtig. Du brauchst da den seriellen Port den der Bootloader des Bricks über USB anbietet. Typischerweise taucht der als /dev/ttyACM0 oder /dev/ttyUSB0 auf.

Loetkolben · April 19, 2013 at 12:12

Hallo photron,

danke fuer die Info. Ich konnte es gestern noch nicht ausprobieren. Habe gerade "remote" auf den Rechner geschaut finde das nicht. Lediglich "ttyS0" bis "ttyS3". Ist eines davon das Device und wenn ja welches? $:-\$

Entschuldigung fuer den langen Output. Ich habe ihn schon mit [...] eingekuerzt, aber ich wollte keine wichtige Info zurueckhalten.

/dev# ls -la
insgesamt 4
drwxr-xr-x 17 root root        3060 11. Apr 21:24 .
drwxr-xr-x 23 root root        4096  3. Apr 21:04 ..
crw-rw----  1 root video    10, 175 11. Apr 21:24 agpgart
crw-------  1 root root     10, 235 11. Apr 21:24 autofs
drwxr-xr-x  2 root root         300 11. Apr 21:24 block
drwxr-xr-x  2 root root          60 11. Apr 21:24 bsg
crw-------  1 root root     10, 234 11. Apr 21:24 btrfs-control
drwxr-xr-x  3 root root          60 11. Apr 21:24 bus
drwxr-xr-x  2 root root        2580 11. Apr 21:24 char
crw-------  1 root root      5,   1 11. Apr 21:25 console
lrwxrwxrwx  1 root root          11 11. Apr 21:24 core -> /proc/kcore
drwxr-xr-x  2 root root          60 11. Apr 21:24 cpu
crw-------  1 root root     10,  62 11. Apr 21:24 cpu_dma_latency
drwxr-xr-x  6 root root         120 11. Apr 21:24 disk
drwxr-xr-x  2 root root          80 11. Apr 21:24 dri
crw-rw----  1 root video    29,   0 11. Apr 21:24 fb0
lrwxrwxrwx  1 root root          13 11. Apr 21:24 fd -> /proc/self/fd
crw-rw-rw-  1 root root      1,   7 11. Apr 21:24 full
crw-rw----  1 root fuse     10, 229 11. Apr 21:24 fuse
crw-------  1 root root     10, 228 11. Apr 21:24 hpet
prw-------  1 root root           0 11. Apr 21:24 initctl
drwxr-xr-x  2 root root          40 11. Apr 21:24 .initramfs
drwxr-xr-x  3 root root         140 11. Apr 21:24 input
crw-------  1 root root      1,  11 11. Apr 21:24 kmsg
srw-rw-rw-  1 root root           0 11. Apr 21:24 log
brw-rw----  1 root disk      7,   0 11. Apr 21:24 loop0
[...]
brw-rw----  1 root disk      7,   7 11. Apr 21:24 loop7
crw-------  1 root root     10, 237 11. Apr 21:24 loop-control
lrwxrwxrwx  1 root root           9 11. Apr 21:24 MAKEDEV -> /bin/true
drwxr-xr-x  2 root root          60 11. Apr 21:24 mapper
crw-------  1 root root     10, 227 11. Apr 21:24 mcelog
crw-r-----  1 root kmem      1,   1 11. Apr 21:24 mem
drwxr-xr-x  2 root root          60 11. Apr 21:24 net
crw-------  1 root root     10,  61 11. Apr 21:24 network_latency
crw-------  1 root root     10,  60 11. Apr 21:24 network_throughput
crw-rw-rw-  1 root root      1,   3 11. Apr 21:24 null
crw-------  1 root root      1,  12 11. Apr 21:24 oldmem
crw-r-----  1 root kmem      1,   4 11. Apr 21:24 port
crw-------  1 root root    108,   0 11. Apr 21:24 ppp
crw-------  1 root root     10,   1 11. Apr 21:24 psaux
crw-rw-rw-  1 root root      5,   2 19. Apr 14:03 ptmx
drwxr-xr-x  2 root root           0 11. Apr 21:24 pts
crw-rw-rw-  1 root root      1,   8 11. Apr 21:24 random
lrwxrwxrwx  1 root root           4 11. Apr 21:24 root -> sda1
lrwxrwxrwx  1 root root           4 11. Apr 21:24 rtc -> rtc0
crw-------  1 root root    254,   0 11. Apr 21:24 rtc0
brw-rw----  1 root disk      8,   0 11. Apr 21:24 sda
brw-rw----  1 root disk      8,   1 11. Apr 21:24 sda1
brw-rw----  1 root disk      8,   2 11. Apr 21:24 sda2
brw-rw----  1 root disk      8,   3 11. Apr 21:24 sda3
brw-rw----  1 root disk      8,   5 11. Apr 21:24 sda5
drwxrwxrwt  2 root root          40 11. Apr 21:24 shm
crw-------  1 root root     10, 231 11. Apr 21:24 snapshot
drwxr-xr-x  3 root root         240 11. Apr 21:24 snd
lrwxrwxrwx  1 root root          24 11. Apr 21:24 sndstat -> /proc/asound/oss/sndstat
lrwxrwxrwx  1 root root          15 11. Apr 21:24 stderr -> /proc/self/fd/2
lrwxrwxrwx  1 root root          15 11. Apr 21:24 stdin -> /proc/self/fd/0
lrwxrwxrwx  1 root root          15 11. Apr 21:24 stdout -> /proc/self/fd/1
crw-rw-rw-  1 root root      5,   0 11. Apr 21:24 tty
crw-------  1 root root      4,   0 11. Apr 21:24 tty0
crw-------  1 root root      4,   1 11. Apr 21:25 tty1
crw-------  1 root root      4,  10 11. Apr 21:24 tty10
[...]
crw-------  1 root root      4,   7 11. Apr 21:24 tty7
crw-------  1 root root      4,   8 11. Apr 21:24 tty8
crw-------  1 root root      4,   9 11. Apr 21:24 tty9
crw-rw----  1 root dialout   4,  64 11. Apr 21:24 ttyS0
crw-rw----  1 root dialout   4,  65 11. Apr 21:24 ttyS1
crw-rw----  1 root dialout   4,  66 11. Apr 21:24 ttyS2
crw-rw----  1 root dialout   4,  67 11. Apr 21:24 ttyS3
drwxr-xr-x  7 root root         160 11. Apr 21:24 .udev
crw-------  1 root root     10, 223 11. Apr 21:24 uinput
crw-rw-rw-  1 root root      1,   9 11. Apr 21:24 urandom
crw-------  1 root root      7,   0 11. Apr 21:24 vcs
crw-------  1 root root      7,   1 11. Apr 21:24 vcs1
[...]
crw-------  1 root root      7,   6 11. Apr 21:24 vcs6
crw-------  1 root root      7, 128 11. Apr 21:24 vcsa
crw-------  1 root root      7, 129 11. Apr 21:24 vcsa1
[...]
crw-------  1 root root      7, 134 11. Apr 21:24 vcsa6
crw-------  1 root root     10,  63 11. Apr 21:24 vga_arbiter
prw-r-----  1 root adm            0 19. Apr 14:02 xconsole
crw-rw-rw-  1 root root      1,   5 11. Apr 21:24 zero

# lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 16d0:063d GrauTec 
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ein anderer PC an dem auch ein Brick und ein Datenlogger haengt sieht so aus:

[...]
crw-rw---- 1 root dialout   4,  64 18. Apr 23:09 ttyS0
crw-rw---- 1 root dialout   4,  65 18. Apr 23:09 ttyS1
crw-rw---- 1 root dialout   4,  66 18. Apr 23:09 ttyS2
crw-rw---- 1 root dialout   4,  67 18. Apr 23:09 ttyS3
crw-rw---- 1 root dialout 188,   0 18. Apr 23:09 ttyUSB0
[...]
# lsusb
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 16d0:063d MCS 
Bus 003 Device 003: ID 0403:e0ec Future Technology Devices International, Ltd 
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Hier gehe ich aber davon aus, dass "ttyUSB0" wohl der Datenlogger ist?!

Der Loetkolben

borg · April 19, 2013 at 12:20

Wenn der Brick im Bootloader ist müsste da bei lsusb stehen:

Bus 001 Device 115: ID 03eb:6124 Atmel Corp. at91sam SAMBA bootloader

Zumindest das VID:PID Paar sollte dabei sein (03eb:6124). Für mich sieht es nicht so aus als wäre da ein Brick im Bootloader angeschlossen .

Was sagt dmesg?

photron · April 19, 2013 at 12:24

Loetkolben, in beiden lsusb ausgaben ist 16d0:063d als VID:PID drin. Das ist der Brick normal gestartet, er ist nicht im Bootloader.

Flashen per Commandline

Recommended Posts

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Link zu diesem Kommentar

Share on other sites

Join the conversation