I'm trying to get a good understanding of how a graphics adapter works and how a graphics driver is built.
So far I've read intel's (very technical) documentation, looked into linux i915 drm driver, and searched the net for more information for weeks.
The platform I'm testing with is a Minnowboard MAX (64-bit Intel®Atom™ E38xx Series SoC - valleyview graphics) and I have the tools and knowledge to change and flash the UEFI firmware (using EDK2 - https://github.com/tianocore/tianocore.github.io/wiki/MinnowBoard). So my questions are:
1) I've read that issuing commands to the graphics adapter happens via the ringbuffer (by issuing batch buffers), is a ringbuffer initialized in the firmware found in the git repository?
2) If not than what are the steps to initialize one?
3) If it is initialized and the console output is generated with the help of the graphics adapter - how can I find the address to which I should write the batch buffers?
Any help or pointers would be greatly appreciated.
Related
Initially I built the Zephyr bluetooth application for native linux and run it in conjunction with Bluez on a BLE controller.I understand that in this, Linux OS and Bluez are used along with Zephyr host stack.
Now, I have flashed bluetooth application from Zephyr stack (samples/bluetooth/beacon)to NXP board successfully. Here there is no bluez used.
For this case, I have a few basic understanding questions:
1. Is the OS functionality also embedded in the bin file that is created after application is compiled. I mean I understand bluetooth stack is Zephyr, but which OS is used on board ?
2. Also, is there any functionality similar to hcitool in Bluez in Zephyr bluetooth stack?
3. Is there any functionality like btmon or hcidump?
To answer your questions:-
Zephyr is an OS itself - it is a Real-Time Operating System (RTOS)
that runs on top of many different types of hardware, just like how
Linux is an operating system that runs on top of many different
hardware. Zephyr is mainly written in C and under the hood talks
directly to the specific processor using its registers and the
vendor's stack. You can find a list of all supported boards
here.
Not identical to hcitool, but there is an hci layer example that
allows you to send raw hci commands. You can find more details on
this here and here. At the end of the day, you may not
need to use hci because it is a low layer and you can probably
achieve the same functionality through higher leve API. All Zephyr's
Bluetooth examples can be found here.
Again, nothing like btmon on Linux how you can see the raw HCI
packets for each command, but Zephyr does support different
Bluetooth logging options depending on the hardware used. More
information on this can be found here.
I hope this helps.
I am plannig to use usb connection to let PC communicate with my equipment based on STM32F373VC.
I tried the CDC class using the example in STM32CubeF3 V1.9.0 by removing the uart peripheral management.
PC detects a usb device with vid:pid 0483:5740. Linux automatically recognizes CDC class (STMicroelectronics STM32F407), loads the cdc_acm module, and the ttyACM0 VCP is created. I don't know about Windows, but reading the readme of the example it seems that a driver should be installed.
I have some questions:
Can I use VID:PID 0483:5740 for my product?
Does the various versions of Windows automatically recognize the device (and associate it with the CDC driver) or is it really necessary to install a driver?
If I can't use these VID:PID, can I ask ST for a PID assigned to me for small productions (as other silicon vendors do)?
Could ST assign me a PID that the various versions of Windows, Linux and Mac automatically recognize as CDCs without needing to install drivers or configure anything?
If not, do VID:PID pairs exist that are automatically recognized by the various versions of Windows, Linux and Mac as CDC class without needing to install drivers or configure and that I can legally use for my small production?
About drivers recognizing your device:
If your device is of class CDC, driver should be able to be loaded no matter what VID:PID is used (as long as selected VID:PID is not assigned to other device that has device specific driver). For Windows please refer to this document.
You should be able to test Linux CDC class driver by altering device descriptor in your device library code (which should be possible, if I correctly understand available ST documentation).
About having your own VID:PID:
There is some thread on github about this here. It should cover all possible options including the ones you asked about.
I have little background on how these hardware actually works, but now I'm required to learn how to write a Linux frame buffer driver for Android devices.
I'm confused by Linux graphics stack. From what I understand, on a desktop computer the compositing window manager interacts with DRM, which then sends data to specific video card driver. On the other hand there are some kind of controllers retrieving data from GPU's memory through DMA and send it to the monitor, as suggested by the answer here .
Also by diagram at page 29 of this book, I figured that a frame buffer driver is on top of actual graphic devices, so it must need to interact with specific video card driver, for example, an nVidia driver.
But when I google writing a frame buffer driver for an embedded device, the results show that as if the driver is directly responsible for contacting with the LCD, so it looks like it's even below a video card driver.
So is a frame buffer driver actually a video card driver?
A framebuffer driver provides an interface for
Modesetting
Memory access to the video buffer
Basic 2D acceleration operations (e.g. for scrolling)
To provide this interface, the framebuffer driver generally talks to the hardware directly.
For example, the vesafb framebuffer driver will use the VESA standard interface to talk to the video hardware. However, this standard is limited, so there isn't really much hardware acceleration going on and drawing is slow.
Another example is the intelfb framebuffer driver. It talks to some intel hardware using a proprietary interface, that exposes more acceleration facilities, so it is faster.
Nowadays, KMS drivers are used instead for most hardware. They do both expose a framebuffer and also access to other GPU functionality, e.g. OpenGL, through DRM.
Your confusion seems to arise from the fact, that the framebuffer driver and the X11 GPU driver are in fact competing! This is why, if you have a KMS system, the switch between graphical and text consoles is instant, however, with a non-KMS system, it is slow, as both the fb driver and the X11 driver need to re-initialize the video hardware on console switch.
Find more information in the comprehensive talk Linux Graphics Demystified by Martin Fiedler:
http://keyj.emphy.de/files/linuxgraphics_en.pdf
Is there any way in any Linux-based OS to access the instructions sent to have it transfer the instructions meant for the GPU to an external device connected via USB3.0 (and, obviously get the pixel output back)?
In Windows there is no native support for this kind of thing. Although many external graphics card exist which connect to a PCi slot, I didn't come across any USB ones.
Is there any way to accomplish this with native support of any of the Linux OSes?
EDIT: I was misunderstood, as far as I can see the comments. I want to program an external graphics card, I'm just looking for a way to get the GPU instructions to get to my device and get back the pixel array.
I am new in Linux Device Driver Field. Can anybody tell which driver will be easier for me to understand among Audio drivers, Video Drivers, Camera Drivers, Power Management Drivers or Boot-loders? Please suggest me the driver which will be easy for a newbie. If you can suggest any good source for the same (not book...any online material if available) it would be great. :)
You should start by studying the basics of Loadable Kernel Modules.
First few chapters of LKMPG by Salzman will be a good start
And the easiest driver, IMHO, is a simpleton driver that uses memory as a device and reads/write to it. One such driver is beautifully explained in third chapter of LDD3e.
You would also need to increase your knowledge of the Linux Kernel itself in order to advance towards relatively hard drivers. The better you understand Kernel's subsystems the easier it will be for you to develop device drivers around them.