I’m using Simics 6.0.83 (Public Release Preview) with target defined based on qsp-client-core.simics and trying to boot coreboot binary as legacy BIOS.
Configuration I’m trying:
# In order to run this, the QSP-x86 (2096), QSP-CPU (8112) and
# QSP-Clear-Linux (4094) packages should be installed.
decl {
! Script that runs the Quick Start Platform (QSP) with a client processor core.
params from "%simics%/targets/qsp-x86/qsp-clear-linux.simics"
default cpu_comp_class = "x86-coffee-lake"
default num_cores = 4
default enable_efi = FALSE
default bios_image = "/home/debian/dasharo/coreboot/build/coreboot.rom"
}
run-command-file "%simics%/targets/qsp-x86/qsp-clear-linux.simics"
When trying to run-command-file
from simics CLI I’m getting:
[board.mb.cpu0.core[0][0] unimpl] Warning: Cache flush without writeback (will not warn again for this CPU).
[board.mb.cpu0.core[0][0] info] CAR segment [0xfef00000: 0xfef40000] added to board.mb.cpu0.mem[0][0]
[board.mb.cpu0.core[0][0] info] 0xc91: Writing to unknown MSR. Signaling GP fault.
[board.mb.cpu0.core[0][0] info] Exception 13 while calling the double fault handler. Triple fault.
Breaking on triple fault. Break on triple fault is controlled by the break_on_triple_fault attribute.
How I can try coreboot in Simics?
3
Answers
Sounds like you need to debug why CoreBoot is not working on the model. Suggest turning on time stamps for the logs (log-setup -time-stamp) to see if the MSR is related to the triple fault. Also try trace-exception around the time of the issue to see which exceptions are involved. If you have built the binary yourself, applying the debugger to it should be straightforward.
About logging: How do I get time stamps on Simics log messages?
Note that CoreBoot might need to support the processor core variant used. The MSR indicated, as an example, is not available on "coffee lake". But it could just be CoreBoot probing available features.
If you want a small bootloader to play with, check out the open-source SlimBootLoader, at https://slimbootloader.github.io/supported-hardware/qsp.html
I am curious hence cloned, built and booted coreboot with coreinfo as payload based on https://doc.coreboot.org/tutorial/part1.html
Maybe you can check out my defconfig as below
I have no idea why Coreboot touches 0xc91 (which is part of Intel Resource Director Technology (Intel RDT) and obviously has different purpose unrelated to cache-as-ram). However, try this:
found no mapping on 0xc91
since Simics has model development tooling – create simple device model that implements missing registers
map such device to MSR’s space using:
Alternatively, you can setup default target for MSR space – in such case, all missing accesses (both reads and writes) would hit it:
First line instantiates model of "set-memory" class which is simple device that always returns its value (in this example, value is set to zero) and ignores writes.
Second line sets default target of MSR’s address space such that all missing accesses goes to
always_zeroes
device.Please note, the latter option would not ensure cache-as-ram logic as on real hardware, but it will help you to pass further. Either way, functional processor model in Simics does not implement caches as in hardware.