Hallo Alle!
Im Forum zu ConTeXt (sowas wie ein Nachfolger für LaTeX, wo ansonsten die Frage des Betriebssystems nicht die große Rolle spielt), wurde folgende Frage gestellt:
"Does it still need proprietary binary blobs in the kernel? Probably yes, so it is as useless as all the models before because it can only run their custom Raspbian distro."
Weiß von Euch Jemand Etwas dazu, was ich weitergeben könnte?
Gruß,
Rudolf
On Tue, Jun 25, 2019 at 06:26:53AM +0200, Rudolf Bahr wrote:
Hallo Alle!
Im Forum zu ConTeXt (sowas wie ein Nachfolger für LaTeX, wo ansonsten die Frage des Betriebssystems nicht die große Rolle spielt), wurde folgende Frage gestellt:
"Does it still need proprietary binary blobs in the kernel? Probably yes, so it is as useless as all the models before because it can only run their custom Raspbian distro."
Weiß von Euch Jemand Etwas dazu, was ich weitergeben könnte?
Die Antwort darauf ist komplizierter, als es einem lieb sein kann :-)
"Blob" hat da nämlich unterschiedliche Bedeutungen (vermutlich lässt sich die Liste verlängern):
(1) zum einen, nicht-freie Treiber, die direkt im Adressraum des Linux kernels ausgeführt werden (strenggenommen verletzen sie die GPL, aber die Linux-community ist da... "tolerant" [1]
(2) dann ist die eng verwandte "Cousine", die im Kernel zwar einen freien "Treiber" hat, der aber nur eine Hülle ist, die die eigentliche Arbeit an ein Programm in user space delegiert, das proprietär ist
(3) schliesslich ist es so, dass der Broadcom BCM28xx (oder BCM27xx) [2] nicht "nur eine ARM CPU" ist, sondern ganz viele verschiedene Subsysteme umfasst (im Jargon ist das ein SoC, ein "System on a Chip"). Jedes dieser Subsysteme hat vielleicht einen, vielleicht mehrere Prozessoren, am prominentesten beim Raspi ist wohl der Grafik-Coprozessor (VideoCore IV), der auch zum Booten des ganzen Systems zuständig ist. Auch die wollen Code, der auch als Blobs in Erscheinung treten kann, die der Linux-Kernel einfach nur durchreicht.
Also: ohne (3) gibt es beim Raspi nicht mal Booten ;-)
Meines Wissens ist Raspi in (1) und (2) weitgehend "sauber" (Korrekturen erwünscht!), (3) ist allerdings weitaus schwieriger (es gibt m.W. aber auch Leute, die a dessen reverse engineering dran sind).
Broadcom selbst scheint, nach anfänglichem Zögern, diesen Anstrengungen freundlich gegenüberzustehen.
Dies alles mit etwas Fehlermarge, da ich schon lange nicht mehr reingeschaut habe. Ergänzungen also willkommen (dann lerne ich auch was bei ;-)
lg
[1] Ein Thema für sich, an dem, wie mensch sich das auch denken kann, so einige Kontroversen entstehen.
Hallo Tomas,
danke vielmals für Deine ausführliche Erklärung, die ich (englisch übersetzt) an das ConTeXt-Forum [1] mit Hinweis auf den Author weitergegeben habe.
Ich hoffe nur, dass keine Rückfragen kommen, weil das ja ein etwas aufwändiges Hin und Her gäbe.
Danke nochmals und viele Grüße,
Rudolf
On Tue, Jun 25, 2019 at 10:27:22AM +0200, tomas@tuxteam.de wrote:
On Tue, Jun 25, 2019 at 06:26:53AM +0200, Rudolf Bahr wrote:
Hallo Alle!
Im Forum zu ConTeXt (sowas wie ein Nachfolger für LaTeX, wo ansonsten die Frage des Betriebssystems nicht die große Rolle spielt), wurde folgende Frage gestellt:
"Does it still need proprietary binary blobs in the kernel? Probably yes, so it is as useless as all the models before because it can only run their custom Raspbian distro."
Weiß von Euch Jemand Etwas dazu, was ich weitergeben könnte?
Die Antwort darauf ist komplizierter, als es einem lieb sein kann :-)
"Blob" hat da nämlich unterschiedliche Bedeutungen (vermutlich lässt sich die Liste verlängern):
(1) zum einen, nicht-freie Treiber, die direkt im Adressraum des Linux kernels ausgeführt werden (strenggenommen verletzen sie die GPL, aber die Linux-community ist da... "tolerant" [1]
(2) dann ist die eng verwandte "Cousine", die im Kernel zwar einen freien "Treiber" hat, der aber nur eine Hülle ist, die die eigentliche Arbeit an ein Programm in user space delegiert, das proprietär ist
(3) schliesslich ist es so, dass der Broadcom BCM28xx (oder BCM27xx) [2] nicht "nur eine ARM CPU" ist, sondern ganz viele verschiedene Subsysteme umfasst (im Jargon ist das ein SoC, ein "System on a Chip"). Jedes dieser Subsysteme hat vielleicht einen, vielleicht mehrere Prozessoren, am prominentesten beim Raspi ist wohl der Grafik-Coprozessor (VideoCore IV), der auch zum Booten des ganzen Systems zuständig ist. Auch die wollen Code, der auch als Blobs in Erscheinung treten kann, die der Linux-Kernel einfach nur durchreicht.
Also: ohne (3) gibt es beim Raspi nicht mal Booten ;-)
Meines Wissens ist Raspi in (1) und (2) weitgehend "sauber" (Korrekturen erwünscht!), (3) ist allerdings weitaus schwieriger (es gibt m.W. aber auch Leute, die a dessen reverse engineering dran sind).
Broadcom selbst scheint, nach anfänglichem Zögern, diesen Anstrengungen freundlich gegenüberzustehen.
Dies alles mit etwas Fehlermarge, da ich schon lange nicht mehr reingeschaut habe. Ergänzungen also willkommen (dann lerne ich auch was bei ;-)
lg
[1] Ein Thema für sich, an dem, wie mensch sich das auch denken kann, so einige Kontroversen entstehen.
On Tue, Jun 25, 2019 at 06:06:26PM +0200, Rudolf Bahr wrote:
Hallo Tomas,
danke vielmals für Deine ausführliche Erklärung, die ich (englisch übersetzt) an das ConTeXt-Forum [1] mit Hinweis auf den Author weitergegeben habe.
Wie gesagt: ich wäre froh, wenn jemand das ergänzt. Ich bin da selber nicht 100% "drin" und vielleicht ist da noch ein Schnitzer.
Ansonsten... gerne natürlich :-)
lg -- t
Du warst schon ausführlicher, als es vermutlich erwartet wurde. Wie gesagt, das ConTeXt-Forum [1] befasst sich normalerweise mit Buchsatz und nicht mit Betriebssystem-Innereien. Die Frage kam wohl auf, als Raspberry 4 veröffentlicht wurde und Einer damit arbeiten wollte. Jetzt habe ich wenigstens auch eine Ahnung, was ein "Blob" ist :-)
Sollte dort noch Etwas dazu geschrieben werden, werde ich das gerne hier weitergeben.
Gruß,
Rudolf
[1] https://wiki.contextgarden.net
On Tue, Jun 25, 2019 at 08:48:10PM +0200, tomas@tuxteam.de wrote:
On Tue, Jun 25, 2019 at 06:06:26PM +0200, Rudolf Bahr wrote:
Hallo Tomas,
danke vielmals für Deine ausführliche Erklärung, die ich (englisch übersetzt) an das ConTeXt-Forum [1] mit Hinweis auf den Author weitergegeben habe.
Wie gesagt: ich wäre froh, wenn jemand das ergänzt. Ich bin da selber nicht 100% "drin" und vielleicht ist da noch ein Schnitzer.
Ansonsten... gerne natürlich :-)
lg -- t
Am Mittwoch, 26. Juni 2019 11:03 CEST, Rudolf Bahr quasi@quasi.de schrieb:
Jetzt habe ich wenigstens auch eine Ahnung, was ein "Blob" ist :-)
Das war übrigens, zumindest ursprünglich, ein Acronym: Binary Large OBject.
Gruss RalfD
On Wed, Jun 26, 2019 at 11:22:21AM +0200, Ralf Mattes wrote:
Am Mittwoch, 26. Juni 2019 11:03 CEST, Rudolf Bahr quasi@quasi.de schrieb:
Jetzt habe ich wenigstens auch eine Ahnung, was ein "Blob" ist :-)
Das war übrigens, zumindest ursprünglich, ein Acronym: Binary Large OBject.
Zu Deutsch ein "zwiespältiges, grosses Ding". Oder so ähnlich ;-P
lg -- t
Hallo,
ein paar Ergänzungen:
"Does it still need proprietary binary blobs in the kernel? Probably yes, so it is as useless as all the models before because it can only run their custom Raspbian distro."
Die beiden Fragen haben streng genommen nichts miteinander zu tun. Auch wenn man in der Anfangszeit des Rapsberry Pi proprietären Code im Kernel brauchte, konnte man trotzdem immer auch andere Betriebssysteme und Linux Distributionen als Rapbian verwenden. Mit einer Distribution, die auf dem DEB Paketformat basiert, konnte man sogar einfach das Kernel DEB aus Raspbian installieren und musste sich dann "nur noch" um den Bootprozess kümmern.
Aktuell gibt es eine Reihe von Alternativen zu Raspbian, viele davon sind in diesem Artikel aufgelistet: https://www.elektronikpraxis.vogel.de/45-betriebssysteme-fuer-den-raspberry-...
Auch Debian kann man auf dem Pi benutzen, vgl. https://wiki.debian.org/RaspberryPi
Also: ohne (3) gibt es beim Raspi nicht mal Booten ;-)
Meines Wissens ist Raspi in (1) und (2) weitgehend "sauber" (Korrekturen erwünscht!),
In der Anfangszeit des Raspberry Pi 1 war der Grafiktreiber proprietär im Sinne von (1). Seit 2014 gibt es einen unabhängigen freien Treiber (vgl. https://heise.de/-2158533). Kurze Zeit später hat Broadcom einen Kernelentwickler angestellt, der sich seither um "offizielle" freie Treiber kümmert. Seit 2016 sind diese auch im Mailline Kernel (Linux 4.4).
Die Specs für den Raspberry Pi 4 und den dafür nötigen Kerneltreiber sind m.W. noch nicht im Detail veröffentlicht, aber aufgrund der Entwicklungen in den letzten Jahren gehe ich davon aus, dass dieser auch wieder direkt vom Mailline Kernel unterstützt werden wird, ggf. muss man 1-2 Kernelversionen abwarten oder einen Backport nutzen.
(3) ist allerdings weitaus schwieriger (es gibt m.W. aber auch Leute, die a dessen reverse engineering dran sind).
Ja, dafür gibt es das RPI Open Firmware Projekt, das mit dem Segen von Broadcom an einer freien Firmware arbeitet. Leider scheint es zur Zeit ziemlich tot zu sein.
https://github.com/christinaa/rpi-open-firmware https://news.ycombinator.com/item?id=11703842
Dies alles mit etwas Fehlermarge, da ich schon lange nicht mehr reingeschaut habe. Ergänzungen also willkommen (dann lerne ich auch was bei ;-)
Ich hoffe, hierzu etwas beigetragen zu haben. ;-)
Gruß, Harald
On Wed, Jun 26, 2019 at 12:40:54PM +0200, Harald Weidner wrote:
Hallo,
ein paar Ergänzungen:
[gut fundiertes und sehr interessantes Zeug]
Vielen, vielen Dank! Nehme ich in meiner informellen Sammlung auf.
Ich hoffe, hierzu etwas beigetragen zu haben. ;-)
Zweifelsohne: vielen Dank nochmal dafür.
lg -- tomás
Hallo,
hier noch mehr vom "interessanten Zeug" :-), das gerade eben vom ConTeXt-Forum hereinkam, ein länglicher Artikel über benchmarking des Raspberry 4:
https://www.tomshardware.com/reviews/raspberry-pi-4-b,6193.html
Gruß,
Rudolf
On Wed, Jun 26, 2019 at 01:25:30PM +0200, tomas@tuxteam.de wrote:
On Wed, Jun 26, 2019 at 12:40:54PM +0200, Harald Weidner wrote:
Hallo,
ein paar Ergänzungen:
[gut fundiertes und sehr interessantes Zeug]
Vielen, vielen Dank! Nehme ich in meiner informellen Sammlung auf.
Ich hoffe, hierzu etwas beigetragen zu haben. ;-)
Zweifelsohne: vielen Dank nochmal dafür.
lg -- tomás
-
Harald Weidner -
Ralf Mattes -
Rudolf Bahr -
tomas＠tuxteam.de