A quick start to the Orange Pi 3B

Orange Pi 3B is a single-board computer with a Rockchip RK3566 (aarch64) and different RAM options (2GB, 4GB, 8GB). What sets this board apart is its builtin M.2 M-KEY slot port which can be used for SATA3 or NVME SSDs, so we don’t need to use the SD card. Everyone that have used Raspberry Pis for a while know that SD cards are always dying. Thus , having other storage option is a must to use a board like this 24/7.

Unfortunately, when we choose something else than a Raspberry Pi, we know that software support might not be the best. In this post, I hope to assist anyone who would like to use it, by discussing potential operating systems, and explaining how to use the GPIO, I2C and SPI interfaces outside the Orange Pi environment.

Operating systems

The Orange Pi company provides official images specifically tailored for their boards, which can be found here. However, I personally prefer using a standard OS or at least one not controlled by the hardware manufacturer. These companies tend to develop custom solutions rather than adhering to standard practices. Therefore, the ultimate goal is to make the board EBBR compliant.

EBBR, or Embedded Base Boot Requirements, is a subset of the EFI boot services that allows compliant devices to load standard distributions supporting EFI. The usability of the operating system will depend on the availability of drivers. The key to making a board EBBR compliant is to find the correct bootloader. The Orange Pi 3B ships with an older version of the U-Boot bootloader, specific to Rockchip SoCs, which does not implement EBBR. The mainline U-Boot bootloader supports EBBR, so if we are able to upgrade this bootloader, we achieve our goal. Basically, we need an U-Boot image for this SBC with the following configs enabled:

CONFIG_CMD_BOOTEFI=y
CONFIG_EFI_LOADER=y

The simplest way I found to retrieve and install an U-Boot image complying with this settings was to use Armbian. Armbian is an ultralight linux build specially for SBCs. This is a community-driven project and creates images based of Debian and Ubuntu. So, if we want a linux image that is not controlled by the hardware developer, Armbian is an option by itself.

To upgrade the default bootloader with Armbian, first we need to install the latest Armbian image on an SD card and boot into Armbian. After that is as simple as running armbian-config, select system and then choosing upgrade firmware . With this, our bootloader is upgraded, allowing us to load distributions that support EFI mode.

If your image doesn’t have the command armbian-config, you can install it by running sudo apt update && sudo apt install -y armbian-config.

After this, I was able to boot Fedora IoT 39 on this board by simply flashing a disk image with the correct architecture (aarch64) onto an NVME disk and inserting it into the Orange Pi 3B. You can use other distributions; however, the compatibility of components like Wi-Fi depends on driver availability. (In Fedora, the Wi-Fi wasn’t recognized.) The Orange Pi 3B utilizes a Motorcomm YT8531 Ethernet controller. Its driver was only included in kernel 6.3, so you should consider this when selecting a distribution.

Failed attempt: Before using the Armbian U-boot boot, I attempt to use a port of the EDK II for this family of CPUs. EDK II is a full UEFI implementation and I was able to boot several distros such as Fedora and Manjaro, however I wasn’t able to have the ethernet port recognized. This may have changed since the last time I tried but I didn’t repeat my experiments.

GPIO

The Orange Pi 3B documentation explains how to utilize the SBC’s 40 pin interface. However, it only targets a library created and maintained by the Orange Pi company for GPIO control, the wiringOP. While you are able to install this software on Armbian, most applications rely on libgpiod , the kernel’s GPIO library, to control these pins.

In libgpiod, a GPIO pin is represented by a channel in a GPIO controller. After analyzing the board schematic and conducting experiments, I was able to identify the mapping between pins and channels.

GPIO Controller	Channel	Name	Physical Pin	Physical Pin	Name	Channel	GPIO Controller
		3.3V	1	2	5V
/dev/gpiochip4	12	SDA2	3	4	5V
/dev/gpiochip4	13	SCL2	5	6	GND
/dev/gpiochip4	4	PWM15	7	8	RXD.2	25	/dev/gpiochip0
		GND	9	10	TXD.2	24	/dev/gpiochip0
/dev/gpiochip3	22	GPIO3_C6	11	12	GPIO3_C7	23	/dev/gpiochip3
/dev/gpiochip4	0	GPIO4_A0	13	14	GND
/dev/gpiochip4	2	TXD.7	15	16	RXD.7	3	/dev/gpiochip4
		3.3V	17	18	GPIO4_A1	1	/dev/gpiochip4
/dev/gpiochip4	10	SPI3_TXD	19	20	GND
/dev/gpiochip4	8	SPI3_RXD	21	22	TXD.9	9	/dev/gpiochip4
/dev/gpiochip4	11	SPI3_CLK	23	24	SPI3_CS1	6	/dev/gpiochip4
		GND	25	26	GPIO4_A7	7	/dev/gpiochip4
/dev/gpiochip1	0	SDA.3	27	28	SCL.3	1	/dev/gpiochip1
/dev/gpiochip4	5	RXD.9	29	30	GND
/dev/gpiochip3	28	GPIO3_D4	31	32	PWM11	16	/dev/gpiochip4
/dev/gpiochip3	31	GPIO3_D7	33	34	GND
/dev/gpiochip3	24	GPIO3_D0	35	36	GPIO3_D5	29	/dev/gpiochip3
/dev/gpiochip3	27	GPIO3_D3	37	38	GPIO3_D2	26	/dev/gpiochip3
		GND	39	40	GPIO3_D1	25	/dev/gpiochip3

I2C and SPI on armbian

The I2C and SPI buses exposed in the GPIO pins are not enabled by default. They can be enabled by applying a DTS overlay. I was able to enable both buses with the following overlays:

I2C bus overlay

/dts-v1/;
/plugin/;

&i2c2 {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&i2c2m1_xfer>;
};

SPI bus overlay

/dts-v1/;
/plugin/;



/ {
        fragment@0 {
                target = <&spi3>;

                __overlay__ {
                        status = "okay";
                        #address-cells = <1>;
                        #size-cells = <0>;
                        #cs-gpio = <0>,<0>;

                        spidev: spidev@0 {
                                status = "okay";
                                compatible = "armbian,spi-dev";
                                reg = <0>;
                                /* spi default max clock 100Mhz */
                                spi-max-frequency = <100000000>;
                        };
                };
        };
};

To enable these overlays you can run armbian-add-overlay <overlay_file.dts>.

It’s possible that by changing the driver used by spidev from armbian,spi-dev to rockchip,rk3066-spi, and adjusting the u-boot settings, both buses could be enabled in other operating systems. However, I haven’t had the opportunity to try it yet due to time constraints.