La dernière fois (Préparer l'environnement de développement RISC-V avec buildroot et crosstool-ng), le noyau a été démarré avec qemu, donc cette fois il fonctionne sur le navigateur Web. Essayez de le démarrer avec TinyEMU (https://bellard.org/tinyemu/), qui est un émulateur RISC-V.

https://sophisticated-overjoyed-treatment.glitch.me/run.html --Construction du noyau TinyEMU et Linux (panique immédiatement car il n'y a pas de rootfs)
dmesg: https://gist.github.com/okuoku/23c2fbd2400d21949fbb5e80c686149d#file-dmesg-txt

Vu de la panique du noyau parent.

tl;dr

Cette fois, je n'ai pas du tout utilisé la bibliothèque d'E / S standard TinyEMU, mais j'ai essayé de configurer et de démarrer la machine virtuelle du côté du langage C d'Emscripten.

** Le chargeur de démarrage doit être celui fourni avec TinyEMU **. Le chargeur connecté a été modifié et la console ne sort pas avec un chargeur normal.
La construction elle-même se construit simplement avec Emscripten 2.0.2 ʻemcc` et fonctionne avec la sortie HTML standard d'Emscripten.

Construire TinyEMU

La construction elle-même n'est pas particulièrement difficile, et si vous compilez et sortez * .c correctement, vous pouvez obtenir quelque chose qui fonctionne.

https://github.com/okuoku/patched-tinyemu-proto/blob/302211483e374b61dd686e1662b59a33eb5fc501/runbuild.bat

emcc jsemu.c softfp.c virtio.c fs.c fs_net.c fs_wget.c fs_utils.c simplefb.c pci.c ^
json.c block_net.c iomem.c cutils.c aes.c sha256.c riscv_cpu.c riscv_machine.c machine.c ^
--llvm-opts 2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -MMD -fno-strict-aliasing ^
-DCONFIG_FS_NET -O3 --memory-init-file 0 --closure 0 -s NO_EXIT_RUNTIME=1 ^
-s "EXPORTED_FUNCTIONS=['_console_queue_char','_vm_start','_fs_import_file','_display_key_event','_display_mouse_event','_display_wheel_event','_net_write_packet','_net_set_carrier','_main']" ^
-s "EXTRA_EXPORTED_RUNTIME_METHODS=[\"ccall\", \"cwrap\"]" ^
--js-library js/lib.js  -s WASM=1 -s TOTAL_MEMORY=67108864 -s ALLOW_MEMORY_GROWTH=1  ^
-DMAX_XLEN=32 -DCONFIG_RISCV_MAX_XLEN=32 -s ASSERTIONS=1 --emrun -g4 ^
--source-map-base http://localhost:6931/ --preload-file kernel --preload-file bbl32.bin emmain.c -o run.html

Routine de configuration initiale (dite «main»)

Dans TinyEMU normal, les paramètres de VM sont effectués du côté JavaScript, mais c'était un peu gênant de s'unifier avec la version native, j'ai donc décidé de préparer une fonction main.

https://github.com/okuoku/patched-tinyemu-proto/blob/302211483e374b61dd686e1662b59a33eb5fc501/emmain.c --Créé ʻemmain.c`

Le chargeur de démarrage bbl32.bin et le noyau du noyau Linux sont une fois intégrés dans l'application --preload-file` d'Emscripten et lus par le fichier de langage C I / O.

Vous pouvez utiliser le noyau construit la dernière fois (https://qiita.com/okuoku/items/3133c75d26c57394fd1a) tel quel, mais le chargeur de démarrage bbl32.bin est livré avec TinyEMU (https://bellard.org/tinyemu). Vous devez utiliser celui de /diskimage-linux-riscv-2018-09-23.tar.gz).

Implémentation HTIF spécifique à TinyEMU (?)

TinyEMU n'émule pas les dispositifs dits UART, mais implémente HTIF (Host-Target IF), qui a été implémenté par Spike (émulateur officiel RISC-V).

Cependant, contrairement à d'autres implémentations telles que qemu, l'implémentation HTIF de TinyEMU a une adresse fixe et le chargeur de démarrage est patché pour transmettre l'adresse.

https://github.com/okuoku/patched-tinyemu-proto/blob/302211483e374b61dd686e1662b59a33eb5fc501/riscv_machine.c#L69 --Dans TinyEMU, le registre HTIF est placé à l'adresse physique 0x40008000.

#define HTIF_BASE_ADDR 0x40008000

https://gist.github.com/okuoku/23c2fbd2400d21949fbb5e80c686149d#file-riscv-pk-diff-L14-L33
Le BBL fourni avec TinyEMU corrige directement les symboles utilisés (correctifs fournis avec TinyEMU).

diff --git a/bbl/bbl.lds b/bbl/bbl.lds
index 26f5816..615c3dc 100644
--- a/bbl/bbl.lds
+++ b/bbl/bbl.lds
@@ -43,15 +43,10 @@ SECTIONS
   _etext = .;
 
   /*--------------------------------------------------------------------*/
-  /* HTIF, isolated onto separate page                                  */
+  /* HTIF I/Os                                                          */
   /*--------------------------------------------------------------------*/
-  . = ALIGN(0x1000);
-  .htif :
-  {
-    PROVIDE( __htif_base = .);
-    *(.htif)
-  }
-  . = ALIGN(0x1000);
+  tohost = 0x40008000;
+  fromhost = 0x40008008;

Un patch à ce script de l'éditeur de liens corrige les adresses de tohost et fromhost.

https://github.com/riscv/riscv-pk/blob/ac2c910b18c3e36cfd85080472e78ad2fe484325/machine/htif.c#L11-L12 --Déclaration de tohost`` fromhost dans le chargeur de démarrage

volatile uint64_t tohost __attribute__((section(".htif")));
volatile uint64_t fromhost __attribute__((section(".htif")));

À l'origine, ces adresses sont acquises lors du chargement de l'émulateur.

https://github.com/qemu/qemu/blob/c47edb8dda0660180f86df4defae2a1f60e345db/hw/riscv/riscv_htif.c#L45-L63 --Code de patch utilisé dans le modèle de machine Spike de qemu

En premier lieu, HTIF lui-même est une ancienne spécification, donc cela n'a peut-être pas d'importance maintenant, mais je veux aussi un protocole plus sérieux.

Utilisez HTIF à 32 bits

Étant donné que HTIF est une interface large 64 bits, il ne peut pas être utilisé avec une architecture 32 bits. (Si l'écriture est en conflit avec deux processeurs ou plus, elle ne peut pas être traitée en toute sécurité)

TinyEMU ne prend pas en charge les multi-processeurs, donc je ne semble pas me soucier de cette zone. ** Déclarez le registre avec une largeur de 32 bits et activez-le lorsque le mot supérieur est écrit ** 32 bits / 64 bits Les deux sont pris en charge.

TinyEmu: https://github.com/okuoku/patched-tinyemu-proto/blob/302211483e374b61dd686e1662b59a33eb5fc501/riscv_machine.c#L163-L166
qemu: https://github.com/qemu/qemu/blob/c47edb8dda0660180f86df4defae2a1f60e345db/hw/riscv/riscv_htif.c#L210-L214

... qemu prend en charge les multi-processeurs, donc je ne pense pas que la même politique fonctionnera. ..

Kanso

J'étais prêt à ce que l'environnement RISC-V 32 bits ait été préparé trop récemment et qu'il soit diversement derrière 64 bits, mais c'est un peu que le débogage pur I / F comme HTIF ne prend pas en charge le 32 bits. C'était inattendu.

TODO: -s SINGLE_FILE = 1 doit être défini pour la distribution avec npm, et le noyau et le chargeur de démarrage doivent être fournis en externe.

Notes sur la construction de TinyEMU et le démarrage du noyau Linux sur Emscripten

Construire TinyEMU

Routine de configuration initiale (dite «main»)

Implémentation HTIF spécifique à TinyEMU (?)

Utilisez HTIF à 32 bits

Kanso