CONFIG_VIRTIO_PCI=y +CONFIG_VIRTIO_BLK=y+
Can also be activated with the panic_on_warn boot parameter.
Let’s learn how to diagnose problems with the root filesystem not being found. TODO add a sample panic error message for each error type:
+This is the diagnosis procedure:
+does the filesystem appear on the list of filesystems? If not, then likely you are missing either:
+the driver for that hardware type, e.g. hard drive / SSD type. Here, Linux does not know how to communicate with a given hardware to get bytes from it at all. In simiulation, the most important often missing one is virtio which needs:
+CONFIG_VIRTIO_PCI=y +CONFIG_VIRTIO_BLK=y+
the driver for that filesystem type. Here, Linux can read bytes from the hardware, but cannot interpret them as a tree of files because it does not recognize the file system format. For example, to boot from SquashFS we would need:
+CONFIG_SQUASHFS=y+
your filesystem of interest appears in the list, then you just need to set the root command line parameter to point to that, e.g. root=/dev/sda
./gem5-regression --arch aarch64 -- --length quick+
./build-gem5 --arch aarch64 +./gem5-regression --arch aarch64 -- --length quick --length long
TODO skip the build by default with --skip-build since we already manage it with ./build-gem5. But we can’t do this because it is the build step that downloads the test binaries. We need to find a way to either download the binaries without building, or to pass the exact same scons build options through test/main.py.
After the first run has downloaded the test binaries for you, you can speed up the process a little bit by skipping an useless scons call:
+./gem5-regression --arch aarch64 -- --length quick --length long --skip-build+
Note however that --skip-build is required at least once per branch to download the test binaries, because the test interface is bad.
In fs.py and se.py, those are selectable with the --cpu-type option.
TODO are there any public performance correlations between those models and real cores? The information to make accurate models isn’t generally public for non-free CPUs, so either you must either rely vendor provided models or on experiments/reverse engineering.
+The information to make highly accurate models isn’t generally public for non-free CPUs, so either you must either rely vendor provided models or on experiments/reverse engineering.
+There is no simple answer for "what is the best CPU", in theory you have to understand each model and decide which one is closer your target system.
+Whenever possible, stick to:
+vendor provide ones obviously, e.g. ARM Holdings models of ARM cores, unless there is good reason not to, as they are the most likely to be accurate
+newer models instead of older models
+Both of those can be checked with git log and git blame.
Simple abstract CPU without a pipeline.
KVM CPUs are an alternative way of fast forwarding boot when they work.
Generic in-order core that does not model any specific CPU.
Implemented by Pierre-Yves Péneau from LIRMM, which is a research lab in Montpellier, France, in 2017.
O3_ARM_v7a: implemented by Ronald Dreslinski from the University of Michigan in 2012
Not sure why it has v7a in the name, since I believe the CPUs are just the microarchitectural implementation of any ISA, and the v8 hello world did run.
+The CLI option is named slightly differently as: --cpu-type O3_ARM_v7a_3.
Generic out-of-order core. "O3" Stands for "Out Of Order"!
the first build takes a while, but it is well worth it
the selection of software packages is relatively limited if compared to Debian, e.g. no Java or Python package in guest out of the box.
+the selection of software packages is relatively limited if compared to Debian.
In theory, any software can be packaged, and the Buildroot side is easy.
Maybe some day someone will use this setup to study the performance of interpreters:
+Maybe some day someone will use this setup to study the performance of interpreters.
Parent section: Interpreted languages.
+Build and install the interpreter on the target:
+./build-buildroot --config 'BR2_PACKAGE_PYTHON3=y'+
Install the interpreter with:
+Usage from guest in full system:
+./run+
and then from there get an interactive shell with:
+python3+
or run an example with:
+python3 lkmc/python/hello.py+
User mode simulation interactive usage:
+./run --userland "$(./getvar buildroot_target_dir)/usr/bin/python3"+
Non-interactive usage:
+./run --userland "$(./getvar buildroot_target_dir)/usr/bin/python3" --userland-args rootfs_overlay/lkmc/python/hello.py+
LKMC 50ac89b779363774325c81157ec8b9a6bdb50a2f gem5 390a74f59934b85d91489f8a563450d8321b602da arch64:
+./run \ + --arch aarch64 \ + --emulator gem5 \ + --userland "$(./getvar \ + --arch aarch64 buildroot_target_dir)/usr/bin/python3" \ + --userland-args rootfs_overlay/lkmc/python/hello.py \ +;+
fails with:
+fatal: syscall unused#278 (#278) unimplemented.+
which corresponds to the glorious getrandom syscall: https://github.com/torvalds/linux/blob/v4.17/include/uapi/asm-generic/unistd.h#L707
Examples:
+rootfs_overlay/lkmc/python/hello.py: hello world
+Build and install the interpreter with:
TODO: broken as of 3c3deb14dc8d6511680595dc42cb627d5781746d + 1:
+Everything is then the same as the Python interpreter setup, except that the executable name is now node!
TODO: build broken as of LKMC 3c3deb14dc8d6511680595dc42cb627d5781746d + 1:
rootfs_overlay/lkmc/nodejs/hello.js: hello world
+String
No OpenJDK package as of 2018.08: https://stackoverflow.com/questions/28874150/buildroot-with-jamvm-2-0-for-java-8/59290927#59290927 partly because their build system is shit like the rest of the project’s setup.
+Unmerged patch at: http://lists.busybox.net/pipermail/buildroot/2018-February/213282.html
+There is a JamVM package though https://en.wikipedia.org/wiki/JamVM which is something Android started before moving to Dalvik,
+Maybe some day other Android Java runtimes will also become compilable. Maybe, since Android is also shit.
+Parent section: ARM multicore.
+ARMv8 architecture reference manual db "ARMv8.1-LSE, ARMv8.1 Large System Extensions"
LDADD: userland/cpp/atomic/aarch64_ldadd.cpp, see also: atomic.cpp.
+LDADD: userland/cpp/atomic/aarch64_ldadd.cpp, see also: atomic.cpp. Kernel inspiration: https://github.com/torvalds/linux/blob/v5.4/arch/arm64/include/asm/atomic_lse.h#L56
and power consumption is key in ARM applications.
SEV is not the only thing that can wake up a WFE, it is only an explicit software way to do it. Notably, global monitor operations on memory accesses of regions marked by LDREX and STREX instructions can also wake up a WFE sleeping core. This is done to allow spinlocks opens to automatically wake up WFE sleeping cores at free time without the need for a explicit SEV.
+SEV is not the only thing that can wake up a WFE, it is only an explicit software way to do it. Notably, global monitor operations on memory accesses of regions marked by LDAXR and STLXR instructions can also wake up a WFE sleeping core. This is done to allow spinlocks opens to automatically wake up WFE sleeping cores at free time without the need for a explicit SEV.
WFE and SEV are usable from userland, and are part of a efficient spinlock implementation.
@@ -30318,7 +30520,7 @@ IN: mainThe recommended ARMv8 spinlock implementation is shown at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s03s02.html where WAIT_FOR_UPDATE is as explained in that section a macro that expands to WFE.
The recommended ARMv8 spinlock implementation is shown at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s03s02.html where WAIT_FOR_UPDATE is as explained in that section a macro that expands to WFE. TODO SEV is used explicitly in those examples via SIGNAL_UPDATE, where is the example that shows how SEV can be eliminated due to implicit monitor signals?
In QEMU 3.0.0, SEV is a NOPs, and WFE might be, but I’m not sure, see: https://github.com/qemu/qemu/blob/v3.0.0/target/arm/translate-a64.c#L1423
@@ -30372,9 +30574,31 @@ IN: mainThe best article to understand spinlocks is: https://eli.thegreenplace.net/2018/basics-of-futexes/
+Can be used to implement atomic variables, see also:
+The ARMv7 analogues are LDREX and STREX.
+In QEMU, CPU 1 starts in a halted state. This can be observed from GDB, where:
TODO: create and study a minimal examples in gem5 where the DMB instruction leads to less cycles: https://stackoverflow.com/questions/15491751/real-life-use-cases-of-barriers-dsb-dmb-isb-in-arm
Remember: Android AOSP is a huge undocumented piece of bloatware. It’s integration into this repo will likely never be super good.
+Remember: Android AOSP is a huge undocumented piece of bloatware. It’s integration into this repo will likely never be super good. See also: https://cirosantilli.com#android
Verbose setup description: https://stackoverflow.com/questions/1809774/how-to-compile-the-android-aosp-kernel-and-test-it-with-the-android-emulator/48310014#48310014
@@ -34826,6 +35050,9 @@ git push --follow-tagshttps://github.com/MichielDerhaeg/build-linux untested. Manually builds musl and BusyBox, no Buildroot. Seems to use host packaged toolchain and tested on x86_64 only. Might contain a minimized kernel config.
https://eli.thegreenplace.net and the accompanying code: https://github.com/eliben/code-for-blog
+