mikrocontroller.net

Forum: PC Hard- und Software Linux Kernel 5.1.1. auf dem BPi-R2


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: $$$ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: $$$ (Gast)
Datum:

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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus, hast du auch die Kernel-Modules generiert und auf dem Target 
ins /lib/modules/ kopiert?

targetdir=/mnt/rootfs
...
make modules         INSTALL_MOD_PATH=$targetdir
make modules_install INSTALL_MOD_PATH=$targetdir

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich kompiliere den Kernel bis jetzt ohne initrd/initramfs.
Es erzeugt uImage und die dazugehörigen Module.
Die Module muss man manuell auf dem Target unter /lib/modules ablegen,
uImage kannst du auch auf einem TFTP-Server ablegen, wovon u-boot es 
dann lädt --> in boot.cmd/.scr entsprechend angeben.
Kann mein script für TFTP-boot posten falls du brauchst.

Nachtrag: ahso, fällt mir jetzt wieder ein: man macht ja 
initrd/initramfs haupts. um die Module darin zu verpacken. Um ehrlich zu 
sein, das hab ich  noch nicht gemacht, wollte aber demnächst auch mal 
gemacht haben  :-)

: Bearbeitet durch User
Autor: Niklas G. (erlkoenig) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Markus, dumme Frage: benutzt du auch eine ARM-Toolchain, d.h. ein 
Crosscompiler, zum kompilieren, oder kompilierst du vlt. mit dem 
x86-Compiler auf dem PC?  :-)

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@All
Danke für die Anregungen und Einwände.

Ich kompiliere mit

make clean
make -j4 ARCH=arm CROSS_COMPILE=arm-suse-linux-gnueabi- zImage dtbs 
LOADADDR=0x82000000

(das ist eine minimal Konfiguration)

Dann boote ich den BPi-R2 mit seinem OS
root@bananapir2:/boot# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"

Kopiere die u.g. Files aufs Target
cp arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dtb <TARGET>/boot/dtb/
cp arch/arm/boot/zImage <TARGET>/boot/zImageX mit [X:1...9]


Mache einen reboot und drücke die Tastatur um ins Uboot zu kommen.

Dort setze ich mit env edit die beiden ENV-Vars:

auf
mmcfdtfile=boot/dtb/mt7623n-bananapi-bpi-r2.dtb
und
mmckernfile=boot/zImageX

Mit diesen temporären Settings boote ich dann.

Markus


Nachtrag zum GCC:

>arm-suse-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-suse-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/arm-suse-linux-gnueabi/7/lto-wrapper
Target: arm-suse-linux-gnueabi
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 
--enable-languages=c,c++ --enable-checking=release --disable-werror 
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp 
--disable-libvtv --disable-libmpx --disable-libcc1 --disable-plugin 
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' 
--with-slibdir=/lib64 --with-system-zlib 
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --with-gcc-major-version-only 
--enable-linker-build-id --enable-linux-futex 
--enable-gnu-indirect-function --program-suffix=-7 
--program-prefix=arm-suse-linux-gnueabi- --target=arm-suse-linux-gnueabi 
--disable-nls --with-sysroot=/usr/arm-suse-linux-gnueabi 
--with-build-sysroot=/usr/arm-suse-linux-gnueabi 
--with-build-time-tools=/usr/arm-suse-linux-gnueabi/bin 
--with-arch=armv6zk --with-tune=arm1176jzf-s --with-float=hard 
--with-abi=aapcs-linux --with-fpu=vfp --disable-sjlj-exceptions 
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 7.4.1 20190424 [gcc-7-branch revision 270538] (SUSE Linux)

: Bearbeitet durch User
Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich kenne die Details von R2 nicht, aber bist du dir wirklich 
sicher mit diesen: --with-arch=armv6zk --with-tune=arm1176jzf 
--with-abi=aapcs-linux ?

Ich benutze für mein R1 und M1 folgendes:

export PATH="/path/to/my/toolchain/bin:$PATH"
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
...

Ich hatte mir meine toolchain vor einiger Zeit selber kompiliert:

$ TOOLCHAIN/bin/arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=TOOLCHAIN/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/...../bin/../libexec/gcc/arm-linux-gnueabihf/9.0.1/ 
lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-source/configure 
--prefix=/sw/src/cross/INSTALL_DIR --target=arm-linux-gnueabihf 
--disable-werror --enable-languages=c,c++ --enable-interwork 
--disable-bootstrap --disable-multilib --disable-nls --disable-doc 
--without-selinux --disable-debug --disable-valgrind-tests 
--disable-documentation --disable-gtk-doc-pdf --disable-gtk-doc 
--disable-manpages --disable-gtk-doc-html --disable-tests 
--disable-libmudflap --disable-libgomp --disable-libssp 
--disable-libstdcxx-pch --without-gd --disable-profile 
--disable-libsanitizer --without-libsanitizer --enable-lto 
--enable-long-long --enable-checking=release --enable-threads=posix 
--with-arch-directory=arm --enable-multiarch --with-arch=armv7-a+mp 
--with-float-abi=hard --with-fpu=neon-vfpv4 --with-float=hard 
--with-tune=cortex-a7 --disable-sjlj-exceptions CFLAGS=' 
-funsafe-math-optimizations -funroll-all-loops -funroll-loops -g0 -O3 
-pipe -DNDEBUG' CXXFLAGS=' -funsafe-math-optimizations 
-funroll-all-loops -funroll-loops -g0 -O3 -pipe -DNDEBUG'
Thread model: posix
gcc version 9.0.1 20190326 (experimental) [trunk revision 269955] (GCC)


(pfade editiert)

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kompilier doch mal mit dem Crosscompiler ein test-program wit 
hello-world und lass es dann auf dem Board laufen um zu sehen ob der 
Compiler auch richtigen Code für den R2 generiert.


Hier zur Info bzw. zum Vergleich noch die cpuinfo des R1:

# cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 45.47
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 4

processor       : 1
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 45.47
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 4

Hardware        : Allwinner sun7i (A20) Family
Revision        : 0000
Serial          : 16516608070121f8


Nachtrag:
Ahso, jetz sehe ich es: die CPU des R2 stammt von Mediatek, nicht von 
Allwinner. Aber ob das wirklich ein Unterscheid macht für das 
beobachtete Problem, muss man noch weiter analysieren.

: Bearbeitet durch User
Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bzgl. des config-bpir2 :
Nimm am besten die config einer funktionierenden Image als Grundlage für 
deine Kernelcompilierung. D.h. schau ob du die config von dem 
alten/funktionierenden Kernel auftreiben kannst: s. /boot und es gibt 
auch eine Möglichkeit die config aus der Image herauszuextrahieren (den 
Befehl dazu müsste ich suchen).
Und: beim Armbian liegt der config unter /boot abgelegt wenn ich mich 
nicht irre.

Nachtrag: nicht aus Image herauslesen, sondern aus /proc:

Kernel config (falls im kernel eingebettet):
# zcat -Sn /proc/config.gz

(oder zless ...)

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> @Mutluit M.
>
> Du meinst also, wenn ich make menuconfig
> aufrufe und dann die alte .config einer anderen
> Kernelversion lade (z.B. Ubuntu 18.04.2 LTS, der
> gerade bei mir läuft, uname -r ==> 4.19.20-mt7623)
> werden mir die fehlenden Konfigurationen des neuen
> Kernels eingebaut, weil in den Skripten enthalten.
>
> Wäre schön, wen dem so wäre - Probiere ich mal gleich
> aus.

Ja, müsste so sein.
Aber: wenn du make menuconfig überhaupt nicht aufrufst, sondern 
stattdessen die andere config nach .config kopierst, und dann den 
make-lauf startest, dann fragt er dich im terminal nach den neuen Sachen 
einzeln ab (ob du sie aktivieren willst usw.).
Im Falle von menuconfig bekommt man die neuen Sachen nicht mit, sie 
werden mit Defaults belegt.

Btw, ich kompiliere gerade auch den neuesten git-Stand (5.1.1 wie bei 
dir).

Nachtrag: auf kernel.org ist schon 5.1.2 raus... :-)
Keine Ahnung wieso der git-Stand mir 5.1.1 anzeigt, obwohl ich eben ein 
git pull gemacht habe, da hat er auch vieles aktualisert...
Ich komme mit den branch-Befehlen beim git noch nicht ganz klar. Im 
Vergleich dazu war svn so einfach :-)

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir hat's geklappt, aber es zeigt 5.1.0 statt 5.1.1 an:

# uname -a
Linux r1-3 5.1.0-my15 #2 SMP Thu May 16 15:23:59 CEST 2019 armv7l 
GNU/Linux


Jetzt muss ich noch klären wieso in meiner git-kopie die Version 5.1.2 
eigentlich nicht erscheint.

: Bearbeitet durch User
Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

:-)

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Jetzt fängt die Arbeit erst an!
>
> Ohne diverser Patches habe ich nur 1 LAN dev
> verfügbar eth0 und daraus abgeleitete br0.
> eth1-eth4 fehlen, sind aber beim Original
> Ubuntu 18.04.2 LTS vorhanden.
> SATA liegt mir auch am Herzen. WLAN und BT
> kann ich verschmerzen, wenn es icht gehen
> sollte. Der R2 soll hinter die FB als FW und
> als NAS für die private Cloud im Einsatz sein.
>
> Na ja wird wohl noch etwas Zeit in Anspruch nehmen,
> bis alles funktioniert.
>
> Immerhin tut sich was in der Community zum BPi-R2.
>
> @Mutluit M.
> Viel Erfolg bei Deinen Versuchen mit Deinem BPi.

Danke. Der Einsatzgebiet bei mir ist ähnlich wie bei dir.
Nach SATA und SATA-Portmultiplier wollte ich mir die integrierte Switch 
des R1 vornehmen, und dann WLAN und BT.

Der R1 wurde in den vergangenen Jahren mMn zu Unrecht als schlecht 
beurteilt. Ich finde den eigentlich sehr gut gemacht.
Jedoch hätte ich eine Quadcore CPU besser befunden, aber das ist ja 
historisch so gekommen; Quadcore gab es zu der Zeit noch nicht (bzw. 
DualCore war damals ausreichend).
Zum Lernen und Experimentieren IMO gut geeignet, auch für 
Netzwerk-Sachen.

Naja, egal, ich werde versuchen das Maximum aus dem Gerät rauszuholen; 
hab hier mehrere von denen, gebraucht günstig erworben über ebay.

: Bearbeitet durch User
Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Markus,
ich glaube in unseren beiden Fällen wäre es wohl besser, wenn man
für den eigenen kernel-build den sunxi-fork (mainline) der kernel-repo 
benutzt.
Denn die sunxi-Leute bringen die für die Banana-Pi-Boards spezifischen
Sachen eher/früher in den kernel rein als der main kernel (torvalds bzw. 
stable):

git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git

Mehr Info:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> @Mutluit M.,
>
> danke für den Hinweis mit dem sunxi-fork.

Der Vollständigkeit halber hier noch dieser Link:
https://git.kernel.org/pub/scm/linux/kernel/git/
Es listet alle kernel-forks auf, die direkt bei kernel.org gehostet 
werden.
Es sind haupts. High-Kaliber-Developer am Linux-Projekt und einige 
Firmen.

> Werde Deinen Vorschlag bei mir Testen. Hängt davon ab ob
> ich in der Lage sein werde den Kernel zu bauen.
> Verschiedene Quellen bringen manchmal unterschiedliche
> Anforderungen an die Build-Tools mit.

Ja, das kann durchaus zutreffen. Ich habe aus der o.g. Liste bis jetzt 
nur die 3 forks "torvalds", "stable" und "sunxi" getestet. Bei denen hat 
meine normale Std-Toolchain ausgereicht.


Hier noch einige allgemeine Infos für Leute die sich erstmalig dafür 
interessieren:

Die o.g. fork-trees sind je ca. 2.5GB gross, brauch man also eine 
einigermassen schnelle Internet-Leitung um es mit "git clone" zu klonen.
Man kann das aber mit einigen Switches (--depth 1) verkleinern wenn man 
nur eine bestimmte Version haben will, s. dazu Beispiel hier: 
https://unix.stackexchange.com/questions/46077/where-to-download-linux-kernel-source-code-of-a-specific-version/46079

Dann nach dem klonen:

- Mit "git tag" kann man dann alle Versionen zurück bis v2.6.11 
auflisten (die noch älteren Versionen scheinen auf archiv-server 
ausgelagert worden zu sein, u.a. auf 
https://mirrors.edge.kernel.org/pub/linux/kernel/ )
- Mit "git checkout vXXX" dann eine bestimmte Version auschecken, bzw. 
"git checkout -b eigenebranch vXXX".
- Und "git branch" bzw. "git branch --all" zeigt die branches an, inkl. 
eigene branch(es).

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Alle .ko Kernel-Module werden aber fehlerfrei erzeugt nur nicht in
> meinem Wunsch-Dir.

Gib dort mal absoluten Pfad an, also FullPath

Nachtrag:
Ich glaube du musst das auf 2 oder 3 Befehlszeilen machen, wie bei mir 
(ich mache alles in einem script):

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

Ich habe ARCH, PATH und CROSS_COMPILE etc. zuvor exportiert, so dass sie 
beim make nicht explizit angeg. werden brauchen.
Und return-code-checks habe ich auch drin, so dass die module nur dann 
generiert werden wenn compile-lauf zuvor erfolgreich war (also $? 
auswerten etc..)

Nachtrag2: hmm. müsste auch alles in nur 1 Befehlszeile, wie du gemacht 
hast, eigentlich auch klappen.


> Aber der Sonntag ist ja noch lang.

:-) Jo, viel Spass am Sonntag!

: Bearbeitet durch User
Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Mutluit M. (mutluit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.