summaryrefslogtreecommitdiffstats
path: root/Documentation/ABI/testing/debugfs-wilco-ec
blob: 73a5a66ddca655ce547e9f1bf9e343bebbedf065 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
What:		/sys/kernel/debug/wilco_ec/h1_gpio
Date:		April 2019
KernelVersion:	5.2
Description:
		As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
		tests, we need to ensure that the H1 chip is properly setting
		some GPIO lines. The h1_gpio attribute exposes the state
		of the lines:
		- ENTRY_TO_FACT_MODE in BIT(0)
		- SPI_CHROME_SEL in BIT(1)

		Output will formatted with "0x%02x\n".

What:		/sys/kernel/debug/wilco_ec/raw
Date:		January 2019
KernelVersion:	5.1
Description:
		Write and read raw mailbox commands to the EC.

		You can write a hexadecimal sentence to raw, and that series of
		bytes will be sent to the EC. Then, you can read the bytes of
		response by reading from raw.

		For writing, bytes 0-1 indicate the message type, one of enum
		wilco_ec_msg_type. Byte 2+ consist of the data passed in the
		request, starting at MBOX[0]

		At least three bytes are required for writing, two for the type
		and at least a single byte of data. Only the first
		EC_MAILBOX_DATA_SIZE bytes of MBOX will be used.

		Example:
		// Request EC info type 3 (EC firmware build date)
		// Corresponds with sending type 0x00f0 with
		// MBOX = [38, 00, 03, 00]
		$ echo 00 f0 38 00 03 00 > /sys/kernel/debug/wilco_ec/raw
		// View the result. The decoded ASCII result "12/21/18" is
		// included after the raw hex.
		// Corresponds with MBOX = [00, 00, 31, 32, 2f, 32, 31, 38, ...]
		$ cat /sys/kernel/debug/wilco_ec/raw
		00 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00  ..12/21/18.8...

		Note that the first 32 bytes of the received MBOX[] will be
		printed, even if some of the data is junk. It is up to you to
		know how many of the first bytes of data are the actual
		response.