C- displaying CPU info using kernel module - c

I've recently learned about kernel modules and I was thinking on how to create one that does what cat /proc/cpuinfo does.
Is it possible to do this without opening/reading the file directly (fread)?
Thanks in advance!

/proc/cpuinfo output is generated by kernel code; you can check that code and do the same in your kernel module.
Code is located in fs/proc/cpuinfo.c
It references 'cpuinfo_op' object that is provided by architecture-dependent code, try 'grep cpuinfo_op arch' from toplevel directory of kernel source to locate it.

Related

No FIQ.h on Raspberry PI3B+

I was exploring the FQI routine for ARM processors. I noticed that most Linux kernels provide a fiq.h header file yet my RPi does not seem to have it. Using find does not return anything. My Linux kernel version is 5.15.61-v8+. How would one use FIQ without the header file on RPI? Thanks.
robin#raspberrypi:/ $ locate interrupt.h
/usr/lib/python3/dist-packages/numpy/core/include/numpy/npy_interrupt.h
/usr/src/linux-headers-5.15.61-v8+/include/linux/interrupt.h
robin#raspberrypi:/ $ locate fiq.h
/usr/src/linux-headers-5.15.61-v8+/include/linux/platform_data/ams-delta-fiq.h
/usr/src/linux-headers-5.15.61-v8+/include/linux/spi/s3c24xx-fiq.h

Linux kernel error: patch refuses to compile

here is the code that i wrote: link
and im selecting the following defconfig(exynos8890-herolte_kor_defconfig) for compiling defconfig file
and my core function (kernel/examplepatch/core.c) is depend on the following options as described in kernel/example/Kconfig
config HAVE_EXAMPLEPATCH
bool
help
Arch supports kernel example patch
config EXAMPLEPATCH
bool "Kernel example patch"
depends on DYNAMIC_FTRACE2
depends on MODULES
depends on SYSFS
depends on KALLSYMS_ALL
depends on HAVE_EXAMPLEPATCH
help
Say Y here if you want to support kernel example patch.
and the following options depends on MODULES , depends on SYSFS and depends on KALLSYMS_ALL are selected through defconfig which i selected at compile time(exynos8890-herolte_kor_defconfig) and the rest dependencies depends on HAVE_EXAMPLEPATCH and depends on DYNAMIC_FTRACE2 are selected through arch/arm64/Kconfig link within CONFIG_ARM64(and exynos8890-herolte_kor_defconfig has CONFIG_ARM64 option too)
but unfortunatly the kernel/examplepatch/core.c refuses to compile i cant see the core.o (compiled object) in kernel/examplepatch
so what part or things are wrong?
thanx
regards

get linux file system information via kernel function

I have to write a linux module and I can't find a proper function to list all mounted file system and their information. I know command "df -T" can achieve this and sadly I can't use that. Is there a kernel function that can do this or other way?
Why not see the kernel code which fills /proc/mounts
mountstats_open() in base.c
refer get filesystem mount point in kernel module
Your code could open/read the /proc/mounts file, line by line. It contains everything that is mounted, including many mount points that you would not expect.
In general, the format is the same as the /etc/fstab file, but will also include all the mounts that the OS adds.

Merge C program and VHDL bitstream via "make" (i.e. using a Makefile)

I am trying to test the VHDL AVR8 soft processor found on Gadget Factory on a Digilent Nexys II (Spartan 3E) Development board. The project includes a Makefile for compiling a C (or other) software program and merging it with the FPGA bitstream so there is no need to resynthesize the HDL with every iteration of the software.
When I execute 'make' I get the following error associated with data2mem:
Merging Verilog Mem file with Xilinx bitstream: main.bit
data2mem -bm bin/top_avr_core_v8_bd.bmm -bt bin/top_avr_core_v8.bit -bd main.mem -o b main.bit
process_begin: CreateProcess(NULL, data2mem -bm bin/top_avr_core_v8_bd.bmm -bt bin/top_avr_core_v8.bit -bd main.mem -o b main.bit, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [main.bit] Error 2
I am executing 'make' in the same directory containing the VHDL project files, and I even have a blank 'main.bit' file in the directory.
Does anyone have any ideas about what's going on here? Does my blank 'main.bit' file need to be formatted a certain way or placed in a different location?
The following is a link to my Makefile:
Makefile
Other information to note: I'm new to using Makefiles in general, let alone for the specific purpose of merging software with an FPGA bitstream file. Also, I am attempting this on a Windows 7 machine in command prompt.
Thanks in advance.
Edit: Here's a link to the AVR8 soft processor on Gadget Factory, and here's the AVR8 source.
Offhand I'd say make cannot invoke the data2mem program. Do you have such a program on your system? Is the directory containing it in your PATH variable? Does it run properly? For example, can you type in that command line yourself at the command prompt and have it work properly?
When you say a "blank" main.bit, I assume you mean a "fully populated except for the memory that I want to put the program into" main.bit... otherwise nothings going to work!
It sounds like you do not have data2mem on your path - are you sure you are running your makefile from a command window/shell which includes the xilinx paths?
On Windows, there is a specific icon for this. Alternatively you can open any old command prompt and run the settings32.bat (or settings64.bat) file from within the Xilinx install folder to get set up. Or on linux, you can source the appropriate .sh/.csh file in your shell.

How to read, understand, analyze, and debug a Linux kernel panic?

Consider the following Linux kernel dump stack trace; e.g., you can trigger a panic from the kernel source code by calling panic("debugging a Linux kernel panic");:
[<001360ac>] (unwind_backtrace+0x0/0xf8) from [<00147b7c>] (warn_slowpath_common+0x50/0x60)
[<00147b7c>] (warn_slowpath_common+0x50/0x60) from [<00147c40>] (warn_slowpath_null+0x1c/0x24)
[<00147c40>] (warn_slowpath_null+0x1c/0x24) from [<0014de44>] (local_bh_enable_ip+0xa0/0xac)
[<0014de44>] (local_bh_enable_ip+0xa0/0xac) from [<0019594c>] (bdi_register+0xec/0x150)
In unwind_backtrace+0x0/0xf8 what does +0x0/0xf8 stand for?
How can I see the C code of unwind_backtrace+0x0/0xf8?
How to interpret the panic's content?
It's just an ordinary backtrace, those functions are called in reverse order (first one called was called by the previous one and so on):
unwind_backtrace+0x0/0xf8
warn_slowpath_common+0x50/0x60
warn_slowpath_null+0x1c/0x24
ocal_bh_enable_ip+0xa0/0xac
bdi_register+0xec/0x150
The bdi_register+0xec/0x150 is the symbol + the offset/length there's more information about that in Understanding a Kernel Oops and how you can debug a kernel oops. Also there's this excellent tutorial on Debugging the Kernel
Note: as suggested below by Eugene, you may want to try addr2line first, it still needs an image with debugging symbols though, for example
addr2line -e vmlinux_with_debug_info 0019594c(+offset)
Here are two alternatives for addr2line. Assuming you have the proper target's toolchain, you can do one of the following:
Use objdump:
locate your vmlinux or the .ko file under the kernel root directory, then disassemble the object file :
objdump -dS vmlinux > /tmp/kernel.s
Open the generated assembly file, /tmp/kernel.s. with a text editor such as vim. Go to
unwind_backtrace+0x0/0xf8, i.e. search for the address of unwind_backtrace + the offset. Finally, you have located the problematic part in your source code.
Use gdb:
IMO, an even more elegant option is to use the one and only gdb. Assuming you have the suitable toolchain on your host machine:
Run gdb <path-to-vmlinux>.
Execute in gdb's prompt: list *(unwind_backtrace+0x10).
For additional information, you may checkout the following resources:
Kernel Debugging Tricks.
Debugging The Linux Kernel Using Gdb
In unwind_backtrace+0x0/0xf8 what the +0x0/0xf8 stands for?
The first number (+0x0) is the offset from the beginning of the function (unwind_backtrace in this case). The second number (0xf8) is the total length of the function. Given these two pieces of information, if you already have a hunch about where the fault occurred this might be enough to confirm your suspicion (you can tell (roughly) how far along in the function you were).
To get the exact source line of the corresponding instruction (generally better than hunches), use addr2line or the other methods in other answers.

Resources