I am developing a program for a micro controller using FreeRTOS. My micro controller has a CAN driver and uses hardware interrupts. There is an interrupt fired when the CAN driver finished transmitting a CAN frame.
For simplicity I am developing and testing some part on Linux (Ubuntu 20). I am using socketCAN on Linux, with a virtual CAN port.
Is it possible to mimic the hardware interrupts on Linux ?
I was thinking to use the POSIX Signals, what do you think ?
Thanks
I found the solution.
The solution is to execute a task in parallel and call the function normally pointed by the interrupt vector.
While finding the solution I remarked that using POSIX signals between FreeRTOS tasks of the POSIX_GCC may lead to problem with linux system calls.
I also figured out that FreeRTOS tasks are monopolizing CPU time if they are used along with classical pthreads.
Related
Now, some pcie device has a cpu, ex:DPU.
I want to use qemu to emulate this device.
Can qemu support this requirment？
QEMU's emulation framework doesn't support having devices which have fully programmable CPUs which can execute arbitrary guest-provided code in the same way as the main system emulated CPUs. (The main blocker is that all the CPUs in the system have to be the same architecture, eg all x86 or all Arm.)
For devices that have a CPU on them as part of their implementation but where that CPU is generally running fixed firmware that exposes a more limited interface to guest code, a QEMU device model can provide direct emulation of that limited interface, which is typically more efficient anyway.
In theory you could write a device that did a purely interpreted emulation of an onboard CPU, using QEMU facilities like timers and bottom-half callbacks to interpret a small chunk of instructions every so often. I don't know of any examples of anybody having written a device like that, though. It would be quite a lot of work and the speed of the resulting emulation would not be very fast.
This can be done by hoisting two instances of QEMU, one built with the host system architecture and the other with the secondary architecture, and connecting them through some interface.
This has been done by Xilinx by starting two separate QEMU processes with some inter-process communication between them, and by Neuroblade by building QEMU in nios2 architecture as a shared library and then loading it from a QEMU process that models the host architecture (in this case the interface can simply be modelled by direct function calls).
Related:
How can I use QEMU to simulate mixed platforms?
https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg01969.html
I am facing a design "issue". I have a board with Xilinx Zynq Soc including dual-core ARM9 and I need to develop an application to support real-time property control application (time deadlines to response time) and also application to do heavy processing (image etc.) and some basic communications between them, but most importantly I will need to be able to control the Linux part (at least e.g. to somehow suspend it, "pause it" in best case to have possibility to shut it down and then run it again). So I was wondering how to combine it.
One of the option, could be RTLinux, which at least to description, what I found offers possibility to run realtime kernel and linux kernel next to it as a thread but it seems that it is now proprieatary by WindRiver..
Then I stepped up over MicroBlaze, where it could be possible to "create" soft processor on Programmable logic, but I am not sure if I can run RTOS on ARM and Linux there?
There are two things that seem to be known as rtlinux. The one you mention, a Wind River revival of the MERT system is a product of that company. Another one, seemingly “RT Linux”, is a real time patch to the mainline kernel which provides deterministic scheduling and fine grained kernel pre-emption.
I think it is the latter one that you want. 10s of google indicates that there is a kconfig target for this SoC, so all the pieces you need should be there.
Do remember there is more to a real time system than just the ability to be real time; the subsystems also have to be well behaved.
Given your description, you have (at least) the following design options:
Dual kernel approach: this means patching the Linux kernel with a (quite invasive) patch that runs a tiny real-time kernel alongside the standard kernel. This approach allows reaching good real-time performance (even in the order of us) at the cost of complexity. It was implemented by the RTLinux project (acquired and then discontinued by Windriver), then by RTAI (mostly focusing on x86) and Xenomai.
If you go along this path, you can see if Xenomai supports your specific SoC; then patch, configure and rebuild the kernel; and finally write the real-time code following Xenomai's API.
Improving the responsiveness of the Linux standard kernel: this is what the PREEMPT_RT project aims at. The real-time performance is lower with respect to the previous approach, but you don't have to write real-time specific code. With this approach, you can patch and build the kernel, then see if the real-time performance is sufficient for your needs.
Synthesizing a Microblaze soft-core on the FPGA, then run Linux on the ARM cores and the real-time code ((either bare-metal or with an RTOS) on the Microblaze.
Unfortunately, your specific SoC does not support ARM's virtualization extensions. Otherwise there would be the additional option of Multi-OS approach: running the Linux OS on one ARM core and the real-time code (either bare-metal or with an RTOS like ERIKA Enterprise) on the other ARM core, through a hypervisor like Jailhouse or Xen.
Background:
I am developing a tool which boots up a custom build of Linux and boots into QT based desktop for x86 based machine. My custom Linux runs from USB and when the it boots on a machine with certain brand of sound cards connected, then my tool runs to a live lock situation with a lot of interrupts. I doubt its some problem with APIC driver but the system is renderd useless and I have to poweroff the system.
My Question:
I would like to simulate the same situation by using a kernel driver or module. I am not sure if I can cause an interrupt to fire from a module. I have a experience with I2C or SPI which causes interrupts on ARM based Linux boards. But i dont know how to do it from a module
Could anybody please suggest me how to cause an interrupt from a driver?
Just create a module with an interrupt forkbomb in it. Google it. It'll only take a second for your vm to halt.
http://www.tldp.org/LDP/tlk/dd/interrupts.html
I'm working on an embedded Linux project where we need to ACK a message from the serial port within 200ms. If I'm not using some real-time variant then won't it be impossible to guarantee Linux would respond within that time bound? The hardware will be a 200MHz ARM running Debian. The kernel version currently used is "2.6.32 #1 SMP PREEMPT". Would also like to know exactly what PREEMPT means here.
Preemptive means an arbritary task with the right priority can interrupt any task running in the scheduler of the OS at any time. With this feature you could guarantee that your task with the timing constraint can meet it's requirement.
The picture below illustrates exactly what scheduling is doing:
Nowadays, virtually every popular OS support preemptive scheduling in user space. However, in kernel space (drivers, other critical kernel tasks) are not supported by this kind of scheduling so there are some initiatives like RTLinux and also your OS, Debian SMP PREEMPT which try to support full preemptive scheduling in the OS (making it a hard realtime system).
So yes, your kernel would provide the timing constraints needed for your application.
It means that it's a real-time kernel. Preempt means to interrupt or stop an action. So if an irq request comes into the kernel, the kernel immediately stops what it's doing and processes irq. So you get a real time response to events happening on the serial bus or an audio input.
I use build real-time kernels when needed (usually audio applications) and it's a series of patches that can be added to the vanilla kernel to make it preemptive (real time).
I don't know without testing if you can respond to a serial request in 200ms but that definitely sounds possible.
Along with Debian, RedHat and other distros with preemptive kernels, there are whole distros dedicated to realtime Linux like RTLinux and I would guess most of them would have ARM versions.
At college I'm studying Operative Systems, and as a first part of the project we have to modify the Timer Interrupt to execute my own code, may be with threads, and I think that Linux present less restrictions to access the Interrupt Vector that Windows does, is not?
Can you give me more details if it's better use Windows or Linux (like Ubuntu) to do this.
Thanks.
I would use Linux, because I think you might fail your assignment if you use Windows. The reason being that the commonly accessible timers (i.e. non-driver stuff) under Windows are not really interrupts, they're messages posted to your thread's message queue.
Whereas under Linux signal/sigaction in combination with timer_create will send a signal, which really counts as "interrupt".