Posts by prefect

Erstmal danke. Ich hab's jetzt etwas klarer. Mein gedanklicher Fehler war, dass ich glaubte ich müsse vom eMMC zur NVMe rüber klonen. Was natürlich völliger Unfug ist, jetzt betrachtet.

Es ist egal welches System ich in der eMMC installiere, auf die NVMe kommt ein neues Image und das kann so gross sein wie es will. Also installiere ich auf der eMMC (8GB) ein kleines Server-Image, boote das, installiere mit dem running Server das zu grosse >8GB Images vom Ubuntu Desktop 64bit direkt auf die NVMe, die natürlich episch genug Platz hat, rekonfiguriere den Boot und hopp!

Ich weiss nicht genau wie und aus welchem Anlass ich mich da festgefahren hatte. Aber passiert eben!

Danke für die Starthilfe!

Es könnte so einfach sein, ist es aber nicht.

Ich versuche auf dieser Hardware ein Ubuntu Desktop 64bit zum fliegen zu bekommen. Aber in meinem Schädel klemmt's.

Hardware:

• CM4 8GB/8GB
• Waveshare IO-Base-B (das ist die kleine im original Raspi-Format mit M.2 auf der Unterseite
• kleine NVMe

Nun habe ich folgendes Problem: die Anleitung wie man die NVMe zum Booten bekommt (J.Geerling) beinhaltet die installation auf klassischem Medium (SD) und dann wird auf die NVMe geklont und der Bootloader umkonfiguriert.

Nun kann man aber ein Ubuntu 64bit Desktop nicht auf 8GB installieren: "At least 2 GB RAM and 16GB eMMC/SD storage required"

Die NVMe wäre ja jenseits von gross genug aber die eMMC ist es eben nicht.

Hat jemand für mich eine Strategie wie ich das System zusammenbekomme? Material hab ich reichlich SSDs, etc. aber ich möchte nicht stundenlang vor die Wand laufen bis sich mir die vermutlich für jeden anderen offensichtliche Lösung erschliesst.

Mir reicht das high-level, ich Google mir die Details gerne zusammen.

Und ja mit Raspbian würde das sicher problemlos gehen aber ich will und brauche das Ubuntu.

Danke für jeden konstruktiven Tip!

Wie ein Wunder: ich hab eine Quelle für ein paar CM4 aufgetan. Dazu ein Baseboard (das grössere) samt Waveshare-Gehäuse.

Nun .-.. Raspis mache ich schon eine Weile, aber das hier sind meine ersten CM4.

Die haben 4 Löcher aber beim Waveshare waren für alles Schrauben dabei, nicht für das CM4.

Ich kann es schon hören :

- "das muss man nicht anschrauben, hält auch so" ... ja ... möglicherweise ... aber ich bin ein Pedant.

- "nimm einfach 2mm oder 2,5mm und ein paar Distanzscheiben" ... ja .. kann ich ... aber wieviel Distanz ist denn richtig? Ich vermute, der Stecker ist da sehr ... wählerisch, oder?

Also am liebsten hätte ich eine Quelle wo ich ein passendes Schraubenset ordern kann. Gerne ein größeres Sortiment auf Vorrat. Und damit das nicht in Werbung ausartet, gerne per pm.

Oder jemand sagt mir wie die die Distanzscheiben sein müssen, Rest bekomm ich dann schon hin.

Vielen Dank für die Hilfe und ein bisschen Toleranz ;-).

Sorry, schon gefunden.

Gibt nen schönen Artikel auf: https://ethertubes.com/raspberry-pi-rts-cts-flow-control/https://ethertubes.com/raspberry-pi-rts-cts-flow-control/

Ich hatte billig nen 5er Satz von den HATs bestellt. Da ich nur ein paar zusätzliche Drähte brauche, trau ich mich mal ran.

Also Lötkobenspitze scharf feilen, drei Whisky gegen das Zittern und los geht's!

Und wo wir grad davon sprachen:

WENN ich für den Raspi einen eigenen HAT stricke, der Hardware-Protokoll machen soll:

ich habe gelesen dass man dann ein paar GPIO-Pins opfert um ein Hardware-Protokoll (CTS,RTS) zu emulieren. Da wäre natürlich Aufgabe des Treibers.

Frage 1: hat der Treiber da konkrete Vorstellungen welche Pins man verwenden würde, oder wäre das nur applikations-seitig umzusetzen also für einen agetty nicht machbar?

Frage 2: wenn es für 1 eine Antwort gibt ... wie konfiguriere ich den Treiber entsprechend?

Quote from jar

Tx Rx CTS RTS DTR DCD DSR RI GND da bin ich schon 9 eines D-Sub 9.

Das reicht nicht für die 4 im MAX3232, da bräuchte man mindestens noch 1-2 MÄXE

Naja, aber wenigstens die ungenutzten zwei hätten für RTS/CTS gereicht. Die ganze Schnittstelle verlangt ja keiner, aber wenigsten ein! Satz Protokoll-Leitungen. Ein paar optionale Jumper (selbst nachzulöten) hätten viel geholfen. Schliesslich hat der MAX 4 Treiber, warum nur 2 nutzen?

So klemme ich leider auf XON/XOFF, was einen fundamentalen Nachteil hat:

Theoretisch ist XON/XOFF eine feine Sache und sollte gut funktionieren. Praktisch hat das Grenzen: ein Serielles Terminal war zumindest damals kein Multi-Tasking-Device und hatte eine 8bit CPU. Wenn man also z.B. einen Delete-To-End-Of-Line abgesetzt hat, war die CPU damit einen Moment beschäftigt. In dieser Zeit wurde das Software-getriebene XON/XOFF nicht durchgeführt ... schwupp gehen Zeichen verloren.

Also mit 19200 und sogar 38400 baud kann ich locker einen "ls -lrtR" laufen lassen, kein bit verloren. Aber wenn ich einen emacs starte, der jede Menge Cursor-Positionierungen macht (wobei die CPU da etwas Zahlen-parsen muss), sieht der untere Teil vom screen aus wie Datensalat. Vielleicht erreiche ich mit "screen" als Puffer etwas, aber ich rechne mir wenig Chancen aus. Mit 9600 baud ist alles hübsch, da scheint dann die CPU im Terminal hinreichend schnell zu sein um nichts zu verlieren. Eventuell muss ich für solche Kandidaten mal einen Arduino stricken, der Hardware-Protokoll von langsamen Devices auf XON/XOFF übersetzt. Klingt wie ein nettes Winter-Wochenende. Wäre ein Terminal mit einem kleinen Multi-Tasking-Kern ausgestattet (oder wenigstens richtig interrupt-getrieben, was wohl leider nicht der Fall war), dann ginge auch bei komplexen Operationenen nichts flöten.

Da nun der Raspberry funktioniert und ich den HAT begriffen habe und die restlichen Probleme eben Probleme vom Terminal sind, versuch ich mal die anderen Terminals, ansonsten ist 9600 baud auch genug zum Arbeiten (nur eben nicht ... "atemberaubend"). Bei den DEC-Terminals ist jedenfalls mit XON/XOFF bei 9600 baud das Ende der Fahnenstange erklommen.

Quote from STF

Serielle Konsole und BT abschalten befreit ttyAMA0. Du kannst auch ttyS0 nehmen, das ist der mini UART (reicht, wenn Du keine exorbitanten Bitraten benötigst) . Noch besser ist die Verwendung innerhalb Deines Programms von /dev/serial0 bzw. /dev/serial1, die auf die UARTs verlinkt sind.

Ich muss das lassen mit der Ironie, die Detektoren scheinen defekt zu sein. Und dabei hab ich extra ein Smiley eingefügt. Sollte ein Gag sein. Dort, wo ich gelernt habe, gab es auch Computer, die in Hamburg vom Kranhaken gefallen sind und auf mysteriöse Weise den Weg an ihren Einsatzort fanden. Da durfte ich aber nicht ran.

Ich glaub der "alte Hase" hat es. Aber die Lösung ist haarsträubend.

Also die Software-Config mit dem overlay etc. hat irgendwie geklappt, irgendwie auch nicht. Daran experimentiere ich noch. Ich würde erwarten dass ich, wenn ich mit dtoverlay in der config.txt den bt abschalte, dann dieses overlay nach dem reboot mit dem dtoverlay Kommando sehen kann ... irgendwie nicht.

Was mich verwundert hat: ich konnte immer ein Signal auf DTR sehen aber keines auf TX. Also hab ich mir die serielle nochmal angeschaut: keine Steuerleitungen. Ist so beim Raspi, ok für mich aber wieso leuchtet dann DTR?!? Also such ich die Platine ab und ... die haben den Stecker gespiegelt. Keine Ahnung wieso. Wenn ich raten soll, dann damit man zum PC hin ohne Nullmodem-Kabel mit 1:1 auskommt. Also ich habs entweder nicht verstanden wie genial das ist oder die haben die Nummer versemmelt. In jedem Fall ist dann mein 9/25 Adapter aus dem Rennen. Ich patche mir mal ein Kabel zurecht, dann wird es geht.

Also Zusammenfassend:

• die Zweifel am Signalpegel waren unbegründet: der MAX3232 liefert +-5V (lass es 5.5 sein) und das reicht für RS-232/V.24 .. alles gut
• die Hersteller der HATs verwenden anscheinend eine Belegung als "Gegenstück" zum PC-COM-Port. Damit ist der "gespiegelt" und die klassische Vorgehensweise "Nullmodem+9/25 Adapter" geht schief: TX und DTR sind getauscht. Als ich die Verkabelung als "ok" eingeschätzt hatte, war das aufgrund der Tatsache, dass der HAT am LED-Display zusätzliche Signale anzeigt ... sonstwo reicht das hin zu Beurteilung der Belegung. Dass die die Pins spiegeln ... damit hatte ich nicht gerechnet ... von wegen "alter Hase" ... "blinder Hase" wäre wohl bezeichnender gewesen.
• das findet man schneller, sobald einem klar ist (da hat bei mir der Funke gefehlt) dass der Raspi keine Steuerleitungen bietet. Hätt ich dass gewusst hätte ich es gestern abend gemerkt. Damit wird aber auch die Entscheidung für den HAT fragwürdig. Nur mit dem USB-Adapter hat das Hardware-PRotokoll auch nicht gegriffen. Mal sehen!

Ich hab was über die Hardware config vom Raspi gelernt, aber damit bin ich noch nicht durch. Immerhin krieg ich nun wohl das Termi ans Laufen. Nur den Designer der HATs könnte ich grillen: warum sieht man nicht optionale Hardware-Protokoll-Leitungen vor? Für irgendein GPIO-Pin-Pärchen? Wenn doch der 232 schon 2 zusätzliche Konverter anbietet. Das wären nur ein paar extra Löcher in der Platine, kein Kostenfaktor.

An alle:

Quote from RTFM

Schau einmal genau in /bin/overlaiys/README und dazu /bin/config.text und /bin/commandline.txt an. BT sollte deaktiviert sein und die Console liegt möglicherweise nur auf dem falschen seriellen Device.

Davon hab ich irgendwann gelesen, aber ich dachte, das wäre durch die device-Bezeichner erledigt. Jetzt kommen mir Zweifel. Ich nehm den Hinweis mal auf und geh damit spielen. Ich bin mit ttyAMA0 losgezogen. Das war auch vom generator so angelegt. Ich geh mal devices zählen. Danke für den Hoffnungsschimmer!

Quote from STF

Naja - OK nicht unbedingt ein klassisches Terminal. Aber mir hattn ja nischd.

Hmmm, also ich hab hier im Regal ein - leider nicht mehr funktionierendes - Terminal von nem VEB sonstwas gab's also durchaus auch "drüben" bekam aber wohl keiner . Die "Ost-Abteilung" meiner CP/M-Rechner-Sammlung muss ich noch mal in Augenschein nehmen, nächstes Jahr vielleicht. Mir fehlt da noch jede Menge Info ... Schaltpläne etc. pp.. Ist für später.

Aber "hatten wir nich" is keine Ansage. Und ab Wiedervereinigung gabs immer noch nen Text-Modus im PC. Also hör auf zu

Oh Mann, mit jeder Zeile die ich lese, dreht sich die Welt:

also V- und V+ sind Outputs am MX2323. Theoretisch erzeugt der Kleine seine negative Spannung also doch selbst.

Es sollte also theoretisch doch einfach funktionieren.

Laut datasheet braucht der MAX2323 im Gegensatz zu den klassischen 1488/1489 Pegel-Konvertern keine Referenzspannung, sondern macht sich die selbst aus VCC und 2 Kondensatoren (die Magie innen drin ... nicht meins .. irgendwie klöppeln die sich ne negative Spannung zusammen und justieren mit den Kondensatoren die Spannung relativ zur Versorgungsspannung VCC ... Stichwort: "Charge Pump" ... naja). V+ und V- sind nur für die Kondensatoren für die Pegel-Anpassung: die Kondensatoren gehen aber nach GND.

Also sollte der MAX2323 irgendwas von +-5.5V oder so raushauen, was V.24 entsprechen würde.

Ergo ... darf ich jetzt mal Pegel messen. HAT ziehen, mit 3.3 V versorgen und mal sehen was der ausspuckt.

STF ... how old-school. Also ehrlich ... ich bin ja aus dem letzten Jahrtausend, zugegeben, aber im neuen habt Ihr immer noch keine modulare Hardware hinbekommen? Eine serielle Schnittstelle in einem Schrabbel-PC damals ... hat einfach funktioniert .

STF: logo, erwähnte ich , dass ich ein alter Knacker bin?

Ich wollte hier in meinem "persönlichen" Museum einige alte V.24 Terminals wieder ans Laufen bekommen (IBM Infowindow II, VT320, VT420, Siemens BA48). Dazu brauchte ich einen Linux-Server. Das röhrende Alteisen (HP DL xxx, IBM RS-6000, SunFire) war mir zu laut, zu gross und zu teuer im Betrieb und erforderte zuviel Pflege und Einarbeitung. Der Raspi ist modern klein und leise. Gute Basis für konzentriertes Arbeiten mit Scripts.

STF, wenn Du schon mal an einem klassischen Terminal gearbeitet hättest, wüsstest Du warum: im Gegensatz zu einem modernen Win/Mac/Lin GUI Panzer ist das recht entspannend ... man konzentriert sich total auf das Wesentliche: den Code. Sicher ... jedem das seine ... Du magst das anders sehen. Ich mag nun mal die Arbeit an einem klassischen Terminal: shell, screen, emacs ... läuft! Und auch wenn es aus dem letzten Jahrtausend ist. Ich kann damit auch aktuelle Software schreiben: das Terminal wird zur Hardware-IDE, naja es ist der Urvater derselben, oder? Ist schon noch ein Full-HD Monitor àm Raspi dran um im Browser die Ergebnisse zu kontrollieren und für Backend-Programmierung brauch ich nicht mal den. Ein wirkliches Back-to-the-roots-Projekt, insoweit hast Du recht.

War das nicht einer der Antriebsfeder vom Raspberry? Modular, flexibel einsetzbar wo anderes keinen Sinn macht? Was wundert Dich?

Für alle nochmal:

so wie es aussieht haben die "fertigen" Platinen aus Asien mit dem MAX2323 nicht das gemacht was ich erwartet hatte.

Im Stillen gerechnet hätte ich mit einer Wandlung von 0/3.3V nach +-5V. Das hätte dem Terminal gereicht weil mit absolut(+-) 5V ein definierter V.24 Pegel angelegen hätte. Aber der Raspi liefert keine -5V und die HATs bauen auch keine. Also wandelt der 2323 nur von 0/3.3V nach 0/5V was ... gelinde gesagt ... witzlos ist, zumindest für mich.

Ich scheitere also an überzogener Erwartungshaltung.

Wenn es mir gelingt dem MAX2323 für seinen V- sowas wie -5V zu beschaffen, müsste es gehen.

Zumindest ist der Raspi sicher, weil der MAX wie ein Bollwerk alles frisst was ich ihm aufgebraten habe. Also die +-12V vom Terminal schluckt der locker, nur er liefert nichts.

Hmm,

ich glaube ich muss nochmal ansetzen.

Das Termi macht +-12V soweit ist mir das (seit jeher, ich bin ein "alter Knacker") klar. Ich lebte in der Annahme dass der Serial-HAT dessen - platinentechnisch - einzige Komponente der MAX3232 ist (meiner Annahme nach ein 3.3 V fähiger MAX232 der ein Pegelwandler von +-12 nach TTL war, aber nun schau ich es einfach gleich nochmal nach).

Der 9-25 Adapter ist nur ein Zwischenstecker der das Steckerformat adaptiert, also nur Drähte, das war auch klar.

Einen Schaltplan als solches gibt es nicht ... keine Frei-Verdrahtung. Die HAT Platinen scheinen alle nach dem gleichen Muster gestrickt:

GPIO(seriell, hab die Pins geprüft) -> MAX3232 -> SubD-9pol

...

Hmmm, ok da ist dann auch der erste Grund: V.24 definiert Pegel von +-3 bis +-12V als valide. zwischen -3V und 3V ist nicht definiert. Der Wandler kann das zwar eigentlich braucht dafür aber die negative Referenzspannung. Der GPIO liefert aber nun keine negative Spannung, also wandelt der MAX wohl tatsächlich nur nach TTL. Das wiederum hilft mir so richtig überhaupt nicht weiter, weil damit wahrscheinlich nur ein USB-Seriell-Wandler umgehen kann aber in keinem Fall eines meiner Terminals.

So'n Mist ... kennt wer eine möglichst fertige Baugruppe (HAT o. sonstiges) die RICHTIGES V.24 kann oder muss ich wiedere Lötdämpfe schnüffeln und mir selbst was stricken?

Wie enttäuschend. Da hätte ich die HATs auch in Asien lassen können, wer macht schon RS232 mit TTL-Pegel ,,, nur ein USB Wandler.

Aber immerhin weiss ich nun woran ich scheitere. jetzt muss ich nur noch ne Spannungsquelle mit -5V beschaffen und crashfrei an den V- des MAX2323 bekommen. Vermutlich wird es leitungstechnisch einfacher einen non-HAT Wandler zu nehmen und frei zu verdrahten und da macht auch schon die ganze Schönheit meines "Mini-Servers" ... kein Drahtverhau ... winke-winke!

Trotzdem danke. Ich kann jetzt weiter!

Hi! (Erster Post, mach ich was falsch, röstet mich nicht gleich, es ist 3 Uhr nachts)

Ich versuche Folgendes: ich möchte ein klassisches CRT-Terminal (DEC VT320) mit seiner seriellen Schnittstelle an den Raspi hängen.

Mein erster Gedanke: serial-HAT kaufen, draufstapeln, Rest ist Software. Soweit die Theorie.

Praktisch habe ich das nicht ans Laufen bekommen. Erst habe ich an mir selbst gezweifelt, aber per USB-Seriell-Adapter bekam ich es hin. Systemd Konfig, Getty-Generator, alles im Griff. Nur über den HAT (mit einem MAX3232 und einer Echtzeituhr) ging es nicht. Meine RS-232 Diagnose-Stecker ergaben zwar eine korrekte Verkabelung, aber das Signal vom HAT war ... lau. Die LEDs kamen kaum zum Leuchten. Das Terminal lies die aber ebenso wie der USB-Adapter in hellem Licht erstrahlen. Nur der Raspi-HAT hatte da bestenfalls ein asthmatisches Glimmen anzubieten und das auch nur auf 2 Protokoll-Leitungen, nicht auf der Datenleitung.

Ich gehe also von einem elektrischen Problem aus und order mir einen weiteren serial-HAT, diesmal ohne Uhr. Draufgestapelt, test, fail. Gleiche Symptomatik.

Nun lauf ich so langsam trocken : Netzteil hab ich gewechselt, hat 3A und sonst ist derzeit nix anderes dran (Wireless Keyboard USB Plug) und das USB-Interface funktioniert auch super wenn die Hats (jeweils natürlich nur einer von denen) drauf sind.

Bevor ich also komplett ausklinke ... bitte helft mir mit Tipps oder Fragen!

Sichergestellt ist also:

• Verkabelung ist korrekt (DCE/DTE), ich habe umfangreiches Test-Equipment mit RS-232 und bilde mir ein, das seit 1984 ganz gut zu können. Hat mir hier aber nicht geholfen.
• Ich habe mehrere 9/25 Adapter getestet ... gleiches Ergebnis
• Ich habe die Systemd-Konfig getestet
• Mit USB-seriell-Adapter bekomme ich starke, klare Signale

Ich würde ja happy annehmen, dass elektrisch was defekt ist, aber den HAT habe ich gewechselt, und wenn der funktionieren würde, müsste ich ein klares Signal bekommen, selbst wenn der Raspi am seriellen Port hinkt.

Gibt es bei diesen Dingern Probleme mit dem GND oder so?

Und bevor jemand es sagt: ja ... natürlich kann ich einfach mit dem USB-Seriell weitermachen. Aber erstens habe ich die HATs nun gekauft, zweites wäre es doch nur der halbe Spass, drittens habe ich über USB bei hohen Datenraten (>=19200 baud) Zeichenverluste, was aber auch am Terminal liegen könnte, soweit bin ich noch nicht mit den Tests. Ich würde wirklich sehr gerne mit der nativen seriellen am GPIO arbeiten.

Vielen Dank im Voraus für jede Hilfe!

Gruss

Adrian