Embedded OS für GUI Entwicklung

Linux - was sonst?
Der Systemstart lässt sich gegenüber dem Standard Raspbian stark 
beschleunigen - je nachdem, was man wirklich braucht.

Für die GUI-Entwicklung solltest du dir QT Embedded anschauen.
http://doc.qt.io/qt-5/embedded-linux.html

Peter schrieb:
> Es sollte kein Schnick Schnack mitführen und somit schnell booten
> können.

Nimm einen nackten Linux-Kernel, ein BusyBox als Userland und starte 
deine Anwendung relativ direkt aus /etc/rc. Schalte Timeouts im 
Bootloader ab und miss nach, wo deine Zeit verschwindet.

Deine SD-Karte wird relativ langsam sein (große Binaries laden dauert, 
Squashfs hilft), und große C++-Bibliotheken können ihre Zeit brauchen, 
bis sie geladen sind.

Es gibt ein paar Tutorials, wie man mit Qt Embedded auf 
Sub-Sekunden-Bootzeiten kommt (allerdings nicht fürn Raspberry).

holger schrieb:
> Beitrag "Windows core iot"
>
> Jetzt ist aus Nino ein Peter geworden;)

Ja, verrückt diese Ähnlichkeit beim Thema :D

Die Antwort hast du doch im anderen Thread schon von Clemens bekommen:
Beitrag "Re: Windows core iot"

Boot2QT benötigt nicht mal einen X-Server, weil das direkt über OpenGL 
läuft. Daher auch die extrem flotten Bootzeiten.

Bei der Frage nach dem OS ist natürlich die Antwort von Stefan die 
einzig richtige. Falls die Frage nach der "richtigen" Distribution 
aufkommen sollte lautet die Antwort "deine eigene". Für den Anfang 
kannst du aber ruhig ein Debian oder was auch immer nehmen, was eben so 
standardmäßig für das jeweilige Board vorgesehen ist.

Christopher J. schrieb:
> Boot2QT benötigt nicht mal einen X-Server, weil das direkt über OpenGL
> läuft. Daher auch die extrem flotten Bootzeiten.

Nicht zwangsläufig.
Das geht auch mit /dev/fb*

Zitat:

EGLFS_DEVICE_INTEGRATION entry: the name of the preferred backend for 
that particular device. This is optional, but very useful to avoid the 
need to set this environment variable in case there are more than one 
plugins present in the target system. In a desktop environment the KMS 
or X11 backends are prioritized, depending on the presence of the 
DISPLAY environment variable. Note that on some boards the special value 
of none is used instead of an actual plugin. This indicates that no 
special integration is necessary to use EGL with the framebuffer and so 
no plugins must be loaded.

Peter schrieb:
> Es sollte kein Schnick Schnack mitführen und somit schnell booten
> können.
Archlinux fuer den RPi 3:
https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3

Da hast du erstmal nichts bei, kein X, keine Desktopoberflaeche, etc. 
Was du brauchst musst du selbst installieren, somit ist kein unnoetiger 
Balast vorhanden. Bootzeit (bis zum login in der Konsole) liegt bei ca. 
10 Sekunden. Ob man es noch schneller bekommt hab ich nie ausprobiert.

Du kannst dir auch mal Python3 und PyQt5 anschauen. Finde ich einfacher 
als Qt mit C++, und schneller in der Entwicklung ist es auch.

Stefan U. schrieb:
> Indem man die anzuzeigenden Daten mit einem Zeitstempel versieht und
> diesen mit anzeigt.

(verstaubte-Erinnerung-ausgrab): Gab es bei frühen elektronischen 
Stellwerken nicht den Trick, die Anzeige pro Frame aktiv vom gerade 
anzeigenden auf den jeweils anderen Computer zu wechseln? Dazu gab es 
noch ein Indikator-Zeichen irgendwo im Eck, der eine macht - der andere 
|. Wenn dann kein + da steht, ist was eingefroren...

Georg A. schrieb:
> Stefan U. schrieb:
>> Indem man die anzuzeigenden Daten mit einem Zeitstempel versieht und
>> diesen mit anzeigt.
>
> (verstaubte-Erinnerung-ausgrab): Gab es bei frühen elektronischen
> Stellwerken nicht den Trick, die Anzeige pro Frame aktiv vom gerade
> anzeigenden auf den jeweils anderen Computer zu wechseln? Dazu gab es
> noch ein Indikator-Zeichen irgendwo im Eck, der eine macht - der andere
> |. Wenn dann kein + da steht, ist was eingefroren...

Gab es. War aber nicht pro Frame, sondern pro 1s (IIRC). Wenn die 
Rechner unterschiedliche Ausgaben produzierten sah man das als "Blinken" 
auf dem Monitor -- und war die Umschaltung eingefroren blieb der Wechsel 
aus - und | stehen (Im Normalbetrieb sieht das aus als ob es sich 
dreht).
Es gab in frühen ESTW auch mal Röhrenmonitore, die ihre eigene 
Bildschirmdarstellung zurücklesen konnten und wieder an den Rechner 
zurückmeldeten.


Gruß,
f

Stefan U. schrieb:
> Wenn es so wäre, müsste das System sehr viel weiter verbreitet sein

Spätestens seit VHS weiß man doch, dass sich nicht zwangsläufig das 
beste durchsetzt.

Mr. Big schrieb:
> Lothar schrieb:
>> RiscOS bootet so schnell wie Circle oder ultibo und kann alles was
>> Linux
>> kann und ist auch noch sicher. Wird auch von der Pi Foundation als
>> Alternative empfohlen.
>
> RiscOS hat nicht mal preemptives Multitasking.

Ist bei Echtzeit-Systemen auch nichts so ungewöhnliches. Da will man das 
manchmal auch gar nicht, da man volle Kontrolle darüber braucht, wann 
welcher Thread läuft.

> Damit fällt es für viele ernst zu nehmende Aufgaben aus.

Für welche denn? Zum Vergleich: Windows 3.1 hatte auch kein präemptives 
Multitasking.

Johannes S. schrieb:
> Rolf M. schrieb:
>> Für welche denn? Zum Vergleich: Windows 3.1 hatte auch kein präemptives
>> Multitasking.
>
> Das war auch immer spassig wenn irgendein Programm das ganze System
> lahmlegen konnte...

Wir sprechen hier allerdings nicht von einem normalen Desktop-System, 
sondern von einem Embedded-System. Da laufen nicht alle möglichen 
Programme von sonstwo, sondern genau eins, das man selbst geschrieben 
hat.
Ob das Programm bei einem Fehler das System lahmlegt oder nicht, macht 
auch nicht viel unterschied, da das Gesamtsystem ohne das Programm eh 
nutzlos ist.
Außerdem kann zumindest im Echtzeit-Systemen bei präemptivem 
Multitasking ein Programm genauso das ganze System lahmlegen, sofern 
seine Priorität entsprechend hoch ist.

> Ein System mit Prioritäten hat schon Vorteile wenn z.B. GUI +
> Messtechnik auf einer CPU laufen.

Ja, das schon. Wenn die GUI irgendwo zuviel Zeit braucht und dann von 
wichtigeren Dingen unterbrochen werden kann, ist das sicher von Vorteil. 
Bei mehreren Cores kann man die beiden Sachen aber entsprechend 
verteilen.

Mr. Big schrieb:
> Rolf M. schrieb:
>> Außerdem kann zumindest im Echtzeit-Systemen bei präemptivem
>> Multitasking ein Programm genauso das ganze System lahmlegen, sofern
>> seine Priorität entsprechend hoch ist.
>
> Nur bei sehr einfachen Systemen mit statischen Prioritäten. Ein
> vernünftiger Scheduler verhindert das.

Ja, bei Desktop-Systemen. Bei Echtzeit-Systemen will man das nicht.

Lothar schrieb:

> RiscOS bootet so schnell wie Circle oder ultibo und kann alles was Linux
> kann und ist auch noch sicher.

Das stimmt so nicht. Zum einen mal kooperatives Multitasking, das ist 
ein nogo (zumindest bei mir).

Und es hat vielleicht 1% des Sofwarebestandes von Linux, vor allem an 
Bibliotheken fuer alles und jedes. Beispiel gefaellig? MariaDB, 
Gtk/GLib, Qt, ....

Ein anderer Vorteil von Linux ist, dass ich auf dem PC alles KOMPLETT 
FERTIG entwickeln kann, mit den identischen Bibliotheken und mit 
brauchbaren Entwicklungsumgebungen und mit schneller Compilierung. Auf 
dem Raspi ist dann nur ein einfaches neuebersetzen noetig, fertig und 
laeuft identisch (oder gar cross-compiling auf dem PC, aber das ist je 
nach Fall nicht immer so einfach).

Nicht falsch verstehen: Ich will das RiscOS keineswegs schlechtmachen 
(und habe es mir auch schon angeschaut - ein coole Sache), aber als 
Ersatz fuer Linux ist es nur in ganz bestimmten Faellen brauchbar.

P.S.: Schade, dass es kein wirklich natives AmigaOs (oder AROS), das 
waere noch interessanter (jaja, ich weiss, das wurde in grauer Vorzeit 
glaube ich sogar vom RiscOS abgeleitet).

Zum Thema bootgeschwindigkeit weise ich mal auf die interessanten Daten 
eiens Users hier hin: 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi"
Verwende das richtige Dateisystem!

Ansonsten habe ich im Kopf, dass Bootzeiten von ~8s beim Raspberry mit 
abgespecktem, GUI-losen Linux realistisch sind. Die GUI dann zu starten 
dürfte noch eine Hand voll Sekunden dauern.

Brummbär schrieb:
> "Linux" ist nur der Kernel. Die Programme gehören nicht dazu.

Das ist mir wohl bewusst, aber 99% aller Leute meinen mit "Linux" den 
Kernel+Treiber+Userspace-Programme, also nutze ich den Begriff in der 
gleichen Weise auf die Gefahr hin, dass mich die 1% Haarespalter 
absichtlich missverstehen koennen ;-)

P.S.: Ich arbeite mit Linux seit "Ygdrassil Linux" 
(https://de.wikipedia.org/wiki/Yggdrasil_Linux), der Oberlehrer bringt 
also wenig.

Hier findet sich eine Sammlung an Dokumenten und Vorträgen zum Thema 
Embedded Linux, unter anderem zur Boot time Optimierung.
https://free-electrons.com/docs/

Lothar schrieb:

> Und wie simulierst du auf dem PC die Embedded Hardware am Pi?

Die zusaetzliche Hardware ist per RS232 angebunden, hauptsaechlich eine 
Sub-CPU (ein Cortex M3), der auch den ganzen Echtzeit-Kram macht und 
weitere serielle Schnittstellen zu weiterer Hardware bereitstellt (quasi 
als UART/SPI Bridge) sowie ein bisschen PWM macht und ein paar Inputs 
auf Aenderungen prueft. Die Dinger kosten ja kaum noch was (in meinem 
Fall < 1 Euro).

Das mag anachronistisch klingen, hat aber einige Vorteile, z.B. muss ich 
eben gar nichts simulieren und ich kann den CM3 direkt vom Raspi aus mit 
neuer Firmware beladen. Und auf die paar cm kriegt man auch ordentlich 
Baudraten hin.

> Bei RiscOS braucht man normalerweise 2x Pi - eines mit Desktop zur
> Entwicklung und eines mit pico - dafür hat man an beiden dieselbe
> Hardware.

Auch eine Moeglichkeit, aber der PC ist eben schon eine andere Nummer. 
Wir lassen z.B. auf dem Raspi auch eine groessere (selbstentwickelte 
natuerlich) Software laufen, die braucht > 12 Minuten zum compilieren 
auf dem Raspi. Auf dem PC nur 30 Sekunden. Das laeppert sich zusammen, 
wenn man alles erst mal auf einem PC fertig entwickeln kann.

> Es gibt auch preemptive und RT Threads aber die nutzen wir gar nicht.
> Das embedded programm muss in Echtzeit laufen, der Rest ist erst mal
> egal. Dann steht halt die GUI mal 1 sec mit hourglass.

Ich verstehe, kann ich mir gut vorstellen das das gut funktioniert. In 
der Praxis brauchbares Echtzeitverhalten auf einem Raspi mit Linux ist 
schon ein Aufwand.

> Die Entwicklung hat mehr Ähnlichkeit mit uC - daher für Linux Nutzer
> gewöhnungsbedürftig.

Oh, ich mache beides seit langer Zeit und springe im Abstand von Minuten 
oder auch Tagen oder Wochen dazwischen hin und her (also PC - Raspi - 
Mikrocontroller). Und dazwischen noch zum "Ausruhen" ;-) die 
Elektronikentwicklung. Nur bestuecken machen wir nicht (mehr) selber 
(ausser Prototypen und vielleicht hie und da 0-Serien).

Das ist jedesmal sowas wie ein Kulturschock ;-)

Stefan U. schrieb:
> Linux natürlich.
> Warum? Weil es die vom Board Hersteller unterstützte Lösung ist. Und
> weil es nichts kostet.

Lothar schrieb:
> Abgesehen davon kommt es auf den Einsatz an. Wenn es sicherheitskritisch
> ist, sollte immer GUI und Steuerung getrennt sein. Also ein Pi für die
> GUI und ein anderes Pi ohne Desktop für die Steuerung (oder eben uC oder
> SPS)

Ok, ist zwar schon länger her, aber da würde mich mal noch ein paar 
Dinge interessieren:
- Soweit ich weiss muss man bei Linux Lizenzgebühren zahlen, wenn man 
das ganze verkaufen möchte, also nix mit gratis.
- Im Sicherheitsbereicht kann man dann auch nicht irgend ein Linux 
nehmen, sondern man braucht schon geprüfte und freigegebene Kernels, 
Compilers, IDE... dazu kommt, dass der eigene Code ebenfalls abgenommen 
werden muss. Da denke ich ist ein Rasperry mehr als falsch
- Darf man Rapserry etc. überhaupt in eigenen Geräten verkaufen? Ich 
kann mich errinnern, das dies einmal verboten war. Also nur zu 
Bastelzwecke und eigenbedarf einsetzbar ist.

Noch meine persönliche Meinung zu Boot-Zeiten:
Mich interessiert selten ob ein Gerät nun 1sec oder 10sec zum booten 
hat. Hautpsache es läuft im Anschluss flüssig. Selbst ein Smartphone 
oder ein Tablett hat >20sec zum booten (also bis man damit arbeiten 
kann). Wieso also hier so viel Optimierungsaufwand reinstecken?

Gruss

Marian M. schrieb:
> Hier findet sich eine Sammlung an Dokumenten und Vorträgen zum Thema
> Embedded Linux, unter anderem zur Boot time Optimierung.
> https://free-electrons.com/docs/

Sehr schoen. Das erste ist natuerlich immer ein "systemd-analyze" und 
"systemd-analyze blame" bzw. "systemd-analyze plot > boot.svg", damit 
man mal einen Ueberblick bekommt, was sich lohnt.

Damit bin ich von 22.5s auf 8.1s runtergekommen mit ein paar einfachen 
Massnahmen, die sich aus den obigen Ausgaben von selbst ergeben. Das 
reicht erst mal fuer mich (da geht sicher noch was, wenn man Aufwand 
betreibt).

Georg A. schrieb:
> (verstaubte-Erinnerung-ausgrab): Gab es bei frühen elektronischen
> Stellwerken nicht den Trick, die Anzeige pro Frame aktiv vom gerade
> anzeigenden auf den jeweils anderen Computer zu wechseln? Dazu gab es
> noch ein Indikator-Zeichen irgendwo im Eck, der eine macht - der andere
> |. Wenn dann kein + da steht, ist was eingefroren...

Ja, und die Systeme haben dann auch alles was die gezeichnet haben 
gleich zurückgelesen. Und im Eck waren auch Felder an denen man schnell 
sehen konnte, ob eine Farbe ausgefallen war. Und natürlich alles 
redundant mit ständigem Umschalten, so dass man Störungen schnell als 
"Blinken" merkt.

Irgendwie schade, dass man das nicht mehr macht. Die Aufgaben sind ja 
damals wie heute eher trivial, so dass selbst ein simpler 
"Selbstbau"-Rechner nicht viel teurer sein muss als einer von der 
Stange.

Patrick B. schrieb:
> - Soweit ich weiss muss man bei Linux Lizenzgebühren zahlen, wenn man
> das ganze verkaufen möchte, also nix mit gratis.

Das ist definitiv falsch.

> - Im Sicherheitsbereicht kann man dann auch nicht irgend ein Linux
> nehmen, sondern man braucht schon geprüfte und freigegebene Kernels,
> Compilers, IDE... dazu kommt, dass der eigene Code ebenfalls abgenommen
> werden muss. Da denke ich ist ein Rasperry mehr als falsch

Vermutlich. Wobei in Deutschland und Oesterreich ja der 
Zertifizierungspilz wuchert, das es eine Freude ist (und das nicht nur 
im Sicherheitsbereich). Aus der Erfahrung kann ich sagen: I.a. sind die 
Sachen, die von Enthusiasten entwickelt wurden, wesentlich besser als 
das Zeugs von Firmen, die die halbe Zeit kiloweise Papier produzieren 
(muessen).

Und die ganzen Zertifizierer sind eine Klasse fuer sich. In der Regel 
haben die von den zugrundeliegenden technischen Details der Sache, die 
sie da zertifizieren, nur sehr wenig Ahnung. Sie besorgen sich halt die 
Normen und ueberlegen dann, was sie in den teuren Bericht schreiben.

Sorry wenn sich jetzt jemand auf den Schlips getreten fuehlt, aber das 
ist nun mal meine Erfahrung. Und ich habe das noch viel zu freundlich 
geschrieben ;-)

> - Darf man Rapserry etc. überhaupt in eigenen Geräten verkaufen? Ich
> kann mich errinnern, das dies einmal verboten war. Also nur zu
> Bastelzwecke und eigenbedarf einsetzbar ist.

Das ist sicher falsch. Z.B. das CM3 (ComputeModule3) ist im Prinzip 
nichts anderes als ein Raspi3 ohne Stecker, das ist explizit fuer die 
Industrie gedacht. Ich habe auch vor einigen Monaten (?) gelesen, dass 
irgend ein bekannter Fernseherhersteller (NEC?) einen Raspi in einen 
seiner Fernseher einbauen will? Finde den Link nicht mehr.

Es ist ja auch fuer den RaspiZero (und /W) nicht explizit verboten, das 
Teil in einem zu verkaufenden Geraet einzubauen. Nur verhindert man de 
facto eine professioneller Verwendung, indem die Abgabe auf 1 Stk. pro 
Bestellung limitiert und Mehrfachbestellungen storniert.

Das war fuer den Zero und Anfangs fuer den ZeroW natuerlich sinnvoll, 
damit die privaten Bastler (das beschschschschEIDENE Wort "Maker" 
vermeide ich) auch mal an so ein Ding kommen.

Inzwischen (fast ein Jahr nach dem Start) ist es fuer den ZeroW wohl nur 
mehr Beutelschneiderei des Haendlerpacks (sorry), weil sie am ZeroW 
alleine "zuwenig" verdienen. Schade eigentlich, da waeren schnell mal 
ein paar 100.000 zusaetzliche Stueck zu verkaufen denke ich.

> Noch meine persönliche Meinung zu Boot-Zeiten:
> Mich interessiert selten ob ein Gerät nun 1sec oder 10sec zum booten
> hat. Hautpsache es läuft im Anschluss flüssig. Selbst ein Smartphone
> oder ein Tablett hat >20sec zum booten (also bis man damit arbeiten
> kann). Wieso also hier so viel Optimierungsaufwand reinstecken?

Prinzipiell korrekt. Trotzdem schadet es nicht, wenn man es mit sagen 
wir 1h Aufwand schafft, die Bootzeit von 22s auf 8s druecken kann. Es 
gibt Leute (Kunden), fuer die das auch ein Kaufargument ist.

Bernhard R. schrieb:
> Inzwischen (fast ein Jahr nach dem Start) ist es fuer den ZeroW wohl nur
> mehr Beutelschneiderei des Haendlerpacks (sorry), weil sie am ZeroW
> alleine "zuwenig" verdienen. Schade eigentlich, da waeren schnell mal
> ein paar 100.000 zusaetzliche Stueck zu verkaufen denke ich.

War es nicht mal so dass man den Zero, für 5$ ja an Afrika und Indien 
vertreiben wollte? Also für Schulen, etc.
Weiss nicht so ganz was daraus geworden ist, aber wenn das zutrifft, 
werden die Händler die Teile auf jeden Fall in Massen los und das 
Problem sind die Fertigungskapazitäten.

Bundles sind in der tat in den shops meist die "default" Einstellung, 
aber man kann auch ohne Bundle kaufen.
Allerdings so ab ~10€.
Immer noch recht günstig für einen ARM mit GPU und fertiger 
Spannungsversorgung sowie GPIOs...

Bernhard R. schrieb:
> Vermutlich. Wobei in Deutschland und Oesterreich ja der
> Zertifizierungspilz wuchert, das es eine Freude ist (und das nicht nur
> im Sicherheitsbereich). Aus der Erfahrung kann ich sagen: I.a. sind die
> Sachen, die von Enthusiasten entwickelt wurden, wesentlich besser als
> das Zeugs von Firmen, die die halbe Zeit kiloweise Papier produzieren
> (muessen).

Ich denke es kommt stark auf den Sicherheitsbereich an: 
sicherheitskritische Teile bei Auto-, Bahn-, Flug- und Medizintechnik 
war das zumindest vor 3 Jahren so.

Bernhard R. schrieb:
> Es ist ja auch fuer den RaspiZero (und /W) nicht explizit verboten, das
> Teil in einem zu verkaufenden Geraet einzubauen. Nur verhindert man de
> facto eine professioneller Verwendung, indem die Abgabe auf 1 Stk. pro
> Bestellung limitiert und Mehrfachbestellungen storniert.

Ok, das ist interessant. Aber ich denke die Verfügbarkeit wird der 
Ausschlaggebende Punkt sein.
Wir haben schon Probleme unsere Ersatzteilgarantie von 10 Jahren zu 
gewährleisten. Wie es mit ursprünglich für Bastler designte Boards 
aussieht, weiss ich nicht. Denke, dass man diese aber spätestens nach 5 
Jahren nicht mehr in dieser Form und Menge bekommt.

Patrick B. schrieb:
> Ok, das ist interessant. Aber ich denke die Verfügbarkeit wird der
> Ausschlaggebende Punkt sein.
> Wir haben schon Probleme unsere Ersatzteilgarantie von 10 Jahren zu
> gewährleisten. Wie es mit ursprünglich für Bastler designte Boards
> aussieht, weiss ich nicht. Denke, dass man diese aber spätestens nach 5
> Jahren nicht mehr in dieser Form und Menge bekommt.

Ja, für richtig seriöse Produkte ist das Compute Module gedacht:
>Raspberry Pi garantiert die Verfügbarkeit von CM3 und CM3 Lite mindestens bis 
>Januar 2023.
Wer damit solch wichtige Geräte baut, wird sich wohl ein paar auf Halde 
legen - ist aber kein großer Kostenfaktor.

Alex G. schrieb:
> Bundles sind in der tat in den shops meist die "default" Einstellung,
> aber man kann auch ohne Bundle kaufen.
> Allerdings so ab ~10€.

Man kann den Zero auch fuer Eur 5,-- kaufen (ohne Versand), aber eben 
immer nur EIN Stueck pro Bestellung, teilweise werden sogar 
Mehrfachbestellungen storniert, obwohl man da ja bereit waere, bei JEDEM 
Stueck 1x Versand zu bezahlen.

Wie gesagt kann ich das beim Zero verstehen, da werden (immer noch) nur 
geringe Stueckzahlen produziert und es soll ja jeder der will wenigstens 
einen bekommen.

Beim ZeroW, der mit VIEL hoeheren Stueckzahlen produziert wird, halte 
ich das, fast ein Jahr nach dem Start fuer reine Geschwaeftemacherei.

Etliche Leute (ich will jetzt nicht schreiben "Wichtigtuer"...) haben 
beim ZeroW Start damals auch ihre Meinung kundgetan, man solle sich doch 
nicht aufregen ueber die Begrenzung auf 1 Stueck, das werde nach ein 
paar Wochen sowieso fallen. Na, das war wohl nix.

Ich bin mir recht sicher, dass es an den Haendlern liegt. Hier sollte 
die Raspberry Foundation mal ordentlich Druck machen, indem einfach mehr 
Haendler zugelassen werden, dann erledigt sich das Problem von selbst.

Lothar schrieb:

> Irgendwie verhält sich der Flash aber doch anders beim
> beschreiben so dass nach einiger Zeit Probleme im Dateisystem der FAT
> Boot Partition auftreten.

Auf der BOOT Partition? Das wundert mich sehr! Habt Ihr Stromausfaelle?

Es ist naemlich so, dass wegen moeglicher Kernel updates /boot 
defaultmaessig readwrite gemountet ist.
Vielleicht wuerde es helfen, /boot erst mal generell ro zu mounten? 
Hierzu einfach in /etc/fstab bei /boot das "defaults" durch 
"defaults,ro" ersetzen.

Vor einem Kernel-Update muesste man dann /boot eben kurzfristig wieder 
rw mounten:

sudo mount -o remount,rw /dev/mmcblk0p1 /boot

Fuer root wuerde ich auch auf dem CM3 jedenfalls F2FS empfehlen wollen, 
obwohl ich damit noch keine echten Erfahrungen vorweisen kann, aber in 
einem halben oder ganzen Jahr kann ich dazu dann was berichten.

Lothar schrieb:
> Nicht das /boot sondern die Bootloader Partition wo kernel.img drin ist.
> Da ist nur FAT zulässig.

Da gibt es wohl ein Missverstaendnis.

Die Bootpartition /dev/mmcblk0p1 wird eben beim Hochfahren auf /boot 
gemountet, das IST also quasi die Bootpartition (jedenfalls das 
FAT-Filesystem, das da drauf ist). Und zwar "readwrite", weil man ja hie 
und da ein Kernelupdate macht und dabei das kernel.img ueberschrieben 
wird.

Wenn Du sie nun ueber /etc/fstab readonly mounten laesst, schuetzt Du 
sie vor Schreibzugriffen und sie geht Dir nicht mehr so leicht kaputt.

Patrick B. schrieb:
> Bernhard R. schrieb:
>> Es ist ja auch fuer den RaspiZero (und /W) nicht explizit verboten, das
>> Teil in einem zu verkaufenden Geraet einzubauen. Nur verhindert man de
>> facto eine professioneller Verwendung, indem die Abgabe auf 1 Stk. pro
>> Bestellung limitiert und Mehrfachbestellungen storniert.
>
> Ok, das ist interessant.

Kuerzlich gefuehrte "Gespraeche" ueber Email usw. mit der Raspi 
Foundation ergeben nun ein etwas anderes Bild bezueglich der 
Stueckzahlen.

Es ist offenbar die Foundation Politik, nur 1 Stueck pro Kunden fuer 5$ 
(Zero) bzw. 10$ (ZeroW) abzugeben. Groessere Stueckzahlen kann man 
offenbar durchaus kaufen, aber zu deutlich hoeherem Preis und man muss 
der Raspi Foundation auch genau erlaeutern, fuer welchen Einsatzzweck.