Hallo Forum, Versuche gerade einen 5.1.1 Kernel auf dem BPi-R2 zu starten. Habe den dtb und das zImage erzeugt und via U-Boot temporär ins Env eingetragen. Nach dem boot Kommando führt das System einen Reboot via CPU reset aus. Kann mir bitte jemand zu der u.g. Ausgabe einen nützlichen Hinweis geben. Ergänzend sei gesagt, dass ich nicht das uInitrd und das FS neu für Kernel 5.1.1 erzeugt habe, da ich erst den Startvorgang des Kernels mit seinen Meldungen betrachten wollte. Der Bootvorgang läuft von der SD-Karte. >binwalk arch/arm/boot/zImage DECIMAL HEXADECIMAL DESCRIPTION ------------------------------------------------------------------------ -------- 36 0x24 Linux kernel ARM boot executable zImage (little-endian), load address: "0x00000000", end address: "0x00058820" 9308 0x245C xz compressed data 9529 0x2539 xz compressed data >file arch/arm/boot/zImage arch/arm/boot/zImage: Linux kernel ARM boot executable zImage (little-endian) Ich habe auch keine weiteren Kernel-Patches eingespielt, weil ich der Meinung war, dass wen im arch/arm/boot/dts/ Verzeichnis ein mt7623n-bananapi-bpi-r2.dtb DT-Blob steht, dies nicht nötig sei. Eventuell irre ich mich da aber!? U-Boot> boot switch to partitions #0, OK mmc1 is current device 1092 bytes read in 12 ms (88.9 KiB/s) Running boot/boot.scr from: mmc 1:1 using boot/boot.scr ## Executing script at 85f80000 Boot script loaded from device 1 127 bytes read in 9 ms (13.7 KiB/s) 28473 bytes read in 18 ms (1.5 MiB/s) 7931375 bytes read in 412 ms (18.4 MiB/s) 362528 bytes read in 33 ms (10.5 MiB/s) Booting boot/zImage5 boot/uInitrd boot/dtb/mt7623n-bananapi-bpi-r2-mw.dtb from: mmc 1:1 using bootargs=console=ttyS2,115200n1 root=UUID=3046aca4-3ffe-4500-a71 Kernel image @ 0x82000000 [ 0x000000 - 0x058820 ] ## Loading init Ramdisk from Legacy Image at 86080000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 7931311 Bytes = 7.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 86000000 Booting using the fdt blob at 0x86000000 Loading Ramdisk to 8f86f000, end 8ffff5af ... OK Loading Device Tree to 8f865000, end 8f86ef38 ... OK Starting kernel ... data abort <========== ????????????????????????????????????? pc : [<82000030>] lr : [<fff97b81>] reloc pc : [<03e69030>] lr : [<81e00b81>] sp : ffb95770 ip : 00000018 fp : 00000400 r10: fffd48d8 r9 : ffb95ee0 r8 : 00000000 r7 : 00000000 r6 : 82000000 r5 : fffd62fc r4 : 00000000 r3 : 00006f39 r2 : 00000000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: b80cf000 016f2818 00000000 00058820 (04030201) Resetting CPU ... resetting ... Sonst sieht der Bootvorgang wie folgt aus: Starting kernel ... Loading, please wait... starting version 237 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. ... Danke für Eure Hilfe! Markus
Du solltest wenigstens einen Kerneldebugger bei der Hand haben um solche Experimente auch zufriedenstellend durchzufuehren. Dann koenntest du naemlich feststellen, wo da geOOOPsed wird. (Stackframe etc.) So wird das nichts.
P.S.: Die alte initrd mit dem neuen Kernel verwenden zu wollen, ist auch mutig ... aeeh ne, eher doof.
@Markus, hast du auch die Kernel-Modules generiert und auf dem Target ins /lib/modules/ kopiert? targetdir=/mnt/rootfs ... make modules INSTALL_MOD_PATH=$targetdir make modules_install INSTALL_MOD_PATH=$targetdir
:
Bearbeitet durch User
Hatte noch keinen Modulsupport enabeled! The present kernel configuration has modules disabled. Type 'make config' and enable loadable module support. Then build a kernel with module support enabled. make: *** [Makefile:1324: modules] Fehler 1 Mir ging es erst einmal den reinen Kernel erfolgreich zu kompilieren und dann zu starten. Sobald ihm ja was fehlt, motzt er dann meist, z.B. beim Laden von falschen Versionen von Modulen aus einer Initrd oder beim fehlen eines Filesystems etc. @Mutluit M. Werde mal Deinen Vorschlag umsetzen. Markus
Also, ich kompiliere den Kernel bis jetzt ohne initrd/initramfs. Es erzeugt uImage und die dazugehörigen Module. Die Module muss man manuell auf dem Target unter /lib/modules ablegen, uImage kannst du auch auf einem TFTP-Server ablegen, wovon u-boot es dann lädt --> in boot.cmd/.scr entsprechend angeben. Kann mein script für TFTP-boot posten falls du brauchst. Nachtrag: ahso, fällt mir jetzt wieder ein: man macht ja initrd/initramfs haupts. um die Module darin zu verpacken. Um ehrlich zu sein, das hab ich noch nicht gemacht, wollte aber demnächst auch mal gemacht haben :-)
:
Bearbeitet durch User
Markus W. schrieb: > Starting kernel ... > > data abort <========== ????????????????????????????????????? Ein "data abort" ist ein harter Absturz, der hat mit Modulen & Co wohl nicht viel zu tun - nicht gefundene Module würden eher irgendeine Kernel-Eigene Fehlermeldung produzieren. Markus W. schrieb: > pc : [<82000030>] Schau doch mal via gdb und der vmlinux Datei oder System.map was für eine Funktion das ist:
1 | arm-linux-gnueabihf-gdb vmlinux |
2 | > info symbol 0x82000030 |
Wobei diese Adresse etwas verdächtig ist - das scheint ganz am Anfang des Image zu sein, d.h. es crasht praktisch sofort (lange bevor irgendwas mit Initrd und Modulen gemacht wird)? Kommt die Meldung vielleicht sogar von U-Boot, weil der Kernel da noch gar keine eigenen Exception Handler gesetzt hat? load address: "0x00000000" - verdächtig. Wie kommt das?
@Markus, hier kannst du evtl. einige Anregungen bekommen: https://www.piprojects.net/debian-image-bauen/ Hat mir selbst sehr geholfen, in die Materie der Image-Erstellung einzusteigen.
Uh oh: > Kernel image @ 0x82000000 > [...] > data abort > PC: [<82000030>] Das ist verdammt weit vorne im Kernel. Da frage ich mich ob die Compiler Flags stimmen oder der korrekte Starup Code verlinkt wurde. Übrigens: > load address: "0x00000000", end address: "0x00058820" könnte schon das Problem sein: Der Kernel wurde IMHO an die flasche Adresse gelinkt.
@Markus, dumme Frage: benutzt du auch eine ARM-Toolchain, d.h. ein Crosscompiler, zum kompilieren, oder kompilierst du vlt. mit dem x86-Compiler auf dem PC? :-)
:
Bearbeitet durch User
@All Danke für die Anregungen und Einwände. Ich kompiliere mit make clean make -j4 ARCH=arm CROSS_COMPILE=arm-suse-linux-gnueabi- zImage dtbs LOADADDR=0x82000000 (das ist eine minimal Konfiguration) Dann boote ich den BPi-R2 mit seinem OS root@bananapir2:/boot# cat /etc/os-release NAME="Ubuntu" VERSION="18.04.2 LTS (Bionic Beaver)" Kopiere die u.g. Files aufs Target cp arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb <TARGET>/boot/dtb/ cp arch/arm/boot/zImage <TARGET>/boot/zImageX mit [X:1...9] Mache einen reboot und drücke die Tastatur um ins Uboot zu kommen. Dort setze ich mit env edit die beiden ENV-Vars: auf mmcfdtfile=boot/dtb/mt7623n-bananapi-bpi-r2.dtb und mmckernfile=boot/zImageX Mit diesen temporären Settings boote ich dann. Markus Nachtrag zum GCC: >arm-suse-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-suse-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/arm-suse-linux-gnueabi/7/lto-wrapper Target: arm-suse-linux-gnueabi Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++ --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp --disable-libvtv --disable-libmpx --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-7 --program-prefix=arm-suse-linux-gnueabi- --target=arm-suse-linux-gnueabi --disable-nls --with-sysroot=/usr/arm-suse-linux-gnueabi --with-build-sysroot=/usr/arm-suse-linux-gnueabi --with-build-time-tools=/usr/arm-suse-linux-gnueabi/bin --with-arch=armv6zk --with-tune=arm1176jzf-s --with-float=hard --with-abi=aapcs-linux --with-fpu=vfp --disable-sjlj-exceptions --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 7.4.1 20190424 [gcc-7-branch revision 270538] (SUSE Linux)
:
Bearbeitet durch User
Also, ich kenne die Details von R2 nicht, aber bist du dir wirklich sicher mit diesen: --with-arch=armv6zk --with-tune=arm1176jzf --with-abi=aapcs-linux ? Ich benutze für mein R1 und M1 folgendes: export PATH="/path/to/my/toolchain/bin:$PATH" export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabihf- ... Ich hatte mir meine toolchain vor einiger Zeit selber kompiliert: $ TOOLCHAIN/bin/arm-linux-gnueabihf-gcc -v Using built-in specs. COLLECT_GCC=TOOLCHAIN/bin/arm-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/...../bin/../libexec/gcc/arm-linux-gnueabihf/9.0.1/ lto-wrapper Target: arm-linux-gnueabihf Configured with: ../gcc-source/configure --prefix=/sw/src/cross/INSTALL_DIR --target=arm-linux-gnueabihf --disable-werror --enable-languages=c,c++ --enable-interwork --disable-bootstrap --disable-multilib --disable-nls --disable-doc --without-selinux --disable-debug --disable-valgrind-tests --disable-documentation --disable-gtk-doc-pdf --disable-gtk-doc --disable-manpages --disable-gtk-doc-html --disable-tests --disable-libmudflap --disable-libgomp --disable-libssp --disable-libstdcxx-pch --without-gd --disable-profile --disable-libsanitizer --without-libsanitizer --enable-lto --enable-long-long --enable-checking=release --enable-threads=posix --with-arch-directory=arm --enable-multiarch --with-arch=armv7-a+mp --with-float-abi=hard --with-fpu=neon-vfpv4 --with-float=hard --with-tune=cortex-a7 --disable-sjlj-exceptions CFLAGS=' -funsafe-math-optimizations -funroll-all-loops -funroll-loops -g0 -O3 -pipe -DNDEBUG' CXXFLAGS=' -funsafe-math-optimizations -funroll-all-loops -funroll-loops -g0 -O3 -pipe -DNDEBUG' Thread model: posix gcc version 9.0.1 20190326 (experimental) [trunk revision 269955] (GCC) (pfade editiert)
:
Bearbeitet durch User
Laut /proc/cpuinfo hat der R2 einen armv7 SoC: root@bananapir2:~# cat /etc/cpuinfo cat: /etc/cpuinfo: No such file or directory root@bananapir2:~# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 2.45 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 3 processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 2.45 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 3 processor : 2 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 2.45 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 3 processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 2.45 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 3 Hardware : Mediatek Cortex-A7 (Device Tree) Revision : 0000 Serial : 0000000000000000 Ich habe mal im Anhang mein .config angehängt, die ich gerade mit menuconfig erstellt habe. Vielleicht kann ja jemand mal drüber lesen. Jetzt ist der Abbruch ähnlich aber nicht gleich! Starting kernel ... data abort pc : [<81e00064>] lr : [<fff97b81>] reloc pc : [<03c69064>] lr : [<81e00b81>] sp : ffb95770 ip : 00000018 fp : 00000400 r10: fffd48d8 r9 : ffb95ee0 r8 : ffb99bf8 r7 : 00000000 r6 : 82000000 r5 : fffd62fc r4 : 00000000 r3 : fffffdff r2 : 00000000 r1 : 00000000 r0 : 00000000 Flags: nZcv IRQs off FIQs off Mode UND_32 Code: e320f000 e320f000 e320f000 e51fd028 (e58de000) Resetting CPU ... resetting ... Diesmal ist der PC: vor der Load-Adr. ??? Markus
Kompilier doch mal mit dem Crosscompiler ein test-program wit hello-world und lass es dann auf dem Board laufen um zu sehen ob der Compiler auch richtigen Code für den R2 generiert. Hier zur Info bzw. zum Vergleich noch die cpuinfo des R1: # cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 45.47 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 4 processor : 1 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 45.47 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 4 Hardware : Allwinner sun7i (A20) Family Revision : 0000 Serial : 16516608070121f8 Nachtrag: Ahso, jetz sehe ich es: die CPU des R2 stammt von Mediatek, nicht von Allwinner. Aber ob das wirklich ein Unterscheid macht für das beobachtete Problem, muss man noch weiter analysieren.
:
Bearbeitet durch User
Bzgl. des config-bpir2 : Nimm am besten die config einer funktionierenden Image als Grundlage für deine Kernelcompilierung. D.h. schau ob du die config von dem alten/funktionierenden Kernel auftreiben kannst: s. /boot und es gibt auch eine Möglichkeit die config aus der Image herauszuextrahieren (den Befehl dazu müsste ich suchen). Und: beim Armbian liegt der config unter /boot abgelegt wenn ich mich nicht irre. Nachtrag: nicht aus Image herauslesen, sondern aus /proc: Kernel config (falls im kernel eingebettet): # zcat -Sn /proc/config.gz (oder zless ...)
:
Bearbeitet durch User
@ Mutluit Das mit der .config stimmt soweit wie Du es schreibst. Allerdings wird die 5.1.1 .config bestimmt diverse Veränderungen erfahren haben, die nicht zum 4.14 Ubuntu Kernel passen. Werde trotzdem mal die .configs vergleichen, vielleicht kann man einem Merge daraus basteln. Danke für die Mühe. Markus
Markus W. schrieb: > @ Mutluit > > Das mit der .config stimmt soweit wie Du es schreibst. > Allerdings wird die 5.1.1 .config bestimmt diverse > Veränderungen erfahren haben, die nicht zum 4.14 Ubuntu > Kernel passen. Klar, aber make menuconfig wird dich dann auf diese neuen Settings aufmerksam machen, bzw. diese neuen Settings abfragen. > Werde trotzdem mal die .configs vergleichen, vielleicht > kann man einem Merge daraus basteln. Oh, sowas ist sehr mühsam. Mach es lieber nach dem KISS-Prinzip :-) Also erstmal eine überhaupt funktionierende Version anstreben. Optimieren kann man später allemal. > Danke für die Mühe. Gerne geschehen. Wünsche viel Erfolg und Gutes Gelingen.
@Mutluit M. Du meinst also, wenn ich make menuconfig aufrufe und dann die alte .config einer anderen Kernelversion lade (z.B. Ubuntu 18.04.2 LTS, der gerade bei mir läuft, uname -r ==> 4.19.20-mt7623) werden mir die fehlenden Konfigurationen des neuen Kernels eingebaut, weil in den Skripten enthalten. Wäre schön, wen dem so wäre - Probiere ich mal gleich aus. Markus
Markus W. schrieb: > @Mutluit M. > > Du meinst also, wenn ich make menuconfig > aufrufe und dann die alte .config einer anderen > Kernelversion lade (z.B. Ubuntu 18.04.2 LTS, der > gerade bei mir läuft, uname -r ==> 4.19.20-mt7623) > werden mir die fehlenden Konfigurationen des neuen > Kernels eingebaut, weil in den Skripten enthalten. > > Wäre schön, wen dem so wäre - Probiere ich mal gleich > aus. Ja, müsste so sein. Aber: wenn du make menuconfig überhaupt nicht aufrufst, sondern stattdessen die andere config nach .config kopierst, und dann den make-lauf startest, dann fragt er dich im terminal nach den neuen Sachen einzeln ab (ob du sie aktivieren willst usw.). Im Falle von menuconfig bekommt man die neuen Sachen nicht mit, sie werden mit Defaults belegt. Btw, ich kompiliere gerade auch den neuesten git-Stand (5.1.1 wie bei dir). Nachtrag: auf kernel.org ist schon 5.1.2 raus... :-) Keine Ahnung wieso der git-Stand mir 5.1.1 anzeigt, obwohl ich eben ein git pull gemacht habe, da hat er auch vieles aktualisert... Ich komme mit den branch-Befehlen beim git noch nicht ganz klar. Im Vergleich dazu war svn so einfach :-)
:
Bearbeitet durch User
Wie es aussieht bleibt make bei allen neunen Optionen,
die mit (NEW) im .config File gekenzeichnet sind, stehen
und fragt die Auswahl ab. (Wie Du es bereits verhergesagt hat!)
Einzig und allein der Punkt
Choose kernel unwinder
1. Frame pointer unwinder (UNWINDER_FRAME_POINTER) (NEW)
> 2. ARM EABI stack unwinder (UNWINDER_ARM) (NEW)
Erforderte eine Entscheidung zwische 1. oder 2.
...
Ich habe mal meine Files angehängt, die mit der Konfig via
make und dem GCC Aufruf zusammenhängen, sowie die diff der
alten und neuen .config.
Hoffe das bringt etwas, falls jemand damit spielen will.
Da ich nicht weiß, wer dass alles lesen wird habe ich mal
die Files mit CRLF (Wagenrücklauf+Zeilenvorschub)-Terminator
versehen.
Markus
@für die Besserwisser weiter Oben aus der Initrd - doof-Fraktion ;-) U-Boot> boot switch to partitions #0, OK mmc1 is current device 1092 bytes read in 11 ms (96.7 KiB/s) Running boot/boot.scr from: mmc 1:1 using boot/boot.scr ## Executing script at 85f80000 Boot script loaded from device 1 127 bytes read in 9 ms (13.7 KiB/s) 27786 bytes read in 16 ms (1.7 MiB/s) 7931375 bytes read in 411 ms (18.4 MiB/s) 8290816 bytes read in 430 ms (18.4 MiB/s) Booting boot/zImage8 boot/uInitrd boot/dtb/mt7623n-bananapi-bpi-r2.dtb from: mmc 1:1 using bootargs=console=ttyS2,115200n1 root=UUID=3046aca4-3ff e-4500-a70b-b8a9ca34d4ae rw rootfstype=ext4 rootwait audit=0 loglevel=1 Kernel image @ 0x82000000 [ 0x000000 - 0x7e8200 ] ## Loading init Ramdisk from Legacy Image at 86080000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 7931311 Bytes = 7.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 86000000 Booting using the fdt blob at 0x86000000 Loading Ramdisk to 8f86f000, end 8ffff5af ... OK Loading Device Tree to 8f865000, end 8f86ec89 ... OK Starting kernel ... Loading, please wait... starting version 237 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Begin: Will now check root file system ... fsck from util-linux 2.31.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1 /dev/mmcblk1p1: clean, 37353/936448 files, 283041/3849616 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Ubuntu 18.04.2 LTS! Welcome to ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 5.1.1 System load: 0.15 0.16 0.07 Up time: 2 min Memory usage: 4 % of 2010MB IP: Usage of /: 6% of 15G [ General system configuration (beta): armbian-config ] root@bananapir2:~# uname -r 5.1.1 @Mutluit M. Danke! - das mit der .config-Adaption war der entscheidende Hinweis ;-) Wieder was dazu gelernt! Markus
Bei mir hat's geklappt, aber es zeigt 5.1.0 statt 5.1.1 an: # uname -a Linux r1-3 5.1.0-my15 #2 SMP Thu May 16 15:23:59 CEST 2019 armv7l GNU/Linux Jetzt muss ich noch klären wieso in meiner git-kopie die Version 5.1.2 eigentlich nicht erscheint.
:
Bearbeitet durch User
Markus W. schrieb: > root@bananapir2:~# uname -r > 5.1.1 Cool! Bei dir hat's geklappt. Gratuliere! Bei mir stimmt was mit den Versionen irgendwas noch nicht, weil der bei mir nur 5.1.0 anzeigt :-( > Danke! - das mit der .config-Adaption war der entscheidende > Hinweis ;-) Wieder was dazu gelernt! :-)
Jetzt fängt die Arbeit erst an! Ohne diverser Patches habe ich nur 1 LAN dev verfügbar eth0 und daraus abgeleitete br0. eth1-eth4 fehlen, sind aber beim Original Ubuntu 18.04.2 LTS vorhanden. SATA liegt mir auch am Herzen. WLAN und BT kann ich verschmerzen, wenn es icht gehen sollte. Der R2 soll hinter die FB als FW und als NAS für die private Cloud im Einsatz sein. Na ja wird wohl noch etwas Zeit in Anspruch nehmen, bis alles funktioniert. Immerhin tut sich was in der Community zum BPi-R2. @Mutluit M. Viel Erfolg bei Deinen Versuchen mit Deinem BPi. Markus
Markus W. schrieb: > Jetzt fängt die Arbeit erst an! > > Ohne diverser Patches habe ich nur 1 LAN dev > verfügbar eth0 und daraus abgeleitete br0. > eth1-eth4 fehlen, sind aber beim Original > Ubuntu 18.04.2 LTS vorhanden. > SATA liegt mir auch am Herzen. WLAN und BT > kann ich verschmerzen, wenn es icht gehen > sollte. Der R2 soll hinter die FB als FW und > als NAS für die private Cloud im Einsatz sein. > > Na ja wird wohl noch etwas Zeit in Anspruch nehmen, > bis alles funktioniert. > > Immerhin tut sich was in der Community zum BPi-R2. > > @Mutluit M. > Viel Erfolg bei Deinen Versuchen mit Deinem BPi. Danke. Der Einsatzgebiet bei mir ist ähnlich wie bei dir. Nach SATA und SATA-Portmultiplier wollte ich mir die integrierte Switch des R1 vornehmen, und dann WLAN und BT. Der R1 wurde in den vergangenen Jahren mMn zu Unrecht als schlecht beurteilt. Ich finde den eigentlich sehr gut gemacht. Jedoch hätte ich eine Quadcore CPU besser befunden, aber das ist ja historisch so gekommen; Quadcore gab es zu der Zeit noch nicht (bzw. DualCore war damals ausreichend). Zum Lernen und Experimentieren IMO gut geeignet, auch für Netzwerk-Sachen. Naja, egal, ich werde versuchen das Maximum aus dem Gerät rauszuholen; hab hier mehrere von denen, gebraucht günstig erworben über ebay.
:
Bearbeitet durch User
Hi Markus, ich glaube in unseren beiden Fällen wäre es wohl besser, wenn man für den eigenen kernel-build den sunxi-fork (mainline) der kernel-repo benutzt. Denn die sunxi-Leute bringen die für die Banana-Pi-Boards spezifischen Sachen eher/früher in den kernel rein als der main kernel (torvalds bzw. stable): git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git Mehr Info: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
:
Bearbeitet durch User
@Mutluit M., danke für den Hinweis mit dem sunxi-fork. War jetzt anderweitig beschäftigt - hoffe am So. weiter spielen zu können. Werde Deinen Vorschlag bei mir Testen. Hängt davon ab ob ich in der Lage sein werde den Kernel zu bauen. Verschiedene Quellen bringen manchmal unterschiedliche Anforderungen an die Build-Tools mit. Markus
Markus W. schrieb: > @Mutluit M., > > danke für den Hinweis mit dem sunxi-fork. Der Vollständigkeit halber hier noch dieser Link: https://git.kernel.org/pub/scm/linux/kernel/git/ Es listet alle kernel-forks auf, die direkt bei kernel.org gehostet werden. Es sind haupts. High-Kaliber-Developer am Linux-Projekt und einige Firmen. > Werde Deinen Vorschlag bei mir Testen. Hängt davon ab ob > ich in der Lage sein werde den Kernel zu bauen. > Verschiedene Quellen bringen manchmal unterschiedliche > Anforderungen an die Build-Tools mit. Ja, das kann durchaus zutreffen. Ich habe aus der o.g. Liste bis jetzt nur die 3 forks "torvalds", "stable" und "sunxi" getestet. Bei denen hat meine normale Std-Toolchain ausgereicht. Hier noch einige allgemeine Infos für Leute die sich erstmalig dafür interessieren: Die o.g. fork-trees sind je ca. 2.5GB gross, brauch man also eine einigermassen schnelle Internet-Leitung um es mit "git clone" zu klonen. Man kann das aber mit einigen Switches (--depth 1) verkleinern wenn man nur eine bestimmte Version haben will, s. dazu Beispiel hier: https://unix.stackexchange.com/questions/46077/where-to-download-linux-kernel-source-code-of-a-specific-version/46079 Dann nach dem klonen: - Mit "git tag" kann man dann alle Versionen zurück bis v2.6.11 auflisten (die noch älteren Versionen scheinen auf archiv-server ausgelagert worden zu sein, u.a. auf https://mirrors.edge.kernel.org/pub/linux/kernel/ ) - Mit "git checkout vXXX" dann eine bestimmte Version auschecken, bzw. "git checkout -b eigenebranch vXXX". - Und "git branch" bzw. "git branch --all" zeigt die branches an, inkl. eigene branch(es).
:
Bearbeitet durch User
@Mutluit M. Ausgehend von Deinem Link https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/ habe ich mir zwei tar.gz Kernels aus der Download Spalte im "summary" Reiter heruntergeladen. s.u. Diese konnte ich problemlos compilieren, wobei ich die letzte von mir verwendete .config aus dem vorhergehendem Durchlauf genommen habe. Die beiden u.g. tar.gz Files linux-sunxi-h3-h5-for-5.2 und linux-sunxi-dt-for-5.2 liefern den selben Kernel LTS 5.1.0-rc1. Diese Files sind wohl die aktuellsten Snapshots aus dem Repository und sind lediglich knapp 170MB groß. https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/snapshot/linux-sunxi-h3-h5-for-5.2.tar.gz Welcome to ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 5.1.0-rc1 System load: 0.36 0.17 0.06 Up time: 2 min Memory usage: 4 % of 2010MB IP: Usage of /: 6% of 15G https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/snapshot/linux-sunxi-dt-for-5.2.tar.gz Welcome to ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 5.1.0-rc1 System load: 0.00 0.03 0.03 Up time: 9 min Memory usage: 4 % of 2011MB IP: Usage of /: 6% of 15G Mein make-Aufruf lautet: make -j4 ARCH=arm CROSS_COMPILE=arm-suse-linux-gnueabi- INSTALL_MOD_PATH=./modules4bpir2 LOADADDR=0x82000000 bzImage modules dtbs, wobei mir leider noch keine .ko Files im INSTALL_MOD_PATH=./modules4bpir2 auftauchen, obwohl das Dir existiert. Alle .ko Kernel-Module werden aber fehlerfrei erzeugt nur nicht in meinem Wunsch-Dir. Aber der Sonntag ist ja noch lang. Markus
Markus W. schrieb: > Alle .ko Kernel-Module werden aber fehlerfrei erzeugt nur nicht in > meinem Wunsch-Dir. Gib dort mal absoluten Pfad an, also FullPath Nachtrag: Ich glaube du musst das auf 2 oder 3 Befehlszeilen machen, wie bei mir (ich mache alles in einem script): make -j3 LOADADDR=0x40008000 uImage modules dtbs make modules INSTALL_MOD_PATH=$targetdir make modules_install INSTALL_MOD_PATH=$targetdir Ich habe ARCH, PATH und CROSS_COMPILE etc. zuvor exportiert, so dass sie beim make nicht explizit angeg. werden brauchen. Und return-code-checks habe ich auch drin, so dass die module nur dann generiert werden wenn compile-lauf zuvor erfolgreich war (also $? auswerten etc..) Nachtrag2: hmm. müsste auch alles in nur 1 Befehlszeile, wie du gemacht hast, eigentlich auch klappen. > Aber der Sonntag ist ja noch lang. :-) Jo, viel Spass am Sonntag!
:
Bearbeitet durch User
Ich hab's bei mir jetzt so gemacht:
1 | make -j3 LOADADDR=0x40008000 uImage dtbs modules INSTALL_MOD_PATH=$targetdir |
2 | if [ $? -eq 0 ] ; then |
3 | echo "TODO: call do_install_as_root" |
4 | fi |
und das folgende muss als root ausgeführt werden (entw. in einem anderen script, oder das haupt-script editieren und als root aufrufen...):
1 | make modules_install INSTALL_MOD_PATH=$targetdir |
:
Bearbeitet durch User
zu: make modules_install INSTALL_MOD_PATH=$targetdir $targetdir ist doch ein beliebiges Verzeichnis, das Du dann zum BPi od. BPiR2 kopierts oder via Mount direkt drauf schreibst. Wozu brauchst Du dann die root Rechte? Du veränderst ja nicht das aktuelle OS auf dem Du kompilierst. Markus
Markus W. schrieb: > zu: > > make modules_install INSTALL_MOD_PATH=$targetdir > > $targetdir ist doch ein beliebiges Verzeichnis, das > Du dann zum BPi od. BPiR2 kopierts oder via Mount > direkt drauf schreibst. > Wozu brauchst Du dann die root Rechte? > Du veränderst ja nicht das aktuelle OS auf dem Du > kompilierst. Also, das kann eine Besonderheit bei mir sein: Ich habe eine Image-Datei, die eine SD-Karte darstellt. Darin sind 2 Partition: erste ist bootfs, die 2. ist rootfs. rootfs ist praktisch das Betriebssystem (hier Debian). Und wenn man sich anschaut welche Access-Rechte /lib und /lib/modules haben, dann ist root notwendig, wenn man die Module gerade dorthin erstellt haben will. targetdir ist zwar /mnt/rootfs, aber der entspr. make-Befehl kopiert es relativ dazu ins lib/modules, also effektiv ins /mnt/rootfs/lib/modules. Das kannst du bei dir natürlich auch anders machen. Ich habe mich an dem weiter oben geposteten howto-link orientiert: https://www.piprojects.net/debian-image-bauen/ Diese Zeile hab ich wieder abgeändert:
1 | make -j3 LOADADDR=0x40008000 uImage dtbs modules INSTALL_MOD_PATH=$targetdir |
in
1 | make -j3 LOADADDR=0x40008000 uImage dtbs modules |
:
Bearbeitet durch User
@Mutluit M.
ich kämpfe gerade noch mit dem 5.1.3 Kernel bei meiner
Toolchain auf dem Notebook.
Bekomme aber gerade Fehler trotz der Angabe von ARCH=arm.
Irgendwie versucht der Compiler den x86 linker LD zu benutzen.
S.u.
Zu dem Target-Modul-Dir kann ich nur sagen, sofern ich das
richtig sehe, dass die Rechte eines gemounteten FS von den
default Einstellungen des aktuell laufenden Kernels und den
Mountoptionen abhängen die auf das FS angewendet werden -
Stichwort (umask und -o Option / Attribute beim mount Befehl)
Markus
root@zbook:/home/markus/Elektrotechnik/ARM/Banana-Pi/Banana-Pi-R2/BPi-R2
-MW/linux-5.1.3
>make ARCH=arm CROSS_COMPILE='arm-suse-linux-gnueabi-' menuconfig
HOSTCC scripts/basic/fixdep
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
/tmp/cczqrtJ8.o: in function `read_file':
fixdep.c:(.text+0x83): undefined reference to `_impure_ptr'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
fixdep.c:(.text+0xdc): undefined reference to `_impure_ptr'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
/tmp/cczqrtJ8.o: in function `main':
fixdep.c:(.text.startup+0x16b): undefined reference to `_ctype_'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
fixdep.c:(.text.startup+0x193): undefined reference to `_ctype_'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
fixdep.c:(.text.startup+0x1c1): undefined reference to `_ctype_'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
fixdep.c:(.text.startup+0x37b): undefined reference to `_ctype_'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
fixdep.c:(.text.startup+0x53a): undefined reference to `_impure_ptr'
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
fixdep.c:(.text.startup+0x563): undefined reference to `_impure_ptr'
collect2: error: ld returned 1 exit status
make[1]: *** [scripts/Makefile.host:92: scripts/basic/fixdep] Error 1
make: *** [Makefile:490: scripts_basic] Error 2
Markus W. schrieb: > @Mutluit M. > > ich kämpfe gerade noch mit dem 5.1.3 Kernel bei meiner > Toolchain auf dem Notebook. > > Bekomme aber gerade Fehler trotz der Angabe von ARCH=arm. > > Irgendwie versucht der Compiler den x86 linker LD zu benutzen. > S.u. Es sieht danach aus dass dein PATH nicht richtig gesetzt ist: als erstes sollte die Toolchain vorkommen. Bei mir ist es so:
1 | TOOLCHAIN="/dir/of/my/crosscompiler" |
2 | export PATH="$TOOLCHAIN/bin:$PATH" |
3 | export ARCH=arm |
4 | export CROSS_COMPILE=arm-linux-gnueabihf- |
5 | |
6 | # optional: |
7 | export CFLAGS="-DNDEBUG -g0 -O3 -pipe -I $TOOLCHAIN/arm-linux-gnueabihf/include" |
8 | export CXXFLAGS=$CFLAGS |
9 | export KBUILD_CFLAGS=$CFLAGS |
10 | export KBUILD_CXXFLAGS=$CXXFLAGS |
11 | export KBUILD_CPPFLAGS=$CXXFLAGS |
:
Bearbeitet durch User
Zur Info für alle Interessierten. Mir ist es gelungen nach vielen Versuchen den neusten Linux Kernel 5.2.0-rc2 für den BPi-R2 zu kompilieren und diesen zum Laufen zu bringen. Ich hatte Probleme eine SSD am SATA Port zu betreiben und wäre fast verzweifelt, bis sich gerade herausstellte, daß beim SATA-Kabel die +5V Versorgungs-Drähte (rt/sz) vertauscht waren. Nachdem ich den Stecker umgebaut habe, wurde die SSD sofort erkannt. Welcome to ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 5.2.0-rc2 System load: 0.19 0.12 0.05 Up time: 2 min Memory usage: 5 % of 2010MB IP: CPU temp: 29�°C Usage of /: 8% of 15G [ General system configuration (beta): armbian-config ] root@bananapir2:~# lsscsi [0:0:0:0] disk ATA INTEL SSDSC2KW24 G200 /dev/sda Bei dem neuen Kernel läuft die SSD auch ohne Patch mit 100-150 MB/Sek. (eine Intel 540s 240GB / SSDSC2KW240H6) Mangels Speicher "/dev/shm" (nur 1GB) habe ich nur ein 512MB File in einer Loop zehn mal auf die SSD geschrieben. Dabei sind die Messwerte (min/max) entstanden. root@bananapir2:/mnt/sda7# ls -l /dev/shm total 524288 -rw-r--r-- 1 root root 536870912 May 30 12:04 BIG_FILE_512MB.bin root@bananapir2:/mnt/sda7# for i in `seq 1 10` > do > time $(cp /dev/shm/BIG_FILE_512MB.bin /mnt/sda7/BIG_FILE_${i}_512M.bin; sync) > done real 0m3.971s user 0m0.032s sys 0m3.670s real 0m4.059s user 0m0.029s sys 0m3.842s real 0m4.093s user 0m0.029s sys 0m3.854s real 0m4.608s user 0m0.033s sys 0m3.872s real 0m5.218s user 0m0.017s sys 0m3.849s real 0m5.086s user 0m0.027s sys 0m3.826s real 0m5.248s user 0m0.009s sys 0m3.845s real 0m5.292s user 0m0.017s sys 0m3.819s real 0m5.246s user 0m0.049s sys 0m3.838s real 0m5.288s user 0m0.009s sys 0m3.872s 135.197.912 Byte/sek. max 101.526.269 Byte/Sek. min real 0m3.865s user 0m0.052s sys 0m3.553s real 0m3.777s user 0m0.024s sys 0m3.511s real 0m3.747s user 0m0.030s sys 0m3.479s real 0m3.765s user 0m0.021s sys 0m3.485s real 0m4.323s user 0m0.033s sys 0m3.480s real 0m5.166s user 0m0.015s sys 0m3.527s real 0m5.132s user 0m0.021s sys 0m3.502s real 0m5.099s user 0m0.023s sys 0m3.499s real 0m5.268s user 0m0.029s sys 0m3.517s real 0m5.092s user 0m0.013s sys 0m3.511s 143.280.200 Byte/Sek. max 101.911.714 Byte/Sek. min root@bananapir2:/mnt/sda7# ls -l total 5242916 -rw-r--r-- 1 root root 536870912 May 30 12:12 BIG_FILE_10_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_1_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_2_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_3_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_4_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_5_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_6_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_7_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_8_512M.bin -rw-r--r-- 1 root root 536870912 May 30 12:11 BIG_FILE_9_512M.bin Markus
Markus W. schrieb: > Zur Info für alle Interessierten. > > Mir ist es gelungen nach vielen Versuchen den > neusten Linux Kernel 5.2.0-rc2 für den BPi-R2 > zu kompilieren und diesen zum Laufen zu bringen. > > Ich hatte Probleme eine SSD am SATA Port zu > betreiben und wäre fast verzweifelt, bis sich > gerade herausstellte, daß beim SATA-Kabel die > +5V Versorgungs-Drähte (rt/sz) vertauscht waren. > > Nachdem ich den Stecker umgebaut habe, wurde > die SSD sofort erkannt. Ich frag mich wie das denn passieren kann, dass das SATA-Stromkabel falsch verdrahtet ist? Die sind doch genormt und auch Massenware. Aber gut zu wissen dass man bei Problemen auch an so eine Möglichkeit denken sollte. Aber wenn ältere Kernel doch liefen, kann es dann nicht sein dass es vlt. ein Problem in diesem neuen Kernel sein könnte?
:
Bearbeitet durch User
@Mutluit M. Die beiden einzelnen Drähte der 5V Versorgung wurden nur falsch in den Stecker montiert, d.h. die beiden Pins verkehrt hineingesteckt. Hatte auch nicht gedacht, dass so was bei einem gekauften SATA Kabel pasieren kann. Markus
@Mutluit M. and All, Was mir noch eingefallen ist, ist die Möglichkeit, dass der SATA-Versorgungs- Spannungs-Stecker (zweipolig/weiß neben dem typischm SATA-Daten Stecker)auf dem BPi-R2 falsch eingesetzt und verlötet sein könnte. Dies ist aber eher unwahr- scheinlich da so ein Bestückungsautomat wohl keine Fehler macht und wenn doch, weil falsch programmiert, wäre es auch anderen Benützern des BPi-R2 aufgefallen. Kann jemand das betätigen oder widerlegen, der auch einen BPi-R2 besitzt? Markus
@All, hätte jemand noch eine Idee, wie/wo ich den xhci-mt in der make menuconfig oder in dem .config File für die Kompilierung aktivieren kann. Danke! Markus
Markus W. schrieb: > > hätte jemand noch eine Idee, wie/wo ich > den xhci-mt in der make menuconfig oder > in dem .config File für die Kompilierung > aktivieren kann. Meinst du vlt. diese Sache (s.a. die User-Comments dazu): https://www.phoronix.com/scan.php?page=news_item&px=Linux-Default-USB-3.0-XHCI
:
Bearbeitet durch User
Danke Mutluit M.! Werde mal nach dem CONFIG_USB_XHCI_HCD in der .config suchen. Habe aber bereits nach xhci erfolglos gescannt, wobei manche deaktivierten Optionen garnicht in der .config auftauchen. In den 5.1.1, 5.1.5 und 5.2-RC2 Kernel sourcen, die ich bis jetzt getestet habe sind die xhci-mtk Sourcen enthalten. xxx:~/Programming/ARM/BPiR2/linux-5.2-rc2 # >find . -name \*xhci-mt\* ./drivers/usb/host/xhci-mtk-sch.c ./drivers/usb/host/.xhci-mtk.o.cmd ./drivers/usb/host/.xhci-mtk-sch.o.cmd ./drivers/usb/host/xhci-mtk.c ./drivers/usb/host/xhci-mtk.h Beim make mudules und make moduls_install werden sie aber bei mir nicht kompiliert. Hintergrund ist bei mir der Wunsch eine weitere SSD via USB3 anzuschließen. Schließe ich einen USB3-Stick an, sehe ich via journalctl -f May 30 bananapir2 kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 2 using xhci-mtk May 30 bananapir2 kernel: usb-storage 4-1:1.0: USB Mass Storage device detected May 30 bananapir2 kernel: scsi host2: usb-storage 4-1:1.0 May 30 bananapir2 kernel: usbcore: registered new interface driver uas May 30 bananapir2 kernel: scsi 2:0:0:0: Direct-Access MUSHKIN MKNUFDIM64GB PMAP PQ: 0 ANSI: 6 May 30 bananapir2 kernel: sd 2:0:0:0: [sdb] 123600896 512-byte logical blocks: (63.3 GB/58.9 GiB) May 30 bananapir2 kernel: sd 2:0:0:0: [sdb] Write Protect is off May 30 bananapir2 kernel: sd 2:0:0:0: [sdb] Mode Sense: 2b 00 00 08 May 30 bananapir2 kernel: sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA May 30 bananapir2 kernel: sdb: sdb1 May 30 bananapir2 kernel: sd 2:0:0:0: [sdb] Attached SCSI removable disk Schließe ich meine M2-SSD via USB3-Adapter an, sehe ich May 30 bananapir2 kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 3 using xhci-mtk May 30 bananapir2 kernel: scsi host2: uas May 30 bananapir2 kernel: xhci-mtk 1a240000.usb: ERROR Transfer event for unknown stream ring slot 1 ep 4 May 30 bananapir2 kernel: xhci-mtk 1a240000.usb: @00000000ac048a30 ac09c000 00000000 05000000 01058000 May 30 bananapir2 kernel: xhci-mtk 1a240000.usb: ERROR Transfer event for unknown stream ring slot 1 ep 6 May 30 bananapir2 kernel: xhci-mtk 1a240000.usb: @00000000ac048a40 ac09c100 00000000 05000000 01078000 ... May 30 bananapir2 kernel: scsi 2:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN May 30 bananapir2 kernel: scsi 2:0:0:0: tag#0 CDB: opcode=0x12 12 00 00 00 24 00 May 30 bananapir2 kernel: xhci-mtk 1a240000.usb: Mismatch between completed Set TR Deq Ptr command & xHCI internal state. May 30 bananapir2 kernel: xhci-mtk 1a240000.usb: ep deq seg = dc1951de, deq ptr = ad764e23 May 30 bananapir2 kernel: scsi host2: uas_eh_device_reset_handler FAILED to get lock err -16 May 30 bananapir2 kernel: scsi 2:0:0:0: Device offlined - not ready after error recovery Also passt noch was nicht. Da ich den xhci-mtk.ko nicht in /lib/modules/5.2-RC2/... finde und er auch nicht via lsmod angezeigt wird hoffe ich dass es nur an dem Fehlen des Treibers liegt, dass ich die SSD nicht sehe. Übrigens habe ich zum MT7623 das u.g. DS per Zufall gefunden. https://drive.google.com/file/d/0B_YnvHgh2rwjR3pwSzNrS1Nqdjg/view Vielleicht kann es sonst jemand noch brauchen. Was ich noch suche und auch gerade versuche, ist das armbianEnv.txt bzw. boot.cmd File so anzupassen, dass mein Kernel von /dev/sda1 und mein Root-FS von /dev/sda6 geladen wird. Falls jemand das schon raus bekommen hat, wie die UBoot-Env diesbezüglich gesetzt werden muss, wäre ich für einen Tipp dankbar. Mir ist Klar, dass der Bootvorgang über die SD oder das NAND- EMMC gestartet wird, aber sobald U-Boot geladen ist, würde ich gerne von dem sda Device starten. Danke für nützliche Hinweise an die Linux-Fraktion. Markus
Markus W. schrieb: > > Also passt noch was nicht. > Da ich den xhci-mtk.ko nicht in /lib/modules/5.2-RC2/... finde > und er auch nicht via lsmod angezeigt wird Wenn der Treiber aktiviert, aber nicht als Modul (M) konfiguriert wurde, dann wird es ja in den Kernel eingebunden, d.h. dann liegt es nicht als externes Modul vor sondern ist fest im Kernel drin. > hoffe ich dass es > nur an dem Fehlen des Treibers liegt, dass ich die SSD nicht sehe. Das ist dann echt merkwürdig.
Markus W. schrieb: > > Übrigens habe ich zum MT7623 das u.g. DS per Zufall gefunden. > > https://drive.google.com/file/d/0B_YnvHgh2rwjR3pwSzNrS1Nqdjg/view > > Vielleicht kann es sonst jemand noch brauchen. Hab z.Zt. zwar kein R2, aber solche Handbücher sind willkommen. Was mir aufgefallen ist: in diesem Handbuch wird SATA/AHCI ja überhaupt gar nicht erwähnt :-( Schon etwas merkwürdig, finde ich. > Was ich noch suche und auch gerade versuche, ist das > armbianEnv.txt bzw. boot.cmd File so anzupassen, dass > mein Kernel von /dev/sda1 und mein Root-FS von /dev/sda6 > geladen wird. Also, root auf sdX sollte eigentlich kein Problem sein, aber ob boot auf sdX sein kann ist fraglich. Wie gesagt ich spekuliere nur weil ich den R2 noch nicht kenne. Ich hatte vor einigen Tagen eine Armbian-Image auf dem M1-Berry ausprobiert. Hier der Inhalt:
1 | # cat armbianEnv.txt |
2 | verbosity=1 |
3 | logo=disabled |
4 | console=both |
5 | disp_mode=1920x1080p60 |
6 | overlay_prefix=sun8i-h3 |
7 | rootdev=UUID=bfbeddf1-eeb9-4314-b555-e14a7b5223ca |
8 | rootfstype=ext4 |
9 | # MY |
10 | fdtfile=sun8i-v40-bananapi-m2-berry.dtb |
D.h. mittels rootdev und rootfstype kann man die root-partition definieren. Statt UUID müsste eigentlich /dev/sdX auch gehen, aber sicher bin ich mir nicht. > Falls jemand das schon raus bekommen hat, wie die UBoot-Env > diesbezüglich gesetzt werden muss, wäre ich für einen Tipp > dankbar. > > Mir ist Klar, dass der Bootvorgang über die SD oder das NAND- > EMMC gestartet wird, aber sobald U-Boot geladen ist, würde ich > gerne von dem sda Device starten. Ja, das geht im Allgemeinen und sollte auch beim R2 gehen; s.o.
:
Bearbeitet durch User
@ Mutluit M. Ich habe nun einen neuen Kompiliervorgang angestoßen. Dabei habe ich die Info im Web gefunden, daß bei make menuconfig in der GUI, die dabei angezeigt wird, ein "/" als Eingabe eine Suchmaske öffnet. Mit der Suche habe ich alle CONFIG Switches lockalisiert, die ein MTK im Namen haben. Ist eine ganze Menge. Dabei werden einem z.B. solche einträge angezeigt: Symbol: MTD_NAND_MTK [=n] │ Type : tristate │ Prompt: MTK NAND controller │ Location: │ -> Device Drivers │ -> Memory Technology Device (MTD) support (MTD [=y]) │ (1) -> Raw/Parallel NAND Device Support (MTD_RAW_NAND [=n]) │ Defined at drivers/mtd/nand/raw/Kconfig:402 │ Depends on: MTD [=y] && MTD_RAW_NAND [=n] && (ARCH_MEDIATEK [=y] || COMPILE_TEST [=n]) && HAS_IOMEM [=y] Mit dieser Hilfe kann man dann zu den entsprechenden Einträgen navigieren. Habe dabei noch einige [n]'s gefunden. z.B. Symbol: BT_MTKUART [=n] Symbol: MTD_NAND_MTK [=n] Symbol: MTK_CMDQ [=n] Symbol: MTK_CQDMA [=n] ... Diese habe ich versuchsweise auf "y" gesetzt und werde mal das Resultat auf dem BPi-R2 ausprobieren. Markus
Korrektur: natürlich meinte ich M2-Berry; M1-Berry gibt's gar nicht :-) Und: es handelte sich um eine neuere Armbian-Img: Armbian_5.83_Bananapim2ultra_Debian_stretch_dev_5.0.10.img
:
Bearbeitet durch User
Mein Kompilerdurchlauf ist nun fertig. make modules_install erzeugt alle Module. Leider ist nirgends ein xhci...ko zu finden. Wie checke ich ob er im Kernel fest einkompiliert ist? Mit objdump -x ? Im Anhang meine *.ko Fileliste, die erzeugt wurde. Markus
Markus W. schrieb: > Mein Kompilerdurchlauf ist nun fertig. > make modules_install erzeugt alle Module. > Leider ist nirgends ein xhci...ko zu finden. > > Wie checke ich ob er im Kernel fest einkompiliert ist? Hm, ja, gute Frage :-) Vlt. folgendes :-) $ grep XXX .config Nachtrag: Die richtige Antwort scheint hier zu sein: https://superuser.com/questions/577307/how-to-get-a-list-of-active-drivers-that-are-statically-built-into-the-linux-ker Also, der folgende Befehl zeigt sie an: cat /lib/modules/$(uname -r)/modules.builtin Statt des $(uname -r) kannst du den Dir-Namen auch direkt angeben... Bei meinem R1 taucht da folgendes auf: kernel/drivers/usb/host/xhci-hcd.ko
:
Bearbeitet durch User
Und die UUID der disk bekommt man u.a. mit fdisk angezeigt: # fdisk -l /dev/sda Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: AE5CF6B4-0136-4DF3-AB1B-5812AC699D6A
Man kann diese Info auch aus dem Build-Verzeichniss heraus holen, wie ich gerade sehe. ./lib/modules/5.2.0-rc2/modules.builtin cat ./lib/modules/5.2.0-rc2/modules.builtin | grep -i xhci liefert jetzt: kernel/drivers/usb/host/xhci-hcd.ko kernel/drivers/usb/host/xhci-pci.ko kernel/drivers/usb/host/xhci-plat-hcd.ko kernel/drivers/usb/host/xhci-mtk.ko Leider bekomme ich noch immer nach dem Anstecken der M2-SSD via USB3 Adapter eine Fehlermeldung mittels journalctl -f. May 31 bananapir2 kernel: scsi host2: uas May 31 bananapir2 kernel: xhci-mtk 1a1c0000.usb: ERROR Transfer event for unknown stream ring slot 1 ep 4 May 31 bananapir2 kernel: xhci-mtk 1a1c0000.usb: @00000000ac0432c0 ac09b000 00000000 05000000 01058001 May 31 bananapir2 kernel: xhci-mtk 1a1c0000.usb: ERROR Transfer event for unknown stream ring slot 1 ep 6 May 31 bananapir2 kernel: xhci-mtk 1a1c0000.usb: @00000000ac0432d0 ac09b100 00000000 05000000 01078001 May 31 bananapir2 kernel: scsi 2:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN May 31 bananapir2 kernel: scsi 2:0:0:0: tag#0 CDB: opcode=0x12 12 00 00 00 24 00 May 31 bananapir2 kernel: xhci-mtk 1a1c0000.usb: Mismatch between completed Set TR Deq Ptr command & xHCI internal state. May 31 bananapir2 kernel: xhci-mtk 1a1c0000.usb: ep deq seg = 303bc2e9, deq ptr = b0939dbb May 31 bananapir2 kernel: scsi host2: uas_eh_device_reset_handler FAILED to get lock err -16 May 31 bananapir2 kernel: scsi 2:0:0:0: Device offlined - not ready after error recovery Details siehe Anhang! lsmod vor und nach dem Anstecken der SSD Disk. Danach depmod -a und erneutes lsmod. Dann noch eine Suche nach xhci und XHCI im /lib/modules/5.2-RC2 .ko-Modul-Verzeichnis. Markus Nachtrag: Wie ist diese Zeile von lsmod zu verstehen? Module Size Used by uas 20480 0 uas hat keine Module, die von ihm abhängen. Laut journalctl -f hat aber das uas etwas mit dem Anstecken der SSD zu tun, da es in diesem Zusammenhang gelistet wird. Wo liegt der Hund begraben?
:
Bearbeitet durch User
@All, hier liegt das Problem: https://lore.kernel.org/patchwork/patch/870229/ im Zusammenhang mit "JMicron" Gerätschaften! lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 480M lsusb -v ... Bus 002 Device 002: ID 152d:0562 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x0562 bcdDevice 2.04 iManufacturer 1 Liangteng iProduct 2 USB3.1 TO NVME SSD iSerial 3 DD20180910888 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 224mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 10 MSC USB Attached SCSI Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 MaxStreams 32 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 42 bNumDeviceCaps 3 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000f0e Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 32 micro seconds ** UNRECOGNIZED: 14 10 0a 00 01 00 00 00 00 11 00 00 30 40 0a 00 b0 40 0a 00 <=== hier ist der Hund begraben!!!!!! Device Status: 0x0000 (Bus Powered) Patch erforderlich für: .../drivers/usb/storage/unusual_uas.h Muss den Kernel wieder neu bauen. Markus
@All
Problem scheinbar oder auch gänzlich gelöst!?
Nach der Erweiterung der ..../drivers/usb/storage/unusual_uas.h
Header Datei um die u.g. Struktur
/* M.W. JMicron Technology Corp. Liangteng USB3.1 TO NVME SSD */
UNUSUAL_DEV(0x152d, 0x0562, 0x0000, 0x9999,
"JMicron",
"USB3.1 TO NVME SSD",
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_IGNORE_UAS),
Und dem Neukompilieren des Kernels,
liefert journalctl -f nach dem Einstecken der M2.SSD folgenden
Output:
May 31 bananapir2 kernel: usb 2-1: new SuperSpeed Gen 1 USB device
number 2 using xhci-mtk
May 31 bananapir2 kernel: usb 2-1: UAS is blacklisted for this device,
using usb-storage instead
May 31 bananapir2 kernel: usb-storage 2-1:1.0: USB Mass Storage device
detected
May 31 bananapir2 kernel: usb-storage 2-1:1.0: Quirks match for vid 152d
pid 0562: 800000
May 31 bananapir2 kernel: scsi host2: usb-storage 2-1:1.0
May 31 bananapir2 kernel: usbcore: registered new interface driver uas
May 31 bananapir2 dnscrypt-proxy[1830]: Fri May 31 11:19:47 2019 [INFO]
Refetching server certificates
May 31 bananapir2 dnscrypt-proxy[1830]: Fri May 31 11:19:47 2019 [INFO]
Server certificate with serial #1559296801 received
May 31 bananapir2 dnscrypt-proxy[1830]: Fri May 31 11:19:47 2019 [INFO]
This certificate has expired
May 31 bananapir2 dnscrypt-proxy[1830]: Fri May 31 11:19:47 2019 [ERROR]
No useable certificates found
May 31 bananapir2 kernel: scsi 2:0:0:0: Direct-Access ITHOO Tech
0204 PQ: 0 ANSI: 6
May 31 bananapir2 kernel: sd 2:0:0:0: [sda] 1000215216 512-byte logical
blocks: (512 GB/477 GiB)
May 31 bananapir2 kernel: sd 2:0:0:0: [sda] Write Protect is off
May 31 bananapir2 kernel: sd 2:0:0:0: [sda] Mode Sense: 53 00 00 08
May 31 bananapir2 kernel: sd 2:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
May 31 bananapir2 kernel: sda: sda1
May 31 bananapir2 kernel: sd 2:0:0:0: [sda] Attached SCSI disk
Weitere Tests zeigen:
root@bananapir2:~# lsscsi
[2:0:0:0] disk ITHOO Tech 0204 /dev/sda
root@bananapir2:~# fdisk -l /dev/sda
Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 9A50C8D9-7B8E-4584-8431-E6A745B2A686
Device Start End Sectors Size Type
/dev/sda1 2048 1000215182 1000213135 477G Linux filesystem
root@bananapir2:~# mount /dev/sda1 /mnt/sda1
root@bananapir2:~# df -h
/dev/sda1 470G 149G 298G 34% /mnt/sda1
Was ich noch nicht ganz verstehe, sind die Flags, die in der
o.g. Struktur gesetzt werden können.
U.u wäre auch die Kombination sinnvoll
US_FL_IGNORE_UAS | US_FL_NO_REPORT_OPCODE
für die
** UNRECOGNIZED: 14 10 0a 00 01 00 00 00 00 11 00 00 30 40 0a 00 b0 40
0a 00
Fehlermeldung!
Leider bin ich aber da nicht so firm, was Linux Kernel-Driver
angeht.
Kann Sich jemand dazu äußern, oder muss ich mich aufgrund
der speziellen Thematik an kernel.org wenden?
Markus
Wie schnell ist denn diese Kombination NVMe/M.2-SSD über USB3.1 am BPI-R2? Oder hat der R2 Native M.2-Anschluss?
Bin gerade dabei es zu Testen. Der Erste Eindruck liegt bei 110MB/Sek+-10MB, wobei ich nicht sicher bin, wie weit ich den Transfer durch meinen Patch negativ beeinflusst habe. Siehe Werte weiter unten. Markus root@bananapir2:~# lsscsi [0:0:0:0] disk ITHOO Tech 0204 /dev/sdb [1:0:0:0] disk ATA INTEL SSDSC2KW24 G200 /dev/sda root@bananapir2:~# fdisk -l /dev/sda Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x0003bb90 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1044479 1042432 509M 83 Linux /dev/sda2 1044480 9431039 8386560 4G 82 Linux swap / Solaris /dev/sda3 9431040 42989567 33558528 16G 83 Linux /dev/sda4 42989568 468860927 425871360 203.1G f W95 Ext'd (LBA) /dev/sda5 42991616 76550143 33558528 16G 83 Linux /dev/sda6 76552192 143652863 67100672 32G 83 Linux /dev/sda7 143654912 468860927 325206016 155.1G 83 Linux root@bananapir2:~# fdisk -l /dev/sdb Disk /dev/sdb: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 9A50C8D9-7B8E-4584-8431-E6A745B2A686 Device Start End Sectors Size Type /dev/sdb1 2048 1000215182 1000213135 477G Linux filesystem Testfile via urandom erzeugen: ============================== count=4096; sync)mnt/sdb1# time $(dd if=/dev/urandom of=./BIG_FILE_4G.bin bs=1M 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 126.982 s, 33.8 MB/s real 2m7.030s user 0m0.037s sys 2m6.872s root@bananapir2:/mnt/sdb1# ls -l BIG_FILE_4G.bin -rw-r--r-- 1 root root 4294967296 May 31 11:44 BIG_FILE_4G.bin Datentransfer starten: ====================== M2.SSD via USB3 ===> INTEL SSD am SATA Port#1 ============================================== root@bananapir2:/mnt/sdb1# for i in `seq 1 5` > do > echo ${i} > time $(dd if=./BIG_FILE_4G.bin of=/mnt/sda7/BIG_FILE_${i}_4G.bin bs=1M; sync) > done 1 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 38.4996 s, 112 MB/s real 0m39.142s user 0m0.070s sys 0m32.509s 2 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 40.3148 s, 107 MB/s real 0m40.880s user 0m0.067s sys 0m33.893s 3 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 40.3395 s, 106 MB/s real 0m40.918s user 0m0.060s sys 0m33.702s 4 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 40.1736 s, 107 MB/s real 0m40.744s user 0m0.084s sys 0m33.725s 5 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 40.5157 s, 106 MB/s real 0m41.038s user 0m0.053s sys 0m33.805s INTEL SSD am SATA Port#1 ===> M2.SSD via USB3 ============================================== root@bananapir2:/mnt/sdb1# for i in `seq 1 5` one> do > echo ${i} > time $(dd if=/mnt/sda7/BIG_FILE_4G.bin of=./BIG_FILE_${i}_4G.bin bs=1M; sync) > done 1 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 35.9385 s, 120 MB/s real 0m36.149s user 0m0.042s sys 0m30.631s 2 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 35.9064 s, 120 MB/s real 0m36.103s user 0m0.048s sys 0m30.693s 3 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 36.4359 s, 118 MB/s real 0m36.729s user 0m0.045s sys 0m31.256s 4 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 36.2919 s, 118 MB/s real 0m36.570s user 0m0.025s sys 0m31.105s 5 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 36.2086 s, 119 MB/s real 0m36.459s user 0m0.044s sys 0m31.011s Von der Intel-SSD zur M2.SSD am USB3.1 Adapter habe ich zwischen 106-112 MB/Sek. in der umgekehrten Richtung sind es 118-120MB/Sek. Gestern habe ich ja aus dem RAM (/dev/shm) nur 512MB große Files auf die Intel SSD, siehe weiter oben in Thred, geschrieben.
Musst aufpassen: du misst ja Read+Write zusammen. Ich würde empfehlen if=/dev/zero of=dein_file für nur write-speed Und if=dein_file of=/dev/null für nur read-speed
:
Bearbeitet durch User
@Mutluit M. Dass ist soweit korrekt, was Du schreibst! Da man Daten aber aus dem Nichts herzaubern kann, mit Ausnahme von /dev/zero, zu dem ich aber meine Meinung schon früher kund getan habe, in Punkto Performance-Messung, ist man daran interessiert, zu sehen wiegroß der Durchsatz durch das System ist. Man schreibt ja vom LAN auf Disk oder umgekehrt oder zwischen zwei Speichermedien. In dem von mir getesteten Fall sind ja verschiedene Teile des SoC's eingebunden und die Beobachtung, dass mindestens 100MB/Sek. an Durchsatz möglich sind ist schon mal eine Hausnummer für so einen SBC wie den BPi-R2. Einzelne Messungen aus dem Speicher sind ja wegen der begrenzten RAM-Größe schwierig und erfordern Kompromisse. Für mich ist von Bedeutung zu sehen in wie weit sich der R2 als Router und Private-NAS für OwnCloud Geschichten einsetzen lässt. Mit zwei SSD's dem SBC (BPi-R2) und NT liegt man unter 300€ und hat eine interessant HW als Bollwerk zwischen der DSL FBox von AVM und seinem Home-LAN. Das ist hauptsächlich mein Einsatzgebiet und aus der Vielzahl von SBC's, die ich mittlerweile besitze ist der R2 als HW unter 100€ echt unschlagbar. Da der neue Kernel auch alle vier NIC's erkennt und einbindet ist es eine wahre Freude dieses Teil zu konfigurieren und hoffentlich auch einzusetzen. Hoffe es finden sich noch einige interessierte User, die den R2 erkunden und aus ihm herauskitzeln was möglich ist. Darin bist Du ja auch involviert und ich hoffe Du hast noch weitere Ideen und Einfälle. Markus
Hi Markus, Kennst du mein github-repo für den bpi-r2? dort habe ich auch schon den 5.2 laufen und ein Großteil der nicht-Mainline-Features (poweroff,hdmi,wifi). macht aus meiner Sicht keinen Sinn,dass jeder bei 0 anfängt. Vielleicht kannst du mir ja helfen :) Gruß Frank
Link vergessen,sorry: https://github.com/frank-w/BPI-R2-4.14/tree/5.2-rc Die Zusatz-Funktionen sind in separaten Branches (5.2-*)
Hallo Frank,
direkt kenne ich Dein R2 Repo nicht, mag aber sein,
dass ich bei diversen Webrecherchen darüber gestolpert bin.
Es ist zwar immer aufwendig und mühselig alles neu zu recherchieren
und das OS zu kompilieren und zu konfigurieren, dass stimmt schon,
aber man bleibt auf dem Laufenden, was sich in der SBC Szene so tut
und man lernt dabei auch viel.
Für mich ist das wie ein Hobby, wobei ich durchaus breit bin meine
Ergebnisse zum R2 zu teilen, weshalb ich auch sie hier poste.
Für mich steht noch an die Boot-Skripte und Konfig-Files so zu
modifizieren, dass einerseits der Kernel im NAND Steht und das
/boot, /home, /var und /tmp Verzeichnis auf den sdaX-Partitionen
liegt.
In U-Boot kann man das mit env print und env set händich durchprobieren
ohne es permanent machen zu müssen.
Wenn alles dann so läuft wie gewünscht kann man die letzte Konfiguration
permanent sicher.
U-Boot> env help
env - environment handling commands
Usage:
env default [-f] -a - [forcibly] reset default environment
env default [-f] var [...] - [forcibly] reset variable(s) to their
default values
env delete [-f] var [...] - [forcibly] delete variable(s)
env edit name - edit environment variable
env exists name - tests for existence of variable
env export [-t | -b | -c] [-s size] addr [var ...] - export environment
env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import
environment
env print [-a | name ...] - print environment
env run var [...] - run commands in an environment variable
env set [-f] name [arg ...]
Die Procedure mit
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
um das boot.scr aus dem boot.cmd zu erzeugen ist mir bekannt.
War mir noch nicht klar ist, die die Zeile
bootcmd=mmc dev 1;run scriptload;run scriptboot;setenv devnum 0;mmc dev
0;run scriptload;run scriptboot
modifiziert werden muss um nicht von mmc Subsystem sonder von SATA
Controller zu booten.
Muss das mmc durch sd oder was anderes ersetzt werden?
Meine U-Boot Settings, d.h. die permanenten Vars sehen wie folgt aus.
U-Boot> printenv
baudrate=115200
bootcmd=mmc dev 1;run scriptload;run scriptboot;setenv devnum 0;mmc dev
0;run scriptload;run scriptboot
bootdelay=3
bootm_size=0x10000000
devnum=1
fdt_addr_r=0x86000000
fdtaddr=0x86000000
fdtcontroladdr=fffd0580
fdtload=setenv loadaddr ${fdtaddr};setenv mmcfile ${mmcfdtfile};run
fileload
fileload=${mmctype}load mmc ${devnum}:${mmcpart} ${loadaddr} ${mmcfile}
initrdload=setenv loadaddr ${rdaddr};setenv mmcfile ${mmcinitrdfile};run
fileload
kernel_addr_r=0x82000000
kernload=setenv loadaddr ${kernel_addr_r};setenv mmcfile
${mmckernfile};run fileload
loadaddr=0x82000000
mmcfdtfile=boot/dtb/mt7623n-bananapi-bpi-r2.dtb
mmcinitrdfile= boot/uInitrd
mmckernfile=boot/zImage
mmcpart=1
mmcscriptfile=boot/boot.scr
mmctype=ext4
ramdisk_addr_r=0x86080000
rdaddr=0x86080000
scriptaddr=0x85F80000
scriptboot=echo Running ${mmcscriptfile} from: mmc ${devnum}:${mmcpart}
using ${mmcscriptfile};source ${scriptaddr};
scriptload=setenv loadaddr ${scriptaddr};setenv mmcfile
${mmcscriptfile};run fileload
Falls Du was in Peto bezüglich der Start-Einstellungen von U-Boothast,
wäre ich dafür dankbar.
Ansonsten muss ich mich noch mit U-Boot geschäftigen - will ja was
lernen ;-)
Markus
:
Bearbeitet durch User
@Markus W, FYI: der @Frank-w hat auch ein u-boot repo (für BPI-R2) auf github, darin auch ein Boot-Menü mit Auswahl: https://github.com/frank-w/u-boot/blob/2019-01-bpi-r2/uEnv.txt
:
Bearbeitet durch User
Richtig, mit den vordefinierten umgebungsvariablen kann man relativ leicht mehrere Kernel parallel probieren (auswahl aus dateilisting oder selbst einen mebüeintrag definieren). Auch tftp-boot und dto (device tree overlays) funktionieren :) wegen kernel...klar kann man sich selbst durchwühlen,aber ich bräuchte halt einige Leute zum testen und ggf. zum Portieren. Besonders der wifi-Treiber ist ziemlich schlecht programmiert (u.a. wmt-tools benötigt). Besonders die netzwerktests sind sehr aufwendig,wenn man dafür extra mehrere clients konfigurieren muss. Aktuell geht nur 1gbit/s durch,selbst wenn die 2.gmac aktiv ist (die erste auf port 6 des switch-chips unterstützt angeblich trgmii=2,5gbit)
@All ich habe immerhin herausgefunden, dass ich mit dem bestehenden uboot von armbien kein boot von SATA Devices machen kann, weil das SATA Subsystem darin fehlt. Ich bin gerade mit dem Bau eines neuen Uboot zugange, kämpfe aber noch mit Python2 Abhängigkeiten auf meinem Python3 System. Es gibt bei mir nur eine find /usr -name \*ython.h /usr/include/python3.7m/Python.h in dem o.g Verzeichnis. In der u.g. setup.py >cat scripts/dtc/pylibfdt/setup.py #!/usr/bin/env python2 Wird der Python2 Interpreter aufgerufen. Und SWIG erzeugt ein libfdt_wrap.c mit dem # include <Python.h> das immer wieder neu generiert wird. Beim ./build.sh Aufruf bzw. bei make erscheinet dann der u.g. Fehler. >make ARCH=arm CROSS_COMPILE=arm-suse-linux-gnueabi- CHK include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s CHK include/generated/generic-asm-offsets.h CHK include/generated/asm-offsets.h PYMOD scripts/dtc/pylibfdt/_libfdt.so scripts/dtc/pylibfdt/libfdt_wrap.c:149:11: fatal error: Python.h: Datei oder Verzeichnis nicht gefunden 149 | # include <Python.h> | ^~~~~~~~~~ compilation terminated. Hat jemend eine Idee woran das liegt und wie ich meine Python-Umgebung anpassen kann. Ein gezieltes setzen des Includpfades von # include <Python.h> auf # include <python3.7m/Python.h> im libfdt_wrap.c scheitert leider wegen der auto-gen Erzeugung der Wrapper-C_Files vai SWIG. Danke für hilfreiche Hinweise. Markus
Betreffend uboot: weder das offizielle (2014er) noch mainline/mein Uboot verfügt über den sata-treiber. Somit muss uboot und der kernel auf sd/emmc liegen. Das rootfs kann dann auf der ssd liegen,wenn der sata-treiber builtin sind (für Module muss bereits FS-Zugriff bestehen. Der R2 verfügt übrigens über einen pcie-Anschluss,es ist kein m2sata.
Hast du es mal mit meinem Repo probiert? Dort existiert eine build.sh,worüber du das menuconfig aufrufen kannst. Musst nur ggf den crosscompiler ändern
Hallo Frank, genau bei diesem Build häge ich. Habe dort den SATA Treiber via menuconfig inkludiert. Hast Du möglicherweise eine .config, auf der ich aufbauen kann, ohne alle Optionen der GUI durchforsten zu müssen. Markus
https://github.com/frank-w/u-boot/blob/70875a64348dfb3c914afd6d8bf562e8a882932e/configs/mt7623n_bpir2_defconfig Für sata fehlt aber wie gesagt der grundlegende hardware-treiber. Es reicht nicht SATA als Abstraktion zu aktivieren ohne den Hardwaretreiber für das Board.
Frank, damit willst Du mir schonend beibringen, dass ich erst den Kernel von der SD oder eMMC laden muss um dann erst auf ein SATA Device wie /dev/sdx zugreifen zu können - richtig? Markus
Korrekt,ich hane im bpi-forum bereits vor einiger zeit nach einem sata-treiber angefragt,aber das ist sehr zäh,deswegen habe ich ja mein eigenes repo angefangen Zumindest das hdmi wird wohl endlich un mainline gefixt
Frank, scheinbar gibt es diesbezüglich bei uboot und SATA seit September 2017 keinen Fortschritt. https://github.com/BPI-SINOVOIP/BPI-R2-bsp/issues/10 Markus
Die "Neue Welle" bei SBCs wird mit sich bringen dass M.2 (NVMe) den SATA ablösen wird. Denn, macht ja viel Sinn: so ein Kleincomputer ist von Hause aus langsamer als ein Desktop oder Laptop; da braucht es wenigestens schnelle SSD-Anbindung über die neuen schnellen Interfaces wie M.2/PCIe/USB-C etc. SATA kann da nicht mehr mithalten.
Doch,seit 2018-11 ist der bpi-r2 grundsätzlich im upstream uboot...vorher gab es nur die 2014er Version die sich mit aktuellen compilern nicht mehr kompilieren lässt bzw nicht startet. Außerdem geht mit dem neuen uboot u.a. dt-overlay.
Noch eine Frage zu uboot! Wenn der aktuelle Linux Kernel den SATA Kontroller vom BPi-R2 ansprechen kann, warum ist es dann so schwierig dies aus uboot zu bewerkstelligen? Ist uboot wegen seiner Kompaktheit als Loader auf andere Treiber Architekturen angewiesen und kann deshalb bestehende Module oder ihren Code aus Linux nicht verwenden? Markus
Die treiber aus dem linux-kernel müssen halt auf uboot portiert werden,was angesichts der unterschiedlichen frameworks nicht trivial ist
Was meinst Du damit! "unterschiedlichen frameworks" => bild tools od. build environment ??? Markus
Frank, Bekomme auf meinem NB den im Anhang gezeigten uboot build error bei ./build config aus Deinem Repo. Hast Du auf die Schnelle eine Idee was mir noch fehlt um Dein uboot aus dem Repo zu bauen. Habe jetzt nur Zugriff auf mein NB und nicht meinen Desktop PC. Markus Nachtrag, habe dies hierzu gefunden: "To answer a more generic case, this error is noticed when you pick a function name which is already used in some built in library. For e.g., select. A simple method to know about it is while compiling the file, the compiler will indicate the previous declaration."
:
Bearbeitet durch User
Kannst du den gcc crosscompiler nutzen https://github.com/frank-w/u-boot/blob/89401dc85a3d1793261024a6e4047a7e4c9d079d/build.sh#L3 ? Evtl. Ist der CC von suse nicht kompatibel...
Ich müsste das Repo für arm-linux-gnueabihf- finden, das sich unter Suse Tumbleweed installieren lässt. Werde mal schauen. Wobei ich erst mal einen Vergleich mit meinem Desktop machen werde. Markus
Es sind soweit ich sehe alles "conflicting types"...es gibt also 2 unterschiedliche Deklarationen (vermutlich uboot-header und includes des compilers). /usr/local/include/sys/types.h Sieht stark danach aus,dass die x64-headers statt des crosscompilers verwendet werden...evtl.musst du einen anderen include path setzen (/usr/share/...) arm-linux-gnueabihf- ist gcc von linaro (standard auf debian-systemen) Mit frameworks meine ich die generischen Funktionen in linux/uboot,die teils unterschiedlich sind
:
Bearbeitet durch User
Der arm-suse-linux-gnueabi-gcc liefert als Such-Pfade
>arm-suse-linux-gnueabi-gcc -print-search-dirs | grep libraries | sed 's/:/\n/g'
die folgenden Verzeichnisse:
libraries
=/usr/lib64/gcc/arm-suse-linux-gnueabi/9/
/usr/lib64/gcc/arm-suse-linux-gnueabi/9/../../../../arm-suse-linux-gnuea
bi/lib/arm-suse-linux-gnueabi/9/
/usr/lib64/gcc/arm-suse-linux-gnueabi/9/../../../../arm-suse-linux-gnuea
bi/lib/
/usr/arm-suse-linux-gnueabi/lib/arm-suse-linux-gnueabi/9/
/usr/arm-suse-linux-gnueabi/lib/
/usr/arm-suse-linux-gnueabi/usr/lib/arm-suse-linux-gnueabi/9/
/usr/arm-suse-linux-gnueabi/usr/lib/
Markus
Hast du die zeile aus dem build-script angepasst auf deinen crosscompiler ohne "gcc"?
Hallo Frank, und Mutluit M., Nach langem Suchen gestern Abend, konnte ich endlich das u-boot.bin erzeugen. Ich muste im Top-Level Makfile die u.g. Zeile (Pos. 361) entsprechend ändern, damit meine Python3 Umgebung verwendet wird PYTHON ?= python ==> PYTHON = python3 und der Linker sich nicht über ein Fehlen von python2.7 Lib beschwert "cannot find -lpython2.7" /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: cannot find -lpython2.7 Zudem musste ich Links in /usr/include entsprechend meiner Python.h auf die jeweiligen Includ-Files setzen, bei mir waren es diese: ln -s ./python3.7m/Python.h Python.h ln -s ./python3.7m/patchlevel.h patchlevel.h ln -s ./python3.7m/pymacconfig.h pymacconfig.h ln -s ./python3.7m/pyport.h pyport.h ln -s ./python3.7m/pymacro.h pymacro.h ln -s ./python3.7m/pyatomic.h pyatomic.h ln -s ./python3.7m/pymath.h pymath.h ln -s ./python3.7m/pytime.h pytime.h ln -s ./python3.7m/object.h object.h ln -s ./python3.7m/pymem.h pymem.h ln -s ./python3.7m/objimpl.h objimpl.h ln -s ./python3.7m/typeslots.h typeslots.h ln -s ./python3.7m/pyhash.h pyhash.h ln -s ./python3.7m/pydebug.h pydebug.h ln -s ./python3.7m/bytearrayobject.h bytearrayobject.h ln -s ./python3.7m/bytesobject.h bytesobject.h ln -s ./python3.7m/unicodeobject.h unicodeobject.h ln -s ./python3.7m/longobject.h longobject.h ln -s ./python3.7m/longintrepr.h longintrepr.h ln -s ./python3.7m/boolobject.h boolobject.h ln -s ./python3.7m/floatobject.h floatobject.h ln -s ./python3.7m/complexobject.h complexobject.h ln -s ./python3.7m/rangeobject.h rangeobject.h ln -s ./python3.7m/memoryobject.h memoryobject.h ln -s ./python3.7m/tupleobject.h tupleobject.h ln -s ./python3.7m/listobject.h listobject.h ln -s ./python3.7m/dictobject.h dictobject.h ln -s ./python3.7m/odictobject.h odictobject.h ln -s ./python3.7m/enumobject.h enumobject.h ln -s ./python3.7m/setobject.h setobject.h ln -s ./python3.7m/methodobject.h methodobject.h ln -s ./python3.7m/moduleobject.h moduleobject.h ln -s ./python3.7m/funcobject.h funcobject.h ln -s ./python3.7m/classobject.h classobject.h ln -s ./python3.7m/fileobject.h fileobject.h ln -s ./python3.7m/pycapsule.h pycapsule.h ln -s ./python3.7m/traceback.h traceback.h ln -s ./python3.7m/sliceobject.h sliceobject.h ln -s ./python3.7m/cellobject.h cellobject.h ln -s ./python3.7m/iterobject.h iterobject.h ln -s ./python3.7m/genobject.h genobject.h ln -s ./python3.7m/descrobject.h descrobject.h ln -s ./python3.7m/warnings.h warnings.h ln -s ./python3.7m/weakrefobject.h weakrefobject.h ln -s ./python3.7m/structseq.h structseq.h ln -s ./python3.7m/namespaceobject.h namespaceobject.h ln -s ./python3.7m/codecs.h codecs.h ln -s ./python3.7m/pyerrors.h pyerrors.h ln -s ./python3.7m/pystate.h pystate.h ln -s ./python3.7m/context.h context.h ln -s ./python3.7m/pythread.h pythread.h ln -s ./python3.7m/pyarena.h pyarena.h ln -s ./python3.7m/modsupport.h modsupport.h ln -s ./python3.7m/compile.h compile.h ln -s ./python3.7m/pythonrun.h pythonrun.h ln -s ./python3.7m/pylifecycle.h pylifecycle.h ln -s ./python3.7m/ceval.h ceval.h ln -s ./python3.7m/sysmodule.h sysmodule.h ln -s ./python3.7m/code.h code.h ln -s ./python3.7m/osmodule.h osmodule.h ln -s ./python3.7m/intrcheck.h intrcheck.h ln -s ./python3.7m/import.h import.h ln -s ./python3.7m/abstract.h abstract.h ln -s ./python3.7m/bltinmodule.h bltinmodule.h ln -s ./python3.7m/eval.h eval.h ln -s ./python3.7m/pyctype.h pyctype.h ln -s ./python3.7m/pystrtod.h pystrtod.h ln -s ./python3.7m/dtoa.h dtoa.h ln -s ./python3.7m/fileutils.h fileutils.h ln -s ./python3.7m/pyfpe.h pyfpe.h Unter der Verwendung des Kommandos ./build.sh importconfig was eine .config erzeugt und ./build.sh Konnte ich des Binary kompilieren und linken. Bei der Fehlersuche, wenn build.sh aussteigt, sind die Kommandos make ARCH=arm CROSS_COMPILE=arm-suse-linux-gnueabi- und make -n ARCH=arm CROSS_COMPILE=arm-suse-linux-gnueabi- hilfreich, wobei CROSS_COMPILE für die eigene Umgebung angepasst werden muss auch in der build.sh Datei. Jetzt werde ich mal das U-boot auf die SD Karte installieren. Markus
:
Bearbeitet durch User
Ich hänge mal meine u-boot.cfg an. Vielleicht könnt Ihr mal drüber sehen. Für das Schreiben von u-boot auf die SD Karte via dd habe ich folgenden Beitrag gefunden. uboot dd iflag=dsync oflag=dsync if=u-boot.bin of=/dev/sde bs=512 seek=63 Please notes: 1) The partition table is at SDcard offset 0 (seek 0), then you have to run: fdisk /dev/sde and create paratiions that does not overlapped with blocks ocppuied by kernel or trust software. 2) add the "dsync" option in dd command to gaurantee every written data is immediately flushed into SD card So whatever you are doing for u-boot is correct, you need to use dd command for that. sudo dd if=u-boot.bin of=/dev/sdb bs=512 seek=2 While partitioning the sd card, Make sure that you are keeping enough room for u-boot image. So start your 1st bootable partition at let's say 1 MB offset. Markus
:
Bearbeitet durch User
was mich wundert ist, dass python3 meiner Meinung nach nichts mit dem include-Pfad des Crosscompilers zu tun haben dürfte...imho darf bei crosscompile /usr/src/linux nicht verwendet werden, bzw. nur als letzte option die build.sh enthält eine install option ;) damit wird die uboot.bin an die Position geschrieben, wie sie für die debian/ubuntu-images passt. Gruß Frank
Bei Meinem OS (SUSE) existiert ein /usr/include Verzeichnis für alle Dev-Packete und /usr/src/include sind die Includes für den Linux-Kernel Build. Hat mit CROSS_COMPILE meiner Ansicht nach nichts zu tun. Markus
Ich bin übrigns gerade mit QEMU-ARM zugange um den u-boot in der Emulation zu starten und damit zu spielen. Leider habe ich noch keine BPi-R2 Machine gefunden. Aber vexpress-a9 soll auch funktionieren. qemu-system-arm -machine vexpress-a9 -cpu cortex-a9 -m 128M -dtb ./linux-5.1.5/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb -kernel u-boot In Anhang sind die möglichen machine und cpu Optionen gelistet. Markus
mit qemu habe ich diesbezüglich keine Ahnung. die Position von uboot wird mit dem preloader und den nachfolgenden headern (BRLYT) festgelegt... ich nehme an, in qemu übergibst du den uboot direkt, oder ein komplettes Datenträger-Image? letztendlich muss qemu ein armv7 mit hardfloat emulieren, aber inwieweit das in der frühen Bootphase möglich ist weis ich nicht ansonsten, wenn Änderungen an meinen Scripten gewünscht sind: einfach Bescheid sagen, dann schauen wir zusammen, wie wir das sauber reinbekommen ohne die bisherige Funktionalität zu stören
@All,
nach langem Rumprobieren ist mir die Anbindung der SSD
und das Konfigurieren von U-Boot gelungen, so daß ich
mit der SSD arbeiten kann.
root@bananapir2:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 969M 0 969M 0% /dev
tmpfs 202M 6.5M 195M 4% /run
/dev/sda6 32G 859M 29G 3% /
tmpfs 1006M 0 1006M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1006M 0 1006M 0% /sys/fs/cgroup
/dev/sda1 485M 147M 309M 33% /boot
/dev/sda5 16G 45M 15G 1% /tmp
/dev/sda3 16G 177M 15G 2% /var
tmpfs 202M 0 202M 0% /run/user/0
root@bananapir2:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=992212k,nr_inodes=168684,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs
(rw,nosuid,noexec,relatime,size=205876k,mode=755)
/dev/sda6 on / type ext4 (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/rdma type cgroup
(rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/pids type cgroup
(rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/sda1 on /boot type ext4 (rw,noatime,nodiratime,commit=600)
/dev/sda5 on /tmp type ext4 (rw,noatime,nodiratime,commit=600)
/dev/sda3 on /var type ext4 (rw,noatime,nodiratime,commit=600)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=205872k,mode=700)
Netzwerk funktioniert soweit auch.
root@bananapir2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 6e:8f:b9:10:ab:d7 brd ff:ff:ff:ff:ff:ff
inet6 XXXX::XXXX:XXXX:XXXX:XXXX/64 scope link
valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet XX.XX.XX.XX/24 brd XX.XX.XX.XX scope global dynamic br0
valid_lft 3069144644sec preferred_lft 3069144644sec
inet6 XXXX::XXXX:XXXX:XXXX:XXXX/64 scope link
valid_lft forever preferred_lft forever
4: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master br0 state UP group default qlen 1000
link/ether 6e:8f:b9:10:ab:d7 brd ff:ff:ff:ff:ff:ff
5: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether 6e:8f:b9:10:ab:d7 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether 6e:8f:b9:10:ab:d7 brd ff:ff:ff:ff:ff:ff
7: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether 6e:8f:b9:10:ab:d7 brd ff:ff:ff:ff:ff:ff
8: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether 6e:8f:b9:10:ab:d7 brd ff:ff:ff:ff:ff:ff
Jetzt muss ich noch die Transferraten und die WAN/-Local-LAN
konfiguration meistern, um den R2 an die FB anzubinden.
Markus
:
Bearbeitet durch User
Willst du den r2 als router oder als reinen lan-client nutzen? bei ersterem musst nur wan aus der bridge nehmen und entsprechend als wan nutzen (anderes subnet nutzen bzw wie ich ppp drüber laufen lassen). Was mich wundert ist dass du dich gefreut hast,dass die lan-ports einzeln greifbar sind,sie dann aber mit der br0 wieder zusammen bridgest. Ssd läuft übrigends unter meinem kernel bereits schon unter 4.14 (habe auch eine dran hängen,wo alles außer das grundsystem drauf liegt...inkl. var und home /tmp ist eine ramdisk)
@All,
@Frank,
Hallo Frank an der LAN-Konfiguration habe ich noch nichts
gemacht. Das sind die default setting von Armbian-Linux.
Unten hast Du einige iperf3 Messungen für den lockalen
Transfer von lan0 zu lan2
Den R2 möchte ich mit dem WAN-NIC an die FB legen und
die lan0-3 Interfaces sollen for NB, PNR, Scanner, IOT
verwendet werden, mit einer FW zwischen WAN/LAN.
Markus
lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.200.0.1 netmask 255.255.255.0 broadcast 192.200.0.255
ether f2:db:06:3b:53:e0 txqueuelen 1000 (Ethernet)
RX packets 282 bytes 21996 (21.9 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1383 bytes 73773 (73.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lan2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.200.0.2 netmask 255.255.255.0 broadcast 192.200.0.255
ether f2:db:06:3b:53:e0 txqueuelen 1000 (Ethernet)
RX packets 266 bytes 20748 (20.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1397 bytes 75125 (75.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
5: lan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master br0 state UP group default qlen 1000
link/ether f2:db:06:3b:53:e0 brd ff:ff:ff:ff:ff:ff
inet 192.200.0.1/24 brd 192.200.0.255 scope global lan0
valid_lft forever preferred_lft forever
7: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master br0 state UP group default qlen 1000
link/ether f2:db:06:3b:53:e0 brd ff:ff:ff:ff:ff:ff
inet 192.200.0.2/24 brd 192.200.0.255 scope global lan2
valid_lft forever preferred_lft forever
root@bananapir2:/home# iperf3 -s 192.200.0.1 -p 5001 &
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
root@bananapir2:/home# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001
Connecting to host 192.200.0.1, port 5001
Accepted connection from 192.200.0.2, port 35707
[ 4] local 192.200.0.2 port 57095 connected to 192.200.0.1 port 5001
[ 5] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 57095
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 320 MBytes 2.68 Gbits/sec
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 320 MBytes 2.68 Gbits/sec 0 959 KBytes
[ 5] 1.00-2.00 sec 381 MBytes 3.20 Gbits/sec
[ 4] 1.00-2.00 sec 390 MBytes 3.27 Gbits/sec 0 1.19 MBytes
[ 4] 2.00-3.00 sec 348 MBytes 2.92 Gbits/sec 0 1.19 MBytes
[ 5] 2.00-3.00 sec 355 MBytes 2.98 Gbits/sec
[ 4] 3.00-4.00 sec 335 MBytes 2.81 Gbits/sec 0 1.19 MBytes
[ 5] 3.00-4.00 sec 337 MBytes 2.83 Gbits/sec
[ 5] 4.00-5.00 sec 356 MBytes 2.98 Gbits/sec
[ 4] 4.00-5.00 sec 356 MBytes 2.98 Gbits/sec 0 1.19 MBytes
[ 5] 5.00-6.00 sec 379 MBytes 3.18 Gbits/sec
[ 4] 5.00-6.00 sec 386 MBytes 3.24 Gbits/sec 0 1.19 MBytes
[ 5] 6.00-7.00 sec 316 MBytes 2.65 Gbits/sec
[ 4] 6.00-7.00 sec 311 MBytes 2.61 Gbits/sec 0 1.19 MBytes
[ 5] 7.00-8.00 sec 339 MBytes 2.85 Gbits/sec
[ 4] 7.00-8.00 sec 338 MBytes 2.83 Gbits/sec 0 1.19 MBytes
[ 5] 8.00-9.00 sec 379 MBytes 3.18 Gbits/sec
[ 4] 8.00-9.00 sec 386 MBytes 3.25 Gbits/sec 0 1.19 MBytes
[ 5] 9.00-10.00 sec 292 MBytes 2.45 Gbits/sec
[ 5] 10.00-10.00 sec 448 KBytes 2.11 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec
sender
[ 5] 0.00-10.00 sec 3.37 GBytes 2.90 Gbits/sec
receiver
[ 4] 9.00-10.00 sec 285 MBytes 2.39 Gbits/sec 0 1.19 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.37 GBytes 2.90 Gbits/sec 0
sender
[ 4] 0.00-10.00 sec 3.37 GBytes 2.90 Gbits/sec
receiver
iperf Done.
root@bananapir2:/home# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001
-b 512k
Accepted connection from 192.200.0.2, port 50525
Connecting to host 192.200.0.1, port 5001
[ 4] local 192.200.0.2 port 57627 connected to 192.200.0.1 port 5001
[ 6] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 57627
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.38 MBytes 11.5 Mbits/sec 0 639 KBytes
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-1.00 sec 384 KBytes 3.14 Mbits/sec
[ 4] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec 0 639 KBytes
[ 6] 1.00-2.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 2.00-3.00 sec 382 KBytes 3.13 Mbits/sec 0 639 KBytes
[ 6] 2.00-3.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 3.00-4.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
[ 6] 3.00-4.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 4.00-5.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
[ 6] 4.00-5.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 5.00-6.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
[ 6] 5.00-6.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 6.00-7.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
[ 6] 6.00-7.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 7.00-8.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
[ 6] 7.00-8.00 sec 63.9 KBytes 524 Kbits/sec
[ 4] 8.00-9.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
[ 6] 8.00-9.00 sec 63.9 KBytes 524 Kbits/sec
[ 6] 9.00-10.00 sec 63.9 KBytes 524 Kbits/sec
[ 6] 10.00-10.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec
sender
[ 6] 0.00-10.00 sec 959 KBytes 786 Kbits/sec
receiver
[ 4] 9.00-10.00 sec 63.9 KBytes 524 Kbits/sec 0 639 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.43 MBytes 2.88 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 959 KBytes 786 Kbits/sec
receiver
iperf Done.
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
root@bananapir2:/home# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001
-b 1024k
Accepted connection from 192.200.0.2, port 49261
Connecting to host 192.200.0.1, port 5001
[ 6] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 44851
[ 4] local 192.200.0.2 port 44851 connected to 192.200.0.1 port 5001
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.38 MBytes 11.5 Mbits/sec 0 639 KBytes
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-1.00 sec 448 KBytes 3.67 Mbits/sec
[ 4] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec 0 639 KBytes
[ 6] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec
[ 6] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 2.00-3.00 sec 574 KBytes 4.70 Mbits/sec 0 639 KBytes
[ 6] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 3.00-4.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
[ 4] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
[ 6] 4.00-5.00 sec 128 KBytes 1.05 Mbits/sec
[ 6] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 5.00-6.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
[ 6] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 6.00-7.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
[ 6] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 7.00-8.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
[ 6] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec
[ 4] 8.00-9.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
[ 6] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec
[ 6] 10.00-10.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec
sender
[ 6] 0.00-10.00 sec 1.56 MBytes 1.31 Mbits/sec
receiver
[ 4] 9.00-10.00 sec 128 KBytes 1.05 Mbits/sec 0 639 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 4.06 MBytes 3.41 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 1.56 MBytes 1.31 Mbits/sec
receiver
iperf Done.
root@bananapir2:/home# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001
-b 2048k
Accepted connection from 192.200.0.2, port 50899
Connecting to host 192.200.0.1, port 5001
[ 6] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 52163
[ 4] local 192.200.0.2 port 52163 connected to 192.200.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-1.00 sec 576 KBytes 4.72 Mbits/sec
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.38 MBytes 11.5 Mbits/sec 0 639 KBytes
[ 6] 1.00-2.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 1.00-2.00 sec 1.25 MBytes 10.5 Mbits/sec 0 639 KBytes
[ 6] 2.00-3.00 sec 192 KBytes 1.57 Mbits/sec
[ 4] 2.00-3.00 sec 893 KBytes 7.32 Mbits/sec 0 639 KBytes
[ 6] 3.00-4.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 3.00-4.00 sec 256 KBytes 2.10 Mbits/sec 0 639 KBytes
[ 6] 4.00-5.00 sec 256 KBytes 2.09 Mbits/sec
[ 4] 4.00-5.00 sec 256 KBytes 2.09 Mbits/sec 0 639 KBytes
[ 6] 5.00-6.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 5.00-6.00 sec 256 KBytes 2.10 Mbits/sec 0 639 KBytes
[ 6] 6.00-7.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 6.00-7.00 sec 256 KBytes 2.10 Mbits/sec 0 639 KBytes
[ 6] 7.00-8.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 7.00-8.00 sec 256 KBytes 2.10 Mbits/sec 0 639 KBytes
[ 6] 8.00-9.00 sec 256 KBytes 2.10 Mbits/sec
[ 4] 8.00-9.00 sec 256 KBytes 2.10 Mbits/sec 0 639 KBytes
[ 6] 9.00-10.00 sec 256 KBytes 2.10 Mbits/sec
[ 6] 10.00-10.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec
sender
[ 6] 0.00-10.00 sec 2.75 MBytes 2.30 Mbits/sec
receiver
[ 4] 9.00-10.00 sec 256 KBytes 2.09 Mbits/sec 0 639 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 5.25 MBytes 4.40 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 2.75 MBytes 2.30 Mbits/sec
receiver
iperf Done.
root@bananapir2:/home# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001
-b 100M
Connecting to host 192.200.0.1, port 5001
Accepted connection from 192.200.0.2, port 54633
[ 4] local 192.200.0.2 port 51421 connected to 192.200.0.1 port 5001
[ 6] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 51421
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 10.9 MBytes 91.2 Mbits/sec 0 639 KBytes
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-1.00 sec 10.8 MBytes 90.6 Mbits/sec
[ 4] 1.00-2.00 sec 12.0 MBytes 101 Mbits/sec 0 639 KBytes
[ 6] 1.00-2.01 sec 12.0 MBytes 100 Mbits/sec
[ 4] 2.00-3.00 sec 11.9 MBytes 99.7 Mbits/sec 0 639 KBytes
[ 6] 2.01-3.00 sec 11.9 MBytes 100 Mbits/sec
[ 4] 3.00-4.00 sec 12.0 MBytes 101 Mbits/sec 0 639 KBytes
[ 6] 3.00-4.00 sec 11.9 MBytes 99.7 Mbits/sec
[ 4] 4.00-5.00 sec 11.9 MBytes 99.6 Mbits/sec 0 639 KBytes
[ 6] 4.00-5.00 sec 11.9 MBytes 100 Mbits/sec
[ 4] 5.00-6.00 sec 11.9 MBytes 99.6 Mbits/sec 0 639 KBytes
[ 6] 5.00-6.00 sec 11.9 MBytes 100 Mbits/sec
[ 4] 6.00-7.00 sec 12.0 MBytes 101 Mbits/sec 0 639 KBytes
[ 6] 6.00-7.01 sec 12.0 MBytes 100 Mbits/sec
[ 4] 7.00-8.00 sec 11.9 MBytes 99.6 Mbits/sec 0 639 KBytes
[ 6] 7.01-8.00 sec 11.8 MBytes 99.5 Mbits/sec
[ 4] 8.00-9.00 sec 12.0 MBytes 101 Mbits/sec 0 639 KBytes
[ 6] 8.00-9.01 sec 12.0 MBytes 100 Mbits/sec
[ 6] 9.01-10.01 sec 11.8 MBytes 98.9 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-10.01 sec 0.00 Bytes 0.00 bits/sec
sender
[ 6] 0.00-10.01 sec 118 MBytes 98.9 Mbits/sec
receiver
[ 4] 9.00-10.00 sec 11.9 MBytes 99.7 Mbits/sec 0 639 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 118 MBytes 99.2 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 118 MBytes 99.0 Mbits/sec
receiver
iperf Done.
root@bananapir2:/home# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001
-b 1000M
Accepted connection from 192.200.0.2, port 53697
Connecting to host 192.200.0.1, port 5001
[ 6] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 38445
[ 4] local 192.200.0.2 port 38445 connected to 192.200.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-1.00 sec 107 MBytes 901 Mbits/sec
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 109 MBytes 917 Mbits/sec 0 639 KBytes
[ 6] 1.00-2.00 sec 119 MBytes 1.00 Gbits/sec
[ 4] 1.00-2.00 sec 119 MBytes 999 Mbits/sec 0 639 KBytes
[ 6] 2.00-3.00 sec 119 MBytes 1.00 Gbits/sec
[ 4] 2.00-3.00 sec 119 MBytes 1000 Mbits/sec 0 639 KBytes
[ 6] 3.00-4.00 sec 119 MBytes 1.00 Gbits/sec
[ 4] 3.00-4.00 sec 119 MBytes 1.00 Gbits/sec 0 639 KBytes
[ 6] 4.00-5.00 sec 119 MBytes 1000 Mbits/sec
[ 4] 4.00-5.00 sec 119 MBytes 999 Mbits/sec 0 639 KBytes
[ 4] 5.00-6.00 sec 119 MBytes 1.00 Gbits/sec 0 639 KBytes
[ 6] 5.00-6.00 sec 119 MBytes 1000 Mbits/sec
[ 6] 6.00-7.00 sec 119 MBytes 1000 Mbits/sec
[ 4] 6.00-7.00 sec 119 MBytes 1.00 Gbits/sec 0 639 KBytes
[ 6] 7.00-8.00 sec 119 MBytes 1.00 Gbits/sec
[ 4] 7.00-8.00 sec 119 MBytes 1.00 Gbits/sec 0 639 KBytes
[ 6] 8.00-9.00 sec 119 MBytes 1000 Mbits/sec
[ 4] 8.00-9.00 sec 119 MBytes 1.00 Gbits/sec 0 639 KBytes
[ 6] 9.00-10.00 sec 119 MBytes 1.00 Gbits/sec
[ 6] 10.00-10.00 sec 63.9 KBytes 704 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 6] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec
sender
[ 6] 0.00-10.00 sec 1.15 GBytes 990 Mbits/sec
receiver
[ 4] 9.00-10.00 sec 119 MBytes 999 Mbits/sec 0 639 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.15 GBytes 992 Mbits/sec 0
sender
[ 4] 0.00-10.00 sec 1.15 GBytes 990 Mbits/sec
receiver
iperf Done.
wie sieht es bei dir aus, wenn du den Bandwith-Parameter weglässt? imho verfälscht er die Werte (erzeugt entweder zu wenig Pakete oder zuviele => pauseframes) der Test oben mit den 2.5GBit ist afaik nur der IP-Stack (SW-limitiert auf TRGMII=2.5Gbit/s), da geht es nicht über die Hardware. Wenn ich Pakete über die Hardware schicke, habe ich maximal 1Gbit/s (mehrere 1G-fähige Clients direkt an den LAN-Ports). auch mit der 2.gmac und der Nutzung des WAN-POrts weiterhin nur 1GBit/s so wie es aussieht, existiert nur ein 1G-Wiring zwischen SOC und Switch (technische Doku zum SOC)....ist aber unbestätigt....offizielle Aussagen sind da schwer zu bekommen.
Ohne -b Option: s.u. Hast Du schon mal nftables installiert/konfiguriert? Gibt es da irgendwo default Regeln zum download, aus denen man etwas abschauen kann. Markus root@bananapir2:/dev/shm# ifconfig lan0 192.200.0.1 up root@bananapir2:/dev/shm# ifconfig lan2 192.200.0.2 up root@bananapir2:/dev/shm# iperf3 -s 192.200.0.1 -p 5001 & [1] 7956 root@bananapir2:/dev/shm# ----------------------------------------------------------- Server listening on 5001 ----------------------------------------------------------- root@bananapir2:/dev/shm# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001 Accepted connection from 192.200.0.2, port 36327 Connecting to host 192.200.0.1, port 5001 [ 5] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 50399 [ 4] local 192.200.0.2 port 50399 connected to 192.200.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.00-1.00 sec 298 MBytes 2.50 Gbits/sec [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 299 MBytes 2.50 Gbits/sec 0 2.06 MBytes [ 5] 1.00-2.00 sec 295 MBytes 2.48 Gbits/sec [ 4] 1.00-2.00 sec 295 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 2.00-3.00 sec 296 MBytes 2.48 Gbits/sec [ 4] 2.00-3.00 sec 296 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 3.00-4.00 sec 296 MBytes 2.48 Gbits/sec [ 4] 3.00-4.00 sec 295 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 4.00-5.00 sec 296 MBytes 2.48 Gbits/sec [ 4] 4.00-5.00 sec 296 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 5.00-6.00 sec 295 MBytes 2.48 Gbits/sec [ 4] 5.00-6.00 sec 295 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 6.00-7.00 sec 295 MBytes 2.48 Gbits/sec [ 4] 6.00-7.00 sec 295 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 7.00-8.00 sec 296 MBytes 2.48 Gbits/sec [ 4] 7.00-8.00 sec 296 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 8.00-9.00 sec 296 MBytes 2.48 Gbits/sec [ 4] 8.00-9.00 sec 296 MBytes 2.48 Gbits/sec 0 2.06 MBytes [ 5] 9.00-10.00 sec 296 MBytes 2.48 Gbits/sec [ 5] 10.00-10.00 sec 576 KBytes 2.38 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-10.00 sec 2.89 GBytes 2.48 Gbits/sec receiver [ 4] 9.00-10.00 sec 296 MBytes 2.48 Gbits/sec 0 2.06 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 2.89 GBytes 2.48 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 2.89 GBytes 2.48 Gbits/sec receiver iperf Done.
nur via iptables (nutzt afaik auch nftables) siehe mein wiki https://www.fw-web.de/dokuwiki/doku.php?id=bpi-r2:network:iptables wg. iperf3: ok, das ist der reine SW-Stack...2,5Gbit/s (trgmii) habe ich hardwareseitig noch nicht hinbekommen
@wie kann es der reine SW-Stack sein, wenn ich am NIC0 und NIC 2 ein Cat.6 Kabel habe. Wenn dem so wäre, müsste ich selbe Ergebnisse bekommen, wenn ich das Kabel entferen, nur dann geht der NIC in den Zustand NO-CARRIER. Ohne Kabel: root@bananapir2:/dev/shm# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001 iperf3: error - unable to connect to server: Cannot assign requested address Mit Kabel: root@bananapir2:/dev/shm# iperf3 -c 192.200.0.1 -B 192.200.0.2 --port 5001 Accepted connection from 192.200.0.2, port 60791 Connecting to host 192.200.0.1, port 5001 [ 5] local 192.200.0.1 port 5001 connected to 192.200.0.2 port 34565 [ 4] local 192.200.0.2 port 34565 connected to 192.200.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.00-1.00 sec 320 MBytes 2.69 Gbits/sec ...
hast du die Adressen statisch festgelegt oder via dhcp? es kann durchaus sein, dass die IP nur pingbar ist, wenn der port up ist. Wie gesagt, ich habe (über die gmac0=trgmii) nicht mehr als 1Gbit/s bekommen, wenn der traffic von den clients kommt bzw. zu diesen hin (von/zu SOC), eine reine client-client-verbindung habe ich nicht getestet, diese wäre bei 2 Clients aber maximal 1Gbit/s und afaik wird der traffic immer zum SOC geschickt (deswegen geht wohl tcpdump nicht richtig auf den DSA-Ports)
@Frank, IP's wurden händisch mittels ifconfig lan0 IP-A up und ifconfig lan0 IP-B up eingerichtet. Wird die Messung von iperf3 nicht bidirektional, also gleichzeitig vom und zum Server/Client betrieben. Markus
Dann wird die Adresse scheinbar deaktiviert,wenn das interface down ist.Macht auch Sinn.... Iperf ist normalerweise nur eine Richtung (client zum server afaik),lässt sich mit -R umdrehen,damit werden dann in 2 Durchgängen beide Richtungen getestet
@Frank,
dann bleibt nur noch die Frage offen, wie der
2.48 Gbits/sec Wert zu deuten ist.
Und noch was anderes, wie kann ich ins eMMC den
U-Boot übertragen.
Reicht ein dd if=SD-Card of=eMMC bs=512 seek=2
mit eMMC = /dev/mmcblk0.
Für die SSD wird
dd if=u-boot.bin of=/dev/sdX bs=512 seek=2
empfohlen, wobei mir nicht klar ist, ob ich
u-boot mit (2731364)
u-boot.bin mit (296196)
u-boot-mtk.bin mit (296708)
nehmen muss.
Das sind die Files, die ich beim Kompilieren Deines
U-Boot Reposytories bekommen habe.
users 2731364 3. Jun 09:24 u-boot
users 296196 3. Jun 09:24 u-boot-dtb.bin
users 296196 3. Jun 09:24 u-boot.bin
users 130229 3. Jun 09:24 u-boot.sym
users 64377 3. Jun 09:24 System.map
users 7904 3. Jun 09:24 u-boot.dtb
users 296708 3. Jun 09:24 u-boot-mtk.bin
Abhängig wie man den eMMC partitioniert
fängt die Partition bei 64'sten oder 2048'sten
512-Block an. Aber u-boot mit der grösten
Filegröße ist größer als 1MB (2731364)
Oder ist u-boot.bin eine komprimierte Version?
Aber Faktor 7 wäre doch zemlich viel an Kompression,
weshalb ich es nicht annehme.
Markus
Wie ich gerad sehe ist das u-boot Fiel eine ELF Binary.
HAtte nicht gedacht, das zum Bootloader-Zeitpunkt schon
ELF Binary ladbar sind. Aber da bin ich nicht so firm drin.
>readelf -S u-boot
There are 29 section headers, starting at offset 0x29a8dc:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg
Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .text PROGBITS 81e00000 010000 0003a8 00 AX
0 0 32
[ 2] .text_rest PROGBITS 81e003c0 0103c0 0275f4 00 AX
0 0 32
[ 3] .rodata PROGBITS 81e279b8 0379b8 011e0b 00 A
0 0 8
[ 4] .hash HASH 81e397c4 0497c4 000018 04 A
12 0 4
[ 5] .data PROGBITS 81e397dc 0497dc 0026e8 00 WA
0 0 4
[ 6] .got.plt PROGBITS 81e3bec4 04bec4 00000c 04 WA
0 0 4
[ 7] .u_boot_list PROGBITS 81e3bed0 04bed0 00123c 00 WA
0 0 4
[ 8] .rel.dyn REL 81e3d10c 04d10c 009518 08 A
12 0 4
[ 9] .bss_start PROGBITS 81e3d10c 056708 000000 00 W
0 0 1
[10] .bss NOBITS 81e3d10c 000000 0196a4 00 WA
0 0 64
[11] .bss_end PROGBITS 81e567b0 056708 000000 00 W
0 0 1
[12] .dynsym DYNSYM 81e46624 056624 000030 10 A
13 3 4
[13] .dynstr STRTAB 81e46654 056654 000001 00 A
0 0 1
[14] .dynamic DYNAMIC 81e46658 056658 000098 08 WA
13 0 4
[15] .gnu.hash GNU_HASH 81e466f0 0566f0 000018 04 A
12 0 4
[16] .ARM.attributes ARM_ATTRIBUTES 00000000 056708 00002b 00
0 0 1
[17] .comment PROGBITS 00000000 056733 000040 01 MS
0 0 1
[18] .debug_line PROGBITS 00000000 056773 02b416 00
0 0 1
[19] .debug_info PROGBITS 00000000 081b89 131e12 00
0 0 1
[20] .debug_abbrev PROGBITS 00000000 1b399b 02902f 00
0 0 1
[21] .debug_aranges PROGBITS 00000000 1dc9d0 0048e8 00
0 0 8
[22] .debug_str PROGBITS 00000000 1e12b8 01758c 01 MS
0 0 1
[23] .debug_frame PROGBITS 00000000 1f8844 00cfec 00
0 0 4
[24] .debug_loc PROGBITS 00000000 205830 06ad44 00
0 0 1
[25] .debug_ranges PROGBITS 00000000 270578 0094b0 00
0 0 8
[26] .symtab SYMTAB 00000000 279a28 017010 10
27 4825 4
[27] .strtab STRTAB 00000000 290a38 009d8f 00
0 0 1
[28] .shstrtab STRTAB 00000000 29a7c7 000114 00
0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
y (purecode), p (processor specific)
:
Bearbeitet durch User
Ich bin mir sicher dass bei den 2,5g nicht die gmac/switch involviert ist... Du musst die uboot.bin nehmen beim r2. als device /dev/mmcblkx ohne partition/bootx. Offset ist der gleiche wie bei sdcard https://www.fw-web.de/dokuwiki/doku.php?id=bpi-r2:storage Habe nur grade gesehen,dass das Beispiel noch den alten uboot nimmt. So machts die build.sh für die SD-Karte: https://github.com/frank-w/u-boot/blob/2019-01-bpi-r2/build.sh#L38 Musst im laufenden system also nur dev setzen auf /dev/mmcblkx (wenn 0 die sdkarte ist dann 1,sonst 0) und kannst die zeile genauso nutzen. Bei emmc muss der preloader mindestens in boot0 (evtl.auch in mmcblkx direkt)
Zur Info, falls es jemanden interessiert und er auch mit einem R2 liebäugelt. Kämpfe noch immer damit U-Boot auf die EMMC zu installieren. Irgendwie klappt es noch nicht @Frank Habe die u.g. Files BPI-R2-HEAD1-512b.img BPI-R2-HEAD440-0k.img BPI-R2-EMMC-boot0-DDR1600-0k-0905.img mit dd in das EMMC geschrieben nach mmcblk0 mit entsprechendem seek/skip offset wie in Deiner R2 Wiki beschrieben. SD/EMMC Schalter am R2 in beiden Stellungen ausprobiert, leider ohne Erfolg. Werde weitere Versuche starten und mich mit U-Boot mehr auseinander setzen, um den Mechanismus besser zu verstehen. Dank Deiner Wiki konnte ich schon Einiges lernen. Danke dafür. Habe zwischenzeitlich eine weitere Disk am SATA Anschluß angeschlossen und zwischen beiden Disks 10GB hin und her transferiert. Hat soweit alles geklappt und der Transfer lag immer über 90GB/Sek. - siehe Anhang. Als Disks ist eine SSD (SSDSC2KW24 von Intel) und eine herkömmliche 2,5" Disk von HST (HTS541010B7) in Betrieb. Man sieht auch, dass der SoC meinen urandom Datenstrom mit 33MB/Sek erzeugt, um das Versuchsfile zu befüllen. Markus
Hast du vorher die boot0-partition aktiviert und den preloader da reingeschrieben? https://www.fw-web.de/dokuwiki/doku.php?id=bpi-r2:storage#betriebssystem_auf_emmc_installieren
:
Bearbeitet durch User
@Frank, echo 0 > /sys/block/mmcblk1boot0/force_ro muss beim R2 echo 0 > /sys/block/mmcblk0boot0/force_ro heisen, wenn EMMC benützt werden soll. gunzip -c BPI-R2-EMMC-boot0-DDR1600-0k-0905.img.gz | sudo dd of=/dev/mmcblk1boot0 bs=1024 seek=0 entsprechend auch gunzip -c BPI-R2-EMMC-boot0-DDR1600-0k-0905.img.gz | sudo dd of=/dev/mmcblk0boot0 bs=1024 seek=0 Habe ich beides gemacht, allerdings verwende ich Deinen u-boot.bin, die ich aus dem Reposirory gebaut habe. Was mir gerade aufgefallen ist, ist dass in ./configs/mt7623n_bpir2_defconfig an der Stelle CONFIG_DEFAULT_ENV_FILE="uEnv.txt" auf uEnv.txt und nicht wie bei mir auf armbienEnv.txt verwiesen wird. Möglicherweise liegt es daran, werde es anpassen. Dachte aber, dass u-boot würde trotzdem was rausgeben, was aber leider nicht der Falls ist. Es tut sich einfach nichts. Danke trotzdem für den Hinweis. Markus
@Frank,
irgendwass muss ich noch falsch gemacht haben,
denn als ich jetzt erneut
echo 0 > /sys/block/mmcblk0boot0/force_ro
gunzip -c BPI-R2-EMMC-boot0-DDR1600-0k-0905.img.gz | sudo dd
of=/dev/mmcblk0boot0 bs=1024 seek=0
echo 1 > /sys/block/mmcblk0boot0/force_ro
durchgeführt habe, kamm sofort die u.g. Ausgabe.
*** U-Boot Boot Menu ***
1. Enter kernel-name to boot from SD/EMMC.
2. Boot kernel from TFTP.
3. Boot from SD/EMMC.
4. Boot from SD/EMMC 4.14.
5. Boot from SD/EMMC 4.19 (fdt/dto).
U-Boot console
Press UP/DOWN to move or Press 1~9,a~f to choose, ENTER to select
Bin wieder einen Schritt weiter.
Danke und bis zum Nächsten Mal.
Markus
Es muss an dem uEnv.txt gelegen haben, denn jetzt steht dort
bootenv=uEnv.txt.
:
Bearbeitet durch User
Loading Environment from MMC... Boot From Emmc(id:0) *** Warning - bad CRC, using default environment Wie wird die CRC ermittelt und wie behebe ich diesen Fehler. Ich möchte von uEnv.txt im EMMC das Env setzen und nicht die default Werte aus dem u-boot.bin verwenden. Wurde irgendwas überschrieben, da gab es so einen Hinweis, wegen größerer Config-Strukturen bei den neueren uboot's. Markus
@Frank, sehe gerade, dass bei Deinen default Einstellungen für u-boot die u.g. Module fehlen. Wie bekomme ich sie hinein kompiliert? ext4load- load binary file from a Ext4 filesystem ext4ls - list files in a directory (default /) ext4size- determine a file's size ext4write- create a file in the root directory Diese sind Bestandteil meines u-boots, der auf der SD Karte enthalten ist und zum Armbien-Linux gehört. Oder wie kann ich den ursprünglichen u-boot von der SD Karte extrahieren. Markus
./build.sh config Ruft die konfiguration (menuconfig) auf. die biry runterkratzen kannst mit dd...musst selbe offsets nehmen wie beim schreiben und zusätzlich count (z.b. 1M),da er sonst die ganze sd/emmc ins image schreibt ab dem Startpunkt. Ob mmcblk0 oder 1 hngt vom kernel des laufenden systems ab. Die offiziellen images haben die sd-karte als 0 und das habe ich in meinen kernels auch so gemacht (mmc-swap ggü. Mainline...siehe einer der ersten commits jedes branches in meinem repo).
Crc war noch...wenn du noch kein environment gespeichert (saveenv) hast oder von einer anderen uboot-version,ist der fehler normal und kann ignoriert werden. Es sind die ersten 4 bytes am offset des environments (ist in der boardconfig definiert...bei meinem uboot 1m bzw. 0x10000) bootenv=uEnv.txt Steht so in meiner uenv.txt (buildtin-environment) und ist der name der datei auf der bootpartition (p1) aus der das dynamische environment geladen wird (damit uboot nicht für jede Env-änderung neu geflasht werden muss)
:
Bearbeitet durch User
Danke für die Infos und Erklärungen. Werde mich mal durchwühlen und weiter Testen. Markus
@All,
@Frank,
kann mir jemand den folgenden Zusammenhang erklären.
Unter Armbien-Linux alias Ubuntu 18.04.2 LTS.
wird ein Textfile "boot.cmd" mit u-boot Instruktionen
in der Art, siehe Anhang, benötigt.
Dieses File wird dann mit dem mkimage Kommande
mkimage -C none -A arm -T script -d boot.cmd boot.scr
in ein boot.scr, anscheinend ein Pseudocode-Skript,
übersetzt.
Zudem gibt es da ein "armbianEnv.txt" File, s.u.
root@bananapir2:/boot# cat armbianEnv.txt
verbosity=1
rootdev=UUID=f3e8ab87-1e59-4e51-a6cb-ae742539564e
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
Dass auf das Root-Device verweist. Dieses File wird
in den Anweisungen aus dem "boot.cmd" in u-boot beim
Bootvorgang geladen, mit
load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}armbianEnv.txt
Der Name "armbianEnv.txt" ist willkürlich und könnte auch "uEnv.txt"
heisen wie bei anderen Linux-Konfigurationen.
Auf der anderen Seite gibt es Systeme, wie z.B. in Deinem Repo
Frank, bei denen u-boot die schon erwähnte "uEnv.txt" Datei
läd, siehe Anhang und sonst nichts.
Dieser Name ist bereits bei der Konfiguration von u-boot vor
dem Kompilieren in der .config hart festgelegt.
Was mir nun nicht klar ist, wie der Bootvorgang verläuft und wie
u-boot unterscheidet ob es die boot.scr oder die uEnv.txt
zu laden hat. Wo ist da der Schalter?
Habe ich zwei so unterschiedliche u-boot Binaries, die einen
so unterschiedlichen Lade-Mechanismus haben oder gibt es da
eine Reihenfolge in der verschiedene Files gesucht werden und
je nach Treffer der eine oder der andere Weg beschritten wird.
Ich hoffe ich konnte mich verständlich ausdrücken
und danke schon mal für eine Erklärung.
Markus
PS.: was bedeutet diese Zeile:
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
@All, @Frank, noch eine Verständnisfrage ;-) mein u-boot Ladevorgang bleibt stehen, siehe Anhang. Bedeutet dieser Output, [BLDR] jump to 0x81E00000 [BLDR] <0x81E00000>=0xEA0000B8 [BLDR] <0x81E00004>=0xE59FF014 dass entsprechend der Zeilen [PART] blksz: 512B [PART] [0x0000000000000000-0x000000000003FFFF] "PRELOADER" (512 blocks) [PART] [0x0000000000000000-0x000000000003FFFF] "MBR" (512 blocks) [PART] [0x0000000000040000-0x00000000000BFFFF] "UBOOT" (1024 blocks) und [PART] load "UBOOT" from 0x0000000000050000 (dev) to 0x81E00000 (mem) [SUCCESS] mein u-boot Binary nicht richtig geladen/gelesen werden kann, weil es ja von 0x50000 nach 0x81E00000 geladen wird und das "UBOOT" Binary in EMMC von 0x40000 bis 0xBFFFF steht. Auf der anderes Seite wird jedoch [SUCCESS] ausgegeben. Bezieht sich das nur auf den Ladevorgang aber nicht darauf, dass ein sinnvolles Programm jetzt im Speicher ab Adresse 0x81E00000 steht. Danke für die Erleuchtung! Markus
Bin immer noch am Straucheln! Den Unterschied zwischen dem uboot Ladevorgang von EMMC und SD habe ich mal angehängt, leider sehe ich noch nicht, warum es bei der EMMC nicht klappt. Eine Idee? In beiden Fällen wird bis bei EMMC [BLDR] jump to 0x81E00000 [BLDR] <0x81E00000>=0xEA0000B8 [BLDR] <0x81E00004>=0xE59FF014 bei SD [BLDR] jump to 0x81E00000 [BLDR] <0x81E00000>=0xEA0000B8 [BLDR] <0x81E00004>=0xE59FF014 ein identischer Output gezeigt, aber nur bei dem Boot von der SD-Karte Kommt die Zeile: U-Boot 2019.01-armbian (Feb 11 2019 - 08:04:39 +0100) CPU: MediaTek MT7623 E3 DRAM: 2 GiB MMC: mmc@11230000: 0, mmc@11240000: 1 ... Kann es sein, dass die weitere Ausgabe aufs HDMI Interface geht und ich einen Monitor anschließen muss? Markus
:
Bearbeitet durch User
@Markus, die Antwort könnte auf der folgenden Seite stehen: http://forum.banana-pi.org/t/cant-boot-from-emmc/3826/3 D.h. "Partition config" ändern mit emmc pconf 0x48 von der u-boot console aus. Zuvor anzeigen mit emmc ecsd
@Mutluit M. Danke für den Hinweis. Habe auch diesen Thread gefunden. Kann aber z.Z. diese Vorgehensweise nicht testen, da der alte Armbien u-boot auf der SD-Karte keine emmc Option einkompiliert hat, nur mmc. Aber ich hatte den neuen u-boot beteits mal beim BiP-R2> u-boot prompt, dann habe ich aber an der uEnv.txt gedreht und seit dem komme ich zu diesem Punkt nicht mehr. LG Markus
Markus W. schrieb: > @Mutluit M. > > Danke für den Hinweis. Habe auch diesen Thread gefunden. > Kann aber z.Z. diese Vorgehensweise nicht testen, da der > alte Armbien u-boot auf der SD-Karte keine emmc Option > einkompiliert hat, nur mmc. > > Aber ich hatte den neuen u-boot beteits mal beim BiP-R2> > u-boot prompt, dann habe ich aber an der uEnv.txt gedreht > und seit dem komme ich zu diesem Punkt nicht mehr. Schau auch hier rein, ist neueren Datums: http://forum.banana-pi.org/t/bananapi-bpi-r2-openwrt18-06-demo-image-and-source-code-release-2019-03-06/8562/ Am besten eine fertige Img für MMC mal ausprobieren. Die meisten benutzen ja u-boot. Kannst dann den inspieren/testen, dessen configs kopieren und die cfgs dann für die eigene Img modifizieren... Btw, du schreibst oft Armbien, der heisst aber Armbian :-)
:
Bearbeitet durch User
Ahja, da schreibst dass der u-boot von Armbian "emmc" nicht aktiviert hat: Vlt. ist notwendig dass du deine eigene u-boot draufkopieren musst. Ich meine, vlt. benötigen aktuelle Kernel-Versionen auch ein aktuelles u-boot. Könnte sein.
@Mutluit M., ich habe es jetzt wieder damit zu Laufen gebracht. Habe erst ab Bkock 320 512kB 0-Daten auf den EMMC geschrieben und dann erneut u-boot.bin (gleiches Binary wie schon verwendet und selber kompiliert) via dd ins EMMC geschrieben. dd if=/dev/zero of=/dev/mmcblk0 bs=1k seek=320 count=512; sync dd if=./u-boot.bin of=/dev/mmcblk0 bs=1k seek=320; sync MMC: no card present Boot from eMMC ** Unrecognized filesystem type ** fatload (uEnv.txt) failed ## Warning: Input data exceeds 1048576 bytes - truncated ## Info: input data size = 1048578 = 0x100002 bootargs=board=bpi-r2 console=earlyprintk console=tty1 fbcon=map:0 console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwai7 ** Unrecognized filesystem type ** Wrong Image Format for bootm command ERROR: can't get kernel image! BPI-R2> Jetzt muss ich das U-Boot Environment entsprechend einrichten. Markus Übrigens zeigt er auch bei der neuen U-Boot Version: BPI-R2> emmc ecsd Unknown command 'emmc' - try 'help' BPI-R2> version U-Boot 2019.01- (Jun 03 2019 - 09:23:51 +0200) arm-suse-linux-gnueabi-gcc (SUSE Linux) 7.4.1 20190424 [gcc-7-branch revision 270538] GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.32
:
Bearbeitet durch User
Das Problem war und ist immer noch, dass das Laden von uEnv.txt fehlschlägt, fatload (uEnv.txt) failed weil die eMMC eine ext4 Partition beinhaltet. Eventuell muss ich zwei Partitionen vorsehen. Eine kleine fat für dtb und kernel und rd und eine große mit ext4 für das FS und den Rest. Markus
Alternative zum o.g. "emmc": mmc partconf 0 1 1 0 Quelle: https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:uboot#change_partition-configuration_of_emmc
Markus W. schrieb: > Das Problem war und ist immer noch, dass > das Laden von uEnv.txt fehlschlägt, > > fatload (uEnv.txt) failed > > weil die eMMC eine ext4 Partition beinhaltet. > Eventuell muss ich zwei Partitionen vorsehen. > Eine kleine fat für dtb und kernel und rd > und eine große mit ext4 für das FS und den Rest. Ich glaube du mussst da noch ein Paar Params angeben. Ich habe bei meinem R1 z.B.: fatload mmc 0 0x49000000 ... D.h. "mmc" und die "0" dahinter musst du evtl. richtig setzen. Vlt. "emmc" und/oder anderen Wert statt 0 Btw, uEnv.txt sollst du eigentlich nicht selber laden, sondern u-boot selbst tut das doch, IMHO. Korrektur: doch, geht, kannst du auch selber laden. Musst aber mit "source 0x..." dann entsprechend ausführen. D.h. du kannst dafür auch anderen Dateinamen benutzen. Da sind idR nur setenv-Sachen drin...
:
Bearbeitet durch User
Mein uboot läd die uenv.txt im ordner bananapi/bpi-r2/linux auf der fat-partition #1 (p1). Wenn deine Partitionen anders sind musst du das im environment anpassen... Ich habe mich da am uboot der offiziellen images gehalten
Hallo Frank, Mutluit M., danke für den Input. Ich möchte die uEnv.txt bzw. uenv.txt kleiner machen. Frank Du hast ja da mehrere Optionen für mehrere Bootwege und Kernelversionen vorgesehen. Die Fülle ist am Anfang etwas unübersichtlich, wenn man damit noch nicht so vertraut ist. Die genannte Fehlermeldung tritt sofort ein, weil der uboot mit seinem fatload bei meiner ext4 Partition kein Erfolg hat ein uenv.txt zu finden. Ich werde weiter kämpfen - Schritt für Schritt. So ist es halb bei solchen SBC's. Da muss man einen Langen Atem aufbringen. Markus
Wenn du den bootcmd rausnimmst hast das reine builtin-env. Aktuell läd es die uenv.txr aus dem ordner und zeigt das menü an. ist ja auch einiges drin für dto (kernel+dtb separat + dtolist) Je nachdem was du brauchst wirfst den rest raus...kannst ja damit hochbooten und nacheinander die variablen leer machen bis es nicht mehr funktioniert...oder startest mit einer leeren uenv.txt und nimmst Stück für stück die vars rein. Da ich mehrere kernel kurz nacheinander starte um diese z.b. vergleichen zu können habe ich das env halt für diese zwecke angepasst Ich habe versucht es in möglichst generische "funktionen" zu packen...meine vorlage war da wesentlich schwerer zu lesen zumal es im code verankert war als const
:
Bearbeitet durch User
Markus, falls du die mmc-utils (binary "mmc") noch nicht hast, dann solltest du es installieren:
1 | Doc/Intro: |
2 | https://www.kernel.org/doc/Documentation/mmc/mmc-tools.txt |
3 | |
4 | Some Usage Examples (by Frank W.): |
5 | https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:storage |
6 | |
7 | Source: |
8 | https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git/ |
9 | |
10 | Get, Build, Help: |
11 | git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git |
12 | cd mmc-utils |
13 | make |
14 | make install |
15 | mmc help |
:
Bearbeitet durch User
Wenn uboot startet kann man es auch darüber machen..."mmc partconf" stand weiter oben glaube schon... Die mmc-binary wäre auch auf meinem github-repo im 4.14-main branch unter utils https://github.com/frank-w/BPI-R2-4.14/blob/4.14-main/utils/mmc/mmc
:
Bearbeitet durch User
@Frank und Mutluit danke für die Infos. Habe meinen eigenen Thread ganz vergessen. Ist wie mit den verbuddelten Haselnüssen bei den Eichkatzerl. War jetzt eine Weile mit anderen Spielsachen abgelenkt. Bin jetzt aber wieder etwas weiter gekommen und am Testen und Spielen mit dem BPi-R2. Markus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.