[sw,opentitanlib] QEMU I2C transport and target mode test #28450
Conversation
ziuziakowska
changed the title
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
6fbc024 to
4af129e
Compare
ziuziakowska
changed the title
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
2 times, most recently
from
50b78e5 to
8ca242c
Compare
ziuziakowska
requested review from
timothytrippel
and removed request for
a team
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
8ca242c to
c243029
Compare
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
c243029 to
c3ef414
Compare
engdoreis
left a comment
engdoreis
left a comment
There was a problem hiding this comment.
Thanks @ziuziakowska for this great work.
I left some suggestions to be considered.
I believe that this a valid new test, and I don't see a reason for not running it on the FPGA and Silicon as well.
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
c3ef414 to
cb80798
Compare
This implements a I2C transport for QEMU. The transport uses a PTY to communicate with a `ot-i2c_host_proxy` device to issue transfers to devices on the internal QEMU I2C buses. See `docs/opentitan/i2c_host_proxy.md` in QEMU for more imformation on the protocol. Signed-off-by: Alice Ziuziakowska <[email protected]>
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
cb80798 to
c5397fb
Compare
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
c5397fb to
ed6c766
Compare
|
CI failure |
AlexJones0
left a comment
AlexJones0
left a comment
There was a problem hiding this comment.
I've left a last couple comments I noticed but this looks great, thanks!
|
CI failure looks unrelated. |
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
1ea7fc8 to
7e9be13
Compare
jwnrt
left a comment
jwnrt
left a comment
There was a problem hiding this comment.
I think this is good, thanks
If possible I'd appreciate a comment on the host side explaining that the 0x30 pointer is just some arbitrary location in the buffer and also that you're doing the try transactions out-of-order so that moving the pointer has some significance and it's not just following on from the previous write.
I think it might be clearer to me if you were to do two separate writes to different parts of the buffer instead of splitting one write, but I don't mind either way.
This creates a test for Opentitan's I2C target mode for QEMU, using a test harness that utilises the I2C QEMU transport implemented in the previous commit. The tested device emulates a simple "memory" device on each I2C bus. The device consists of a 256-byte "memory". On a write transfer to the device, the first byte sets the "pointer" to within the memory where subsequent bytes are written to or read from. This value is incremented after each written or read byte. During a read transfer, bytes from memory to be read are buffered in the TX FIFO, which is refilled if its fill level drops below a threshold. The test harness uses the I2C host proxy device in QEMU to issue transfers to write to and read from the emulated memory device. Signed-off-by: Alice Ziuziakowska <[email protected]>
Pulls in recently merged `ot-i2c_host_proxy` device. Signed-off-by: Alice Ziuziakowska <[email protected]>
ziuziakowska
force-pushed
the
qemu_i2c_target_mode
branch
from
7e9be13 to
4986eb4
Compare
|
CI FPGA failures are unrelated |
5 participants
This implements the I2C transport for QEMU in
opentitanlib, and creates a test of Opentitan's I2C target mode that uses the functionality in a test harness.In this test, a simple "memory" device is emulated by software, and can be interacted with over the I2C bus. The test harness performs transfers with the device, through the new OT I2C host proxy device in QEMU to interact with devices on the internal I2C bus, namely OT I2C. The software also listens to another I2C address, and exits the test successfully when written to with a magic value.
This depends on the I2C transport protocol and host proxy device implementation in QEMU - see lowRISC/qemu#190.
For now the test is QEMU-specific, but in theory this could also run on any other execution environments which already have an I2C transport implementation in
opentitanlib, with little adaptation.