-
Notifications
You must be signed in to change notification settings - Fork 905
[sw,opentitanlib] QEMU I2C transport and target mode test #28450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[sw,opentitanlib] QEMU I2C transport and target mode test #28450
Conversation
6fbc024
to
4af129e
Compare
50b78e5
to
8ca242c
Compare
8ca242c
to
c243029
Compare
c243029
to
c3ef414
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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]>
cb80798
to
c5397fb
Compare
c5397fb
to
ed6c766
Compare
CI failure |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've left a last couple comments I noticed but this looks great, thanks!
CI failure looks unrelated. |
1ea7fc8
to
7e9be13
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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]>
7e9be13
to
4986eb4
Compare
CI FPGA failures are unrelated |
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.