Resources for the i96 OrangePi

I’ve put together a collection of information that may help get the OrangePi-i96 up and running. The documents include:

  • How to get the board past 2nd boot (for Debian and Ubuntu)
  • a wifi driver to keep the MAC address persistent
  • a replacement of the WiringPi/gpio command line tool
  • a script to fixup the GPIO pins on the i96 connector, to make them usable
  • documentation of pin assignments, Linux device driver numbers

You can find this stuff at

Let me know if this stuff is useful

1 Like

I have upgraded my opio tool (a clone of gpio) to fully support the OP-2G-IOT, as well as the OP-i96. You can find it at https://wiki.pbeirne.com/patb/opio

It worked. First using the gpio_fixup.py to initialize the gpio registers then “./opio readall” to get a the actual mapping.

+-----+-----+----------+------+-+ OrangePi i96 +-+------+----------+-----+-----+
| gpio| alt | i96 Name | Mode | V | Physical | V | Mode | i96 Name | alt | gpio|
+-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
|     |     | GND      |      |   |  1 ||  2 |   |      | GND      |     |     |
| 40  | CTS | UART2.CTS| alt  | ? |  3 ||  4 |   |      | PWR_BTN_N|     |     |
| 104 | TX  | UART2.TX | alt  | ? |  5 ||  6 |   |      | RST_BTN_N| 1.4v|     |
| 103 | RX  | UART2.RX | alt  | ? |  7 ||  8 | ? | alt  | SPI2.CLK | CLK | 2   |
| 41  | RTS | UART2.RTS| alt  | ? |  9 || 10 | ? | alt  | SPI2.DI  | DI  | 4   |
| 14  | TX  | UART1.TX | alt  | ? | 11 || 12 | ? | alt  | SPI2.CS  | CS  | 6   |
| 102 | RX  | UART1.RX | alt  | ? | 13 || 14 | ? | alt  | SPI2.DO  | DO  | 3   |
| 0   | SCL | I2C2.SCL | alt  | ? | 15 || 16 | ? | alt  | I2S.LRCK | LRCK| 10  |
| 1   | SDA | I2C2.SDA | alt  | ? | 17 || 18 | ? | alt  | I2S.BCK  | BCK | 9   |
| 38  | SCL | I2C3.SCL | alt  | ? | 19 || 20 | ? | alt  | I2S.DO   | DO  | 13  |
| 39  | SDA | I2C3.SDA | alt  | ? | 21 || 22 | ? | alt  | I2S.DI   | DI  | 11  |
| 15  | CTS | GPIO.A   | in*  | 0 | 23 || 24 | 1 | out  | GPIO.B   | LCD | 20  |
| 56  | ROM | GPIO.C   | out  | 0 | 25 || 26 | 1 | out  | GPIO.D   | CTS | 66  |
| 67  | RTS | GPIO.E   | in*  | 0 | 27 || 28 | 1 | out  | GPIO.F   | LCD | 22  |
| 30  | LCD | GPIO.G   | in*  | 0 | 29 || 30 | 0 | in*  | GPIO.H   | LCD | 29  |
| 28  | LCD | GPIO.I   | in*  | 0 | 31 || 32 | 0 | in*  | GPIO.J   | LCD | 27  |
| 26  | LCD | GPIO.K   | in*  | 0 | 33 || 34 | 0 | in*  | GPIO.L   | LCD | 25  |
|     | 1.8v| V_PAD    |      |   | 35 || 36 |   |      | SYS_DCIN | n/c |     |
|     | 5V  | VDD_IN   |      |   | 37 || 38 |   |      | SYS_DCIN | n/c |     |
|     |     | GND      |      |   | 39 || 40 |   |      | GND      |     |     |
+-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+
 Note: *these pins are set to GPIO mode but do NOT have exports in /sys/class/gpio

We just got 2x orangepii96 s and wanted to try it with our power-distribution-unit extension board Managed power distribution unit with 6 outputs, 0-60V mezzanine expansion kit for 96boards – Lightside Instruments AS

Ultra96 is what we use for our flagship product but that is an overkill for this.

After initially being startled by the second reboot hang and the gpio tool not supporting the board now with your post we definitely saved some hours and are much more optimistic.

1 Like

Good! I’m glad it helped out. Once you get the OrangePi-i96 configured, it’s quite stable. While I’m typing this, I have to i96 boards running in front of me with uptimes of >60days.

Promising. Have you tried building from source a complete image?

Also do you have a complete datasheet from Unisoc or did you use the kernel source to extract register addresses etc.?

I see you list the V_PAD (pin 35) as 1.8 V but the boards i have seem to be in the “3.3 V mode”. Did you figure how to change from 3.3 V to 1.8 V? I am just guessing this might work … there was nothing that indicated the board will be 3.3V 96boards IE. I would rather have a 1.8V one.

In any case if there is documentation that has answers to all these questions I think we might even develop a board ourselves that has for example onboard ethernet and is in the 96boards CE form factor.

/V

I found the chip datasheet in a posting on the OrangePi forum, : https://github.com/Testato/IOTphone/blob/master/Documents/RDA8810PL.Smartphone.Application.Processor.V1.04.pdf But honestly, I got most register locations from kernel-source and uboot-source.

The official i96 board/interface spec (40 pin connector) has the label on pin 35 as “+1V8”, so I used that as the label in the ‘opio’ program. However, the actual OrangePi-i96 boards that I have, that pin measures 2.8-2.9V. This agrees with the schematic (https://github.com/96boards/documentation/blob/master/iot/orangepi-i96/hardware-docs/files/orangepi_i96_v1_2-print.pdf)

I don’t think there’s much use of 1.8V power on this board. I don’t see any way to change the power rail (V_PAD) without screwing up a whole bunch of things.

I also found the “confidential” chip datasheet but it is far from being complete e.g. “3.10.3 Control Registers” has partial specification of the registers. There is nothing specifying how the bit order is mapped to the actual GPIOs. Seems one must use kernel/uboot source indeed to get the details needed.

I will try contacting Unisoc and see if they can require some sort of NDA to provide the complete documentation.

Yes it is not 3.3V but indeed 2.8V …

The V_PAD power domain and others (see 6.2.3 LDOs) is regulated by the internal regulators so it is either some internal flash or pin that is pulled up or down that determines that level. Seems that one can select between 1.8V mode and 2.8V mode of operation. The external 5V power source is converted stepped down to V_BAT (4.2V ) and that goes into the chip.

I am certain that these boards can be configured to run on 1.8V instead of 2.8V. I just do not know how. The Schematic on page 3 shows that the V_PAD power domain can be either 1.8V or 2.8 V.

Did you meanwhile found any solution on how to change between 1.8 and 2.8V I need it also…

The board starts with 1.8V which is later toggled to 2.8V. So If you stop the boot process you can measure 1.8V.

The question is if this change is done from the main or the base band processor. The followup question is if the baseband processor is documented somewhere.

I created a branch to the 3.10 vanilla kernel and added the source archive as patch. Should be exactly the same when checked out: https://github.com/vlvassilev/linux/tree/v3.10-orangepii96

In case someone wants to post any useful patches.

… same with u-boot: https://github.com/vlvassilev/u-boot/tree/orangepii96