[geklärt] "Marvell Armada 370" in QEMU emulieren

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
Livingston
Beiträge: 1366
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

[geklärt] "Marvell Armada 370" in QEMU emulieren

Beitrag von Livingston » 28.06.2020 16:56:46

Moinmoin,

ich bin auf der Suche nach einer machine-/cpu-Kombination innerhalb von QEMU, die halbwegs mit meinem debianisierten Buffalo-NAS LS441D übereinstimmt. Das NAS hat einen "Marvell Armada 370"-Prozessor, der einen 32-bittigen armhf-Kernel verträgt, eine funktionierende devicetable habe ich auch bereits ergattert.

Für die Emulation brauche ich keinen 100%-Treffer, da ich nur eine emulierte Umgebung benötige, auf der ich ein paar Sachen kompilieren kann (Kernel-Module, u.U. aber auch einen kompletten Kernel). Auf dem Originalgerät, dauert das einfach zu lange.

Nach längerer Suche sieht es danach aus, als wären Cortex9 oder Cortex15 geeignete Kandidaten für die QEMU-Einstellungen, um darin ein Debian-armhf laufen zu lassen. Als Host für QEMU dient übrigens ein Intel i6700.

Crosscompilieren ginge natürlich auch, aber eine halbwegs nahekommende Emulation hätte schon was.

Passt das oder gibt es entsprechende Erfahrungen?
Zuletzt geändert von Livingston am 30.10.2020 15:06:05, insgesamt 1-mal geändert.

Benutzeravatar
TRex
Moderator
Beiträge: 8038
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: "Marvell Armada 370" in QEMU emulieren

Beitrag von TRex » 29.06.2020 19:42:21

Weder Ahnung noch Erfahrung, aber Interesse am weiteren Fortschritt.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!Wie man widerspricht

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: "Marvell Armada 370" in QEMU emulieren

Beitrag von hikaru » 06.07.2020 15:56:30

Ich hatte vor rund 7 Jahren ein ähnliches Anliegen um Software für mein Nokia N900 (OMAP 3430) auf meinem Desktop-PC (mäßig übertakteter i7-2700k) zu compilieren. Als emulierte Maschine hatte ich sowohl "versatile[ap]b"*, als auch "N900"** probiert. Das Ergebnis war ernüchternd. Den damaligen Chromium auf dem N900 selbst zu compilieren dauerte knapp einen Tag***. In qemu dauerte es etwa zwei Tage.
Ich habe dann auch mit dem Gedanken gespielt, mal ordentliches Cross-Compiling zu lernen, aber am Ende siegte Faulheit über Geldbeutel und ich legte mir ein Cubieboard 2 (Allwinner A20, damals mit das Schnellste was armhf für kleines Geld hergab) zu, welches Chromium in etwa 6 Stunden compilierte. Das reichte mir.

Was ich sagen will:
Mit qemu eine andere Architektur zu emulieren bringt meiner betagten Erfahrung nach keine Geschwindigkeitsvorteile. Setz dich auf den Hosenboden und lerne Cross-Compilieren! :THX:
(Oder sei faul und besorg dir eine schnelle native Compilierkiste! :oops: )


*) Ich weiß nicht mehr, welche Variante es war.
**) Galt damals wohl noch als experimentell und war schlecht dokumentiert.
***) Wenn nicht zwischendurch der Watchdog zubiss.

Benutzeravatar
Livingston
Beiträge: 1366
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

Re: "Marvell Armada 370" in QEMU emulieren

Beitrag von Livingston » 10.07.2020 13:49:00

Zwischenstandsmeldung

Leider rennt mir ein wenig die Zeit davon, aber ich komme langsam vorwärts.
Was dem Marvell Armada 370 am nächsten kommt ist wohl Cortex-A9. Da ich ich ohnehin nicht erwarte, meine Linkstation vollständig emulieren zu können, wähle ich eines der Debian-Images aus, das halbwegs passt. Dann werde ich 3 Zeitmessungen für komplette Kernel-Compile-Durchläufe durchziehen.
1. Native auf der Linkstation
2. In der noch rauszupickenden Emulation
3. Crosscompiled unter voller Ausnutzung meines i6700-Prozessors.

Ein anschließender Vergleich mit md5sum/shasum sollte Gewissheit bringen, ob und wie schnell das Gewünschte herauskommt.
Bis demnächst

1000001101000
Beiträge: 6
Registriert: 05.11.2019 02:15:27

Re: "Marvell Armada 370" in QEMU emulieren

Beitrag von 1000001101000 » 04.09.2020 04:01:29

I have a script I use for cross compiling kernels for that device, it demostrates how to do that :

https://github.com/1000001101000/Debian ... _kernel.sh

Cross compiling is much faster than compiling under qemu or alternate arm devices.


You can also create a chroot environment using qemu/debootstrap:

Code: Alles auswählen

apt-get install qemu-user-static debootstrap qemu-system-arm
mkdir armhf-buster
qemu-debootstrap --arch armhf "buster" armhf-buster http://deb.debian.org/debian/
cp /usr/bin/qemu-arm-static armhf-buster/usr/bin/
chroot armhf-buster
This allows you to emulate an armhf system and works quite well.

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: "Marvell Armada 370" in QEMU emulieren

Beitrag von Tintom » 04.09.2020 16:25:40

Meine Erfahrungen mit qemu vs. crosscompile sind zwar etwas älter, aber ich habe damals auch zuerst mit qemu angefangen um dann kurze Zeit später entnervt auf crosscompile zu wechseln. Gerade beim Kernel war das wesentlich schneller und vor allem weit weniger komplex.

Benutzeravatar
Livingston
Beiträge: 1366
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

Re: "Marvell Armada 370" in QEMU emulieren

Beitrag von Livingston » 30.10.2020 14:56:00

Am Ende habe ich es getan.
Kernel kompiliert auf: qemu-Emulation, native und mit Cross-Compiler. Das Ergebnis ist... umwerfend.

Zur Emulation noch ein paar Gedanken vorweg: Ich habe nichts gefunden, womit ich die Hardware meiner Maschine zu 100% nachbilden kann. Die angebotenen virtuellen Maschinen weichen alle in einzelnen Punkten voneinander ab. Macht aber nix, denn ich wollte ja erst mal eine ungefähre Einschätzung haben, was man mit Virtualisierung überhaupt hinbekommt. Deshalb habe ich für den Test mit qemu das Modell "virt" ausgesucht und alles stark vereinfacht. Deshalb auch nur 1 Core wie in der echten Maschine. Da hätte ich vielleicht noch was dran geschraubt, wenn ich vorher geahnt hätte, wieviel Performance das Ganze kostet.

Der qemu-Aufruf sieht so aus:

Code: Alles auswählen

qemu-system-arm -M virt -m 1024 \
		-kernel $WORKDIR/$IMG \
		-initrd $WORKDIR/$INITRD \
		-append "root=/dev/vda3" \
		-drive if=none,file="$WORKHD",format=qcow2,id=hd \
		-device virtio-blk-device,drive=hd \
		-netdev tap,id=mynet,ifname=tap0,script=no,downscript=no \
		-device virtio-net-device,mac=52:54:00:12:34:56,netdev=mynet \
		-display none -daemonize -no-reboot
In der virtuellen Kiste läuft ein sshd, das virtuelle Netzwerk ist auf dem Host mit einer Bridge eingebunden.

1. Versuch:

Code: Alles auswählen

4.19.0-12-armmp (emuliert: qemu-system-arm -M virt, Aufruf-Script s.o, Host: siehe Versuch 3)
lstone@emunase:~/linux-source-4.19$ time make all
real    1734m42,753s
user    1435m41,478s
sys     275m2,881s
Krass... wie in alten Zeiten, als ich meine ersten Kernel-Kompilier-Versuche mit einem 486-DX 40Mhz machte. Nur mit dem Unterschied, dass es früher nicht >2 Tage dauerte.

2. Versuch:
Direkt auf der Hardware (Buffalo LS441DE mit "Marvell Armada 370"-Prozessor)

Code: Alles auswählen

4.19.0-12-armmp (native: ARMv7 Processor rev 1 (v7l) @ 1.20GHz)
lstone@nase:~/linux-source-4.19$ time make all
real    1115m23,809s
user    1012m15,931s
sys     77m13,367s
Schon mal viel besser, kommt an die Compile-Zeiten der 90'er-Jahre langsam ran.

3. Versuch:

Code: Alles auswählen

4.19.0-12-armmp (crosscompiled: Intel Core i7-6700K CPU @ 4.00GHz)
lstone@grossrechner:~/linux-source-4.19$ time make -j8 ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- all
real    13m59,245s
user    102m14,466s
sys     7m39,843s
Hier habe ich natürlich alle 4 Proze mit Hyperthreading (-j8) ausgenutzt.

Ich denke das Ergebnis ist eindeutig. Es war jedenfalls sehr lehrreich.

EDIT: Die time-Angabe im 3. Versuch kommt ein wenig ins Straucheln (user 102m14,466s). Ich denke, das liegt an der der Tatsache, dass ich mit der Option -j8 kompilert habe. Die Angabe real 13m59,245s entspricht aber meiner direkten Beobachtung.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams

1000001101000
Beiträge: 6
Registriert: 05.11.2019 02:15:27

Re: [geklärt] "Marvell Armada 370" in QEMU emulieren

Beitrag von 1000001101000 » 09.11.2020 15:38:56

It all depends on what you need.

If you're compiling something modern like the current kernel, cross-compiling will be by far the fastest option.

Rather than emulate a whole "virt" system you can use "transparent" emulation to just emulate the target architecture without emulating a whole virtual kernel and virtual hardware. see:
https://wiki.debian.org/QemuUserEmulation

I've been using that option a lot lately for building disk images and for setting up compiler environments where no suitable crosscompiler is available (15-year old versions of GCC+LIBC on obsolete architectures).

For tasks where the chroot option does not work because of unsupported syscalls/hardware the full emulation you tried usually works though is slower. It can still be faster than native for slower targets and can be easier to script/automate than real hardware.

Benutzeravatar
Livingston
Beiträge: 1366
Registriert: 04.02.2007 22:52:25
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.0.0.1

Re: [geklärt] "Marvell Armada 370" in QEMU emulieren

Beitrag von Livingston » 10.11.2020 20:16:12

@1000001101000

Thanks for all tips and advices. In fact it was your NAS-project on github https://github.com/1000001101000/Debian_on_Buffalo that let me try out an approach with qemu. On the one hand I'd like to have a whole sandbox before bricking my NAS, on the other hand... you are right, it's so much easier to cross compile (at least nowadays) or use the "transparent" method.
Nevertheless, if I go about dirty tricks (e.g. changing details in initrd) it feels better to play with a more or less whole emu first.
CU on github :D
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams

Antworten