AuronX Geschrieben March 14, 2013 at 14:19 Geschrieben 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. Zitieren
ArcaneDraconum Geschrieben March 14, 2013 at 14:53 Geschrieben 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. Zitieren
Equinox Geschrieben March 14, 2013 at 15:14 Geschrieben 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. Zitieren
borg Geschrieben March 14, 2013 at 15:35 Geschrieben 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 Zitieren
Loetkolben Geschrieben March 14, 2013 at 16:07 Geschrieben 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 Zitieren
borg Geschrieben March 14, 2013 at 16:21 Geschrieben 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. Zitieren
Loetkolben Geschrieben March 14, 2013 at 16:39 Geschrieben 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 Zitieren
borg Geschrieben March 14, 2013 at 16:48 Geschrieben 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. Zitieren
Equinox Geschrieben March 14, 2013 at 17:01 Geschrieben 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. Zitieren
Loetkolben Geschrieben March 14, 2013 at 17:07 Geschrieben 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 Zitieren
borg Geschrieben March 14, 2013 at 17:23 Geschrieben 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 . Zitieren
benatweb Geschrieben March 14, 2013 at 17:52 Geschrieben 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... Zitieren
borg Geschrieben March 14, 2013 at 18:07 Geschrieben 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 Zitieren
Loetkolben Geschrieben March 14, 2013 at 18:14 Geschrieben 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 Zitieren
AuronX Geschrieben March 14, 2013 at 19:42 Autor Geschrieben 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? ^^ Zitieren
borg Geschrieben March 14, 2013 at 22:20 Geschrieben 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 . Zitieren
AuronX Geschrieben March 15, 2013 at 14:13 Autor Geschrieben 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 ^^ Zitieren
Loetkolben Geschrieben April 12, 2013 at 19:00 Geschrieben 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 Zitieren
AuronX Geschrieben April 13, 2013 at 10:34 Autor Geschrieben 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... Zitieren
Loetkolben Geschrieben April 18, 2013 at 18:06 Geschrieben 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 Zitieren
AuronX Geschrieben April 18, 2013 at 18:50 Autor Geschrieben 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 Zitieren
photron Geschrieben April 19, 2013 at 07:49 Geschrieben 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. Zitieren
Loetkolben Geschrieben April 19, 2013 at 12:12 Geschrieben 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 Zitieren
borg Geschrieben April 19, 2013 at 12:20 Geschrieben 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? Zitieren
photron Geschrieben April 19, 2013 at 12:24 Geschrieben 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. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.