J'ai téléchargé l'image Raspbian sur cette page . J'essaie de compiler un noyau qui peut être utilisé pour démarrer l'image dans qemu.
J'ai téléchargé la source du noyau Linux sur kernel.org et j'ai exécuté:
make versatile_defconfig
make menuconfig
J'ai ensuite ajouté les fonctionnalités suivantes au noyau:
- Prise en charge PCI (CONFIG_PCI)
- Prise en charge des périphériques SCSI (CONFIG_SCSI)
- Prise en charge des disques SCSI (CONFIG_BLK_DEV_SD)
- Prise en charge SCSI SYM53C8XX version 2 (CONFIG_SCSI_SYM53C8XX_2)
- Le système de fichiers Extended 3 (ext3) (CONFIG_EXT3_FS)
- Le système de fichiers Extended 4 (ext4) (CONFIG_EXT4_FS)
J'ai également monté l'image disque en boucle et:
- commenté
/etc/ld.so.preload
- ajusté
/etc/fstab
pour utiliser/dev/sda1
et/dev/sda2
J'ai ensuite démonté l'image et tenté de démarrer la machine avec:
qemu-system-arm \
-M versatilepb \
-m 256 \
-kernel linux-4.3/arch/arm/boot/zImage \
-hda 2015-09-24-raspbian-jessie.img \
-serial stdio \
-append "root=/dev/sda2 rootfstype=ext4 rw console=ttyAMA0"
Le noyau a pu monter le système de fichiers mais il a immédiatement rencontré des problèmes:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: init Not tainted 4.3.0 #1
Hardware name: ARM-Versatile PB
[<c001b5c0>] (unwind_backtrace) from [<c0017e18>] (show_stack+0x10/0x14)
[<c0017e18>] (show_stack) from [<c0069860>] (panic+0x84/0x1ec)
[<c0069860>] (panic) from [<c0025b98>] (do_exit+0x81c/0x850)
[<c0025b98>] (do_exit) from [<c0025c5c>] (do_group_exit+0x3c/0xb8)
[<c0025c5c>] (do_group_exit) from [<c002dfcc>] (get_signal+0x14c/0x59c)
[<c002dfcc>] (get_signal) from [<c001bf28>] (do_signal+0x84/0x3a0)
[<c001bf28>] (do_signal) from [<c0017a94>] (do_work_pending+0xb8/0xc8)
[<c0017a94>] (do_work_pending) from [<c0014f30>] (slow_work_pending+0xc/0x20)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
Au début, je me demandais si cela n'était pas lié à SELinux. J'ai essayé de démarrer le noyau avec:
selinux=0 enforcing=0
... mais cela n'a fait absolument aucune différence.
Qu'est-ce que je fais mal? Et que signifie cette erreur?
Mises à jour
J'ai également essayé ce qui suit, sans succès:
- J'ai essayé de compiler avec et sans
CONFIG_VFP
activé - J'ai ajouté
CONFIG_DEVTMPFS
etCONFIG_DEVTMPFS_MOUNT
- L' application de ce patch et permettant
CPU_V6
,CONFIG_MMC_BCM2835
, &CONFIG_MMC_BCM2835_DMA
- Utilisation de la
gcc-linaro-arm-linux-gnueabihf-raspbian
chaîne d'outils Compiler un programme C simple avec la chaîne d'outils puis passer son chemin vers le noyau via
init=
works - ce qui me fait croire qu'il existe une différence entre les formats binairesfile <sample program>
:ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 2.6.26, BuildID[sha1]=e5ec8884499c51b248df60aedddfc9acf72cdbd4, not stripped
file <file from the image>
:ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=3e92423821f3325f8cb0ec5d918a7a1c76bbd72c, stripped`
J'ai compilé ce programme C simple avec la chaîne d'outils:
<path>/arm-linux-gnueabihf-gcc --static simple.c -o simple
... et copié /root
dans l'image, en changeant le init=
paramètre de démarrage en /root/simple
. Cela me donne les éléments suivants lors du démarrage:
Starting bash...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
Il semble étouffer l' execv()
appel.
la source
cat .config | grep CONFIG_VFP
donneCONFIG_VFP=y
- semble être activé.CONFIG_VFP
et cela ne fait aucune différence.versatilepb
est un processeur ARM926, qui est plus ancien que l'ARM1176 du RPi, donc les binaires Raspbian peuvent utiliser une autre fonctionnalité qui n'est pas émulée. Sur unixmen.com/emulating-raspbian-using-qemu , est-ce-cpu arm1176
utile?Réponses:
J'ai également essayé de démarrer des images ARM avec QEMU sans succès fiable. Je suis désolé de dire que vous devrez utiliser du vrai matériel pour travailler avec un OS ARM, ou attendre patiemment que les développeurs fassent un émulateur plus fiable pour ARM.
C'est décembre 2018, et il y a toujours des problèmes avec
qemu-system-arm
.J'ai pu démarrer Raspbian Jessie sur un émulateur QEMU en utilisant un Ubuntu 18 Bionic fraîchement installé, mais il n'était pas stable pour mon travail, j'ai donc dû le laisser pour du vrai matériel. Il gèlerait fréquemment.
qemu-system-arm
ne fonctionnait pas sur mon système d'exploitation, j'ai donc utilisé Virtualbox pour installer Ubuntu Bionic et à l'intérieur de Bionic j'ai installé Raspbian avec QEMU.J'ai suivi ce tutoriel: https://azeria-labs.com/emulate-raspberry-pi-with-qemu/
Bonne chance
la source
Je sais que c'est une question un peu ancienne, mais comme il n'y a toujours pas de bonnes réponses pour tester les images Raspberry Pi avec QEMU, permettez-moi de fournir une réponse partielle.
Je voulais utiliser l' image raspi3 d'Ubuntu 16.04 avec QEMU. Je l'ai téléchargé, extrait, monté la partition de démarrage, obtenu le fichier vmlinuz et le fichier initrd, et ... qemu-system-arm -M blabla -cpu ... -kernel ... ne fonctionne pas. Écran noir.
Ensuite, l'utilisation d'un kernel-qemu-4.4.34-jessie d' ici avec l'image xenial / rootfs a conduit au même problème "init kill" que vous avez.
Mais comme j'utilise un bon noyau connu et que votre programme C simple lié statiquement fonctionne, il est probable que le problème n'apparaît que lorsque l'on utilise l'éditeur de liens dynamique. (Et l'éditeur de liens n'est pas particulièrement sensible aux noyaux, car le ld-2.24 du dernier raspbian basé sur debian9 (stretch) fonctionne bien sur un noyau basé sur 4.4 debian8 (jessie).)
Même après avoir copié les fichiers qui fonctionnent sur / avec l'image "jessie" dans l'image ubuntu xenial, je n'ai eu qu'une étrange erreur "appelant preinit: KE".
Oh, et quiconque cherche à compiler un noyau pour un Raspberry Pi, devrait consulter ce site, qui fait directement référence aux documents / howto " officiels ".
la source
Le noyau linux n'exécute plus init à la place, il exécute systemd qui est comme init mais des fonctionnalités un peu plus avancées et des capacités de multitâche supplémentaires, bien que contre la philosophie unix, systemd soit utile.
la source