Xunlong Orange Pi One & Lite

Orange Pi One is a H3 based development board produced by Xunlong. It's clearly Orange Pi PC's little/smaller sibling. Compared to the PC the following is different: smaller size, 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth), 2 USB host ports aren't exposed and the following is also missing: IR receiver, microphone and TRRS jack for Audio/CVBS video. Also Xunlong chose a different voltage regulator that requires software adjustments to get dynamic voltage frequency scaling (dvfs) working. Apart from that Xunlong tried to keep the One as compatible as possible to the PC so that all OS images for the PC work with the One with just one drawback: Non functional dvfs and most likely thermal problems -- see the compatibility section below.

= Identification = The PCB has the following silkscreened on it: Orange Pi One V1.1

= Sunxi support =

Current status
The H3 and Orange Pi One support is progressing nicely. It is possible to find a usable mainline 4.x kernel (plus some patches) and a legacy 3.4 kernel in various work-in-progress git branches. See the Manual build section for more details.

Manual build
You can build things for yourself by following our Manual build howto and by choosing from the configurations available below.

Mainline U-Boot
Use the orangepi_pc build target (supported since v2016.01-rc2) unless an orangepi_one target is available.

It can boot from the SD card or via FEL. Only the initial basic functionality is implemented and there are still no USB host and Ethernet drivers for H3 in U-Boot v2016.01 (it affects only u-boot functionality, device would work in linux as long kernel supports it).

Sunxi/Legacy Kernel
The 3.4 kernel from the official Allwinner's git repository does not support H3 yet. But it is possible to use one of the kernel forks, based on the lichee H3 SDK tarball:
 * Siarhei Siamashka's branch '20151207-embedded-lima-memtester-h3' at https://github.com/ssvb/linux-sunxi/tree/20151207-embedded-lima-memtester-h3
 * Yann Dirson's fork added a few more fixes and adopted most of Boris Lovosevic' great initial work on Allwinner's H3 kernel
 * On top of that Armbian has a bunch of 3.4.x patches for H3 devices: https://github.com/igorpecovnik/lib/tree/master/patch/kernel/sun8i-default

Configure this kernel using sun8i_h3_defconfig, the rest is explained in the kernel compilation guide.

Use the xunlong_orange_pi_pc.fex file for generating script.bin or Armbian's preliminary fex file for the One containing fixes for dvfs_table, cooler_table and the missing IR receiver and USB ports.

When booting the legacy 3.4 kernel with the mainline U-Boot, add the following line to boot.cmd:

setenv machid 1029

Mainline kernel
Initial H3 patches have been submitted to the mainline kernel, but have not landed yet. Currently you can find these patches in the arm-linux mailing list, or alternatively in one of the work-in-progress kernel forks:
 * Maxime Ripard's branch 'sunxi/for-next' at https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/log/?h=sunxi/for-next (very basic H3 support, without USB)
 * Hans de Goede's branch 'sunxi-wip' at https://github.com/jwrdegoede/linux-sunxi/tree/sunxi-wip (many work-in-progress patches, including H3 and USB support for it)
 * Siarhei Siamashka's branch '20151223-h3-mainline-smp-hack' at https://github.com/ssvb/linux-sunxi/tree/20151223-h3-mainline-smp-hack (minimal set of H3 patches, with USB and SMP)

Use the sun8i-h3-orangepi-pc.dtb device-tree binary unless a sun8i-h3-orangepi-one.dtb is available.

= Tips, Tricks, Caveats =

FEL mode
The Orange Pi One will fail over to FEL mode if it doesn't detect a card present in the µSD slot. There is no dedicated FEL button.

Compatibility
Since Xunlong doesn't provide new OS images users of Orange Pi One try to use images/settings for Orange Pi PC. While this seems to work and Ethernet and USB are functional the logs get flooded with "ARISC ERROR" messages due to a different voltage regulator (full log):

[ARISC ERROR] :message process error [ARISC ERROR] :message addr  : f004b840 [ARISC ERROR] :message state : 5 [ARISC ERROR] :message attr  : 2 [ARISC ERROR] :message type  : 30 [ARISC ERROR] :message result : ff [ARISC WARING] :callback not install [cpu_freq] ERR:set cpu frequency to 1008MHz failed!

On the Orange Pi PC the SY8106A is accessible through I2C and the H3's AR100 OpenRISC core tries to adjust the CPU core voltage (VDD_CPUX) this way. On the One a different voltage regulator is used: the SY8113B (datasheet) is a step-down converter that can adjust its output voltage driven by two resistors. According to Xunlong staff on OPi One this is used to switch between 1.1V at 624 MHz and 1.3V at every cpufreq above. Users that looked a little bit closer discovered that the similar AX3833 is used on the first batch of boards instead (see Gallery and link to datasheet below).

Normal dvfs settings
The following changes to the fex file should let the Vcore voltage jump between 1.1V at 648 MHz or below and 1.3V above 648 MHz (upper limit: 1200 MHz):

[cooler_table] cooler_count = 4 cooler0 = "1200000 4 4294967295 0" cooler1 = "1008000 4 4294967295 0" cooler2 = "816000 4 4294967295 0" cooler3 = "648000 1 4294967295 0"

[dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1200000000 min_freq = 648000000 LV_count = 2 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100
 * extremity_freq = 1296000000

Settings for overvolted Orange Pi Ones
On at least one board (tkaiser's) idle consumption jumps between 1.6W and 2.1W when switching between the two settings (more or less regardless of cpufreq settings) and temperature differs by 7-8°C without a heatsink applied. Which is a bad sign. After some further investigation it seems AX3833's Vout voltage might be significantly higher than expected (maybe both values 200mV above, so we're talking not about 1.1V/1.3V but ~1.3V/1.5V instead, the latter clearly exceeding H3's max specs).

Under these circumstances choosing fex settings that always remain at the lower voltage is necessary to prevent overheating:

[dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 1270 pmu_level1 = 1270 max_freq = 1200000000 min_freq = 648000000 LV_count = 2 LV1_freq = 1200000000 LV1_volt = 1270 LV2_freq = 648000000 LV2_volt = 1270

At the moment it's unknown how many boards are affected by the overvolted behaviour. The best idea is to use a Multimeter and check 1V2C and TP1 test points on the PCB for the real voltages used. In case you're affected follow the relevant discussion in the Armbian forum for news.

In case the SoC's internal temperature exceeds 80°C thermal throttling jumps in and starts to decrease the CPU core's clockspeed and if that doesn't help and the SoC's temperature reaches 90°C then CPU cores will be killed. At least in theory since these temperature readouts need some sort of calibration and the temperatures seem to be way off when using Allwinner's 3.4.x kernel together with mainline u-boot -- please see below.

From left to right: idle board switching between interactive and performance governor therefore jumping between 648 and 1200 MHz and also adjusting Vcore voltage. Then a sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4 run demonstrates thermal throttling and then cpuburn-a7 quickly killed cpu1, cpu2 and cpu3 since the SoC's temperature exceeded 90°C:



CPU clock speed limit
Xunlong advertises the "Orange Pi One" as being only capable of running at 'up to 1.2GHz'. Since the SY8113B/AX3833 voltage regulator should only be able to switch between 1.1V and 1.3V this would prevent clocking the SoC higher than 1200MHz according to the common comments in the FEX files from various H3 SDK variants:
 * dvfs voltage-frequency table configuration
 * pmuic_type:0:none, 1:gpio, 2:i2c
 * pmu_gpio0: gpio config.
 * pmu_levelx: 0~9999: voltage(mV), 10000~90000:gpio0 state. voltage form high to low.
 * extremity_freq(Hz): cpu extremity frequency when run benckmark or demo apk
 * 1536MHz@1500mV with radiator, 1296MHz@1340mV without radiator
 * max_freq: cpu maximum frequency, based on Hz, can not be more than 1200MHz
 * min_freq: cpu minimum frequency, based on Hz, can not be less than 60MHz
 * LV_count: count of LV_freq/LV_volt, must be < 16
 * LV1: core vdd is 1.50v if cpu frequency is (1296Mhz, 1536Mhz]
 * LV2: core vdd is 1.34v if cpu frequency is (1200Mhz, 1296Mhz]
 * LV3: core vdd is 1.32v if cpu frequency is (1008Mhz, 1200Mhz]
 * LV4: core vdd is 1.20v if cpu frequency is (816Mhz,  1008Mhz]
 * LV5: core vdd is 1.10v if cpu frequency is (648Mhz,   816Mhz]
 * LV6: core vdd is 1.04v if cpu frequency is (0Mhz,     648Mhz]
 * LV7: core vdd is 1.04v if cpu frequency is (0Mhz,     648Mhz]
 * LV8: core vdd is 1.04v if cpu frequency is (0Mhz,     648Mhz]
 * LV5: core vdd is 1.10v if cpu frequency is (648Mhz,   816Mhz]
 * LV6: core vdd is 1.04v if cpu frequency is (0Mhz,     648Mhz]
 * LV7: core vdd is 1.04v if cpu frequency is (0Mhz,     648Mhz]
 * LV8: core vdd is 1.04v if cpu frequency is (0Mhz,     648Mhz]

Wrong reported SoC temperature
It has been recently discovered that internal SoC temperature readouts in Allwinner's kernel 3.4.x (query /sys/class/thermal/thermal_zone1/temp for the value in degree Celsius) might be way off when combining the legacy kernel with mainline u-boot. The reason is yet unknown but until this issue is resolved you should be aware that this might affect thermal throttling negatively since real thermal values might be higher when the 'budget cooling' driver starts to throttle CPU clockspeed or even shuts cores down.

Think about applying a heatsink to the SoC. If you're using mainline kernel you should be rather safe since neither cpufreq scaling nor dvfs (dynamic voltage frequency scaling) is implemented yet and the SoC should run constantly at 1008 MHz at default voltage (to be confirmed).

DRAM clock speed limit
DRAM is clocked at 672 MHz by the hardware vendor. But the reliability still needs to be verified. One of the ways of doing reliability tests may be https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test (developed for Orange Pi PC first it checks the DRAM setup in the current mainline U-Boot v2016.01-rc2 + a bugfix).

LEDs
The board has two LEDs next to the 40 pin GPIO header:
 * A red LED, connected to the PA15 pin.
 * A green LED, connected to the PL10 pin.

When using kernel 3.4 with Xunlong's or loboris' settings then the LEDs can only be switched on/off. By changing the definition in the fex file (see patch or the aforementioned preliminary fex file for the Orange Pi One Armbian uses) both LEDs can be used the usual way (using different triggers and so on)

Camera module
Xunlong sells also a cheap 2MP camera (an attempt to fix the driver's limited resolutions can be found here). Unlike Orange Pi Plus/2 that can directly connect to the camera module for the Orange Pi PC/One/Lite an 'expansion board' is needed (see gallery below). If you order from Xunlong simply say that you need the camera for Orange Pi One and they ship camera together with the small board.

HDMI to DVI converters
When trying to use HDMI to DVI converters with Allwinner's 3.4.x kernel for H3/R16/A83T/H8/R58 a small fix has to be applied. The fex file has to be modified (and converted back to script.bin afterwards) so that the following has been added to the [hdmi_para] section: hdcp_enable = 0 hdmi_cts_compatibility = 1

Orientation of the GPIO header
Due to the position of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO connector by 180° so RPi HATs can still be used but will project over the board in the opposite direction than intended. Keep this also in mind when you want to power the board through GPIO pins 2/4/6 (2/4 being connected directly with DC-IN and 6 being GND)

Locating the UART
The UART pins are located next to the Ethernet jack. They are marked as TX, RX and GND on the PCB. Just attach some leads according to our UART Howto.

= Pictures =

= See also =


 * Xunlong Orange Pi site
 * Official Github Repository.
 * Official Orange Pi Form.
 * H3_Manual_build_howto
 * Schematic v1.1: [[File:ORANGE PI-ONE-V1_1.pdf]]
 * AX3833 datasheet: [[File:AX3833.pdf]]

OS images
At the moment there are no final dedicated OS image available for the Orange Pi One. Choosing those made for Orange Pi PC works but due to different voltage regulators on both boards cpufreq/dvfs stuff isn't working correctly and it's necessary to exchange script.bin or try to let the fix-thermal-problems.sh script fix script.bin contents. Armbian started to support all H3 based Orange Pi variants and you find already preliminary OS images trying to address the aforementioned issues for Orange Pi One.

= References =