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
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
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'm trying to run this tutorial XDP code that is provided in the bcc.
The code I use is this script: bcc/examples/networking/xdp/xdp_drop_count.py.
and to my understanding, XDP flag works as follows (from that question):
#define XDP_FLAGS_SKB_MODE (1U << 1)
#define XDP_FLAGS_DRV_MODE (1U << 2)
#define XDP_FLAGS_HW_MODE (1U << 3)
So, doesn't this mean that if I change the flags bit to
flags |= 1 << 3
I should be able to run this code in hardware accelerated mode (offloaded)?
I have a NIC card that supports XDP HW accelerated mode and it works fine when I just attach a simple program with only one line of code:
return XDP_PASS;
and attach it in offloaded mode by using ip link set dev interface xdpoffload etc.
So I have confirmed my NIC is capable of loading an offloaded XDP program but when I try the above, it gives me an error:
bpf: Attaching prog to enp4s0np1: Invalid argumentTraceback (most recent call last) :
File "xdp_drop_count.py", line 132, in <module>
b. attach_xdp(device, fn, flags)
File "usr/lib/python2.7/dist-packages/bcc/__init__.py", line 723, in attach_xdp % (dev, errstr))
Exception : Failed to attach BPF to device enp4s0np1: No such file or directory
Also, when I set the flags to :
flags |= 1 << 2
I am not sure if this is actually running the XDP program in driver mode.
Am I missing something?
Thank you in advance.
If you build bcc from sources
Since commit d147588, bcc has hardware offload support. To offload programs using bcc, you will need three things:
The XDP_FLAGS_HW_MODE bit (1U << 3) should be set in the flags passed to attach_xdp().
The name of the interface to which you want to offload the program should be given to BPF() with the device= parameter. It will allow bcc to offload the maps to the appropriate device. It is unnecessary if you don't have maps.
The interface's name should also be given to load_func, again with parameter device=, such that bcc tells the kernel where to offload the program.
Note that, with the latest bcc sources, the xdp_drop_count.py script has been updated to do all this for you when you pass the -H option:
sudo ./xdp_drop_count.py -H $ETHNAME
For older versions of bcc
Older versions of bcc do not support hardware offload. You can use bpftool or ip (>v4.16) instead, e.g.:
sudo ip link set dev $ETHNAME xdpoffload obj prog.o sec .text
sudo bpftool prog load prog.o /sys/fs/bpf/prog type xdp dev $ETHNAME
For a BPF program to be attached as a XDP program, it needs to be offloaded to the NIC first, when being loaded on the system.
In your case, the b.load_func() provided by bcc does not support any option for offloading programs when passing them to the kernel. So when you later call b.attach_xdp() with the XDP_FLAGS_HW_MODE, the function fails, because it cannot find any program offloaded on the NIC.
Right now there is no workaround for offloading program with bcc. As pchaigno mentioned, the function simply does not offer an option to indicate the program should be offloaded.
It should not be too difficult to add support for offloading programs to bcc though, so it should probably be available in the future (especially if pchaigno feels like adding it :p). You would still need to replace the per-CPU array by a regular array in your program, as the former is not supported for offload at this time.
Regarding the mode in which your programs run, this is something you can check with bpftool net for example.
I understand that a lot of compilation issues on the Pi Zeros are due to the fact that they use armv6, whereas the newer Raspberry Pi's like the 3 A+ and B+ use armv7. However, I do not understand how to find the offending library in an application that is causing the issue, and if there is perhaps a simple fix for the problem.
Background:
I am trying to port an application from a Linux Desktop environment to the Pi Zero (running armv6). I successfully ported it to the Pi 3 B and B+. That is, I compiled the code, and checked that it is producing the correct output.
However, the Pi Zero implementation compiles, but just spits out a single message when run:
Illegal instruction
This is most likely due to some command that is not compatible with armv6, but I cannot figure out which command that is. I would like to start by determining which library is the problem child. Please tell me how I would diagnose that.
Extra Info:
I have checked that the compiler is not the issue. How? I made a simple hello world program, and compiled it for the Pi Zero:
#include<iostream>
int main(int argc, char *argv[]){
std::cout << "Hello World!" << std::endl;
return 0;
}
So the compiler itself doesn't seem to be the issue.
More details:
If I run readelf -A myapp, my understanding is that the output is reporting that the app is indeed compiled for armv6:
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Here is the readelf -A for one of the shared libraries:
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv4
Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: Deprecated
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
To identify a fault such as Illegal instruction you can run the program under a debugger capable of interacting with the operating system's fault handler.
On a Linux system such as the pi, that would be gdb. You may need to install this, on a debian-derived distribution that would be sudo apt-get install gdb
Then run your program
gdb myprog
or if your program needs command line arguments
gdb myprog --args some_argument another_argument
Once gdb starts up type run, and the program will execute near normally until it reaches the illegal instruction, at which point you will be dumped back at the gdb prompt with a hopefully informative error message.
There you can explore with commands such as backtrace or if the programmer has associated source, list. If the fault is at an address gdb can see as being mapped as from a file it should show you that - you can also get at the mapping information via the gdb command info files or by looking in /proc/[PID]/maps
If for some reason you can't run the program live under gdb, you can research how to enable core dumps for your system, and then load the program and the core dump into gdb for post-mortem analysis.
Depending on system configuration, if running the program on its own without a debugger, you may also see information about the fault in the output of dmesg or another system log.
i have simple answer just press up button and try
rpi0 can run all programs if you have armel
see here its a rpi0 os build script build a minimal os on based on armel architecture
https://gitlab.com/kalilinux/build-scripts/kali-arm
how i solved i tried to run java on raspbian os it did not worked i used kali for raspberry pi zero java was running
so use armel arch
I'd like to start service before user mode is loaded (in kernel mode).
The reason is I wanna run several system applications(asm code to write data to BIOS) that are not allowed in user mode (privileges problem).
That's why I got an idea: 1. Write windows service 2. Start and run it in kernel mode
Is it possible?
Are there any other ways to solve the problem?
I don't usually use Vista (use linux instead), that's why I'm asking.
Windows services are user-mode applications. To run in kernel-mode you should write a driver. (So-called "legacy" driver will be enough, see Driver Development Part 1: Introduction to Drivers).