Back to home page

OSCL-LXR

 
 

    


0001 What:           /sys/kernel/debug/wilco_ec/h1_gpio
0002 Date:           April 2019
0003 KernelVersion:  5.2
0004 Description:
0005                 As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
0006                 tests, we need to ensure that the H1 chip is properly setting
0007                 some GPIO lines. The h1_gpio attribute exposes the state
0008                 of the lines:
0009                 - ENTRY_TO_FACT_MODE in BIT(0)
0010                 - SPI_CHROME_SEL in BIT(1)
0011 
0012                 Output will formatted with "0x%02x\n".
0013 
0014 What:           /sys/kernel/debug/wilco_ec/raw
0015 Date:           January 2019
0016 KernelVersion:  5.1
0017 Description:
0018                 Write and read raw mailbox commands to the EC.
0019 
0020                 You can write a hexadecimal sentence to raw, and that series of
0021                 bytes will be sent to the EC. Then, you can read the bytes of
0022                 response by reading from raw.
0023 
0024                 For writing, bytes 0-1 indicate the message type, one of enum
0025                 wilco_ec_msg_type. Byte 2+ consist of the data passed in the
0026                 request, starting at MBOX[0]. At least three bytes are required
0027                 for writing, two for the type and at least a single byte of
0028                 data.
0029 
0030                 Example::
0031 
0032                     // Request EC info type 3 (EC firmware build date)
0033                     // Corresponds with sending type 0x00f0 with
0034                     // MBOX = [38, 00, 03, 00]
0035                     $ echo 00 f0 38 00 03 00 > /sys/kernel/debug/wilco_ec/raw
0036                     // View the result. The decoded ASCII result "12/21/18" is
0037                     // included after the raw hex.
0038                     // Corresponds with MBOX = [00, 00, 31, 32, 2f, 32, 31, 38, ...]
0039                     $ cat /sys/kernel/debug/wilco_ec/raw
0040                     00 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00  ..12/21/18.8...
0041 
0042                 Note that the first 16 bytes of the received MBOX[] will be
0043                 printed, even if some of the data is junk, and skipping bytes
0044                 17 to 32. It is up to you to know how many of the first bytes of
0045                 data are the actual response.