I'm trying to develop NDIS6.0 based mini-port driver on WEC7 (Windows Embedded Compact 7) for a PCIe network card.
In MPInitialize function when I try to read PCI config space using function NdisMGetBusData, It is returning zero.
From documentation, it should read number of bytes read. There is no any more info available in documentation.
I'm not getting any debug message from NDIS wrapper layer.
I have added print in my OALPCICfgRead in my OAL layer. I'm not getting this print also.
The function that I'm calling is :
ulResult = NdisMGetBusData(
Adapter->AdapterHandle,
PCI_WHICHSPACE_CONFIG,
FIELD_OFFSET(PCI_COMMON_CONFIG, VendorID),
buffer,
PCI_COMMON_HDR_LENGTH );
Here ulResult is zero.
Not getting any additional debug prints from NDIS.
Prints in PCI controller lower level functions also not appearing.
It'll be helpful if somebody help me on debugging this issue.
The problem is in WEC7's CEDDK.dll.
There was no support for PCI bus HalGetBusDataByOffset and HalSetBusDataByOffset functions for ARM in DDK_BUS.lib (they have built in support for x86 ).
When I cloned this driver from public code and added this support, the functionality is working fine now.
This seems to be undocumented in MSDN.
Related
I'm trying to communicate to a custom piece of hardware from a (userspace) C++ program. The device is an HID device, but not a mouse/keyboard.
On Windows, I can use HidD_SetOutputReport to send a report, and then HidD_GetInputReport to receive the reply. (There is more than one report being generated, but those calls let me specify which one I want.)
I'm not doing anything fancy, so it's nice and straightforward.
I am having trouble figuring out what the simple Linux alternative to those calls is.
If someone could point me towards documentation or a code example that illustrates equivalent operations on Linux, I would be very grateful.
Thank you.
If your device is a HID device then for sending the HID report you need to write to the corresponding /dev/hid* device. This will be HidD_SetOutputReport alternate.
Most of the devices now using EP0 for backward communication, so for getting the response you need to read from corresponding /dev/hid* device. This will beHidD_GetInputReport alternate.
If your hardware are not using the EP0 for communication then you can find the information from your Endpoint descriptor, in which it will be defined how to get the response back.
I'm working on a project that will have SPIFFS, Bluetooth and WiFi libraries. The program is all set so the librarys don't interfere in the communication, since Bluetooth can't work when WiFi is set. But I'm getting the following problem when I attempt to add a command line from the library https://github.com/mobizt/Firebase-ESP32, this library is responsable of making connection to firestore database:
text section exceeds available space in boardSketch uses 1517102 bytes (115%) of program storage space. Maximum is 1310720 bytes.
Global variables use 63300 bytes (19%) of dynamic memory, leaving 264380 bytes for local variables. Maximum is 327680 bytes.
Sketch too big; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing it.
Error compiling for board DOIT ESP32 DEVKIT V1.
I only get this error when adding this piece of code:
Firebase.begin(&config, &auth);
Firebase.reconnectWiFi(true);
I'm using arduino ide to work with esp32, but I have esp-idf in case it helps solving the issue.
It looks like you've reached the limit of the partition size for your application. I don't know how Arduino configures the ESP IDF partitions, but you should be able to change them however you want. See the documetation on partitions
I have a problem with the i2c/SMBus on a Linux System with an Intel Apollo Lake processor. I am trying to read/write from/to an EEPROM but I face some issues. My EEPROM is located at the address 0x56, and I am able to watch the Bus with my Logic Analyzer.
When I try to read from the device via i2ctools (i2cget) the System behaves as expected. My issue occurs when I try to perform a write command via i2cset for example. i2cset ends with an error (Write failed). Because I am able to watch the Bus electrically I can also say that all lines stay HIGH and the Bus is not touched. I was able to activate the dev_dbg() functions in the i2c driver i2c_i801 and when I perform i2cset I am able to find (dmesg) the debug message:
[ 765.095591] [2753] i2c_i801:i801_check_post:433: i801_smbus 0000:00:1f.1: No response
When running my minimal I²C Python code using the smbus2 lib, I get the following error message and the above mentioned debug message:
from smbus2 import SMBus
bus = SMBus(0)
b = bus.read_byte_data(86,10) #<- This is performed
b = bus.write_byte_data(86,10,12) #<- This is not performed
bus.close()
Error:
File "usr/local/lib/python3.8/dist-packagers/smbus2-0.4.0-py3.8.egg/smbus/smbus2.py", line 455, in write_byte_data
ioctl(self.fd, I2C_SMBUS, msg)
OSERROR: [Errno 6] No such device or adress
A big hint for me is that I am not able to perform a write command in the address space form 0x50 to 0x57. My guess is that some driver locks the address space to prevent write command to that "dangerous" area.
My question is: "Does anyone know this kind of behavior and is there a solution so that I can write to my EEPROM at address 0x56? OR Is there a lock surrounding the i2c adress space from 0x50 to 0x57 and who is my opponent?"
I am kind of a newbie to the whole driver and kernel world so please be kind and it is quite possible that I made a beginner mistake.
I would appreciate hints and tips I can look after surrounding my problem.
It seems that I found the cause of my problem. In this Forum post is described that Intel changed a configuration Bit at the SMBus controller.
OK, I know what's going on.
Starting with the 8-Series/C220 chipsets, Intel introduced a new
configuration bit for the SMBus controller in register HOSTC (PCI
D31:F3 Address Offset 40h):
Bit 4 SPD Write Disable - R/WO.
0 = SPD write enabled.
1 = SPD write disabled. Writes to SMBus addresses 50h - 57h are
disabled.
This badly documented change in the configuration explains the issues.
One Challenge is, that to apply and enable changes to the SPD-write Bit the System needs to be rebooted. Unfortunately while rebooting the BIOS will change the Bit back to the default. The only solution seems to be an adaption in the BIOS.
For me, this issue is resolved. I just wanted to share this information in case someone faces the same issues.
I'm trying to support 9-bit UART using Android Things,
When I try to set the data size to 9 I receive IO exception.
The only configurations that works are 7 and 8 bits.
I know that is possible to make 9-bit emulation using the parity error interrupt, but on android things, I don't receive any handler of it.
I tried also to set it using the native library, same exception.
Is there a chance to have this interrupt?
I'm using Pico-Pi iMX7D.
I don't understand why there is no high-level support of it.
Thank you in advance
Moved to feature request here: https://issuetracker.google.com/issues/67995082
I am trying to undestand how to USE linux kernel drivers. One day I wrote linux kernel module for handling interrupts from gpio. Built it with "make" command and loaded it with "insmod" and it worked. But now I am trying to use this ov5642 camera driver.I downloaded the source code. made "make" command in folder with sources and when it built I used "insmod" command to load it. It is now listed in already loaded modules list but I have got no idea how to get grabbed frames.
How can I make it work and access its output ?
In order to capture frames from the module, you need to "probe" your driver with a platform device (i.e. you have to create a platform device in order to call "ov5642_probe" function). If the probe function is being called, and ends successfully reaching to "return 0", you will get a print "Chip ID 0x5642 detected" in dmesg. (You can easily check weather the probe function is being called or not by putting a simple "printk(KERN ERR "### my probe function is being called")" at line number 935 in probe function and check in dmesg. If it is being called, you have to interface the camera properly in order to probe driver successfully.
If probe function fails (i.e. being called but not reaching till "return 0"), then there should be problem with reading the registers of ov5642. Check the i2c connections and power supplies of camera properly (and make sure its power on sequence is performed as mentioned in datasheet) if you get "Chip ID" other than 0x5642 or i2c read fails.
If the probe function is not being called, then you need to create a proper platform_device.
Assuming you are doing this on a custom board where ov5642 module is interfaced.
If you get "Chip ID 0x5642 detected" in dmesg, then you should try with "v4l-utils" package. There are many options available in v4l2-ctl command where you can set format, query capabilities, start stream, grab frame. If you are unable to install v4l-utils on your board, then, you should try https://gist.github.com/maxlapshin/1253534. You can also refer to Documentation/video4linux/ on lxr online or any kernel source offline if you are interested in developing a camera driver.
If you are a newbie, and you want to learn to deal with kernel drivers, refer to http://www.makelinux.net/ldd3/ and specially platform driver documentation under Documentation/driver-model/platform.txt on lxr for creating and probing a platform driver.