Hinweise zum Erstellen von TinyEMU und zum Booten des Linux-Kernels auf Emscripten

Beim letzten Mal (RISC-V-Entwicklungsumgebung mit Buildroot und Crosstool-ng vorbereiten) wurde der Kernel mit qemu gestartet, sodass er diesmal im Webbrowser funktioniert. Versuchen Sie es mit TinyEMU (https://bellard.org/tinyemu/), einem RISC-V-Emulator.

• https://sophisticated-overjoyed-treatment.glitch.me/run.html
• Erstellter TinyEMU- und Linux-Kernel (sofort Panik, da keine Rootfs vorhanden sind)
• dmesg: https://gist.github.com/okuoku/23c2fbd2400d21949fbb5e80c686149d#file-dmesg-txt

Von der übergeordneten Kernel-Panik aus gesehen.

tl;dr

Dieses Mal habe ich überhaupt keine TinyEMU-Standard-E / A-Bibliothek verwendet, sondern versucht, VM auf der C-Sprache von Emscripten zu konfigurieren und zu starten.

• ** Der Bootloader muss mit TinyEMU geliefert werden **. Der angeschlossene Lader wurde geändert, und die Konsole verfügt nicht über einen normalen Lader.
• Der Build selbst wird einfach mit Emscripten 2.0.2 emcc erstellt und funktioniert mit der Emscripten-Standard-HTML-Ausgabe.

Erstellen Sie TinyEMU

Der Build selbst ist nicht besonders schwierig, und wenn Sie * .c entsprechend kompilieren und ausgeben, können Sie etwas bekommen, das funktioniert.

• 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

Ersteinrichtungsroutine (sogenanntes main)

In normaler TinyEMU werden VM-Einstellungen von der JavaScript-Seite aus durchgeführt, aber die Vereinheitlichung mit der nativen Version war etwas unpraktisch. Daher habe ich beschlossen, eine Hauptfunktion vorzubereiten.

• https://github.com/okuoku/patched-tinyemu-proto/blob/302211483e374b61dd686e1662b59a33eb5fc501/emmain.c --Erstellt emmain.c

Der Bootloader bbl32.bin und der Linux-Kernel kernel sind einmal in Emscriptens --preload-file App eingebettet und werden von der C-Sprachdatei I / O gelesen.

Sie können den zuletzt erstellten "Kernel" (https://qiita.com/okuoku/items/3133c75d26c57394fd1a) so verwenden, wie er ist, aber der Bootloader "bbl32.bin" wird mit TinyEMU (https://bellard.org/tinyemu) geliefert. Sie müssen die von /diskimage-linux-riscv-2018-09-23.tar.gz) verwenden.

TinyEMU-spezifische (?) HTIF-Implementierung

TinyEMU emuliert keine sogenannten UART-Geräte, sondern implementiert HTIF (Host-Target IF), das von Spike (offizieller RISC-V-Emulator) implementiert wurde.

Im Gegensatz zu anderen Implementierungen wie qemu hat die HTIF-Implementierung von TinyEMU jedoch eine feste Adresse, und der Bootloader ist gepatcht, um die Adresse zu übermitteln.

• https://github.com/okuoku/patched-tinyemu-proto/blob/302211483e374b61dd686e1662b59a33eb5fc501/riscv_machine.c#L69
• In TinyEMU wird das HTIF-Register an der physischen Adresse "0x40008000" abgelegt.

#define HTIF_BASE_ADDR 0x40008000

• https://gist.github.com/okuoku/23c2fbd2400d21949fbb5e80c686149d#file-riscv-pk-diff-L14-L33
• Die mit TinyEMU gelieferte BBL patcht die verwendeten Symbole direkt (Patches, die mit TinyEMU geliefert werden).

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;

Ein Patch für dieses Linker-Skript korrigiert die Adressen von "tohost" und "fromhost".

• https://github.com/riscv/riscv-pk/blob/ac2c910b18c3e36cfd85080472e78ad2fe484325/machine/htif.c#L11-L12
• Erklärung von tohost`` fromhost im Bootloader

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

Ursprünglich werden diese Adressen beim Laden des Emulators erfasst.

• https://github.com/qemu/qemu/blob/c47edb8dda0660180f86df4defae2a1f60e345db/hw/riscv/riscv_htif.c#L45-L63 --Patch-Code, der im Spike-Maschinenmodell von qemu verwendet wird

Erstens ist HTIF selbst eine alte Spezifikation, daher spielt es jetzt vielleicht keine Rolle, aber ich möchte auch ein ernsthafteres Protokoll.

Verwenden Sie HTIF bei 32 Bit

Da HTIF eine 64-Bit-Schnittstelle ist, kann es nicht mit einer 32-Bit-Architektur verwendet werden. (Wenn Schreibkonflikte auf zwei oder mehr CPUs geschrieben werden, können sie nicht sicher verarbeitet werden.)

TinyEMU unterstützt keinen Multiprozessor, daher scheint mir dieser Bereich egal zu sein. ** Deklarieren Sie das Register mit einer Breite von 32 Bit und aktivieren Sie es, wenn das obere Wort geschrieben wird ** 32 Bit / 64 Bit Beide werden unterstützt.

• 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 unterstützt Multiprozessoren, daher denke ich nicht, dass dieselbe Richtlinie funktionieren wird. ..

Kanso

Ich war darauf vorbereitet, dass die RISC-V 32-Bit-Umgebung zu kürzlich vorbereitet wurde und im Vergleich zu 64-Bit viel zurückliegt, aber es ist ein bisschen so, dass ein reines Debugging-I / F wie HTIF 32-Bit nicht unterstützt. Es war unerwartet.

TODO: -s SINGLE_FILE = 1 muss für die Verteilung mit npm festgelegt werden, und der Kernel und der Bootloader müssen extern bereitgestellt werden.