Linux Kernel 5.1.1. auf dem BPi-R2

[Markus W. (dl8mby)]

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

[$$$ (Gast)]

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.

[$$$ (Gast)]

P.S.: Die alte initrd mit dem neuen Kernel verwenden zu wollen,
ist auch mutig ... aeeh ne, eher doof.

[Mutluit M. (mutluit)]

@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

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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  :-)

[Niklas G. (erlkoenig)]

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:

arm-linux-gnueabihf-gdb vmlinux
> 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?

[Mutluit M. (mutluit)]

@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.

[Jim M. (turboj)]

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.

[Mutluit M. (mutluit)]

@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?  :-)

[Markus W. (dl8mby)]

@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)

[Mutluit M. (mutluit)]

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)

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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.

[Mutluit M. (mutluit)]

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 ...)

[Markus W. (dl8mby)]

@ 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

[Mutluit M. (mutluit)]

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.

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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 :-)

[Markus W. (dl8mby)]

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

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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.

[Mutluit M. (mutluit)]

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!

:-)

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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.

[Mutluit M. (mutluit)]

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/

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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).

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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!

[Mutluit M. (mutluit)]

Ich hab's bei mir jetzt so gemacht:

  make -j3 LOADADDR=0x40008000 uImage dtbs modules INSTALL_MOD_PATH=$targetdir
  if [ $? -eq 0 ] ; then
    echo "TODO: call do_install_as_root"
  fi

und das folgende muss als root ausgeführt werden
(entw. in einem anderen script, oder das haupt-script editieren und als 
root aufrufen...):

  make modules_install INSTALL_MOD_PATH=$targetdir

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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:

  make -j3 LOADADDR=0x40008000 uImage dtbs modules INSTALL_MOD_PATH=$targetdir

in

  make -j3 LOADADDR=0x40008000 uImage dtbs modules

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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:

TOOLCHAIN="/dir/of/my/crosscompiler"
export PATH="$TOOLCHAIN/bin:$PATH"
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-

# optional:
export CFLAGS="-DNDEBUG -g0 -O3 -pipe -I $TOOLCHAIN/arm-linux-gnueabihf/include"
export CXXFLAGS=$CFLAGS
export KBUILD_CFLAGS=$CFLAGS
export KBUILD_CXXFLAGS=$CXXFLAGS   
export KBUILD_CPPFLAGS=$CXXFLAGS

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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?

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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.

[Mutluit M. (mutluit)]

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:

# cat armbianEnv.txt
verbosity=1
logo=disabled
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
rootdev=UUID=bfbeddf1-eeb9-4314-b555-e14a7b5223ca
rootfstype=ext4
# MY
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.

[Markus W. (dl8mby)]

@ 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

[Mutluit M. (mutluit)]

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

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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

[Mutluit M. (mutluit)]

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

[Markus W. (dl8mby)]

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?

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

Wie schnell ist denn diese Kombination NVMe/M.2-SSD über USB3.1 am 
BPI-R2?
Oder hat der R2 Native M.2-Anschluss?

[Markus W. (dl8mby)]

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.

[Mutluit M. (mutluit)]

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

[Markus W. (dl8mby)]

@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

[Frank-w (Gast)]

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

[Frank-w (Gast)]

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-*)

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

@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

[Frank-w (Gast)]

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)

[Markus W. (dl8mby)]

@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

[Frank-w (Gast)]

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.

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

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.

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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.

[Frank W. (frank-w)]

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.

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

Die treiber aus dem linux-kernel müssen halt auf uboot portiert 
werden,was angesichts der unterschiedlichen frameworks nicht trivial ist

[Markus W. (dl8mby)]

Was meinst Du damit!

"unterschiedlichen frameworks"  => bild tools od. build environment ???

Markus

[Markus W. (dl8mby)]

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."

[Frank W. (frank-w)]

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...

[Markus W. (dl8mby)]

Kompiliert aber den LK 5.2-RC2 fehlerfrei! ?

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

Hast du die zeile aus dem build-script angepasst auf deinen 
crosscompiler ohne "gcc"?

[Markus W. (dl8mby)]

Ja, habe ich!

[Markus W. (dl8mby)]

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

[Markus W. (dl8mby)]

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

[frank-w (Gast)]

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

[Markus W. (dl8mby)]

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

[Markus W. (dl8mby)]

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

[frank-w (Gast)]

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

[Markus W. (dl8mby)]

@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

[Frank W. (frank-w)]

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)

[Markus W. (dl8mby)]

@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.

[frank-w (Gast)]

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.

[Markus W. (dl8mby)]

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.

[frank-w (Gast)]

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

[Markus W. (dl8mby)]

@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
...

[frank-w (Gast)]

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)

[Markus W. (dl8mby)]

@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

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

@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)

[Frank W. (frank-w)]

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)

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

@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.

[Markus W. (dl8mby)]

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

[Markus W. (dl8mby)]

@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

[Frank W. (frank-w)]

./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).

[Frank W. (frank-w)]

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)

[Markus W. (dl8mby)]

Danke für die Infos und Erklärungen.

Werde mich mal durchwühlen und weiter Testen.

Markus

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

@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

[Markus W. (dl8mby)]

@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

[Mutluit M. (mutluit)]

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 :-)

[Mutluit M. (mutluit)]

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.

[Markus W. (dl8mby)]

@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

[Markus W. (dl8mby)]

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

[Mutluit M. (mutluit)]

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

[Mutluit M. (mutluit)]

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...

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

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

[Frank W. (frank-w)]

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

[Mutluit M. (mutluit)]

Markus, falls du die mmc-utils (binary "mmc") noch nicht hast, dann 
solltest du es installieren:

Doc/Intro:
  https://www.kernel.org/doc/Documentation/mmc/mmc-tools.txt

Some Usage Examples (by Frank W.):
  https://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:storage

Source:
  https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git/

Get, Build, Help:
  git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
  cd mmc-utils
  make
  make install
  mmc help

[Frank W. (frank-w)]

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

[Markus W. (dl8mby)]

@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