This might be obvious for some but not to me so I'll ask =)
I'm having an issue that I have build an embedded Linux stack for some piece of hardware (NVidia TX2 + ConnectTech Astro carrier). I use a PCIe card from EPIX
If I use Ubuntu's official distribution for tegra, the PCIe card is properly detected.
With identical kernel and device tree blob, and the same HW unit, the detection fails with embedded Linux.
I thought that detecting PCIe devices would be kernel's job and not be influence by the distro, unless the drivers are built as kernel modules and inserted at different times. But in my case they are build in kernel.
Could someone elaborate why the detection would work with one distro but not the order?
Here is a link to what I tried to do to fix the detection
tx2-pcie-does-not-detect-endpoint-on-connecttech-carrier-board
Thanks!
A Linux distribution contains a kernel that usually differs from the vanilla kernel of the same release. Most of the time a distribution kernel contains lots of back ports of bug fixes that were discovered and fixed later in micro releases. There may be other features that a specific vendor includes and the vanilla kernel does not, like more recent version of certain drivers, etc. What makes this even more confusing is that sets of these back ports are often different in distributions from different vendors. As a side effect, this makes it difficult to depend on something like KERNEL_VERSION() macro in custom kernel code or in custom device drivers.
I can't say about the specific issue that you're having. The topic is pretty generic, and I hope that this explanation helps.
Related
My boss has given a code for testing PCI express on an Altera board. The code consist of several c code files having instructions such as reading Bios, setting some registers, writing to buffers etc.
My job at present is to see the functionality of the code by running it.
I am new to FPGA and I am unable to understand what tools, compilers etc will I use for compiling it for the FPGA.
Since it is a C code so I am sure I cannot use the same environment as that of Verilog/VHDL. Can I get some hints as to what compilers are available for compiling C code for testing various interfaces of an FPGA?
Thanks and regards
H
If the FPGA board is just connected through a standard PCIexpress interface, it isn't that hard to create a Linux driver to simply access a couple of registers. This might even be easier to do than getting some old DOS-based drivers to work.
I did some work on this in a pre-project to my masters thesis some years ago - if you're interested, it's available here: http://loejer.dk/files/FORK,%20pdf.zip
It sounds like the intent is that you connect the PCI-E card to a normal computer with a PCI-E slot, then run the test software on the host computer, so it will talk to the board via PCI-E, and exercise the board from the host, collect data on the host, and so on.
Such code will almost certainly be quite non-portable. You'll probably need to ask what system it's for (or examine the code to find hints -- e.g., if it starts with #include <windows.h> that's a pretty fair indication that it's for Windows).
The OS it's written for will give at least an 80% (or so) clue about what compiler to use -- if it's for Windows, chances are pretty good that it's intended for Microsoft's compiler. If it's for Linux, there's an even better chance that it's for gcc/g++. If it's for MacOS, it's probably for g++, but if it's really new, might target Clang.
I'm currently developing an OpenCL-application for a very heterogeneous set of computers (using JavaCL to be specific). In order to maximize performance I want to use a GPU if it's available otherwise I want to fall back to the CPU and use SIMD-instructions. My plan is to implement the OpenCL-code using vector-types because my understanding is that this allows CPUs to vectorize the instructions and use SIMD-instructions.
My question however is regarding which OpenCL-implementation to use. E.g. if the computer has a Nvidia GPU I assume it's best to use Nvidia's library but if no GPU is available I want to use Intel's library to use the SIMD-instructions.
How do I achieve this? Is this handled automatically or do I have to include all libraries and implement some logic to pick the right one? It feels like this is a problem that more people than I are facing.
Update
After testing the different OpenCL-drivers this is my experience so far:
Intel: crashed the JVM when JavaCL tried to call it. After a restart it didn't crash the JVM but it also didn't return any usable
devices (I was using an Intel I7-CPU). When I compiled the
OpenCL-code offline it seemed to be able to do some
auto-vectorization so Intel's compiler seems quite nice.
Nvidia: Refused to install their WHQL-drivers because it claimed I didn't have Nvidia-card (that computer has a Geforce GT 330M). When
I tried it on a different computer I managed to get all the way to
create a kernel but at the first execution it crashed the drivers
(the screen flickered for a while and Windows 7 said it had to
restart the drivers). The second execution caused a bluee-screen of
death.
AMD/ATI: Refused to install 32-bit SDK (I tried that since I will be using a 32-bit JVM) but 64-bit SDK worked well. This is the only
driver which I've managed to execute the code on (after a restart
because at first it gave a cryptic error-message when compiling).
However it doesn't seem to be able to do any implicit vectorization
and since I don't have any ATI GPU I didn't get any performance
increase compared to the Java-implementation. If I use vector-types I
might see some improvements though.
TL;DR None of the drivers seem ready for commercial use. I'm probably better of creating JNI-module with C-code compiled to use SSE-instructions.
First try to understand hosts & devices: http://www.streamcomputing.eu/blog/2011-07-14/basic-concept-hosts-and-devices/
Basically you can just do exactly what you described: check if a certain driver is available and if not, try the next one. What you choose first depends completely on your own preference. I would pick the device I have tested my kernel best on. In JavaCL you can pick the fastest device with JavaCL.createBestContext and CLPlatform.getBestDevice, check the host-code here: http://ochafik.com/blog/?p=501
Know NVidia does not support CPUs via their driver; only AMD and Intel do. Also is targeting multiple devices (say 2 GPUs and a CPU) a bit more difficult.
There is no API providing what you want. however, you can do the following:
i suggest you iterate over clGetPlatformIDs and query for the number of devices (clGetDeviceIDs), and device type for each device;
and pick the platform which has both types.
then build a map in u'r code, that maps for each type the list of platforms supporting it, ordered in some manner.
finally, just get the first item in the list corresponding for CL_DEVICE_TYPE_CPU and the first item corresponding for CL_DEVICE_TYPE_GPU.
if both returned results are equal (platform_cpu == platform_gpu) then pick one of them and use it for both.
if there is a platform supporting both, you will get match as before since you got order lists. then u can also do load balancing if u like on a single platform, like what Intel has.
Sorry for being late to the party, but regarding Intel's implementation behaviour under JavaCL, I'm afraid you've been bitten by a JavaCL bug :
https://github.com/ochafik/nativelibs4java/issues/297
Fixed in JavaCL 1.0.0-RC2 !
Cheers
Before designing my own Linux OTA stack, I'd better probe if anybody knows of an existing Linux OTA stack/framework that I could make use of/contribute to.
What I mean by Linux OTA stack/framework is a service capable of updating the Linux kernel on my device from a remote repository. Basically something like the OTA update feature found on most Linux smartphones today. It must be 99.99% fail-safe such that my devices (which will be mounted in 500 cars for 6-12 months) will not turn into useless bricks that require on-site service to become working again.
An open source solution is not a must - commercial solutions that do the job has equal interest.
Thanks in Advance.
Christian
Could you just use the APT, combined with suitable kernel packages?
Doing the actual update is pretty trivial, you can use any of the existing package management frameworks to provide a new kernel package that the system upgrades to when available.
The hard part is when your device reboots into the new kernel you need some way to detect if it doesn't boot, and boot it back into the old kernel. To do that without human intervention you'll need some sort of watchdog facility in your hardware.
I am very curious in messing up with HW. But my top level "messing" so far was linked or inline assembler in C program. If my understanding of CPU and ring mode is right, I cannot directly from user mode app access some low level CPU features, like disabling interrupts, or changing protected mode segments, so I must use system calls to do everything I want.
But, if I am right, drivers can run in ring mode 0. I actually don´t know much about drivers, but this is what I ask for. I just want to know, is learning how to write your own drivers and than call them the way I should go, to do what I wrote?
I know I could write whole new OS (at least to some point), but what I exactly want to do is acessing some low level features of HW from standart windows application. So, is driver the way to go?
Short answer: yes.
Long answer: Managing access to low-level hardware features is exactly the job of the OS kernel and if you only want access to a single feature there's no need to start your own OS from scratch. Most modern OSes, such as WIndows, Linux, or the BSDs, allow you to add code to the kernel through kernel modules.
When writing a kernel module (or device driver), you write code that is going to be executed inside the OS kernel and will thus be running in CPU ring 0. Great power comes with great responsibility, which in this case means that you should really know what you're doing as there will be no pre-configured OS interface to prevent you from doing the wrong things. You should therefore study the manuals of your hardware (e.g., Intel's x86 software developer's manuals, device specs, ...) as well as standard operating systems development literature (where you're also going to find plenty on the web -- OSDev, OSDever, OSR, Linux Device Drivers).
If you want to play with HW write some programs for 16-bit real-mode (or even with your own transition to protected-mode). There you have to deal with ASM, BIOS interrupts, segments, video memory and a lot of other low-level stuff.
I'm looking at options to access DVB data on OS X. Initially I want to support the EyeTV DTT USB device, but in the long-run I'd like to support a number of popular devices. The problem I have is that there is no standard way of controlling such devices.
All the applications I know of that use them either hide the driver code within the application (for example EyeTV itself, all it's drivers are implemented totally in userspace and are not accessible to external apps), or they use the seemingly defunkt MMInputFamily driver (no source code availible any more, author gone walkabouts).
I've done some research and found that a number of the devices I want to support are supported within the Linux DVB project. Further research indicates that some years ago there was an attempt to abstract the linux implementation so that it could potentially be recompiled on other platforms. The idea being that efforts to support devices should be pooled and the best way to do that would be to make the current open source implementation work on multiple platforms: it seems in the end to have amounted to little however.
The idea of compiling linux drivers against other *nix type platforms has also been taken up elsewhere with some success. The approach the author took is detailed on the page I linked, it seems potentially viable on OS X as well.
At any rate, there seem to be a number of options, but no clear winner:
Find the source code for the MMInputFamily driver, try to get it working on OS X 10.6 and add support for the devices I require, referrencing the linux source code for pointers. Problem: the source code is nowhere to be found, nor is the author. Additionally it seems the author might perhaps have gone down another route had he fully appreciated the previous efforts to port the linux drivers to OS X.
Attempt to port the linux drivers to OS X in a manner similar to the FreeBSD project I linked. Problem: this is very low-level work and work in this layer is not recommended by Apple if it can be avoided.
Write a driver with OS X's IOKit: this is the preferred method for implementing drivers but I would have to do everything from scratch, clearly not a small job.
If I could I would really like to use the Linux source code, but I'm unsure if such a thing is really viable. Does anyone have any advice or ideas on the best way to proceed with this task?