Da ich immer wieder nach Empfehlungen für die Konfiguration des Kernels speziell für den Cubietruck (Specs) gefragt werden, habe ich nun einmal meine Konfiguration zusammengetragen. Ausgehend von der sunxi_defaultconfig habe ich hier nur Punkte aufgezählt, die mir besonders wichtig erscheinen und/oder von der Default-Konfiguration abweichen.
Für Anregungen, Wünsche oder Hinweise auf Fehler bin ich natürlich immer offen.
General setup
[*] Support for paging of anonymous memory (swap)
[*] System V IPC
[*] POSIX Message Queues
[*] open by fhandle syscalls
[ ] uselib syscall
Timers subsystem --->
Timer tick handling (Idle dynticks system (tickless idle))
[ ] Old Idle dynticks config
[*] High Resolution Timer Support
CPU/Task time and stats accounting --->
Cputime accounting (Simple tick based cputime accounting) ---> ?
[*] BSD Process Accounting
[*] Kernel .config support
[*] Enable access to .config through /proc/config.gz
[*] Optimize for size
[ ] Disable heap randomization
[*] Optimize very unlikely/likely branches
Stack Protector buffer overflow detection (Regular) --->
Im allgemeinen sollte man Server bzw. Embedded-System hinreichend mit Speicher ausstatten, damit man nicht in die Verlegenheit kommt Daten auf die Festplatte oder gar Flash auszulagen. Dennoch sollte man eine ausreichend große Swap-Partition einrichten um Lastspitzen ohne OOM-Killer überstehen zu können. „Support for paging of anonymous memory (swap)“ sollte also unbedingt aktiviert sein.
Die System V IPC ist ein essentieller Bestandteil der meisten Distributionen und sollte immer aktiviert sein, denn über diese Funktionen tauschen Prozessen untereinander effizient Daten aus.
Neuere Versionen von udev (>=208) erfordern, dass „open by fhandle syscalls“ gesetzt ist.
CONFIG_USELIB spielt heute keine Rolle mehr, da dieser Systemaufruf nur von der antiken libc5 und früher benötigt wurde und seit der glibc nicht mehr verwendet wird. Die Wahrscheinlichkeit sehr, sehr alte, binäre Software für die armv7-Architektur zu finden ist verschwindend gering.
loadable module support
[*] Enable loadable module support
[*] Module unloading
[*] Compress modules on installation
Compression algorithm (GZIP) --->
System Type
[*] MMU-based Paged Memory Management Support
[*] Allwinner SoCs --->
[ ] Allwinner A10 (sun4i) SoCs support
[ ] Allwinner A10s / A13 (sun5i) SoCs support
[*] Allwinner A31 (sun6i) SoCs support
[*] Allwinner A20 (sun7i) SoCs support
[ ] Allwinner A23 (sun8i) SoCs support
[ ] Allwinner (sun9i) SoCs support
[*] Support Thumb user binaries
[*] Enable ThumbEE CPU extension
[*] Enable kuser helpers in vector page
[*] Enable VDSO for acceleration of some system calls
[*] Enable the L2x0 outer cache controller
[*] ARM errata: LoUIS bit field in CLIDR register is incorrect
Kernel Features
(4) Maximum number of CPUs (2-32)
[ ] Support for hot-pluggable CPUs
Preemption Model (No Forced Preemption (Server)) --->
[*] High Memory Support
[*] Allocate 2nd-level pagetables from highmem
[*] Allow for memory compaction
[*] Enable KSM for page merging
[*] Enable cleancache driver to cache clean pages if tmem is present
[*] Enable frontswap to cache swap pages if tmem is present
<*> Common API for compressed memory storage
CPU Power Management
CPU Frequency scaling --->
<*> 'ondemand' cpufreq policy governor
<M> 'conservative' cpufreq governor
Floating point emulation
[*] Advanced SIMD (NEON) Extension support [*] Support for NEON in kernel mode
Die NEON SIMD-Erweiterungen bringen gerade bei den heute üblichen Verschlüsselungsalgorithmen erhebliche Geschwindigkeitsvorteile und sollten unbedingt aktiviert werden.
Power management options
[ ] Suspend to RAM and standby
Networking support
--- Networking support
Networking options --->
<*> Packet socket
<*> Packet: sockets monitoring interface
<*> Unix domain sockets
<*> UNIX: socket monitoring interface
<*> The IPv6 protocol --->
Device Drivers
[*] Network device support --->
[*] Ethernet driver support --->
[*] Allwinner devices
<*> Allwinner A10 EMAC support
[*] STMicroelectronics devices
<*> STMicroelectronics 10/100/1000 Ethernet driver
<*> STMMAC Platform bus support
<*> Allwinner GMAC support
< > USB Network Adapters ----
Graphics support --->
Frame buffer Devices --->
<*> Support for frame buffer devices --->
[*] Simple framebuffer support
Console display driver support --->
<*> Framebuffer Console support
[*] Map the console to the primary display device
[*] USB support --->
<M> USB Mass Storage support
[*] LED Support --->
-*- LED Trigger support --->
<M> LED Timer Trigger
<*> LED One-shot Trigger
<*> LED Heartbeat Trigger
File systems
< > Second extended fs support
<*> The Extended 4 (ext4) filesystem
[*] Use ext4 for ext2/ext3 file systems
[*] Ext4 POSIX Access Control Lists
[*] Ext4 Security Labels
<*> Ext4 Encryption
<*> Btrfs filesystem support
[*] Btrfs POSIX Access Control Lists
<*> F2FS filesystem support
[*] Dnotify support
[*] Inotify support for userspace
[*] Filesystem wide access notification
[*] Quota support
<M> FUSE (Filesystem in Userspace) support
<M> Overlay filesystem support
DOS/FAT/NT Filesystems --->
<*> VFAT (Windows-95) fs support
Pseudo filesystems --->
[*] Tmpfs virtual memory file system support (former shm fs)
[*] Network File Systems --->
<*> NFS client support
< > NFS client support for NFS version 2
< > NFS client support for NFS version 3
<*> NFS client support for NFS version 4
[*] Root file system on NFS
<M> CIFS support (advanced network filesystem, SMBFS successor)
Kernel hacking
[*] Magic SysRq key [*] Filter access to /dev/mem
Security options
[*] Restrict unprivileged access to the kernel syslog
Cryptographic API
<*> User-space interface for hash algorithms
<*> User-space interface for symmetric key cipher algorithms
<*> User-space interface for random number generator algorithms
[*] Hardware crypto devices --->
<M> Support for Allwinner Security System cryptographic accelerator
[*] ARM Accelerated Cryptographic Algorithms --->
<*> SHA1 digest algorithm (ARM NEON)
<*> SHA-224/256 digest algorithm (ARM-asm and NEON)
<*> SHA-384/512 digest algorithm (ARM-asm and NEON)
<*> AES cipher algorithms (ARM-asm)
<*> Bit sliced AES using NEON instructions
Hallo,
die Umstellung auf eine neue Mainline – Kernelversion >4.0 (bisher 3.4.105) macht mir insofern Sorgen, dass ich die neue DTB Konfiguration für die GPIOs nicht verstehe. Sowohl selbst gesuchte Interrupts wie auch die kryptische Adressfindung bieten mehr als eine Möglichkeit, das System kaputtzuschießen.
Gibt es hier eine allgemeine FEX ähnliche Grundkonfiguration für den CT ?
[gpio_para]
gpio_used = 1
gpio_num = 32
gpio_pin_1 = port:PH20
gpio_pin_2 = port:PH10
gpio_pin_3 = port:PC19
…
Danke für eine Hilfestellung oder den Verweis auf ein Tool, was bei der Bearbeitung der DTS Dateien helfen kann.
Hallo,
meines Wissens nach muss für den Mainline-Kernel der DTB nicht mehr angepasst werden, weil die GPIOs komplett via SysFS exponiert werden, wenn der Kernel mit CONFIG_GPIO_SYSFS übersetzt wurde. Dies ist bei meinen Kernels der Fall. Nähere Infos stehen hier:
http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel
Ich habe bisher nur die via GPIO gesteuerten LEDs verwendet, aber selbst noch keine zusätzliche Hardware an den Cubietruck gesteckt. Ich würde mich über eine Rückmeldung freuen, falls dies so klappt 😉
Hallo, ich arbeite mich gerade in einen kleinen Homeserver aus Cubietruck und Nextcloud ein und würde gerne wissen, ob da prinzipiell kein Suspend/Standby möglich ist (oben ist die entsprechende Checkbox auch nicht markiert) … schließlich könnte das gute Stück bei mir doch viele Stunden am Tag auch einfach schlafen.
Suspend und Standby sind beides prinzipiell möglich, aber aus meiner Sicht nicht sinnvoll. Der gemessene IDLE-Stromverbrauch (sekundärseitig) unterschied sich bei mir nicht vom Suspend-To-RAM. Eine eventuell angeschlossene SATA-Festplatte in den Standby zu schicken lohnt sich aber – dies kann via „hdparm“ auch händisch ausgelöst werden. Suspend-To-Disk ginge theoretisch auch, jedoch hat man dann das Problem des Aufweckens. Wake on LAN wird nicht unterstützt und wenn man eine IP-Schaltsteckdose dazwischensteckt, verbraucht diese dann im Durchschnitt mehr, als man durch diese Aktion einsparen könnte. Ich für meinen Teil nutze die „Schlafzeiten“ für besonders CPU-intensive Jobs wie Offsite-Backups, Datenbankenoptimierung, CRON-Jobs, OCR-Erkennung von PDFs in der Cloud, Systemupdates… und so weiter. Also mein Tipp: Hier ist nicht viel Einsparpotential, man sollte eher nach Verwendungsmöglichkeiten für die zur Verfügung stehende Rechenleistung suchen.
Hallo Robert,
danke für Deine Rückmeldung, ist schon einleuchtend. Da ich meine Linuxkenntnisse von vor >10 J. erst wieder reaktivieren muss, gibts für das Serverlein halt noch nicht so viel zu tun in den Schlafzeiten … 😉 Und da die Platte trotz entsprechender hdparm-Anweisung trotzdem immer wieder nach <1 Minute aufwacht (muss mal schauen, ob ich mit blktrace (?) dahinterkomme, wer/was das ist), hatte ich gedacht, es wäre eleganter, die Maschine für die Nachtzeiten einfach komplett schlafen zu legen …
Wenn ich mal raten darf, schreibt einer der Daemons z.B. der Log-Daemon zyklisch auf die Platte. Es lohnt sich rund um die Nextcloud ein wenig Systemtuning zu betreiben. Z.B. da Temp oder Logverzeichnis ins RAM legen. Ich habe diesbezüglich schon einmal ein paar Tipps für die OwnCloud 9.x gegeben, die sich natürlich auf die NextCloud anwenden lassen.