Using ioctl interface various info can be fetched. How do you get extra info like product name, class, vendor name, subsystem name etc?
There are couple of command line tools available such as:
1. lshw -C network
2. detecting nic and ports on systems loaded with linux
You can start a process and get the result but Is there any raw c/c++ method to get above mentioned information?
Cheers
Prashant
All the information you seek is in /sys/bus/pci/devices/*/*:
class
device
driver
modalias
subsystem
subsystem_device
subsystem_vendor
vendor
You can see how lspci(8) reads through the files with strace -o /tmp/out lspci, /tmp/out will have plenty of details. (I don't know any easy way to restrict this to just the NICs; I think both lspci(8) and the kernel have hard-coded lists of PCI ID -> name mappings.)
Look in sysfs or procfs, unfortunately this information has a habit of being changed and so cannot be relied on :(
Related
I built a certain driver as module (m) for Linux, the spi-imx by NXP. Nontheless, Linux probes this driver when booting. I'm struggling to find out what process/other module/driver requests this spi-imx driver. A depmod does not show any dependencies between the spi-imx an other modules (except for the spidev as submodule).
After some research, I found out that Linux automatically (?) calls modprobe when it detects a new device. So does Linux actually call modprobe because the ecSPI'S status in the device tree as "okay"? If so, how can I prevent this? I would like to dynamically load the spi-imx from a user space application via modprobe. The story behind it: a coprocessor uses this SPI line in parallel to the Linux boot process. This interferes of course and interrupts the coprocessor's use of the SPI line. When the coprocessor has finished its transfer via SPI (a boot mechanism as well), it should hand over the SPI line to Linux.
I'm very thankful for any kind of tips, links, hints and comments on this.
Thanks a lot for the answers. As you guys mentioned, I also found out that Linux itself probes the device if present ("okay").
One possible solution is to complete cut off the modprobe call via an entry like "install spi-imx /bin/false" in the *.conf file. But that makes it impossible to load the driver via modprobe, for Linux and for user space.
"blacklist spi-imx" inside a *.conf located at /etc/modprobe.d/ is the way to prevent Linux from probing the driver when booting. After that, a modprobe from user space can successfully load the driver afterwards.
Thanks again & best regards
I have started a bare-metal application for AArch64. The bare-metal application should implement a simple kernel (for memory/device management and exception handling) and an userland which can made syscalls to output something over the UART via printf() as example. Currently I'm working on the kernel at EL1. The indent is to put kernel and userland in a single ELF binary, because I don't have implemented an filesystem driver and ELF support yet.
The kernel should reside at address 0xC0000000 and the main application (userland) at 0x40000000 as example. But I will change this addresses later. Is it possible to pass two linker scripts to GNU ld? I realize that I must use different sections for kernel and userland.
Or in another question:
Is my indent even possible? Okay it's maybe a generic question, but currently didn't find a similar question here.
From the LD manual: https://man7.org/linux/man-pages/man1/ld.1.html, it's said:
Multiple -T options accumulate.
Just use it like this: -T script1.ld -T script2.ld
What would be the simplest and most portable way (in the sense of only having to copy a few files to the target machine, like procdump is) to generate a kernel dump that has handle information?
procdump has the -mk option which generates a limited dump file pertaining to the specified process. It is reported in WinDbg as:
Mini Kernel Dump File: Only registers and stack trace are available. Most of the commands I try (!handle, !process 0 0) fail to read the data.
Seems that officially, windbg and kd would generate dumps (which would require kernel debugging).
A weird solution I found is using livekd with -ml: Generate live dump using native support (Windows 8.1 and above only).. livekd still looks for kd.exe, but does not use it :) so I can trick it with an empty file, and does not require kernel debugging. Any idea how that works?
LiveKD uses the undocumented NtSystemDebugControl API to capture the memory dump. While you can easily find information about that API online the easiest thing to do is just use LiveKD.
I am trying to debug multiple devices at once with openocd on eclipse. I have 2x STM32F303 discovery borards, I have set the hla_serial flag to a proper board, but still no luck.
Separate boards are doing ok, but when trying to debug it's Eclipse saying it'came to error in last sequence.
So if anyone had experience with that. Thanks
We can use hla_serial option within openocd 0.9+ ONLY. I'd recommend to download from
GNU ARM Eclipse project or compile yourself.
To obtain hla_serial, the easiest way found after reading the patch that included this option (http://openocd.zylin.com/#/c/2198/), more specific function "string_descriptor_equal", was to provide a wrong serial, so it would print the correct one.
The command below will create file log_with_correct_serial.txt. Switch board config file for the one currently being used.
openocd.exe -d3 -f board/stm32f4discovery.cfg -c "hla_serial wrong_serial" 2>log_with_correct_serial.txt
Opening log_with_correct_serial.txt you will find correct serial in line containing something like
Debug: 229 23 libusb1_common.c:67 string_descriptor_equal(): Device serial number 'xxxxxxxxxxx' doesn't match requested serial 'wrong_serial'
So create a derived config (for example stm32f4discovery-mydevice1.cfg, assuming stm32f4discovery is used) inside folder board on openocd root directory. Use something like Notepad++ to copy serial as it is hex numbers.
# This is an STM32F4 discovery board with a single STM32F407VGT6 chip.
# http://www.st.com/internet/evalboard/product/252419.jsp
# hla_serial thanks to http://wunderkis.de/stlink-serialno/index.html
source [find board/stm32f4discovery.cfg]
hla_serial V?nIpSU)?
Now to open your device you can use the command below to start debugging using ST-Link adapter.
openocd.exe -f board/stm32f4discovery-mydevice1.cfg
In each eclipse project provides a different board config for each project and you are good to go.
I am writing a Perl script that will be deployed and executed on many servers. Some of my requirements are retrieving the manufacturer, model and serial number. Unfortunately I can't seem to figure out how to do that. I'm not seeing any built in libraries to do this.
I'm not sure if I can use libraries that don't come with Perl since I wouldn't be able to include those when it gets executed on the other servers.
Any thoughts?
There's a perl module called Parse::DMIDecode which will use the dmidecode program that Brian pointed out.
It's not Perl but you can invoke
$ sudo dmidecode
from within your script. That will dump the BIOS info and on my machine I get:
System Information
Manufacturer: Hewlett-Packard
Product Name: HP xw6600 Workstation
Version:
Serial Number: CXC9062H43
UUID: 53F3EB48-4CF9-DD11-BBDA-29023A11001F
Wake-up Type: Power Switch
SKU Number: RV725AV
Family: 103C_53335X
I don't know how much of the above is a) standard info b) populated by our service desk when provisioning PCs for our use. But it's worth investigating further.
From the man page for dmidecode:
dmidecode is a tool for dumping a computer's DMI (some say
SMBIOS) table contents in a human-readable format. This table contains
a
description of the system's hardware components, as well as other useful pieces of information such as serial numbers and BIOS
revision.
Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good
point in
terms of report speed and safeness, this also makes the presented information possibly unreliable