Welcher SBC ist Open Source?

mir keiner bekannt.
arduino ist kein sbc.

arduino ist ein mikrocontroller.
beim rpi liegt nicht alles offen, cpu und gpu.

Dann sollte man erstmal klären:
- Was ist ein SBC
--> Arduino schonmal nicht!

- Was meint OpneSource
--> Software?
--> SoftCore?

Oder meinst du auch OpenHardware?

Das ist eine schwierige Frage, denn: Was genau braucht es denn damit 
der SBC "Open Source" ist?

Natürlich, RPi, BBB, und Co., da läuft überall ein Linux drauf, und im 
zweifel lassen sich die Boards auch Bare-Metal programmieren. Die 
eigentliche Software ist also Open-Source. Und die Schaltpläne der 
Boards können auch eingesehen werden. Aber: Reicht das um das ganze als 
"Open-Source" zu bezeichnen?

Ich sag mal was für Mich Open-Source wäre:
Open-Source wäre für mich, wo alles einsehbar bar! Also nicht nur Code 
vom OS oder Schaltpläne vom Board, sondern auch, was In der CPU/GPU 
passiert (und damit meine ich keinen Verkackten "Block-Schaltbilder"). 
Und genau hier scheitert es. ARM ist noch mehr zugenagelt als x86. Was 
in der CPU für Microcode und Backdoars ausgeführt werden? Keine Ahnung. 
Weiß nur der Hersteller...

Bei ARM ist das Problem, das Nur der Core lizensiert wird, was dann aber 
an Peripherie noch dazu kommt, das kann der Hersteller frei entscheiden.

Bei x86 gibt es (soweit ich weiß!) an der Stelle kein Spielraum. der 
Core ist der Core, fertig. Was das Mainboard nachher an Schnittstellen 
hat, liegt beim Mainboard-Hersteller, hat in dem Sinne aber nichts mit 
der CPU zu tun.
Und bei x86 ist ganz klar das Problem, der Microcode, die Intel MMU und 
die Intel Innovation Engine. Das sind nämlich 3 Teile die sich jeder 
Kontrolle entziehen, sowohl der Kontrolle durch das OS, als auch der 
Kontroller des Nutzers, als auch der Kontrolle der Kernel-Hacker. Intel 
weiß, was darin passiert. Der Rest der Welt darf raten...
BIOS/UEFI/SecureBoot sind ebenfalls so Sachen, die von den 
Boardherstellern nicht offengelegt wird.

Was wäre eine Open-Source alternative? FPGA!
Moment, stop, nein, nicht wirklich. Hier ist wieder das Problem: Selbst 
wenn man den Code hätte, der Ausgeführt wird, weiß man was da sonst noch 
so im inneren passiert? Vielleicht auch ein kleiner Teil des FPGA-Cores 
der eine versteckte Firmware vom Hersteller hat?

Also, die Frage ist: Was genau ist für Dich Open-Source?
Reicht es dir, die Board-Schaltpläne und das OS einsehen zu können?
Dann ist Arduino Open-Source, fällt aber nicht unter SBC.
Dann sind RPi, BBB und Co. SBC die auch Open-Source sind.

Grüße

Moin,

Schnurrbart Ente schrieb:
> Aber die Software ist bei allen OpenSource. Was bedeutet das?

Nicht alle Software ist OpenSource. Bei dickeren Chips, wie sie in den 
diversen $OBST-pi Rechnern verbaut sind, gibts oft mehr oder weniger 
kleine (aber deshalb nicht unwichtige) Teile, die's nur als Binaerblob 
gibt. Gerne davon betroffen ist:

Der erste Bootloader, also das erste Stueck Software, das der Prozessor 
aus einem vom user programmierbaren Flash laed und ausfuehrt. Das kann 
ein kleines binary sein, das "nur" u-boot laed, aber signiert sein muss, 
damit der Prozessor es ausfuehrt.
Saemtliche Software, die um Hardwarebeschleunigung herum arbeitet. 
Manche Funktionen z.b. Graphik, Audio/Video-Codecs, 
Ver/Entschluesselungen lassen sich durch spezielle Hardware ausserhalb 
des Prozessors deutlich schneller abarbeiten. Zu dieser Hardware gibts 
oft vom Hersteller keine Unterlagen fuer normale Sterbliche. Mit Glueck 
evtl. ein paar Binaries, die diese Hardware ansprechen und deren 
Interface zum Prozessor hin mehr oder weniger duerftig dokumentiert ist.

Das sind die ueblichen Verdaechtigen.

> Kann man da nur die I/O selber programmieren oder noch etwas tiefer
> gehen?

Kommt halt drauf an, was "tiefer" heisst. An ein paar Pins wackeln wird 
eher funktionieren, als z.B. schnelle DCT-Funktionen per 
Videobeschleunigung zu programmieren.


> Also irgendwie den Prozessor programmieren oder so?
"Prozessor programmieren" sollte keine Probleme machen, da der 
Prozessortyp meist gut dokumentiert ist und man zumindest fuer die 
gaengigen Prozessoren (ARM) an jeder Ecke mit Crosscompilern 
zugeschuettet wird.

Gruss
WK

Scelumbro schrieb:
> Lass mich raten - du kompilierst deinen Linuxkernel selbst
Lass mich raten - du bist zu doof um eine Suchmaschine deiner Wahl zu 
benutzen?

Scelumbro schrieb:
> Für den RPI gibt es keine Schaltpläne
Ach, und was ist das hier?
https://www.raspberrypi.org/wp-content/uploads/2012/04/Raspberry-Pi-Schematics-R1.0.pdf

Rene S. schrieb:
> Dann sollte man erstmal klären:
> - Was ist ein SBC
> --> Arduino schonmal nicht!

Wieso nicht? Natürlich ist das ein SBC, wenn man unter SBC "single board 
computer" versteht.

Ein Microcontroller ist der AVR (oder ARM), der auf die Arduinoplatine 
gelötet ist.

Tim M. schrieb:
> Also wo kann ich wirklich nachvollziehen was die CPU macht?

Auf welchem Level hättest Du das gerne? Auf Bit- und Registerebene, oder 
möchstest Du den internen Logikgattern zusehen können, oder gar den 
einzelnen Transistoren?

Tim M. schrieb:
> Mir ist schon klar, dass du dich über mich lustig machst,

Das ist ein Missverständnis. Es gibt halt unterschiedliche Sichtweisen, 
was man unter "nachvollziehen, was eine CPU macht" versteht.

Sehen, was ein Assemblerprogramm anstellt, sehen, was in den internen 
Registern abläuft, wenn ein einzelner Befehl abgearbeitet wird, oder 
auch sehen, was auf den verschiedenen Bussen des Controllers/Prozessors 
während der Abarbeitung von Befehlen geschieht.

Das ist ernstgemeint.

Für ersteres genügt irgendein Controller, bei dem die 
Assemblerprogrammierung ausreichend gut dokumentiert ist (d.h.: 
Praktisch jeder, wie sonst sollte man dafür Programme schreiben?), für 
die weiteren Einsichten bräuchte man z.B. VHDL-Modelle des CPU-Kerns und 
einen fetten Simulator.

Moin,

Tim M. schrieb:
> Welche Architektur kommt denn momentan am nächsten an den Begriff "Open
> Source" heran? ARM, X86, MIPS, Sparc?

Das hat nichts miteinander zu tun. Du kannst auf allen Architekturen 
Open und Closed source schreiben und anbieten. Es ist das drumherum; 
alles was nicht-Prozessor ist, was Probleme macht: 
Graphikbeschleunigung, Videocodecs, Cryptounits,....
Und dann evtl. noch ein Signaturcheck im 1.Stage bootloader oder wie 
beim RaspPI - dass der 1.Stage bootloader garnicht von der eigentlichen 
CPU ausgefuehrt wird. Aber auch das ist voellig von der CPU-Architektur 
unabhaengig.

Gruss
WK

Tim M. schrieb:
> Aber für den Prozessor finde ich nur Blockschaltbilder. Hier würde ich
> meine Nase einfach tiefer reinstecken wollen

Für den entsprechenden ARM-Kern (ARM11) hast Du Dir die Dokumentation 
von ARM selbst schon 'reingezogen?

https://www.arm.com/products/processors/classic/arm11/arm1176.php
https://www.arm.com/products/processors/classic/arm11/index.php