changing an I2C address in the ACPI table

374 views
Skip to first unread message

Kris Jones

unread,
Apr 12, 2018, 12:28:25 AM4/12/18
to Chromium OS dev
Hi guys, 
 I have a Chell (HP Chromebook 13 G1) and I need to change the I2C address (and PNP ID, at some point) of the touchpad. 

I have already successfully created a test build of the OS, and integrated the driver I'm developing into the kernel. 
I assume I need to build coreboot and flash new firmware onto the laptop in order to change a value in the ACPI table. 

My questions are:

1. Can I build coreboot the same way I build the kernel? (I did a "cors_workon" to start, I build it with "cros_workon_make" and then I push it to the system with the "update_kernel.sh" script.)

2. Which file in which branch do I need to edit in order to change the I2C address of the trackpad?
Do I change "devicetree.cb" in the latest "release" branch, or the "mainboard.asl" in the branch named for my system? 

or 

Thanks!

Duncan Laurie

unread,
Apr 12, 2018, 2:17:55 PM4/12/18
to razo...@gmail.com, Chromium OS dev
On Wed, Apr 11, 2018 at 9:28 PM Kris Jones <razo...@gmail.com> wrote:
Hi guys, 
 I have a Chell (HP Chromebook 13 G1) and I need to change the I2C address (and PNP ID, at some point) of the touchpad. 

I have already successfully created a test build of the OS, and integrated the driver I'm developing into the kernel. 
I assume I need to build coreboot and flash new firmware onto the laptop in order to change a value in the ACPI table. 


Given some of the items I note below it may be easier to attempt this without modifying the BIOS.

I would recommend enabling CONFIG_ACPI_CUSTOM_DSDT in the kernel and supplying a DSDT that describes the device you are adding.

Since your device is at a different i2C address you should not run into any conflicts with the current touchpad device.  I believe the interrupt will get allocated to the first device to successfully probe.

So hopefully you can just copy the existing device from \_SB.PCI0.I2C1.ELTP from the mainboard.asl that you linked to, and modify the name/HID/address as appropriate.

There are some decent instructions on the custom DSDT process at:

 
My questions are:

1. Can I build coreboot the same way I build the kernel? (I did a "cors_workon" to start, I build it with "cros_workon_make" and then I push it to the system with the "update_kernel.sh" script.)


Some binaries are not made available to end users directly as our license agreement does not always allow it to be distributed independently of a platform.

This applies to the Intel FSP binaries for the Chell platform, which means you will need to extract them from the existing BIOS.

There is also the issue of write protect and the danger associated with flashing the BIOS where you could end up with a device that does not boot.

Some more reading on this:

The community pages are typically focused on using upstream coreboot, but many of the same ideas apply to using an image built from the official firmware branch.

 
2. Which file in which branch do I need to edit in order to change the I2C address of the trackpad?
Do I change "devicetree.cb" in the latest "release" branch, or the "mainboard.asl" in the branch named for my system? 


In general it is best to use the firmware branch as it will be the most reliable for the platform you are working on.

One more word of caution: the firmware build relies on a complete chromium os branch and has many interdependent packages.  You may find that it is necessary to do a separate checkout/chroot/board for the firmware branch for things to work.  This is especially true as the platform ages and the branch diverges further from master.

-duncan

Kris Jones

unread,
Apr 20, 2018, 9:25:48 PM4/20/18
to Chromium OS dev
Thanks so much for this info! I did not want to have to flash the firmware to change the ACPI entry for my i2c device, but I didn't know about the "dsdt_override" functionality. It was exactly what I was looking for. I compiled a modified DSDT table into the kernel and it detects the i2c device with a different address and loads a custom driver.

One additional question:
I want to add another entry for an i2c-hid device, but I can't find an example of an actual DSDT entry for an i2c-hid device from a ChromiumOS device. I got example entries from several different Win10 machines, but they seem to have way more stuff in them than I think I need to make an i2c-hid device work on ChromiumOS. There are lots of "devicetree.cb" files in branches of the coreboot repo, but I don't know how to translate those entries into the equivalent ASL.
I even decoded the DSDT from a "reef" device, but it doesn't seem to have entries for any of the touch controllers attached to the system. (Are they in an OEM table, or something?)
 
For i2c-hid, I know I need at least a _CID name with "PNP0C50", and I think I need a _DSM method, but I don't know what it should return. 
I know something in there should contain the HID descriptor address. My guess is the _DSM returns it. 

Any guidance you can give about what an i2c-hid DSDT entry needs to look like for ChromiumOS is greatly appreciated!

Duncan Laurie

unread,
Apr 20, 2018, 10:44:04 PM4/20/18
to Kris Jones, Chromium OS dev
On Fri, Apr 20, 2018 at 6:25 PM Kris Jones <razo...@gmail.com> wrote:
Thanks so much for this info! I did not want to have to flash the firmware to change the ACPI entry for my i2c device, but I didn't know about the "dsdt_override" functionality. It was exactly what I was looking for. I compiled a modified DSDT table into the kernel and it detects the i2c device with a different address and loads a custom driver.

One additional question:
I want to add another entry for an i2c-hid device, but I can't find an example of an actual DSDT entry for an i2c-hid device from a ChromiumOS device. I got example entries from several different Win10 machines, but they seem to have way more stuff in them than I think I need to make an i2c-hid device work on ChromiumOS. There are lots of "devicetree.cb" files in branches of the coreboot repo, but I don't know how to translate those entries into the equivalent ASL.
I even decoded the DSDT from a "reef" device, but it doesn't seem to have entries for any of the touch controllers attached to the system. (Are they in an OEM table, or something?)
 

At boot time we generate the compiled AML bytecode into an SSDT for devices that are described in coreboot devicetree.cb.

You should be able to find and disassemble the SSDT in the same location in sysfs as the DSDT on Reef to see what it ends up looking like.
 
For i2c-hid, I know I need at least a _CID name with "PNP0C50", and I think I need a _DSM method, but I don't know what it should return. 
I know something in there should contain the HID descriptor address. My guess is the _DSM returns it. 

Any guidance you can give about what an i2c-hid DSDT entry needs to look like for ChromiumOS is greatly appreciated!



On Wednesday, April 11, 2018 at 9:28:25 PM UTC-7, Kris Jones wrote:
Hi guys, 
 I have a Chell (HP Chromebook 13 G1) and I need to change the I2C address (and PNP ID, at some point) of the touchpad. 

I have already successfully created a test build of the OS, and integrated the driver I'm developing into the kernel. 
I assume I need to build coreboot and flash new firmware onto the laptop in order to change a value in the ACPI table. 

My questions are:

1. Can I build coreboot the same way I build the kernel? (I did a "cors_workon" to start, I build it with "cros_workon_make" and then I push it to the system with the "update_kernel.sh" script.)

2. Which file in which branch do I need to edit in order to change the I2C address of the trackpad?
Do I change "devicetree.cb" in the latest "release" branch, or the "mainboard.asl" in the branch named for my system? 

or 

Thanks!

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

Kris Jones

unread,
May 2, 2018, 8:15:09 PM5/2/18
to Chromium OS dev, razo...@gmail.com
This worked perfectly! Thanks!

I copied the entry for the digitizer device from the mainboard.asl for Caroline, and only had to remove the one "_PRW" line. I updated the HID descriptor address with mine, and everything else was the same as for generic i2c. 

I've got a couple more questions:
1. Is there a way to skip the i2c-hid enumeration process for a device? I'm wondering if there's a process like embedding a custom DSDT, where you create binary files and set some kernel config options, but for the HID and report descriptors.

2. I'm migrating over to Chell/ACPI from Peppy that used the "chromeos_laptop" driver. The old method had the ability to add a "platform_data" structure to the "i2c_board_info" struct, which I used to pass in the limit settings for the events. I can't find the analog for doing this in the ACPI process. 

Is there a way to pass in platform data when using ACPI?

Thanks so much for all your help!

Duncan Laurie

unread,
May 2, 2018, 10:25:27 PM5/2/18
to Kris Jones, Chromium OS dev
On Wed, May 2, 2018 at 5:15 PM Kris Jones <razo...@gmail.com> wrote:
This worked perfectly! Thanks!

I copied the entry for the digitizer device from the mainboard.asl for Caroline, and only had to remove the one "_PRW" line. I updated the HID descriptor address with mine, and everything else was the same as for generic i2c. 

I've got a couple more questions:
1. Is there a way to skip the i2c-hid enumeration process for a device? I'm wondering if there's a process like embedding a custom DSDT, where you create binary files and set some kernel config options, but for the HID and report descriptors.


One way could be to intercept things at the I2C level and use the i2c-stub driver to present a fake i2c-hid device:

This doesn't quite align with the ACPI based enumeration as it wouldn't have a corresponding I2C bus in ACPI to describe it so you have to do the binding with module parameters and sysfs...
 
2. I'm migrating over to Chell/ACPI from Peppy that used the "chromeos_laptop" driver. The old method had the ability to add a "platform_data" structure to the "i2c_board_info" struct, which I used to pass in the limit settings for the events. I can't find the analog for doing this in the ACPI process. 

Is there a way to pass in platform data when using ACPI?


The method for abstracted platform data is the convoluted _DSD package which is like the HID descriptor but with a different UUID and a flexible format.  In linux this can conveniently map to ARM DTS.

First a couple links:

This is something that we also generate in coreboot now because the ASL code is messy, so you have to look into older branches to find static ASL code examples.  The same Chell board has some examples in the audio headphone codec:

In coreboot this same set of variables can be set and then generated in the SSDT:

Which maps to the kernel driver:

And finally, the kernel notes on i2c-hid bindings in particular:

-duncan

Sohel Khan

unread,
May 2, 2018, 11:55:35 PM5/2/18
to Kris Jones, Chromium OS dev


Sohel khan

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

Kris Jones

unread,
May 11, 2018, 9:48:17 PM5/11/18
to Chromium OS Development, razo...@gmail.com

I haven't gotten to the platform data step, yet, since I've run into a strange problem. 

I can successfully enumerate my device as just a keyboard, or just a mouse, using i2c-hid, but when I try to use a report descriptor with the two devices together, ChromiumOS locks up. (Actually it reboots the first time, and then the second time it locks up.) I get no useful info about the lock up out of the debug serial port. Just a bunch of "init: ui main process ($PID) terminated with status 2". 

The report descriptors I have for the keyboard and mouse work fine on their own. I tried putting them together as a single top level report, and I also tried giving them each unique report IDs, but that had no effect. 

Am I doing something wrong? I would think multiple different usage types should be supported on i2c-hid. Is that incorrect?
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages