Zephyr: I2C simulation in native_posix

[sjg20]

It looks like the i2c tests do not run on native_posix. This means that we need to use real hardware or qemu to run the tests. Of course I could be wrong as I am still learning about Zephyr.

Describe the solution you'd like
Would like i2c tests to run on native_posix.

Describe alternatives you've considered
Doing nothing, relying on hardware or qemu to run I2C tests.

Additional context
Something similar has been implemented in U-Boot. The device tree specifies the emulation drivers that are connected to a bus. WIth that it is possible to run a test of the I2C functionality on sandbox, U-Boot's equivalent of native_posix.

Emulation definitions:
https://github.com/u-boot/u-boot/blob/master/arch/sandbox/dts/test.dts#L389

Sample test:
https://github.com/u-boot/u-boot/blob/master/test/dm/i2c.c#L117

Sandbox I2C driver:
https://github.com/u-boot/u-boot/blob/master/drivers/i2c/sandbox_i2c.c

Thing that finds the emulator for a particular I2C device:
https://github.com/u-boot/u-boot/blob/master/drivers/i2c/i2c-emul-uclass.c

Emulator for an I2C EEPROM:
https://github.com/u-boot/u-boot/blob/master/drivers/misc/i2c_eeprom_emul.c

[carlescufi]

@sjg20 here is a current run-down of simulation of hardware using native_posix today in Zephyr:

• Bluetooth Low Energy uses BabbleSim with a set of hardware models that transform the hardware access to registers to send information to the BabbleSim simulator. (cc @aescolar)
• Flash access uses a simulated driver that can be used with fuse
• USB uses the Linux USB/IP subsystem to simulate a device

Not sure which approach is more appropriate in this case, but wanted to sum up the current options.

[aescolar]

Minor correction / expansion to @carlescufi list:

• In native_posix, peripherals are mostly mapped to real host HW, but some are just "emulated" (like flash being a file) :
  
  
  
  • Bluetooth Low Energy uses a real HCI adapted attached to the host
  
  
  • Ethernet is mapped to a TAP device
  
  
  • USB uses the Linux USB/IP subsystem to simulate a device
  
  
  • UART is mapped to a new pseudoterminal which is created when native_posix runs.
  
  
  • Display: is mapped to a SDL graphics window
  
  
  • Entropy: Is mapped to the host rand( )
  
  
  • Flash access uses a binary file in the host filesystem, that can be mounted from the Linux side (the driver provides FUSE access) while native_posix is running.
  
  
  • Time/RTC: can be mapped to the host timing with or without some drift & offset, or run fully decoupled
  
  

• In the nrf52_bsim: Peripherals are fully emulated:
  
  
  
  • The BLE controller HW is based on a nRF52 RADIO HW model which uses the BabbleSim physical layer simulation to communicate with other simulated BLE devices.
  
  
  • There is some other HW models of some other peripherals (PPI, TIMER, RTC, RNG, AES) and all live in a simulated world unrelated to the real host machine. (But no I2C)
  
  

Anyhow, depending on what you need and want to achieve you may want to build some emulated I2C driver which maps to some emulated I2C peripheral which you could configure to have compiled in or not(?)

[carlescufi]

Thank you @aescolar for all the extra info!

[sjg20]

I made a start on this based on I2C slave stuff I found already in Zephyr.

https://github.com/zephyrproject-rtos/zephyr/pull/26003/checks?check_run_id=743461426

I should mention that I am much more interested in fakes/emulators than in trying to connect to real hardware on the native_posix host, because my goal is testing as much code as possible,

[aescolar]

I should mention that I am much more interested in fakes/emulators than in trying to connect to real hardware on the native_posix host, because my goal is testing as much code as possible,

That is perfectly ok. There is different needs out there. Even if we were to already have some type of driver in native_posix that connects to real HW, we could still add a new driver for testing that has some funny backend, or viceversa. Drivers can be configured in or out as needed.

[sjg20]

Just an update on this. The I2C pull request died a death because the existing i2c slave feature is not what I thought it was. It requires special hardware with two I2C ports wired together and the test relies on that.

Instead I am working on a new, fairly simple emulation framework that is specifically targeted to running tests quickly in native_posix. For example, it allows writing an emulator for an I2C EEPROM and then using normal i2c calls to access it. The i2c_emul driver looks after finding the correct emulator and sending the I2C traffic to it.

@cfriedt FYI too

[sjg20]

Current discussion here:
https://github.com/zephyrproject-rtos/zephyr/pull/27300

[sjg20]

https://github.com/zephyrproject-rtos/zephyr/issues/27531 is a more general treatment of this one.

I think it is OK to close this one.