Unlike the Raspberry Pi that hides the I2C bus used internally for recognizing extension boards (HATS), the two buses used internally by the Orange Pi PC 2 for managing on-board resources are visible yet not available for use. Armbian Bionic comes with overlays to enable three additional I2C controllers. The first two correspond to the physical buses available on the 40 pin GPIO header, just as on the Raspberry Pi. The third is used for the camera serial interface (CSI).

Table of Contents

1. Default I2C Configuration
2. Enabling the i2c0 Controller
3. Enabling the i2c1 Controller
4. The i2c2 Controller and the Camera Serial Interface (CSI)
5. Enabling the DS1307/DS3231 driver on i2c1 with a Custom Overlay

Default I2C Configuration

The Allwinner H5 SoC has up to 4 I2C controllers according to the TWI overview found in the Allwinner H5 Datasheet (page 49).

2.2.9.6. TWI

• Up to 4 TWI(Two Wire Interface) controllers
• Supports Standard mode(up to 100K bps) and Fast mode(up to 400K bps)
• Master/Slave configurable
• Allows 10-bit addressing transactions
• Perform arbitration and clock synchronization
• Allows operation from a wide range of input clock frequencies

Remember that TWI (Two Wire Interface) is the same thing as I2C (Inter-Integrated Circuit). The GPIO map shows that two physical I2C buses are available on the same pins of the 40 pin header as on Raspberry Pi models with a 40 pin header. Physical pins 3 and 27 are the data lines (TWI0_SDA and TWI1_SDA respectively) and pins 4 and 28 are the clocks (TWI0_SCK and TWI1_SCK respectively).

On a fresh install of the Raspbian Bionic there were two i2c devices present in the /dev directory. After installing the i2c-tools package, it was possible to check for connected I2C devices.

The results were surprising because there were two devices connected to PA12 and PA11 (physical pins 3 and 5), which I thought would be controlled by i2c0, but the addresses (0x30, 0x32 and 0x59) were wrong. As for bus 1, I had no clue what could be at 0x65, but the address was probably correct since UU indicates the presence of a driver. A look at loaded modules gave some information

A Web search led to a 2013 commit in the Linux repository with a hint of what the module does.

The SUNXI wiki Xunlong Orange Pi PC 2, CPU clock speed limit about the OPiPC2 had some information about I2C address 0x65. "The Orange Pi PC 2 board uses the SY8106A voltage regulator (U9) for providing the CPU core voltage (VDD_CPUX, nominally 1.2V at 6A). The default CPU voltage is 1.1V after power-on (selected by the resistors on the PCB) and can be changed at runtime by software via I2C interface (I2C address 0x65)." Looking into the voltabe regulator, the only register that I dared attempt to read was its status register, expecting a value of 0x01.

However, I did not get very far.

While removing the rtc_ds1307 module in order to read the temperature of the DS3231 real time clock had worked on the Raspberry Pi, I was clearly out of luck here. That's that, time to move on to the other I2C bus. Here's what I found about i2c-0 by listing the I2C bus devices and pertinent startup messages.

According to SUNXI, the Allwinner H3 SoC uses a Synopsys DesignWare HDMI controller. Furthermore, "...H5 is basically an Allwinner H3 with the Cortex-A7 cores replaced with Cortex-A53 cores." Presumably, the OPiPC2 also has a Synopsys DesignWare HDMI controller which the startup messages appear to confirm. What can also be seen is that there is an I2C bus driver connected to the i2c-0 controller. By the way, the drm in the sun4i-drm display engine stands for Direct Rendering Manager, a subsystem of the Linux kernel interfacing with the GPU, not for Digital Rights Management. So it certainly looks like i2c-0 controls another internal I2C channel.

It would probably be best to avoid poking both these internal I2C buses given the warning in the i2cdetect man page:

Warning
This program can confuse your I2C bus, cause data loss and worse!

Fortunately, no OPiPC2 were harmed in the making of this post.

Enabling the i2c0 Controller

The system configuration utility, can be used to enable the i2c0 controller.

Select System (System and security settings) then Hardware (Toggle hardware configuration: UART, I2C, etc. and finally mark i2c0 for installation. Notice that there are 3 I2C device tree overlays that can be enabled. Basically, the utility adds an entry in the configuration file /boot/armbianEnv.txt. Accordingly, it is possible to activate the wanted device tree overlay by including it in the configuration file (see Device Tree overlays in the Armbian User Guide Documentation).

No matter which way is used to activate the I2C controller, it will be necessary to reboot. When that is done, look for connected devices on i2c-0.

The two devices connected to physical pins 3 and 5 of the 40 pin header assigned to the i2c-0 controller are found at the correct addresses.

• 0x57: AT24C32 EEPROM
• 0x68: DS3231 Real time clock.

The physical module with these two devices was discussed in detail when installed on a Raspberry Pi. I wanted to replicate the read and write to EEPROM test done in that post but I ran into a couple of difficulties. The first was easy to fix: add the default user to the i2c group that was created when i2c-tools was installed, to avoid the need to resort to the sudo command all the time when dealing with the I2C bus.

The second problem was a **** stack smashing detected *** error each time I tried running the eeprog program. All discussions of "stack smashing" talked of buffer overruns which sent me on a futile search for buffers in the source code. Trying to locate the latest version of the original branch of eeprog, I found a fork of version 0.7.6 by Alvin Wang with one change in the 24cXX.c source code that fixed the problem. Here is how to install and fix the "tear" version of eeprog in the same manner.

In the editor change the first line of the eeprom_open function.

to

What I think is going on is that ioctl(fd, I2C_FUNCS, &funcs), called in eeprom_open, returns a 64 bit list of functions in Armbian Bionic which is a 64 bit OS but an int is 32 bits. The problem did not occur in Raspbian Buster which is still a 32 bit system. After that fix, it was possible to carry on as with the Raspberry Pi.

Since there is a real-time clock on the H5 SoC which is enabled in the kernel and there does not seem to be a real-time clock overlay equivalent to i2c-rtc found in Raspbian, hwclock cannot be used to acces the DS3231 (this is not an accurate statement and, as shown further on, an rtc overlay can be installed.) It was easy to read and write the real time clock registers with some i2c-tools utilities: i2cdump and i2cset.

This corresponds to the time 00-01-01 00:03:18. Let's change the year and dump the RTC registers again.

The time was changed to 22-01-01 00:08:14 so that clearly the year had been updated without problem.

Enabling the i2c1 Controller

It was easy to check that i2c1 controls the hardware I2C bus on pins 27 and 28 of the 40 GPIO header by connecting the RTC/EEPROM module to those pins (SDA to pin 27, SCL to pin 28). This is the modified configuration file.

After rebooting, I checked all I2C buses.

As before, the internal I2C controllers are assigned higher bus numbers because of the I2C controllers added with overlays. It was a simple matter to check that the EEPROM on bus 1 could be accessed.

This time I used an updated version of a rtc Python script to verify that it was possible to read and write to the DS3231 on bus 1.

The i2c2 Controller and the Camera Serial Interface (CSI)

Here is the part of the description file pertaining to I2C overlays.

While the main reference for the OPiPC2 hardware does describe the camera serial interface (CSI), it does not specify the I2C controller used nor the GPIO pins. The schematic does show that pins PE12 and PE13 of the H5, identified as PE12/CSI_SCK/TWI2_SCK and PE13/CSI_SDA/TWI2_SDA are connected to CAM-SCK and CAM-SDA (pins 4 and 3 of the CSI connector).

I was hoping to use a Raspberry Pi camera to test the I2C - CSI connection on the OPiPC2 but a discussion on the Orange Pi Forum, How to Interface Raspberry Pi Camera on Orange pi, and a related Hackaday entry: Raspberry Pi camera on Orange Pi Plus board. Convert MIPI CSI-2 2 lanes into DVP using a FPGA. considerably diminished my hopes. They were completely dashed when it became obvious the camera cable did not fit in the OPiPC2 CSI connector. Nevertheless, I enabled the I2C bus and proceeded with the usual detection of the I2C buses.

As before there are two more I2C buses beside the three enabled with device tree overlays.

Strangely i2cdetect -y 2 took more than four minutes to complete the bus scan.

Unfortunately, I could not investigate this I2C hardware bus any further.

Enabling the DS1307/DS3231 driver on i2c1 with a Custom Overlay

Among the example custom overlays in the Armbian Github repository, there is one named i2c-ds1307.dts which can be installed following the Armbian User Guide instructions. Preparing for that, I cutdown on the number of I2C controllers, installing only i2c1. Here is the content of the /boot/armbianEnv.txt file.

After rebooting, there were three I2C devices.

I created a directory and copied the overlay source file to it.

I changed the alias to set the DS3231 as device rtc1 instead of rtc0 so that hwclock can read/write both the DS3231 and the built-in real-time clock.

If the hardware clock was to be connected to the PA12 and PA11 I2C bus and appear as rtc3 in the /dev directory then the "alias" fragment should be rtc3 = "/soc//i2c@1c2ac00/ds1307@68";. Of course, the i2c0 parameter would have to be included in the overlays line of the /boot/armbianEnv.txt configuration file.

The overlay had to be compiled and the system then had to be rebooted.

A first check of I2C buses, loaded kernel modules and rtc devices after the reboot was very encouraging.

The following shows that the system utility hwclock can be used to read or set the time of both the external DS3231 real-time clock and the internal real-time clock.

As far as I know, armbian-add-overlay compiles i2c-ds1307.dts to /boot/overlay-user/i2c-ds1307.dtbo and added the user_overlays line in /boot/armbianEnv.txt.

So to remove the overlay, I deleted the compiled dtbo file, leaving an empty /boot/overlay-user/ directory, and I removed the user_overlays=i2c-ds1307 line in /boot/armbianEnv.txt file. After rebooting, /dev/rtc1 was gone.

The armbian-add-overlay compiler will not add the overlays=i2c1 to the configuration file on its own. This must be done manually as shown above.