[fli4l] fli4l auf raspberry?

[Hans Bachner]

Hallo Christoph,

erst einmal vielen Dank für die ausführliche Antwort!

Christoph Schulz schrieb am 07.03.2017 um 23:59:
> Hans Bachner schrieb:
>
>> Es gibt allwöchentliche Meldungen über die Fortschritte in s.f.d, in
>> denen kommt der Banana Pi eigentlich nicht vor. Da - jedenfalls vor etwa
>> eineinhalb, knapp zwei Jahren - erst mit dem Port begonnen wurde, hat
>> das bei mir suggeriert, dass hier noch nicht viel weiter gegangen ist.
>
> Die fli4l-Software für den BPi-R1 ist da, wir *paketieren* sie bloß nicht
> wöchentlich, wie wir es für x86 und x86_64 tun. Zum einen ist das zur Zeit
> ein Ressourcen-Problem, zum anderen ist die BPi-R1-Unterstützung natürlich
> auch nicht komplett fertig. Insbesondere OPT_HDINSTALL funktioniert noch
> nicht, aus denselben Gründen wie beim RPi (siehe anderen Post in diesem
> Thread). Man kann jedoch für alle Architekturen die Pakete von der
> Paketsammlung unter http://fli4l.nettworks.org/tarballs/ herunterladen.
> Diese Pakete werden bei jeder Änderung im Code neu erzeugt, so dass die
> Pakete immer den aktuellen Stand der Entwicklung widerspiegeln.

Danke für die Erinnerung an diesen Link.

Auf <http://www.fli4l.de/download/entwicklerversion-40/aktuell.html> 
werden jedenfalls nur die x86(_64) Versionen angeboten, auch sonst habe 
ich auf www.fli4l.de keinerlei Erwähnung des Banana Pi gefunden - daher 
auch mein Eindruck, das Projekt liege auf Eis.

> Dass dies ein Henne-Ei-Problem ist (keine offiziellen testing-Pakete,
> dadurch wenige Nutzer, dadurch wenig Feedback, dadurch wenig "Druck", den
> Port zu vervollständigen, dadurch keine offiziellen testing-Pakete), ist mir
> bewusst. Aber hier im Forum gibt es auch kaum jemanden, der nach BPi-R1
> fragt. Du bist der erste seit langem. Und wer fragt, der wird auch
> entsprechend aufgeklärt.

Wenige Nutzer (und wenig Feedback) gibt's halt auch, weil kaum jemand 
davon weiß. Würden die Pakete auf der Downloadseite der Entwicklerseite 
mit angeboten, gäbe es vielleicht auch schon mehr Nutzer.

>>> Die Unterstützung für den BPi-R1 aka. Lamobo R1 ist doch schon seit Juli
>>> 2015 im Repository. Das von dir angesprochene Problem der Trennung der
>>> Switch-Ports kann ich nicht beurteilen, weil du kaum etwas darüber
>>> geschrieben hast. Wenn es jedoch das Problem ist, das unter FFL-1664
>>> beschrieben ist, dann ist dies bereits März 2016 behoben worden.
>>
>> Mein Stand ist hier <mlob6p$q66$1 at vm-news.spline.inf.fu-berlin.de> vom
>> Juni 2015.
>>
>> Ich habe eine der ersten sunxi Versionen im Juli 2015 heruntergeladen -
>> die war aber wimre insbesondere hinsichtlich Switch/VLAN (darüber habe
>> ich nur gelesen, nicht selbst entsprechende Erfahrungen gemacht) und
>> WLAN (im Master-Modus) noch nicht (uneingeschränkt) benutzbar. Eine
>> saubere VLAN-Trennung ist aber für den Einsatz im Büro unerlässlich.
>
> Schaue dir FFL-1444 für den allgemeinen Fortschritt und FFL-1664 für die
> VLAN-Switch-Problematik an.
>
>> In den wöchentlichen Fortschritts-Berichten war nie von banana pi oder
>> sunxi die Rede, daher hab ich angenommen, dass das Projekt eher auf Eis
>> liegt. Was aber angesichts der mit großem Abstand größeren x86(_64)
>> Community auch durchaus verständlich wäre.
>
> Den Aufwand für die Portierung machen die systemabhängigen Teile -- also
> Betriebssystem-Kern, Boot-Lader, ggf. hardwarespezifische Treiber
> (OPT_HWSUPP etc.).

Das ist mir schon klar.

> Bis auf OPT_HDINSTALL sollte das alles funktionieren,
> soweit ich mich erinnern kann. Wenn bei dir etwas nicht wie geplant
> funktionieren sollte, dann vermerke das bitte im FFL-1444-Ticket.

Ich hab mir noch gestern die aktuelle sunxi-Version heruntergeladen und 
werde sehen, dass ich in den nächsten zwei, drei Wochen ein wenig zum 
Testen komme.

> Bevor es Klagen und Beschwerden gibt: Die interne Grafikkarte wird *nicht*
> unterstützt, und das wird auch so bleiben. Wer also eine physische Konsole
> möchte, benötigt ein serielles Kabel.

Klar - war glaub ich auch von Anfang an so kommuniziert. Ich hab daher 
dem Testgerät, das ich 2015 dem Team zur Verfügung gestellt habe, auch 
gleich ein TTL <--> USB Kabel beigelegt. Zumindest für 
(semi-)professionellen Einsatz halte ich ohnehin die serielle Konsole 
für sinnvoller - die lässt sich über einen entsprechenden Adapter auch 
leicht ins Netzwerk einbinden (und absichern) und ist dann relativ 
Plattform-unabhängig mit einer beliebigen Terminal-Emulation (z.B. 
PuTTY) von überall her gut erreichbar.

>> Noch eine Frage: gilt die Einschränkung, dass das Bootmedium nur unter
>> Linux erstellt werden kann, nur für das erste Mal? Funktioniert in der
>> Folge ein Update über SCP?
>
> Wo steht, dass das Bootmedium nur unter Linux angelegt werden kann? Dies
> sollte unter Windows inzwischen genauso funktionieren (seit November 2015).

Das steht in deinem Beitrag vom 21. Juli 2015:
<molmlv$57a$1 at vm-news.spline.inf.fu-berlin.de>

Dass es da im November des gleichen Jahres eine Änderung gegeben hat, 
ist an mir vorbeigegangen - sorry.

Sobald ich zum Testen gekommen bin, melde ich mich jedenfalls wieder.

Danke für deine Arbeit + schöne Grüße,
Hans.

PS: noch eine Frage: die tarballs gibt es in den Varianten trunk - 
testing - stable, wobei ich angenommen hätte, dass stable die älteste 
der drei Versionen ist. Die letztverfügbaren build-Nummern für die 
meisten Module sind aber 47284/47285/47286 für diese drei Zweige, also 
stable hat die jüngste build-Nummer. Wie darf ich das verstehen?