NetBSD läuft auf Raspberry Pi

Athaba

Libellenliebhaber
Wie heute im NetBSD Blog zu lesen ist unterstützt das Projekt seit kurzem den Raspberry Pi. Auch, wenn es sich bisher nur um einen ersten Schritt handelt und noch an einigen Treibern gearbeitet werden muss bootet das System jetzt bereits in den Multiuser-Modus. Die Entwicklung ist also in vollem Gange.

Post im NetBSD Blog: http://blog.netbsd.org/tnf/entry/wanna_raspberry
Erster Commit: http://mail-index.netbsd.org/source-changes/2012/07/26/msg035951.html
Boot Log: http://mail-index.netbsd.org/port-arm/2012/07/13/msg001367.html
 

.not

Well-Known Member
Das freut mich natürlich ungemein nachdem mein Raspberry Pi in den nächsten Tagen eintreffen sollte. :)
 

carbuncle

Rainbow Six
Ich warte auch schon sehnsüchtig... Die Youtube Videos mit raspbmc sind ja der Hammer. Ein schöner kleiner Media Streaming Client...
 

Athaba

Libellenliebhaber
Meiner sollte auch irgendwann mal ankommen ;) NetBSD wäre dann in der Tat mal interessant...

Also, ich weiß nicht. NetBSD ist vielleicht nicht mehr so groß, wie es mal war, aber es hat ein paar echt geniale neue Dinge, wie Lua Support, ihre automatische Testinfrastruktur (atf), portiert einige Linuxfeatures als erstes, hat Projekte, wie netpgp, ist gemessen an tatsächlichen Lücken immer noch das (so betrachtet) "Sicherste", etc.

Dann gibt es noch das echt portable pkgsrc, das jetzt auch von Minix verwendet wird. Die Pakete ist meist aktueller als andere Projekte (geht jetzt nicht unbedingt um andere BSDs. Ich war mal Gentoo-User und damals war Gentoo bekannt dafür. Dementsprechend verfolge ich das immer noch. Mittlerweile wird es aber von anderen Projekten übertrumpft. Mal abgesehen, dass es wohl nie eine entsprechende Stabilität aufwies und auch sonst weniger Features hatte (DESTDIR zum Beispiel)). Dann gibt es auch noch pkgsrc-wip. Nicht neu, aber von dem was ich gesehen habe immer noch eines der besten Projekte um Neulinge an Land zu ziehen.

Klar, jeder soll das verwenden, was passt und ich unterstelle auch nicht, dass es abwertend gemeint war, aber ich denke nicht, dass NetBSD mit diesen Dingen so uninteressant ist. Vielleicht könnten die oben genannten Dinge, die NetBSD vor allem in der Gesamtheit ziemlich einzigartig machen aber ein wenig mehr Hype vertragen (oder habt ihr von allem gewusst?). Vieles davon ist ja gerade für Entwickler nicht uninteressant.

Zurück zum Thema. Ich wollte den Pi vor ein oder zwei Wochen bestellen, aber die 17 Wochen Wartezeit, die mir RS nennt tun doch ein wenig weh.
 
Zuletzt bearbeitet:

.not

Well-Known Member
Ich warte auch schon sehnsüchtig... Die Youtube Videos mit raspbmc sind ja der Hammer. Ein schöner kleiner Media Streaming Client...
Würde mich da nicht verfrüht freuen, raspbmc ist noch nicht wirklich stabil und angenehm nutzbar - zumindest was man in den ganzen Foren bisher so liest.

Ich seh' jetzt nicht ganz wie dein Beitrag mit zuglufttier's zusammenhängt - er sagt dich selbst, dass es nicht uninteressant ist. Und dann zählst du die Vorteile von NetBSD auf, nur um dann zu sagen dass es keinesfalls abwertend gemeint war? :ugly:
 

carbuncle

Rainbow Six
Würde mich da nicht verfrüht freuen, raspbmc ist noch nicht wirklich stabil und angenehm nutzbar - zumindest was man in den ganzen Foren bisher so liest.


Ich seh' jetzt nicht ganz wie dein Beitrag mit zuglufttier's zusammenhängt - er sagt dich selbst, dass es nicht uninteressant ist. Und dann zählst du die Vorteile von NetBSD auf, nur um dann zu sagen dass es keinesfalls abwertend gemeint war? :ugly:

Jo stimmt, wird noch etwas dauern bis es benutzbar ist. Ich hab eh 10-13 Wochen Lieferzeit :ugly:
 

Amin

Well-Known Member
Also, ich weiß nicht. NetBSD ist vielleicht nicht mehr so groß, wie es mal war, aber es hat ein paar echt geniale neue Dinge, wie Lua Support, ihre automatische Testinfrastruktur (atf), portiert einige Linuxfeatures als erstes, hat Projekte, wie netpgp, ist gemessen an tatsächlichen Lücken immer noch das (so betrachtet) "Sicherste", etc.
...

Ich finde NetBSD auch sehr interessant, vorallem von den Features her (z.B. das sie OpenPGP selbst implementieren). Aber mir scheint, das es als Desktop-System nicht einsetzbar ist, da anscheinend keine originalen Nvidia-Treiber möglich sind? Oder täusche ich mich? Wenn man bedenkt, das auch AMD-Treiber nicht verfügbar sind (zumindest wie bei FreeBSD), wird die Luft für Grafikchips sehr dünn?
Gibt es wenigstens Intel HDx000-Grafik?
 

Athaba

Libellenliebhaber
Da habe ich wieder was angefangen... ;)

Amin, du hast recht. NetBSD ist wohl eher kein Desktop-System, wenn man viel auf Multimedia Wert legt. Ich muss aber ehrlicherweise zugeben, dass ich NetBSD schon lange nicht mehr für so etwas verwendet habe und was Grafiktreiber angeht somit nicht auf dem Stand der Dinge bin.

Der Grund für das Posting war nur, dass ich ein paar Dinge aufzeigen wollte, die sich um NetBSD in letzter Zeit getan haben. Vielleicht interessiert es ja den einen oder Anderen. Wäre cool, wenn es mal wieder eine größere Userbase zustande bekommt. Irgendwie sind vor allem Entwickler daran interessiert, was sich ja mit Lua-Support und atf durchaus unterstreichen lässt. Das Einzige was es vielleicht für den Desktop einigermaßen interessant macht sind aktuelle Pakte und pkgin als Manager. Klar kann man da auch FreeBSD nehmen, muss man aber nicht.

Dass FreeBSD auch auf den Pi portiert wird ist echt cool. Damit gibt es ja schon einige OSs dafür. Ich habe auch etwas von einem AROS-Port gelesen. Auch ein echt cooles Projekt, aber das wird dann wohl zu OT. Wäre nur cool, wenn man mit dem Pi dann eine schöne, offene Plattform für alternative Systeme hat, wo man sich ziemlich sicher sein kann dass es für alles Treiber gibt, vor allem jetzt wo der Desktopmarkt schon seit ein paar Jährchen stark schrumpft. Vielleicht hängen die Geeks dann mal wirklich nur noch an ARMs. Raspberry Pi ist ja da nicht die einzige offene Plattform.
 

carbuncle

Rainbow Six
Das einzige Manko an dem Pi ist dieser proprietäre Videocore IV. Wo ist das Problem dabei dass die Specs offen gelegt werden? Es kann doch nur ein Vorteil sein dass Entwickler durch offene Specs alles aus dem Grafikkontroller rauskitzeln können. Wahrscheinlich ists aber eine Art FPGA wo der Binary Blob die Intelligenz nachlädt. Das offenzulegen könnte wirklich Probleme geben (Lizenzproblem wegen Fremdfirmen).
 

Yamagi

Possessed With Psi Powers
Teammitglied
Ein Problem praktisch aller im Moment erhältlichen ARM-SOC ist, dass sie diverses "Interlectual Property" von Drittfirmen beinhalten. Die meist verbaute PowerVR-GPU mit dem zugehörigen Videobeschleuniger ist da nicht die Spitze des Eisbergs. Das zieht zwei Dinge nach sich:

- Viele ARM-SOC sind unnötig teuer, da diverse IP-Geber ihre Lizenzzahlungen erhalten müssen. Die mögen im Einzelfall gering sein, aber Kleinvieh macht halt auch Mist. Dazu kommen dann noch die Lizenzen für den Patentwahnsinn. Da ist man für die potenteren Chips ganz schnell im Bereich 20$ bis 40$. Gerade im Nicht-High-End Bereich ist das schon ein bedeutender Kostenfaktor.

- Treibertechnisch ist das Ganze eine Katastrophe. Diverse Komponenten haben keine Spezifikation oder unterscheiden sich subtil voneinander, letztendlich gibt es kaum die aus der x86-Welt bekannten Industriestandards. Das zieht sich zum Teil bis auf die Ebene von grundlegenden Dingen wie Speicherverwaltung herunter. Linus vom Linux regte sich deshalb ja auch schon mal lautstark auf, dass er es Leid ist, zig verschiedene ARM-Inkarnationen mit noch mehr kaputten Treibern zu pflegen. Das Ganze in Kombinationen mit schön defekten Blobs.

Beides öffnet die Tür für Intel. Schon der Smartphone-Atom Medfield kann mit der unteren ARM-Oberklasse gut mithalten, ist dank eines deutlich stärkeren Kerns zudem weniger auf Threading angewiesen und damit besser zu programmieren. Zudem kann Intel einen SOC komplett selbst anbieten, ohne auf IP von Drittanbietern zurückgreifen zu müssen. Nicht zuletzt haben sie ja mit großen Tamm-Tamm angekündigt, dass PowerVR mit der kommenden Generation rausfliegt und durch GMA ersetzt wird. GMA mag nie besonders toll gewesen sein, aber besser als dies andere Geschmeiß ist es alle mal. Zusammen mit der neuen Architektur ab 2013 und 22nm kann das zu einem "Conroe-Effekt" führen. Ich sage nicht, dass Intel schnell Monopolist wird, aber das ARM so einfach durchmarschieren und sich den ganzen SOC-Markt krallen kann, sehe ich auch nicht.
Damit ARM aus der "Proprietäre Hardware"-Ecke rauskommt, müssen sie erst einmal eine in sich konsistente und weitgehend gleichartige Plattform bauen. Es wurde zwar viel über Microsofts Entscheidung nur 4 ARM-Plattformen zu unterstützen gelästert, aber damit könnte die Bildung eines Industriestandards beginnen. Dann ist da noch das kommende ARM8... Zumindest bleibt es spannend.

Aber das war nun schon wieder Offtopic, obwohl ich es eigentlich gar nicht wollte. :/
 

Yamagi

Possessed With Psi Powers
Teammitglied
Ich vermute, dass man es historisch sehen muss. MIPS - ja lange Zeit eine Tochter von SGI und auf Ultra-High-End-Prozessoren fixiert - kam relativ spät in das Embedded-Geschäft. Nachdem die Firma eigenständig wurde, war sie recht klein und es fehlte wahrscheinlich an Kapital. Trotzdem gelang es MIPS nennenswerte Marktanteile zu erringen, gerade im Bereich Netzwerktechnik waren und sind ihre 64-Bit Prozessoren (z.B. als SOC von Octeon) sehr beliebt.

PowerPC behauptete lange von sich die meistverkaufteste CPU-Architektur zu sein und PPC war auch im Embedded-Bereich sehr beliebt. Allerdings sieht man seit einigen Jahren immer weniger PPC, sie befinden sich subjektiv gesehen deutlich auf dem Rückzug. Ich weiß nicht genau woran es liegt, aber ein Punkt ist sicher das lange Zeit relativ starre Lizenzmodell und die nicht immer glückliche Beziehung zwischen Freescale und IBM.

SPARC sah man einige Zeit lang im Embedded-Bereich, gerade LSI war dort aktiv. Allerdings ist es eingeschlafen, es scheint keine nennenswerten SOC auf SPARC-Basis zu geben. Dinge wie Super-H waren sowieso immer Außenseiter.

Im Rückblick gesehen hat ARM einige Dinge richtig gemacht und einfach Glück gehabt:
- ARM war sehr billig, hat damit den Markt vom unteren Low-End-Bereich aufgerollt.
- ARM hatte schon früh herausragendes Powermanagement.
- ARM hatte Glück das richtige Produkt zur richtigen Zeit zu haben und damit in Smartphones praktisch alternativlos zu werden.
- ARM hatte einen guten Draht zu Apple.
- Die Konkurrenz hat geschlafen.

Dabei ist ARM nicht einmal eine sooo schöne Architektur. Gerade das kommende ARMv8 klingt teilweise doch sehr "bastelig". Es ist halt auch eine alte und historisch gewachsene Struktur. Man kann schlecht in die Zukunft schauen, aber ich denke, dass das Rennen sich auf ARM und x86 beschränken wird. PPC, SPARC und Exoten sind schon zu weit zurückgefallen und werden in ihren Spezialbereichen bleiben, MIPS fehlt die Marktmacht. Einzig Chinas noch zu wählende "Staatsarchitektur" mag daran was ändern können. Für Intel und AMD besteht die Herausforderung darin, das überzüchtete x86 "klein" zu bekommen. Intel ist recht gut davor, aber wie gut sie es am Ende wird nur die Zukunft zeigen können. ARM darf durch seinen Hype nicht größenwahnsinnig werden und muss beachten, dass Intel und AMD bei leistungsfähigen CPUs einen extrem Vorsprung haben. Zudem verheizen moderne, leistungsstarke CPUs einen Großteil der Energie im Cache und Bussystem und nicht in den Kernen, dass die "x86-Steuer" wirklich existiert ist nie bewiesen worden. Eine leistungsstarke ARM-CPU könnte den Effizienzvorteil der Architektur verlieren oder zumindest auf ein Maß schrumpfen lassen, dass er irrelevant wird. Bei den Überlegen muss man auch noch im Kopf behalten, dass Intel eine der wenigen ARM-Volllizenzen besitzt, also nicht nur Kernel einkaufen und verbauen kann, stattdessen auch eigene entwickeln. Zwar hat man das XScale-Geschäft verkauft, aber wenn es hart auf hart kommt, ist eine "Intel-ARM-CPU" nicht auszuschließen. Wie ich schrieb, es wird spannend. :)
 

Amin

Well-Known Member
1987 wurde der erste kommerzielle ARM produziert. Das war auch der erste RISC für den Mainstream, zu der Zeit gab es ja nur Inhouse-RISCs (HP). Immerhin hatte ich selber schon 1991 einen Acorn Archimedes mit ARM3 zu Hause stehen, zu einem PC-Preis! Die konkurrierten damals zu Amiga und x86-PCs.

Da war MIPS im Power Play-Magazin nur als sündhaft teure SGI-64-Bit-Workstation ein Begriff.

1992 kam dann der Apple Newton PDA mit einem ARM6 auf dem Markt, der wohl einfach DER Beweis war, das man 32 Bit-RISC-Power stromsparend in einem Handheld betreiben konnte. Auch wenn der Newton kein kommerzieller Erfolg war, war es einfach ein technologischer Beweis. Danach sprangen die Palm-PDAs von 16-Bit-Motorola auch auf 32-Bit-ARMs auf. Damit war wohl der Siegeszug für ARM unaufhaltsam.

MIPS ist doch erst viel später zu einem Embedded-Chip geworden, da es lange "nur" ein teurer Workstation-Chip war.
 

Yamagi

Possessed With Psi Powers
Teammitglied
FreeBSD hat nun eine grundlegende Unterstützung in 10-CURRENT:
Code:
Author: gonzo
Date: Thu Aug 30 20:59:37 2012
New Revision: 239922
URL: http://svn.freebsd.org/changeset/base/239922

Log:
  Add barebone Raspberry Pi port. Supported parts:
    - Interrupts controller
    - Watchdog
    - System timer
    - Framebuffer (hardcoded resolution/bpp)
 

namor

Imperator
Heute wurde der graphics-blob des R-PI open sourced unter BSD3 license. Ein Port wäre IMO interessant: http://www.raspberrypi.org/archives/2221

EDIT: "This repository contains the source code for the ARM side libraries used on Raspberry Pi. These typically are installed in /opt/vc/lib and includes source for the ARM side code to interface to: EGL, mmal, GLESv2, vcos, openmaxil, vchiq_arm, bcm_host, WFC, OpenVG." (https://github.com/raspberrypi/userland)
 
Zuletzt bearbeitet:
C

CrimsonKing

Guest
Taugt NetBSD als System für ein RPi-basiertes NAS oder sollte man dafür doch lieber auf was andres zurückgreifen?
 

Crest

rm -rf /*
Teammitglied
CrimsonKing: Der R-PI taugt von hinten bis vorne nicht als NAS Hardware. Das SoC besteht aus einer lahmarschigen CPU mit winzigen Caches und einer langsamen GPU, die eigentlicher Herr im Hause ist, sowie USB als Systembus. Sowohl Platten als auch der 100Mb/s NIC müssen über den selben USB 2.0 Controller angesprochen werden. Das Ergebnis ist du bekommst nicht mal das 100Mb/s Ethernet voll mit nem einfachen HTTP oder FTP Server.
 
Oben