[Fli4l_dev] FFL-1444: Banana Pi R2

[Alexander Dahl]

Moin,

Artur Kawa schrieb Dienstag, 25. Juni 2019, 10:31 (CEST):
>> Da sehe ich keinen Hinderungsgrund. :-)
>
> Die Kiste habe ich noch nicht. FLI4L läuft noch auf x86 Basis
> und säuft Strom wie ein Loch. Dank an Energiewende und
> 30 Cent / kWh.

Wie gesagt, pcengines APU könnte eine Alternative sein.

> Bei mir ging es ursprünglich um die Frage, R1 oder R2 kaufen,
> weil dort mehrere Netzwerkanschlüsse vorhanden sind.
> Da ich zwei oder drei Subnetze nutzen wollte, schien mir
> das Teil insbesondere auf Grund seines Stromverbrauchs
> mehr als passend.
>
> Ich könnte die R1 Hardware kaufen und damit beginnen.
>
> Es ging mir auch um die Frage, dass ich mich nun mit der
> Unterstützung auf R1 nicht um ein "totes Pferd" kümmere,
> weil schließlich das "bessere" R2 verfügbar ist und
> möglicherweise kein Interesse bestand de R1 weiter zu
> pflegen. Ich weiß nicht, was das FLI4L Team in Planung
> für die Zukunft hatte.

"Das Team" plant an der Stelle nicht viel. Wenn irgendwer Zeit hat,
macht er was und dann wozu er gerade Lust hat oder was dringend ist.

Verabschiedet Euch mal bitte von dieser "Das Team"-Denke. fli4l ist ein
Free Software Projekt, _JEDER_ kann beitragen und wenn irgendwer
außerhalb des Teams Bock hat R1-Support zu machen und zu pflegen, dann
go go go! Ticket-System nutzen, Patches reinknallen und wenn es "dem
Team" zu umständlich wird, die da rauszupopeln und zu committen, kriegt
er oder sie halt commit-Rechte. Fragen im IRC oder hier in
spline.fli4l.dev und wenn das nervt, dann tretet dem Team auf die Füße
für eine öffentliche Mailingliste! *hint*

> Ich meine, wenn es dann 1-2 User nutzen würden, wären
> die Mühen echt um sonst, weil man für die R1 Unterstützung
> Zeit verschwendet und dann nutzt es Niemand.

sunxi bzw. der Support für R1 war ursprünglich neben RPi 1 so eine Art
Testballon wie weit wir mit Arm-Boards kommen können und ob das
überhaupt geht. Grundsätzlich geht das, haben wir ja gesehen.
Perspektivisch wäre es super, wenn es ein generisches armv7 Target gäbe,
damit könnte man die meisten Boards abfeiern, die so rumfliegen und dann
ist R1 nur ein Board von vielen und wird halt mitgepflegt.

> Kann auch sein, dass die R1 Boards durch R2 abgelöst
> werden und man die R1 Hardware in einem Jahr kaum noch
> kaufen kann. Das wäre dann auch so ein Schuss ins Knie.

Dann sind immer noch alte R1 Boards draußen, wenn das nicht absurd
aufwändig wird, kann man die ja weiter supporten.

> Ich bräuchte als ersten Punkt die ganzen Links, wo ich die
> Informationen zum Bauen des FLI bekomme.

Ja es gibt im wesentlichen zwei Themen: "wie nutze ich das FBR
(buildroot)" und "wie baue ich ein fli4l opt Paket". Das verteilt sich
auf die Dokumentation der Pakete 'base' und 'src', wenn Du die tarballs
lädst, hast Du da unterhalb vom Ordner 'doc' irgendwo PDFs zum Lesen.

> Die Buildroot Doku hab ich mir angeschaut. Ist echt gut.

Braucht man nur, wenn man an den buildroot-Paketen im FBR rumfummeln
muss.

> Wo die Sourcen sind weiß ich. Aber das war es dann auch.
> Den Fli kompiliert habe ich bisher noch nie. Aber ich denke,
> dass ich das schon hinbekomme, da ich früher öfter den Linux
> Kernel kompilierte. Wird auch nicht so viel anders sein,
> denke ich.

Das steht ganz gut in der oben erwähnten Doku, für den schnellen
Überblick hilft auch `./fbr-make help` glaube ich.

> Das Wiki, von dem Du sprachst, wo kann man das einsehen?

http://wiki.fli4l.de/ bzw.
https://web.nettworks.org/wiki/display/f/fli4l-Wiki

> Und vor allem: Reicht so ein R1 um 100 MBit Anschluß mit
> OpenVPN bei Vollauslastung zu bedienen oder braucht es
> da schon einen R2?
>
> Kann momentan die Leistung von den A20 ARM Cortex-A7
> nicht recht einschätzen.

Das kann ich persönlich nicht beurteilen, weiß nicht wie schnell die
Kisten sind.

> Welche FLI4L 4.x Version soll ich dann verwenden?

Wenn Du es "nur" benutzen willst, testing oder die weekly tarballs. Wenn
Du entwickeln willst, dann check Dir svn trunk aus! Siehe
http://www.fli4l.de/entwicklung/software-repository/

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6