I try to improve numpad integrated to touchpad driver for Linux. Via i2c it sets up backlight level. I would like read backlight level which I wrote via I2C, so in other words I would like to get the current state of touchpad LEDs. So I do:
sudo i2ctransfer -v -f -y 2 w13#0x15 0x05 0x00 0x3d 0x03 0x06 0x00 0x07 0x00 0x0d 0x14 0x03 0x01 0xad r13
And kernel log:
i2ctransfer-52950 [002] .... 13100.114028: i2c_write: i2c-2 #0 a=015 f=0200 l=13 [05-00-3d-03-06-00-07-00-0d-14-03-01-ad]
i2ctransfer-52950 [002] .... 13100.114030: i2c_read: i2c-2 #1 a=015 f=0201 l=13
i2ctransfer-52950 [002] .... 13100.115055: i2c_reply: i2c-2 #1 a=015 f=0201 l=13 [00-00-00-00-00-00-00-00-00-00-00-00-00]
i2ctransfer-52950 [002] .... 13100.115055: i2c_result: i2c-2 n=2 ret=2
And I was surprised with all zeros 00-00-00-00-00-00-00-00-00-00-00-00-00 as result. I expect the same value. I miss basics? It is not a static register what I change?
05-00-3d-03-06-00-07-00-0d-14-03-**01**-ad
is got by reversed engineering on windows with the installed official driver from this log. Selected rows from log:
[0]0000.0000::03/13/2021-22:23:06.173 [SimplePeripheralBusProbe]device 5: ##00 write 13 - 0000: 05 00 3d 03 06 00 07 00 0d 14 03 01 ad
[0]0000.0000::03/13/2021-22:23:06.173 [SimplePeripheralBusProbe] [SpbPeripheralCompleteRequestPair] <--
[0]0000.0000::03/13/2021-22:23:06.173 [SimplePeripheralBusProbe] [SpbPeripheralOnCompletion] <--
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [OnRead] --> entry
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe]Received read request 00003BF8EE838318 of length 16 for SPBTARGET 00003BF8EE35AB98 (WDFDEVICE 00003BF8EE8504F8)
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [SpbPeripheralRead] --> entry
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe]Formatting SPB request 00003BF8EEF082E8 for read
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [SpbPeripheralSendRequest] --> entry
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe]Saving client request 00003BF8EE838318, and sending SPB request 00003BF8EEF082E8
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [SpbPeripheralSendRequest] <--
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [SpbPeripheralRead] <--
[3]0004.00F8::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [OnRead] <--
[0]0000.0000::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [SpbPeripheralOnCompletion] --> entry
[0]0000.0000::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe]Completion callback received for SPB request 00003BF8EEF082E8 with STATUS_SUCCESS
[0]0000.0000::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe] [SpbPeripheralCompleteRequestPair] --> entry
[0]0000.0000::03/13/2021-22:23:06.179 [SimplePeripheralBusProbe]Marking SPB request 00003BF8EEF082E8 for reuse, and completing client request 00003BF8EE838318 with STATUS_SUCCESS
** stars value is changed, depends on purpose: 0x00 means disable, 0x01 means enable, 0x41-46 specific level of backlight (these numbers were brute forced)
Related
I've spent a day reading about APDU commands, never used them before and I'm still not sure how do I code a procedure/function in Delphi to communicate with a Smart Card, any help/advice would be much appreciated.
The Smart Card has two applets installed. This command selects the Secure element
applet and routes subsequent APDU commands to it.
IsoCase: Case4Short
Class: 0x00
Instruction: 0xa4
Data: 0x10 0xA0 0x00 0x00 0x07 0x48 0x46 0x4A 0x49 0x2D 0x54 0x61 0x78 0x43 0x6F 0x72 0x65
Le: 0x00
Example: 0x00 0xA4 0x04 0x00 0x10 0xA0 0x00 0x00 0x07 0x48 0x46 0x4A 0x49 0x2D 0x54 0x61 0x78 0x43 0x6F
0x72 0x65 0x00
How is the procedure supposed to look like, do I need to use any components, libraries, dlls? No idea what needs to be between begin and end tags. Thanks in advance.
During the study of the PCI firmware specification and the looking at the existing implementations of the PXE Boot Agents, I had a misunderstanding of how this should work.
According to PCI Firmware Specification, during the POST procedure the BIOS should map Option ROM into UMB memory (0xC000-0xF000), then call "Init" entry point by the offset 0x3, and after this the BIOS can disable Option ROM.
PXE oprom binary consists from three parts: "Initialization code", "Base code" and "UNDI code".
BIOS loads into UMB only "Initialization code". Base code and UNDI code are loaded into memory later through copying directly from the flash memory (from PCI Flash BAR (BAR1, according Intel specifications).
The question: what are the reasons for the need for such an algorithm of work?
Why the vendors do not use the BIOS mechanisms and do not load the entire Extension ROM into memory (instead copying from Flash BARs)?
A monolithic PXE option ROM was a single unit but most PXE option ROMs now have a split architecture (split into UNDI option ROM and a BC option ROM). Although, the BC ROM is typically embedded in the BIOS and may not even appear as an option ROM.
The NIC only has one option ROM nowadays, the UNDI option ROM.
Option ROM Header: 0x000DA000
55 AA 08 E8 76 10 CB 55 BC 01 00 00 00 00 00 00 U...v..U........
00 00 00 00 00 00 20 00 40 00 60 00 ...... .#.`.
Signature 0xAA55
Length 0x08 (4096 bytes)
Initialization entry 0xCB1076E8 //call then far return
Reserved 0x55 0xBC 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Reserved 0x00 0x00 0x00 0x00 0x00
PXEROMID Offset 0x0020 //RWEverything didn't pick it up as a separate field and made it part of the reserved section so I separated it.
PCI Data Offset 0x0040
Expansion Header Offset 0x0060
UNDI ROM ID Structure: 0x000DA020 //not recognised by RW Everything so I parsed it myself
55 4E 44 49 16 08 00 00 01 02 32 0D 00 08 B0 C4 UNDI......2...
80 46 50 43 49 52 ¦-ÇFPCIR
Signature UNDI
StructLength 0x16
Checksum 0x08
StructRev 0x00
UNDIRev 0x00 0x01 0x02
UNDI Loader Offset 0x0D32
StackSize 0x0800
DataSize 0xC4B0
CodeSize 0x4680
BusType PCIR
PCI Data Structure: 0x000DA040
50 43 49 52 EC 10 68 81 00 00 1C 00 03 00 00 02 PCIR..h.........
08 00 01 02 00 80 08 00 ........
Signature PCIR
Vendor ID 0x10EC - Realtek Semiconductor
Device ID 0x8168
Product Data 0x0000
Structure Length 0x001C
Structure Revision 0x03
Class Code 0x00 0x00 0x02
Image Length 0x0008
Revision Level 0x0201
Code Type 0x00
Indicator 0x80
Reserved 0x0008
PnP Expansion Header: 0x000DA060
24 50 6E 50 01 02 00 00 00 D7 00 00 00 00 AF 00 $PnP............
92 01 02 00 00 E4 00 00 00 00 C1 0B 00 00 00 00 ................
Signature $PnP
Revision 0x01
Length 0x02 (32 bytes)
Next Header 0x0000
Reserved 0x00
Checksum 0xD7
Device ID 0x00000000
Manufacturer 0x00AF - Intel Corporation
Product Name 0x0192 - Realtek PXE B02 D00
Device Type Code 0x02 0x00 0x00
Device Indicators 0xE4
Boot Connection Vector 0x0000
Disconnect Vector 0x0000
Bootstrap Entry Vector 0x0BC1 // will be at 0xDABC1
Reserved 0x0000
Resource info. vector 0x0000
I'm running a program with two CAN channels (using TowerTech CAN Cape TT3201).
The two channels are can0 (500k) and can1 (125k). The can0 channels works perfectly but can1 runs a write:No buffer space available error.
I'm using ValueCAN3/VehicleSpy to check the messages.
This is before I run the program. can0 and can1 both seem to send, but only can0 shows up in VehicleSpy.
root#cantool:~# cansend can0 100#00
root#cantool:~# cansend can1 100#20
This is after I try running the program
root#cantool:~# cansend can1 100#20
write: No buffer space available
root#cantool:~# cansend can0 111#10
While my program is running : I get this error for all messages to be sent on can1
2016-11-02 15:36:03,052 - can.socketcan.native.tx - WARNING - Failed to send: 0.000000 12f83018 010 1 00
2016-11-02 15:36:03,131 - can.socketcan.native.tx - WARNING - Failed to send: 0.000000 0af81118 010 6 00 00 00 00 00 00
2016-11-02 15:36:03,148 - can.socketcan.native.tx - WARNING - Failed to send: 0.000000 12f81018 010 6 00 00 00 00 00 00
2016-11-02 15:36:03,174 - can.socketcan.native.tx - WARNING - Failed to send: 0.000000 0af87018 010 3 00 00 00
2016-11-02 15:36:03,220 - can.socketcan.native.tx - WARNING - Failed to send: 0.000000 12f89018 010 4 00 00 00 00
2016-11-02 15:36:03,352 - can.socketcan.native.tx - WARNING - Failed to send: 0.000000 12f83018 010 1 00
However sometimes the whole program works perfectly (if the module is rebooted or some random instances).
How do I fix this?
root#cantool:~# uname -r
4.1.15-ti-rt-r43
after doing some digging, I found this
root#cantool:-#ip -details link show can0
4:can0: <NOARP,UP,LOWER_UP, ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 100
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 24000000
root#cantool:-#ip -details link show can1
5: can1: <NOARP,UP,LOWER_UP, ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state STOPPED restart-ms 100
bitrate 125000 sample-point 0.875
tq 500 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
c_can: tseg1 2..16 tseg2 2..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
Turns out that can1 is STOPPED for some reason
however when I try:
ip link set can1 type can restart
RNETLINK answers: Invalid argument
After you enable the can0 interface with sudo ifconfig can0 up, run:
sudo ifconfig can0 txqueuelen 1000
This will increase the number of frames allowed per kernel transmission queue for the queuing discipline. More info here
... sometimes the whole program works perfectly (if the module is rebooted or some random instances).
The reason why it works when you restart the SocketCAN interface, is that you might clear up just enough buffer space to make it work.
I have derived the WiFI Authentication and Encryption data format by writing it and then reading it from an application running on microcontroller.
Can some one please tell me the macros or values for the Authentication type (WPA-Personel,Shared,WPA2-Enterprise,WpA2-Enterprise,WPA2-Personel)fields and Encryption type fields (None,WEP,TKIP,ES,AES/TKIP).
I have figured out for WPA/WPA2-Personel authentication type and AES encryption type so far as below .
52 0x10 0x03 2 Attribute ID: Authentication Type
54 0x00 0x02 2 Attribute Length: 2 octets
56 0x00 0x20 2 Authentication Type: WPA2-Personal
58 0x10 0x0F 2 Attribute ID: Encryption Type
60 0x00 0x02 2 Attribute Length: 2 octets
62 0x00 0x08 2 Encryption Type: AES
Any official documentation will be highly appreciated.
I'd like to parse a proprietary message with the following format. The messages are of variable length from 8bytes to 16 bytes. If the message is more than 8 bytes, it is put into multi packet message.
Byte0 Byte1 Byte2 Byte3 Byte4 Byte5 Byte6 Byte7-14 Byte15
Header Header Flags SlaveID Sequence Command Command Data Chksum
I send these messages to a device and expect a response from said device with similar format. I know what the messages are supposed to say, but I'm really struggling to find a away to parse the data in real time and display the information in somesort of GUI framework. Currently, I'm planning on dumping the data into a .txt/.csv file and post-processing with matlab.
I'm a hardware guy. This is not my strong suit.
Example:
Command, Reponse
0xAC 04 01 01 00 8C 01 01 chksum
0x04 AC 83 01 00 8C 01 01 0B D9 chksum
0x8c01 command to test power supply 0x01
Device echos the command and power supply it was checking and also returns the bit-shifted value of the power supply voltage 0x0BD9