Touch support question, ectool

Support
1

So this is a ChromeOS issue but I’m hoping someone here can help me

I have an Acer C736T (CRAASKVIN) and when I replace the touchscreen, touch no longer functions. Acer says to use the SHIM they provide but that didn’t work and when this happened with MAGLITH, I was able to fix it with the following command: ectool cbi set 8 0 4

I was hoping maybe someone would know how I could fix this issue with ectool.

I’m not sure what I’m doing, but I believe I can use ectool to check I2C bus for a specific USB MUX IC, identify USB MUX IC type, then set SSFC.

If anyone knows how I can do this it would be greatly appreciated. I really hope this makes sense…

2

so what exactly are you needing then?

no, you can’t. And not sure why you are bringing USB into a discussion about i2c devices.

SSFC on your device is used to tell coreboot which touchscreen type is installed. You changed your touchscreen type, so SSFC/CBI has to be updated to match

3

The first quote from me is for MAGLITH, this is CRAASKVIN

I gathered the second quote from an Acer script I was sent awhile back, which does exactly what I figured out on my own with MAGLITH. Maybe it was doing more than just updating SSFC/CBI for the touch screen.

Is there anyway to know what values to use for ectool cbi set for which touchscreen?

4

yes, the coreboot override devicetree file for the board will tell you:

src/mainboard/google/brya/variants/craask/overridetree.cb

CRAASK has 4 touchscreen options, and 3 FW_CONFIG values

fw_config
<snip>
	field TS_SOURCE 38 41
		option TS_UNPROVISIONED 	0
		option TS_GTCH7503		    1
		option TS_ILTK0001		    2
	end
end
...
			chip drivers/i2c/hid
				register "generic.hid" = ""GTCH7502""
				register "generic.desc" = ""G2 Touchscreen""
                                <snip>
				device i2c 0x40 on
					probe TS_SOURCE TS_UNPROVISIONED
				end
			end
			chip drivers/i2c/hid
				register "generic.hid" = ""GTCH7503""
				register "generic.desc" = ""G2 Touchscreen""
                                <snip>
				device i2c 0x40 on
					probe TS_SOURCE TS_GTCH7503
				end
			end
			chip drivers/i2c/hid
				register "generic.hid" = ""ELAN9004""
				register "generic.desc" = ""ELAN Touchscreen""
                                <snip>
				device i2c 10 on
					probe TS_SOURCE TS_UNPROVISIONED
				end
			end
			chip drivers/i2c/hid
				register "generic.hid" = ""ILTK0001""
				register "generic.desc" = ""ILITEK 
                                <snip>
				device i2c 41 on
					probe TS_SOURCE TS_ILTK0001
				end
			end

First, you need to determine the touchscreen type. You can do that with i2cdetect, or since there are 3 values you can just set each in sequence and see which works.

so, get the current SSFC value:
ssfc_val=$(ectool cbi get 8 | grep -m1 'uint' | cut -f3 -d ' ')

the touchscreen type is bits 38-41 in FW_CONFIG, but SSFC is the upper 32-bits, so have to subtract 32 when setting via ectool - so we’re dealing with bits 6-9 here (bit mask is 0x3c0).

clear the existing touchscreen value:
ssfc_val=$((ssfc_val & ~0x3c0))
set the new touchscreen value. Since the valid values are 0/1/2, and we’re starting with bit 6, we can use 0x40, 0x80, and 0xc0 here:
ssfc_val=$((ssfc_val | 0x40))

write the new value to cbi:
ectool cbi set 8 $ssfc_val 4

if that works, great, if not clear and try the next option.

5

Thank you so much!

6

Unfortunately none of those options worked, I have a feeling it’s an issue with these screens but hopefully Acer will be able to help

I set ssfc_val=$((ssfc_val | 0x40))
ssfc_val=$((ssfc_val | 0x80))
ssfc_val=$((ssfc_val | 0xc0))

and for each one, ectool cbi set 8 $ssfc_val 4, then rebooted, and no touch function for any of them

7

well, use i2cdetect to see if there’s anything at the expected addresses. Can also look at cbmem to see how fw_config is being read/applied

8

Am I correct that for i2cdetect, I run

i2cdetect -F (device i2c)

So for the above values either 0x40, 41, or 10?

Using 10 returns a list with all yes values, does that mean the touchscreen is the Elan9004?

9

that would be my guess - so you want to clear the bits and not set anything.

When mentioning values to test above, should have been 0x0, 0x40, and 0x80 for 0/1/2

1 Like
10

One last question - how do you find this information?

I assumed this was in the chromium documentation but when I attempt to navigate to src/mainboard/google/brya/variants/craask/overridetree.cb it requests a user name and password (I can get to google/brya before it requires credentials)

11

no idea why they started requiring credentials to view the source, you can open up in an incognito window last I checked. But I just looked at my local copy. And I’ve worked with fw_config/SSFC before so know how it all works

1 Like