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
Related
I’m currently trying to perform integrity measurement using a TPM (SLB 9670) on a Raspberry Pi 3 model B+.
I have the TPM installed and working properly since I can execute some basic commands like tpm2_getrandom() and so on. Now I want to perform an integrity measurement using IMA, and I have recompiled the new kernel with the following config:
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_INTEGRITY=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
CONFIG_IMA_AUDIT=y
CONFIG_IMA_LSM_RULES=y
CONFIG_IMA_WRITE_POLICY=y
CONFIG_IMA_READ_POLICY=y
CONFIG_IMA_APPRAISE=y
CONFIG_IMA_APPRAISE_BOOTPARAM=y
CONFIG_HW_RANDOM_TPM=y
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y
but the ima for some reason still doesn’t detect the TPM and gives the errors:
I have done some research and found out that maybe this is due to the fact that the ima get initialized before the TPM, so I have also tried to compile another version of the kernel where I change the code line in devices/clk/bcm/clk-bcm2835:
from:
postcore_initcall(__bcm2835_clk_driver_init);
to
subsys_initcall(__bcm2835_clk_driver_init);
But it still didn’t work.
Please help!
You are on the right path, I believe what is missing is the SPI & TPM kernel modules have to be configured to built-in. Take a look at this doc for the detailed steps.
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 want to use a SensorTag 2 so that it is sitting there broadcasting it's data (and, critically connectable over bluetooth) from when it's turned on to when\if I ever turn it off. Out of the box, the tag is set to only advertise over Bluetooth for a few mins which means that when the connection eventually fails or when the device connected to the tag boots etc etc you can't connect again without physically visiting the tag and resetting it.
I see there is firmware that the myWeatherCenter people have created that lets the tag work as a weather station by basically setting it to advertise indefinitely... frustratingly though their firmware is only the sensortag version 1 :-(
I've researched on and off for months and months now and nothing coming back.. suggesting either nobody else wants this, there is a really simple solution everyone one else knows about or ...? I can't even see anyone else asking this question really... which is worrying.
Does anyone have a firmware file that sets this setting for the sensortag 2 or know how to modify the firmware to set this setting?
It is definitely possible to change the SensorTag 2/CC2650 platform so that its behavior suits your use case. I - for example - currently use a custom firmware doing pre-processing of sensor readings on the SensorTag and sending data directly in the advertisement message indefinitely (of course you have to tweak intervals and payload to get a decent battery life).
I assume you have CCS and the sources (SensorTagApp and SensorTagStack) at hand?
I recommend flashing the current SensorTagStack first, if not done yet (though I'm not yet on 2.2 myself).
In the SensorTagApp project under Application you find SensorTag.c. In there you should change:
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_LIMITED
to
#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_GENERAL
This is the usual advise and might already do the trick.
In my firmware I also changed (in SensorTag.c, in the SensorTag_init function):
uint16_t advertOffTime = 0;
to
uint16_t advertOffTime = 1;
Please try these changes and get back to me. If that wasn't enough I will do a more thorough comparison of the stock firmware and my custom firmware. I also recommend the more specific ti Bluetooth low energy forum.
You could find the workflow for a complete solution and the firmware for continuous advertising which I created recently, at Sensortag CC2650STK Custom Firmware Modification&Download Workflow (Continuous Advertising) using Code Composer Studio, Debugger DevPack and Flash Programmer 2 software
I'm trying to write an application in pyserial to talk to an external device (a Casio graphics calculator) which according to its manual uses 9600bps asynchronous serial with no flow control, no parity and 8 bits, but for the stop bit values it specifies 3 stop bits for sending and 2 stop bits for receiving. The manual makes no mention of start bit length.
First, does anyone know how to specify two different stop bit values using pyserial, and secondly can you actually specify a stop bit length of 3? The only options that pyserial has are 1, 1.5 and 2 bits.
I've so far managed to send single characters from my Linux laptop to the graphics calculator (setting either 1 or 2 stop bits seemed to work) but getting characters back from the graphics calculator isn't working (I have tested both the cable and port and they should work), so I'm guessing the stop bit setting could be an issue. If anyone knows where to go from here, any help would be greatly appreciated!
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.