I2C transport device for Opentitantool #190

ziuziakowska · 2025-09-18T15:27:50Z

This is an I2C device that allows external software such as opentitantool to communicate with and issue commands to devices on a QEMU I2C bus. The communication is done through a socket chardev.

See docs/i2c_transport.md for usage and wire protocol information.

The device can be instantiated with these command line parameters:

-chardev socket,id=i2c0tp,path=i2c0tp,server=on,wait=off -device ot-i2c-transport,bus=ot-i2c0,chardev=i2c0tp, to instantiate on Earlgrey bus ot-i2c0.

The intention is to use opentitantool to write to the socket and issue transactions, but for testing netcat can be used for manually providing commands using the protocol.

hw/opentitan/ot_i2c_transport.c

rivos-eblot · 2025-09-19T07:55:30Z

hw/opentitan/ot_i2c_transport.c

+{
+    (void)data;
+
+    DeviceClass *dc = DEVICE_CLASS(klass);


You probably need reset handler(s) to reinitialize your state machine, FIFO, ...

hw/opentitan/ot_i2c_transport.c

include/hw/opentitan/ot_i2c_transport.h

docs/opentitan/i2c_transport.md

rivos-eblot · 2025-09-23T14:46:02Z

docs/opentitan/i2c_transport.md

+
+`-chardev socket,id=i2ctp,file=<name>,server=on,wait=off -device ot-i2c-transport,bus=<bus>,chardev=i2ctp`
+
+Where `bus` is any of the OpenTitan Earlgrey I2C buses: `ot-i2c0`, `ot-i2c1`, or `ot-i2c2`.


May be rather add a reference to EG and DJ machines, as several OT machines use I2C buses, which may have different naming / count, so it is probably better to move machine specific details to machine documentation.

I added a note that these names are for EG. I do not know what the DJ I2C bus name is.

I think this will need a fix as in EG the devices have a OT_COMMON_DEV_ID property that is used to construct the name of the bus in ot_i2c. This property is not present in the DJ instantiation.

hw/opentitan/ot_i2c_transport.c

rivos-eblot · 2025-09-23T15:40:47Z

hw/opentitan/ot_i2c.c

    }

    switch (event) {
+    case I2C_START_SEND:


Can you elaborate why SEND_ASYNC could not work with OT_I2C_TRANSPORT?

I believe it should, but I do not know what the difference is between SEND and SEND_ASYNC in QEMU. I chose to use SEND for write transactions because it appears that SEND_ASYNC is a newer interface which might not be supported by all bus devices.

hw/opentitan/ot_i2c_transport.c

docs/opentitan/i2c_transport.md

rivos-eblot · 2025-09-23T15:53:06Z

docs/opentitan/i2c_transport.md

+
+* All bytes values are encoded as a pair of case-insensitive ASCII hex digits. For example, decimal 161 is encoded as either `A1` or `a1`.
+
+* End of a command is indicated with an `S`, this ends the transaction.


I do not know the capability of the OT I2C target mode capabilities, but how the restart are handled?

e.g. in I2C: W A R A S
with:

W: write

R: read

A: address

S: stop

BTW not sure to understand how ACK/NACK signalling is handled

Looking at it again, I think there is actually a way to perform something of a "repeated-start condition" and change the transfer direction without ever releasing the bus. I will rework the command parser to allow for this.

In QEMU's I2C implementation, send to write a byte of data to a device can NACK by returning a non-zero value. event can also NACK a start event. All other event and transfer types such as recv and send_async must succeed. In those cases the special !! value is returned instead of any data.

Should'nt the protocol over the socket closely stick to the I2C protocol? I'm not sure I have a clear mental picture of the I2C data exchange over the socket vs. a real I2C bus. Maybe it is the case. I think it would be nice to have a short doc (ASCII doc in MD file?) to depict the I2C transport protocol over the socket vs. the physical I2C protocol.

I've updated the protocol slightly. Transactions now start with an address byte and then a R or W for the direction - this is a start condition. After that bytes can be written or read once started, and the transaction can change direction any number of times after that using additional Rs and Ws for a repeated-start condition. The transaction is stopped with an S.

This is a pretty thin wrapper around the raw I2C functions, but I do not think there is much we can do to make it more robust (e.g, QEMU's I2C implementation does not support multiple controllers at once, and there is nothing stopping anyone with access to the bus from ending any transfer with i2c_end_transfer including ones they are not part of, so these behaviours are undefined by us.)

The intention of this device is to be an I2C host device that is driven externally by OpenTitanTool. It will be used to issue read and write operations to other I2C devices on its bus - of primary interest is issuing commands to the OpenTitan I2C host/target block. This "bus device" is present on the bus, but it cannot be interacted with by other bus devices and cannot have transactions targetting it. Signed-off-by: Alice Ziuziakowska <[email protected]>

Signed-off-by: Alice Ziuziakowska <[email protected]>

Needed for `ot_i2c_transport` to be able to communicate with `ot_i2c` in target mode. Signed-off-by: Alice Ziuziakowska <[email protected]>

ziuziakowska requested review from AlexJones0, jwnrt and engdoreis September 18, 2025 15:28

ziuziakowska force-pushed the ot_i2c_transport branch 2 times, most recently from 4aa1651 to c990a45 Compare September 18, 2025 15:33

rivos-eblot reviewed Sep 19, 2025

View reviewed changes

ziuziakowska force-pushed the ot_i2c_transport branch from c990a45 to f759510 Compare September 19, 2025 12:38

rivos-eblot reviewed Sep 22, 2025

View reviewed changes

include/hw/opentitan/ot_i2c_transport.h Outdated Show resolved Hide resolved

ziuziakowska force-pushed the ot_i2c_transport branch 4 times, most recently from e89e6b2 to d0289a0 Compare September 23, 2025 11:43

ziuziakowska changed the title ~~[DRAFT, WIP] I2C transport device for Opentitantool~~ I2C transport device for Opentitantool Sep 23, 2025

ziuziakowska requested a review from rivos-eblot September 23, 2025 11:44

ziuziakowska force-pushed the ot_i2c_transport branch from d0289a0 to d9c2532 Compare September 23, 2025 11:48

rivos-eblot requested changes Sep 23, 2025

View reviewed changes

ziuziakowska mentioned this pull request Oct 1, 2025

[qemu] Earlgrey 1.0.0 i2c implementation lowRISC/opentitan#27896

Open

ziuziakowska force-pushed the ot_i2c_transport branch 2 times, most recently from e64d525 to 0e7efaa Compare October 3, 2025 10:58

ziuziakowska added 4 commits October 3, 2025 12:11

[ot] hw: opentitan: add I2C transport device to Kconfig and meson

b61300e

Signed-off-by: Alice Ziuziakowska <[email protected]>

[ot] docs: opentitan: document I2C transport in i2c_transport.md

e39ebb9

Signed-off-by: Alice Ziuziakowska <[email protected]>

[ot] hw/opentitan: ot_i2c: implement I2CSlaveClass send

d716e69

Needed for `ot_i2c_transport` to be able to communicate with `ot_i2c` in target mode. Signed-off-by: Alice Ziuziakowska <[email protected]>

ziuziakowska force-pushed the ot_i2c_transport branch from 0e7efaa to d716e69 Compare October 3, 2025 11:11


		`-chardev socket,id=i2ctp,file=<name>,server=on,wait=off -device ot-i2c-transport,bus=<bus>,chardev=i2ctp`

		Where `bus` is any of the OpenTitan Earlgrey I2C buses: `ot-i2c0`, `ot-i2c1`, or `ot-i2c2`.


		* All bytes values are encoded as a pair of case-insensitive ASCII hex digits. For example, decimal 161 is encoded as either `A1` or `a1`.

		* End of a command is indicated with an `S`, this ends the transaction.

I2C transport device for Opentitantool #190

Are you sure you want to change the base?

I2C transport device for Opentitantool #190

Uh oh!

Conversation

ziuziakowska commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ziuziakowska commented Sep 18, 2025 •

edited

Loading