(I saw one of my previous posts didn't actually answer the "where's the BIOS file used by simics?" question, so I renamed the previous one and am pulling that question out and making it standalone here.)
I can see the BIOS code for a default "targets\qsp-x86\firststeps.simics" invocation by just stepping through the debugger from the start. But if I want to see the full binary, is there a specific file somewhere I can look at?
you can check "bios" attribute on motherboard image:
simics> board.mb->bios
"%simics%/targets/qsp-x86/images/SIMICSX58IA32X64_1_0_0_bp_r.fd"
You can specify what BIOS image to use by bios_image script parameter to qsp-clear-linux.simics scripts.
Help info for the script:
$ ./simics -h targets/qsp-x86/qsp-clear-linux.simics
System:
bios_image - existing file or NIL
BIOS file.
Default value:
"%simics%/targets/qsp-x86/images/SIMICSX58IA32X64_1_0_0_bp_r.fd"
you can run with your own BIOS like this:
$ ./simics -e '$bios_image=my-bios.bin' targets/qsp-x86/qsp-clear-linux.simics
Now the BIOS is not quite handled consistently with some other things. Typically in Simics, disks and similar things are images. You can list them using list-persistent-images and resolve locations using lookup-file:
simics> list-persistent-images
┌─────────────────────┬────────────┬───────────────────────────────────────────────────────┐
│Image │Unsaved data│File(s) (read-only/read-write) │
├─────────────────────┼────────────┼───────────────────────────────────────────────────────┤
│board.disk0.hd_image │ no│%simics%/targets/qsp-x86/images/cl-b28910-v2.craff (ro)│
│board.disk1.hd_image │ no│ │
│board.mb.sb.spi_image│ yes│%simics%/targets/qsp-x86/images/spi-flash.bin (ro) │
└─────────────────────┴────────────┴───────────────────────────────────────────────────────┘
simics> lookup-file "%simics%/targets/qsp-x86/images/spi-flash.bin"
"/disk1/simics-6/simics-qsp-x86-6.0.47/targets/qsp-x86/images/spi-flash.bin"
The BIOS in the QSP is just loaded straight into target memory for execution. Which is a bit of a cheat for convenience.
Upon searching around, I found the following folder:
C:\Users\yourusername\AppData\Local\Programs\Simics\simics-qsp-x86-6.0.44\targets\qsp-x86\images
Inside that folder are the following 3 files:
SIMICSX58IA32X64_1_0_0_bp_r.fd
SIMICSX58IA32X64-ahci.fd
spi-flash. bin
Both SIMICSX58IA32X64_1_0_0_bp_r. fd and SIMICSX58IA32X64-ahci.fd have UEFI filevolume headers at the start, and a seeming BIOS entry point at the end. The spi-flash. bin seems to have a placeholder of the flash descriptor which would go at the start of the flash, but is mostly empty. So I believe Intel basically either stitches these together in memory, or possibly just uses the spi-flash. bin to allow for "soft strap" configuration or somesuch (since it's a virtual MCH/ICH anyway.)
Related
I have a Yocto build that I am trying to shrink. I have removed a lot of unnecessary code by building core-image-full-cmdline. The Yocto mega manual mentions that to strip the size of your kernel you can use the ksize.py script in the project build directory. When I run this script I get an output of all 0s. This cannot be correct as I have a working SD card image with a booting kernel.
As I remember, you need to execute the script in the kernel folder. The script scan the current folder.
cd /path/to/kernel
python /path/to/ksize.py
(use python2 or 3 depending the current Yocto branch)
#PierreOlivier is right, you need to run this specifically from the kernel build directory (not the kernel source directory), in my case it is:
$ cd tmp/work/qemuarm64-poky-linux/linux-yocto/5.15.14+gitAUTOINC+72e4eafb6b_f77b2ba7d5-r0/linux-qemuarm64-standard-build
$ ../../../../../../../scripts/tiny/ksize.py
Linux Kernel total | text data bss
--------------------------------------------------------------------------------
vmlinux 20936031 | 15461191 4784912 689928
--------------------------------------------------------------------------------
fs/built-in.a 4548119 | 3862922 640608 44589
drivers/built-in.a 3991696 | 3591409 339384 60903
kernel/built-in.a 3104792 | 2078218 834883 191691
net/built-in.a 3083322 | 2731018 305491 46813
Additionally I recommend you try setting either:
DISTRO="poky-tiny"
or
PREFERRED_PROVIDER_linux-yocto = "linux-yocto-tiny"
Which would build a smaller kernel and/or rootfs as reference (assuming you are using linux-yocto and poky), you may set this on your local.conf
1 - There's a "Simics Training" package shown in the package manager, and a "targets\simics-user-training" and " targets\workshop-01". Where is the documentation about starting up and going through these trainings? (I assume this is different than just the normal "my-simics-project-1/documentation.html" documentation, because that documentation doesn't ever reference either of those targets in the Getting Started section)
2 - In the documentation there's a line: "The QSP-x86 package contains a legacy processor core which is used by default in the included simulated machines. To use more modern processors, the package QSP-CPU can be installed, which contains recent processor cores." How does one actually use the QSP-CPU to select a different CPU to be simulated? (Related: I see in the release notes a bunch of mentions of ICH10. Is that what the default QSP-x86 "targets\qsp-x86\firststeps.simics" is simulating? Ideally I'd like to simulate at least a PCH-based system.)
#Point 1
If you check the doc/ folder in your SImics project, you should have the lab instructions. It is a bit inconsistent that they are stand-alone PDFs, but that comes from how they are built currently. Look for nut-001 and workshop-01.
#Point 2 (and how come StackOverflow does not have heading styles? You can really use those to write nicely structured answers)
If you have installed everything, use the scripts "qsp-atom-core.simics" etc. to run the standard QSP setup but with a different type of core. For example:
> simics.bat targets\qsp-x86\qsp-client-core.simics
To see how that core is selected, open the script file. For example, to look at the client core script, first type/cat the trampoline script in the project. Then, go and open or cat or type the script file itself. For example:
C:\Users\jengblo\simics-projects\my-simics-project-5>type targets\qsp-x86\qsp-client-core.simics
# Auto-generated file. Any changes will be overwritten!
decl { substitute "C:\\Users\\jengblo\\AppData\\Local\\Programs\\Simics\\simics-qsp-cpu-6.0.1\\targets\\qsp-x86\\qsp-client-core.simics" }
run-command-file "C:\\Users\\jengblo\\AppData\\Local\\Programs\\Simics\\simics-qsp-cpu-6.0.1\\targets\\qsp-x86\\qsp-client-core.simics"
Given that trampoline, go to the actual script file:
C:\Users\jengblo\simics-projects\my-simics-project-5>type C:\\Users\\jengblo\\AppData\\Local\\Programs\\Simics\\simics-qsp-cpu-6.0.1\\targets\\qsp-x86\\qsp-client-core.simics
# 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
}
run-command-file "%simics%/targets/qsp-x86/qsp-clear-linux.simics"
And note how the "cpu_comp_class" parameter is set. The way to find available such classes in a bit obscure, admittedly. In your running Simics session started from the client-core script (for example), check the types of the components inside the motherboard.
simics> list-components board.mb
┌─────────┬─────────────────────────┐
│Component│Class │
├─────────┼─────────────────────────┤
│cpu0 │processor_x86_coffee_lake│
│gpu │pci_accel_vga_comp │
│memory │simple_memory_module │
│nb │northbridge_x58 │
│sb │southbridge_ich10 │
└─────────┴─────────────────────────┘
Note the class of the cpu0 component. To find other classes from the same pattern, use the list-classes command:
simics> list-classes substr = processor_x86
The following classes are available:
┌─────────────────────────────┬──────────────────────────────┐
│ Class │ Short description │
├─────────────────────────────┼──────────────────────────────┤
│processor_x86QSP1 │N/A (module is not loaded yet)│
│processor_x86QSP2 │N/A (module is not loaded yet)│
│processor_x86_airmont │N/A (module is not loaded yet)│
│processor_x86_broadwell_xeon │N/A (module is not loaded yet)│
...
You can then build a custom script to start with a given core. Follow the pattern of "qsp-client-core.simics" as found in the installation. Copy that file into your project, and modify the core class as well as other parameters.
I'm using cdb with the sosex extension. Everything seems to be working fine except that I am unable to get any !mbp breakpoints to to resolve and !mu/!muf don't show source info.
Got going with the following commands:
.lines
sxe ld:clrjit
g
.loadby sos clr
.cordll -ve -u -l
.load c:\blah\sosex.dll
sxe ld:myassembly.dll
ld myassembly
!mbm myassembly!myfunction
g
It then hits the function I'm interested in and breaks. However !mu doesn't show any source info, only IL and native.
I verified that the symbols, including source lines info, were loaded by doing:
? `myassembly!c:\blah\whatevs.cs:20`
which prints out a correct offset.
SOSEX version is the latest from stevestechspot. Running against .NET Framework 4.7.3. cdb and sosex both x64.
Source file locations on the machine match those in the PDB file.
UPDATE
Having the same problem with SOS. IP2MD doesn't show the source line.
I debugged through sos.dll, and it correctly translated the native address to an IL address and passed the resulting IL address to a function in dbgeng, DebugClient::GetLineByOffset(). However this returned E_FAIL, which from the disassembly it appears hardcoded to do.
So it looks like SOS relies on something that is no longer implemented in the debugger engine to get the source line from the IL offset.
Reported: https://developercommunity.visualstudio.com/content/problem/414350/sos-debugger-extension-for-windbg-cant-find-source.html
Was told to report it as a WDK issue - raised here:
https://social.msdn.microsoft.com/Forums/en-US/2f9d4bbe-8322-4e8d-883a-e40d19f21209/sos-debugger-extension-for-windbg-cant-find-source-lines?forum=wdk
In a device driver source in the Linux tree, I saw dev_dbg(...) and dev_err(...), where do I find the logged message?
One reference suggest to add #define DEBUG . The other reference involves dynamic debug and debugfs, and I got lost.
dev_dbg() expands to dynamic_dev_dbg(), dev_printk(), or no-op depending on the compilation flags.
#if defined(CONFIG_DYNAMIC_DEBUG)
#define dev_dbg(dev, format, ...) \
do { \
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
} while (0)
#elif defined(DEBUG)
#define dev_dbg(dev, format, arg...) \
dev_printk(KERN_DEBUG, dev, format, ##arg)
#else
#define dev_dbg(dev, format, arg...) \
({ \
if (0) \
dev_printk(KERN_DEBUG, dev, format, ##arg); \
})
#endif
dynamic_dev_dbg() and dev_printk() call dev_printk_emit() which calls vprintk_emit().
This very same function is called in a normal mode when you just do a printk(). Just note here, that the rest functions like dev_err() will end up in the same function.
Thus, obviously, the buffer is all the same, i.e. kernel intrenal buffer.
The logged message at the end is printed to
Current console if kernel loglevel value (can be changed via kernel command line or via procfs) is high enough for certain message, here KERN_DEBUG.
Internal buffer which can be read by running dmesg command.
Note, data in 2 is kept as long as there still room in the buffer. Since it's limited and circular, newer data preempts old one.
Additional information how to enable Dynamic Debug.
First of all, be sure you have CONFIG_DYNAMIC_DEBUG=y in the kernel configuration.
Assume we would like to enable all debug prints in the built-in module with name 8250. To achieve that we simple add to the kernel command line the following 8250.dyndbg=+p.
If the same driver is compiled as loadable module we may either add options 8250 dyndbg to the modprobe configuration or to the shell command line when do it manually, like modprobe 8250 dyndbg.
More details are described in the Dynamic Debug documentation.
The "How certain debug prints are automatically enabled in linux kernel?" raises the question why some debug prints are automatically enabled and how DEBUG affects that when CONFIG_DYNAMIC_DEBUG=y. The answer is lying in the dynamic_debug.h and since it's used during compilation the _DPRINTK_FLAGS_DEFAULT defines the certain message appearence.
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
#define _DPRINTK_FLAGS_DEFAULT 0
#endif
you can find dev_err(...) in kernel messages. As the name implies, dev_err(...) messages are error messages, so they will definitely be printed if the execution comes to that point. dev_dbg(...) are debug messages which are more generously used in the kernel driver code and they are not printed by default. So everything you have read about dynamic_debugging comes into play with dev_dbg(...).
There are several pre-conditions to have dynamic debugging working, below 1. and 2. are general preconditions for dynamic debugging. 3. and later are for your particular driver/module/subsystem and can be .
Dynamic debugging support has to be in your kernel config CONFIG_DYNAMIC_DEBUG=y. You may check if it is the case zgrep DYNAMIC_DEBUG /proc/config.gz
debugfs has to be mounted. You can check with sudo mount | grep debugfs and if not existing, you can mount with sudo mount -t debugfs /sys/kernel/debug
refer to dynamic_debugging and enable the particular file/function/line you are interested
I have been doing a project that has many classes (including cpp and header files) and one executable cpp that has int main. With ROS, I'm trying to link these with CMakeLists.txt and with the runtime, I'm planning to compile it without having to change the txt every time. Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)
rosbuild_init()
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
rosbuild_add_library(${PROJECT_NAME} Im_Basibos.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_HedefeGitme.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Konum.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Robot.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Sonar.cpp)
rosbuild_add_executable(srctest Im_RobotKontrol.cpp)
I dont know how to link the header files, I have to link these:
Im_Basibos.h, Im_Basibos.cpp
Im_HedefeGitme.h, Im_HedefeGitme.cpp
Im_Konum.h, Im_Konum.cpp
Im_Robot.h, Im_Robot.cpp
Im_Sonar.h, Im_Sonar.cpp
and
Im_Robot.cpp that has int main()
Any answer will be much appreciated. Thanks already..
I guess rosbuild_add_library works the same than add_library and is not meant to works the way you're using it. It's meant to create static or shared libraries, not to build object files.
I'm giving you two possible ways to build your executable.
version 1
If you only need to build an executable srctest and no separate library.
What you need to do is to list your source files in some variables, say srctest_SOURCES:
set(srctest_SOURCES Im_Basibos.cpp Im_HedefeGitme.cpp
Im_Konum.cpp Im_Robot.cpp Im_Sonar.cpp
Im_RobotKontrol.cpp)
Then build those sources into an executable:
add_executable(srctest ${srctest_SOURCES})
version 2
Now, if you really want to first build a library, say testlib then link it to your srctest executable, that can be done too:
set(testlib_SOURCES Im_Basibos.cpp Im_HedefeGitme.cpp
Im_Konum.cpp Im_Robot.cpp Im_Sonar.cpp)
add_library(testlib ${srctest_SOURCES})
add_executable(srctest Im_RobotKontrol.cpp)
target_link_libraries(srctest testlib)
Thanks to Guillaume for the methods,
Since I'm working with ROS environment,
the exact commands that did the trick were:
rosbuild_add_library(${PROJECT_NAME} Im_Basibos.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_HedefeGitme.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Konum.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Robot.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Sonar.cpp)
rosbuild_add_executable(srctest Im_RobotKontrol.cpp)
target_link_libraries(srctest ${PROJECT_NAME})