Hello, Guest the thread was called554 times and contains 23 replays

last post from strik at the

ZoomFloppy unter Linux mit OpenCBM Version 0.4.99.103.

  • Während der Feiertage hatte ich mal wieder etwas Zeit, mein CBM Equipment auszupacken und zu testen. Und siehe da, die ZoomFloppy läuft nicht mehr mit dem aktuellen OpenCBM, welches ich vom git repo https://github.com/OpenCBM/OpenCBM gezogen und compiliert habe. Die ZoomFloppy hängt bei allen cbmctrl Kommandos (außer reset) bei:


    Code
    1. [XUM1541] xum1541_wait_status checking for status
    2. BULK SUBMIT

    An meiner Hardware hat sich seit dem letzten Test 2020 nichts geändert. Das Problem habe ich mit meiner alten ZoomFloppy, und einer neu erworbenen jungfräulichen (kein Firmware update) ZoomFloppy reproduzieren können. Natürlich gab es seit 2020 einige Linux Mint Updates. Hat irgend einer von Euch OpenCBM mit der aktuellen Version 0.4.99.103 und einer ZoomFloppy unter Linux Mint oder Ubuntu laufen?

    Was bei mir funktioniert ist die OpenCBM Version 0.4.99.99. Und meine XU1541 funktioniert problemlos mit OpenCBM Version 0.4.99.103 und der gleichen Hardware, dem gleichen OS, den gleichen Kabeln/USB Ports .

    PS: Ich habe schon strik direkt per PN gefragt, er scheint aber die letzten Tage offline zu sein.

  • Ich habe an meiner Zoomfloppy mal ein Firmware Update gemacht auf Version 8, das lief mit der älteren Opencbm auch nicht.


    Um OpenCBM Version 0.4.99.99 mit XUM1541 Firmware 8 testen zu können muss der Funktionsaufruf xum1541_check_version() in xum1541.c entfernt werden - ansonsten bekommst Du eine Fehlermeldung.

  • Um OpenCBM Version 0.4.99.99 mit XUM1541 Firmware 8 testen zu können muss der Funktionsaufruf xum1541_check_version() in xum1541.c entfernt werden - ansonsten bekommst Du eine Fehlermeldung.

    Weil das keine unterstützte Kombination ist.

    Erst eine neuere OpenCBM-Version hat die Möglichkeit erhalten, mit mehreren Firmware-Versionen zu arbeiten. Uns ist klar, dass viele ZF auf Version 7 stehen und wohl kein Update erfahren werden. Daher können diese VErsionen (>0.4.99.100, glaube ich) mit 7 oder 8 umgehen.


    Die 0.4.99.99 kann es eben nicht. Das ist gewollt so. Das Entfernen eines Tests ist da nicht unbedingt hilfreich.


    Dieses Verhalten könnte auch ein Grund sein, auf neuere OpenCBM-Versionen zu wechseln.

  • Quote

    Dieses Verhalten könnte auch ein Grund sein, auf neuere OpenCBM-Versionen zu wechseln.

    Mein Problem: alles über OpenCBM Version 0.4.99.99 funktioniert bei mir nicht - nicht mit xum1541 Firmware 7 und schon gar nicht mit Firmware 8. Ich habe mir vor Wochen zur Überprüfung des Problems sogar eine neue ZoomFloppy gekauft, die mit Firmware 8 ausgeliefert wurde. Auch diese ZoomFloppy funktioniert nicht mit OpenCBM Versionen >0.4.99.100.

  • Ich habe den XUM1541 mit Firmware 8 hier und die SW-Version 0.4.99.103. Ich schaue morgen (ähhh heute ;) ) mal, ob's bei mir noch funzt.

    Hab zwar ArchLinux - das macht zu Ubuntu und Co. aber keinen großen Unterschied was das USB- und Treiber Handling angeht ....

    was sagt bei Dir denn:

    Code
    1. xum1541cfg devinfo

    ??

  • Um OpenCBM Version 0.4.99.99 mit XUM1541 Firmware 8 testen zu können muss der Funktionsaufruf xum1541_check_version() in xum1541.c entfernt werden - ansonsten bekommst Du eine Fehlermeldung.

    interessant. Mein XUM1541 hat auch die 0.8er Firmware drauf. Auf meinem Laptop (Archlinux) läuft opencbm 0.4.99.99 - ohne Probleme mit der 0.8er Firmware (kompiliert wurde es in 2019).

    Auf meinem Desktop-PC habe ich opencbm_0.4.99.99 kompiliert und da meckert er Rum wegen der zu hohen Firmware-Version - hab die Funktion und die Auswertung der Funktion mal auskommentiert und nun läuft die 0.8er Firmware auch auf meinem Desktop-PC mit opencbm 0.4.99.99.


    Wie auch immer - die 0.4.99.103 bekomme auch ich nicht zum Laufen - auf keinem Rechner. Das Comilieren und Installieren läuft ohne Fehler, aber das Device lässt sich nicht ansprechen. Nur ein "cbmctrl reset" ist möglich was mir sagt, dass die USB-Verbindung eigentlich funzt. Der RESET macht aber auch nur einen PIN des AVRs kurz auf LOW, da fließen ja keine Daten. Irgendwas wurde wohl bei der 0.4.99.103er Version von OpenCBM kauputt optimiert ....

    Dieses Verhalten könnte auch ein Grund sein, auf neuere OpenCBM-Versionen zu wechseln.

    und wenn die 0.4.99.103er Version von open cbm sich aufhängt, wenn ich den Befehl "cbmctrl status 8" absetze, was mache ich dann ?

    Warten auf die 104er Version ?

  • Wie auch immer - die 0.4.99.103 bekomme auch ich nicht zum Laufen - auf keinem Rechner. Das Comilieren und Installieren läuft ohne Fehler, aber das Device lässt sich nicht ansprechen.

    Hängst du bitte mal die Ausgabe von XUM1541_DEBUG=9 LIBUSB_DEBUG=9 cbmctrl status 8 mit der .103 an? (Ich nehme an, eine neue Firmware hast du nicht geflasht?)


    Wie bist du denn an die Sourcen gekommen? Aus git ausgecheckt (468084f8)? Falls ja, probierst du dann bitte mal, ob sich mit der .102 (eedaa3f1) was ändert?


    Läuft der Desktop auch unter Arch Linux?

  • Läuft der Desktop auch unter Arch Linux?

    ja

    Linux pcc2q 5.15.14-1-lts #1 SMP Tue, 11 Jan 2022 15:37:45 +0000 x86_64 GNU/Linux

    Wie bist du denn an die Sourcen gekommen?

    einfach das tar.gz hier heruntergeladen und entpackt. Da gibts aber nur die .99 und die .103

    hab jetzt mal das git geclont und gebaut und installiert und mein XUM1541 angequatcht mit folgendem Ergebnis:

    Code
    1. XUM1541_DEBUG=9
    2. LIBUSB_DEBUG=9
    3. xum1541cfg devinfo
    4. xum1541 device, model 2 (ZOOMFLOPPY), firmware version 8
    5. cbmctrl -V
    6. cbmctrl version 0.4.99.103, built on Jan 15 2022 at 19:28:23
    7. # ab hier bleibt er dann hängen, was er bei der version .99 nicht tut:
    8. cbmctrl status 8


    (Ich nehme an, eine neue Firmware hast du nicht geflasht?)

    doch, in 2020 - die Verion 8.

    Die Frage ist, ob es die Richtige für mein Gerätwar, es gibt ja 3 Firmware-Hexfiles:

    xum1541-PROMICRO_7406-v08.hex

    xum1541-PROMICRO-v08.hex

    xum1541-ZOOMFLOPPY-v08.hex


  • einfach das tar.gz hier heruntergeladen und entpackt. Da gibts aber nur die .99 und die .103

    Ok. Ich habe eben zur Kontrolle auch genau diese Sourcen heruntergeladen und gebaut -> funktioniert bei mir (mit einem Pro-Micro basierten Gerät, eine ZF habe ich nicht, ich glaube aber auch nicht, dass das hier einen Unterschied macht).

    hab jetzt mal das git geclont und gebaut und installiert und mein XUM1541 angequatcht mit folgendem Ergebnis:

    Nein, sorry, ich meinte schon den Befehl so eingeben, wie ich es geschrieben habe, also alles in einer Zeile. Und auch wirklich mit "cbmctrl status".

    Die Frage ist, ob es die Richtige für mein Gerät war, es gibt ja 3 Firmware-Hexfiles:

    Das Gerät kenne ich gar nicht. Wenn die ZF Firmware bisher funktioniert hat (bzw. mit .99 immer noch funktioniert) dann wird es schon passen. Zumindest ist ja wohl auch ein 32u2 MCU Mikrocontroller drauf.

  • Das Gerät kenne ich gar nicht. Wenn die ZF Firmware bisher funktioniert hat (bzw. mit .99 immer noch funktioniert) dann wird es schon passen. Zumindest ist ja wohl auch ein 32u2 MCU Mikrocontroller drauf.

    so sieht es aus - das Readme zeigt nämlich, dass ich NUR die xum1541-ZOOMFLOPPY-v08.hex nehmen kann.

    Code
    1. 2. Select the appropriate device type (Device->Select). Choose one of
    2. the following:
    3. - ZoomFloppy: ATmega32U2
    4. - USBKEY development board: AT90USB1287
    5. - Original Bumble-B: AT90USB162

    ich habe diese FW nochmal mit -f (force) draufgespielt, ging problemlos.

    Nein, sorry, ich meinte schon den Befehl so eingeben, wie ich es geschrieben habe, also alles in einer Zeile. Und auch wirklich mit "cbmctrl status".

    EDIT:

    nach einiger Zeit kommt dann immer wieder .....

    Code
    1. [60.207007] [00003330] libusb: debug [usbi_wait_for_events] poll() returned 0
    2. [60.207034] [00003330] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
    3. [60.207041] [00003330] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
    4. [120.217047] [00003330] libusb: debug [usbi_wait_for_events] poll() returned 0
    5. [120.217071] [00003330] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
    6. [120.217077] [00003330] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
  • ein "cbmctrl reset" funktioniert aber !


    Achso, angeschlossen ist eine 1571 mit JiffyDOS aber mit CBM-DOS gehts auch nicht.

  • Mal dazwischengefragt: Gibt es irgendeinen Grund, die Kombination 0.4.99.99 mit FW 7 nicht mehr zu nutzen? Mir scheint dort, wenn die Installation glückt, alles zu funktionieren.

  • Mal dazwischengefragt: Gibt es irgendeinen Grund, die Kombination 0.4.99.99 mit FW 7 nicht mehr zu nutzen?

    Naja, es gibt schon ein paar Gründe die 103er zu preferieren ....

    2. News/Changelog

    OpenCBM v0.4.99.103:

    • new: Windows installation script for automatical installation
    • new: Pre-built Linux packages
    • new: MacOS and FreeBSD ports
    • new: Integration of USB based devices (XU1541, XUM1541) by introducing a plugin concept
    • new: tool d82copy
    • new: Allow serial nibbling for nibtools with VIC-1570 and VIC-1571 devices
    • change: Transfer routines are more robust now
    • change: Added option --petscii to cbmctrl
    • change: Various fixes for newer compilers (gcc) and platforms (Linux 3.x, 4.x, Windows 10)
    • fix: Many, many bug fixes
    • Moved development for SourceForge to GitHub


    Allerdings was nützt ein Bugfixing von vielen vielen Bugs wenn die Kiste dann gar nicht mehr funzt ....

    Ich lasse auf meinem Desktop-PC erstmal die defekte 103er drauf, vielleicht ergibt sich ja hier noch was ....

    Hab mir als Erleichterung gleich mal ein Update-Script geschrieben ....

  • Vielen Dank, das ist hilfreich.

    (Ich nehme an, eine neue Firmware hast du nicht geflasht?)

    doch, in 2020 - die Verion 8.

    Zumindest die Version die jetzt drauf ist, ist ziemlich aktuell (Oktober 2021). Hast du das dann heute doch noch geflasht?

    [XUM1541] firmware git revision is 3ef4fc0d

    Ich kann mit der gleichen Version das Problem aber auch nicht nachvollziehen. Ich muss mir das Protokoll mal genauer ansehen.


    Bei mir sieht der relevante Teil (da, wo es bei dir dann hängen bleibt), so aus:

    Hast du die Firmware selber compiliert oder ist die auch aus dem Repository? Ich hänge mal das Hexfile an, das bei mir für die entsprechende Version für die Zoomfloppy rauskommt. Ggfs. kannst du das ja auch mal testen.

  • Hast du das dann heute doch noch geflasht?

    ja, mit dem File xum1541-ZOOMFLOPPY-v08.hex aus dem aktuell geclonten git - funzte problemlos und auf dem Laptop mit version ....99.99 läuft das Teil auch nach wie vor problemlos.

    Hast du die Firmware selber compiliert oder ist die auch aus dem Repository? Ich hänge mal das Hexfile an, das bei mir für die entsprechende Version für die Zoomfloppy rauskommt. Ggfs. kannst du das ja auch mal testen.

    also die Prüfsumme ist schonmal ne Andere .... das file mit hinten _ ist das von Dir.

    Code
    1. md5sum xum1541-ZOOMFLOPPY-v08.hex xum1541-ZOOMFLOPPY-v08_.hex
    2. e1bdefa83e7a1cd4c52b9283a0678af6 xum1541-ZOOMFLOPPY-v08.hex
    3. 7684d01f8c99d1e3fc968b681115b73e xum1541-ZOOMFLOPPY-v08_.hex
  • der gleiche Fehler mit Deiner FW mit dem gleichen log am Ende ....

    Code
    1. [XUM1541] wrote 2 bytes (48 6f)
    2. [XUM1541] xum1541_wait_status checking for status
    3. [ 0.936901] [00002248] libusb: debug [libusb_alloc_transfer] transfer 0x560aa0bb43e8
    4. [ 0.936908] [00002248] libusb: debug [libusb_submit_transfer] transfer 0x560aa0bb43e8
    5. [ 0.936915] [00002248] libusb: debug [add_to_flying_list] arm timer for timeout in 2147483647ms (first in line)
    6. [ 0.936924] [00002248] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 3
    7. [ 0.936936] [00002248] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
    8. [ 0.936944] [00002248] libusb: debug [usbi_wait_for_events] poll() 3 fds with timeout in 60000ms
  • new: Allow serial nibbling for nibtools with VIC-1570 and VIC-1571 devices

    Gut, das ging aber auch schon mit der .99 problemlos, in sofern sehe ich jetzt tatsächlich keinen Grund, irgendwas zu ändern. Danke für die Zusammenstellung! :)

  • Ich bin etwas ratlos. Mein Verdacht ist, dass es eigentlich gar kein USB-Problem ist, sondern sich die Firmware sich aus irgendeinem Grund aufhängt und der Fehler nur in der Zoomfloppy-Version steckt und ich ihn deshalb nicht nachvollziehen kann. Ich habe aber keine Idee, was das sein könnte.


    Sorry, dass ich deshalb etwas im Nebel stochern muss.


    Probierst du bitte bei Gelegenheit mal die Firmwares aus der angehängten Datei aus? Am besten mit der "-3d012ae7" starten. Das ist die älteste, wenn es mit der auch nicht funktioniert, dann liegt es vermutlich nicht (nur) an der Firmware.

    Achso, angeschlossen ist eine 1571 mit JiffyDOS aber mit CBM-DOS gehts auch nicht.

    Das ist auch noch eine interessante Info. Eine 1541 zum alternativ Testen hast du nicht zufällig? (Es könnte sein, dass die SRQ-Leitung angesteuert wird und ich weiß nicht auswendig, was die 1571 dann macht).


    In diesem Zusammenhang könntest du auch mal ausprobieren was cbmlinetester -i macht (Bleibt es auch hängen oder funktioniert es? Reagiert DATA wenn du ATN mit den Tasten 'a'/'A' ansteuerst?)


    [Edit]Nein, das mit der 1571 hat vermutlich keinen Einfluss. Eben probiert, meiner ist es egal ob SRQ gesetzt ist oder nicht, cbmctrl status funktioniert trotzdem.[/Edit]

    [Edit 2]Gerade gesehen dass "3d012ae7" und "0589b674" identisch sind. Eine davon kannst du dir also sparen.[/Edit 2]

  • Code
    1. xum1541cfg devinfo

    ??


    Code
    1. $ xum1541cfg devinfo
    2. unknown command: devinfo

    Das xum1541cfg sub commando devinfo wurde offenbar entfernt ?