rreignier

Hi @rdeyes
 
On an Orange Pi One (which might be close to your Orange Pi PC), I have managed to get the OV5640 thanks to the amazing work of the contributors of this thread.
 
Last time I have tried was on Armbian 20.08.17 with Linux 5.8.16.
 
The device tree overlay I use is this one (you may have to change some pins) :
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; }; &ccu { assigned-clocks = <&ccu 107>; assigned-clock-parents = <&osc24M>; assigned-clock-rates = <24000000>; }; &pio { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; &i2c2_pins { bias-pull-up; }; &i2c2 { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu 107>; clock-names = "xclk"; AVDD-supply = <&reg_vcc_af_csi>; DOVDD-supply = <&reg_vdd_1v5_csi>; DVDD-supply = <&reg_vcc_csi>; reset-gpios = <&pio 4 14 1>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 0>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; &csi { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; };  
To enable it, I use this command:
sudo armbian-add-overlay csi-ov5640.dts And then, to take a picture:
media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:JPEG_1X8/1920x1080]' fswebcam -d /dev/video0 -r 1920x1080 -D 0 --jpeg 100 /tmp/test.jpg  
I hope this can help you and others.

I do not have the board with me right now, I will try later.
 
But yesterday, after a system update to Linux 5.10, the camera switched to /dev/video1 and I had to use this fork of fswebcam with these commands:
$ media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:YUYV8_2X8/1280x720]' $ ./fswebcam --displayfps 1 -S 30 -d /dev/video0 -r 1280x720 -p YUV420P - > /tmp/cam_1280x720_yuv420p.jpg  
And for reference, to use it with OpenCV I had to specify the size and format:
#include <iostream> #include <opencv2/opencv.hpp> int main(int, char**) { VideoCapture cap; cap.open(1, CAP_V4L2); if (!cap.isOpened()) { cerr << "ERROR! Unable to open camera\n"; return -1; } cap.set(cv::CAP_PROP_FRAME_WIDTH, 1280); cap.set(cv::CAP_PROP_FRAME_HEIGHT, 720); cap.set(cv::CAP_PROP_FOURCC, cv::VideoWriter::fourcc('Y','U','1','2')); Mat frame; // The first images might be black so take several before for(size_t i = 0; i < 10; ++i) { cap >> frame; } if (frame.empty()) { cerr << "ERROR! blank frame grabbed\n"; return -1; } imwrite("/tmp/opencv_frame.jpg", frame); return 0; }  

Thank you! That's the part that i was missing. 
Now i'm able to run ov5640 on OrangePiPcPlus with kernel 5.4.45. My dts: https://pastebin.com/gdQnnrxQ
/dev/video1 appears after reboot (no manual modprobe ov5640 needed). ov5640 for some reason does not leave any footprint in dmesg.
I've kept compatible = "allwinner,sun6i-a31-i2c" in i2c2@1c2b400 to be able to check chip id by i2cdetect. And nothing was working without compatible = "allwinner,sun8i-h3-csi" and other stuff inside csi@1cb0000.
 
Would be nice to pull the solution into official build (maybe as overlay)  . Ov5640 module is one of very few official orangepi accessories
 
 
according to https://linux-sunxi.org/CSI
media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY/1920x1080]' 1920x1080 and 1280x760 are working well for me
fswebcam -d /dev/video1 -r 1920x1080 -D 3 --jpeg 100 /mnt/sd/aaa.jpg --- Opening /dev/video1... Trying source module v4l2... /dev/video1 opened. No input was specified, using the first. Delaying 3 seconds. --- Capturing frame... Captured frame in 0.00 seconds. --- Processing captured image... Setting output format to JPEG, quality 100 Writing JPEG image to '/mnt/sd/aaa.jpg'.  

@MikePooh, I think there's still some schematic-reading involved at the moment, if you're willing to do that though it should be do-able. I don't know anything about other boards yet so this is the process followed. I think for "it just works" you'll need to wait a bit more. I'm assuming a lot here, e.g. active high and fixed-voltage gpio-switched regulators, so there is risk in following this.

The first step is getting i2c working, the driver won't be able to do anything until you can communicate with the camera. I'll use the h5 in my Orange Pi Zero Plus2 as an example but I believe the process should be identical for h3 boards. Looking at the schematic (https://linux-sunxi.org/images/f/f6/ORANGE_PI-ZERO-PLUS2_V1_0.pdf), on page 9 is the csi connector. We want AFCC_EN, CSI_EN and CSI-PWR-EN to be '1' to power the camera. They might be named differently on different boards, but generally you're looking for the ones that aren't connected to pins (on page 6,  chip U1D) with a CSI_* function (e.g. PE9/CSI_D5/TS_D5). I'm looking for AFCC_EN and CSI-PWR-EN which link to page 6. So AFCC_EN comes from pin PA7/SIM_CLK/PA_EINT7 and CSI-PWR-EN from PA8/SIM_DATA/PA_EINT8. We need to remember those PXX numbers.
 
rreignier said their camera was on the i2c1 bus, so we need to confirm that too. Following CSI-SCK and CSI-SDA from page 9 to page 6 reveals the i2c interface. CSI-SCK for me connects to "PE12/CSI_SCK/TWI2_SCK" and CSI-SDA to "PE13/CSI_SDA/TWI2_SDA". Maybe someone can confirm, but I think TWIx_SDA equals I2Cx. You can test by enabling the i2c bus overlays one after the other and running i2cdetect while measuring with a multimeter on low range (200mv) A/C voltage between ground and the SCK pin on the camera connector - the correct bus will generate a voltage for a short while. We need to remember that bus number.

Note the reset-gpios and powerdown-gpios the same way.

Next is the change to the device tree. In Armbian checkout the linux source  with "apt install linux-source-<kernel version>-current-sunxi" (or linux-source-<kernel version>-current-sunxi64 for h5) which will leave you with a tar in /usr/src of your kernel source. extract it (do it in a new folder or it will trash your current one) and then copy your kernel config in (cp /boot/config-* ./.config). Edit your .dts (./arch/arm/boot/dts/ for h3, ./arch/arm64/boot/dts/allwinner/ for h5) in line with my previous comment, swapping in your values for regulators, i2c bus and reset/powerdown. for a quick bodge, which pin goes in which regulator doesn't actually matter - my change just forced them all on anyway. As lex said, there's supposed to be an order, my change doesn't respect that order but it has worked so far. Then run "make dtbs" from the top level of the kernel source. That should produce a .dtb file in the same folder as the .dts.

backup your current dtb and copy the new one to /boot/dtb/allwinner/*.dtb (that's the h5 path, not sure of the h3 path sorry, might be /boot/dtb/). I think you can alternatively specify this as fdtfile in the armbianEnv.txt. The armbianEnv.txt way will probably survive an update better.

Finally, add a line to /etc/modules that says ov5640. Reboot and you might be good to go. If you don't have a /dev/video0 device we'll have to debug.

Obviously if I've got something wrong feel free to chip in.

Has anyone had success with resolutions other than 640x480? The driver seems to have some code for it, but I haven't gotten anything to work.

@rreignier, I've just gotten an ov5640 going with my Orange Pi Zero Plus2 at 640x480 on mainline, Buster 5.4.43 - maybe the following applies to you too.

I had bus locked errors until I powered up the camera, on the Zero it was PA8 and PA7 for autofocus (which I turned on just in case). Looking at the One schematic (https://linux-sunxi.org/images/7/7e/ORANGE_PI-ONE-V1_1.pdf) it looks like it's PA17, PG11 and PG13 for autofocus.

After that I still wasn't getting an answer on i2c2, the ov5640 datasheet (https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf) says XVCLK (CLK_CSI_MCLK in the device tree) needs to be running before accessing registers. I couldn't see an a/c voltage on the csi-mclk pin so figured that was the issue. The fix for me was connecting the clock parent in the device tree. I'll post my dtb changes. I'm not sure this is all correct, but it lets me open the camera without having to mess with any gpios etc after boot.

Inside the "model = "OrangePi Zero Plus2";" braces:
reg_vdd_1v5_csi: vdd-1v5-csi { compatible = "regulator-fixed"; regulator-name = "vdd1v5-csi"; regulator-min-microvolt = <1500000>; regulator-max-microvolt = <1500000>; gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_csi: vcc-csi { compatible = "regulator-fixed"; regulator-name = "vcc-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 8 GPIO_ACTIVE_HIGH>; /* PA8 */ enable-active-high; regulator-boot-on; regulator-always-on; }; reg_vcc_af_csi: vcc-af-csi { compatible = "regulator-fixed"; regulator-name = "vcc-af-csi"; regulator-min-microvolt = <2800000>; regulator-max-microvolt = <2800000>; gpio = <&pio 0 7 GPIO_ACTIVE_HIGH>; /* PA7 */ enable-active-high; regulator-boot-on; regulator-always-on; }; At top level:
&ccu { /* Use a stable clock source with known fixed rate for MCLK */ assigned-clocks = <&ccu CLK_CSI_MCLK>; assigned-clock-parents = <&osc24M>; assigned-clock-rates = <24000000>; }; &csi { status = "okay"; port { #address-cells = <1>; #size-cells = <0>; /* Parallel bus endpoint */ csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; &i2c2_pins { bias-pull-up; }; &i2c2 { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <&reg_vcc_af_csi>; DOVDD-supply = <&reg_vdd_1v5_csi>; DVDD-supply = <&reg_vcc_csi>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; I also added csi_mclk_pin to sunxi-h3-h5.dtsi (after "csi_pins: csi-pins {") but I suspect you could reference the pin directly in the dtb and skip this:
/omit-if-no-ref/ csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; I'm currently having issues with only being able to use 640x480, vlc reporting incorrect frame size and crashes when streaming from motion, but I don't want to derail your thread unless you have the same issues.

Hope that helps,
Greg

OV5640 is ready and works in mainline kernel.
/dev/video0 will be created if the driver can find the sensor using the i2c line (generally speaking).
 
You can check the schematic of your board if the sensor is attached to i2c. Compare it to NanoPi Neo Air schematic and you will see the nuances.

Even with a working camera on 3.4.113 there's not any indication something is happening on i2c:
 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@drone:~# i2cdetect -y 0      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --  
 
 
 

According to https://cateee.net/lkddb/web-lkddb/VIDEO_OV5640.html the OV5640 is in mainline since 4.13 so any earlier implementation must have been custom.

Hi!
 
Now that the camera interface has been merged in mainline Kernel, I would like to try to use the OrangePi OV5640 camera module on my OrangePi One.
So with the latest Armbian Bionic (20.02.1, kernel 5.4.20), I have been trying to get a device tree overlay.
 
But for now, it fails to compile with:
$ sudo armbian-add-overlay sun8i-h3-csi.dts Compiling the overlay Error: sun8i-h3-csi.dts:27.23-24 syntax error FATAL ERROR: Unable to parse input tree Error compiling the overlay My current overlay looks like this:
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <&reg_aldo1>; DOVDD-supply = <&reg_dldo3>; DVDD-supply = <&reg_eldo3>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; fragment@2 { target = <&csi>; __overlay__ { status = "okay"; port { csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;`
 
Also, according to the documentation, the regulator fields are required but this board does not have much regulators (like AXP209), so I have no idea what to write here.
 
But this is my first time writing a device-tree overlay so I am not sure what is wrong with this line.
 
Could someone guide me to get my overlay right?
 
And, does anyone already got the CSI interface working with OV5460 sensor on a H3 based board?
 
Thank you.

Possible.
 
I don't have the board but can assist in bringing things together if there is an interest. 

Hi,
 
I am not an expert in that domain, but I am also interested in RS-485 communication on Allwinner based SBC.
For your information OMAP is a series of CPU for Texas Instrument, so the OMAP UART driver is only used on these CPUs. The BeagleBone Black is made of an OMAP processor for example.
 
What I found is that RS-485 drivers only exists for few devices likes the AT91 series from Atmel, OMAP serias from Texas Instruments, i.MX28 series from Freescale (now NXP)...
 
One solution is to use the RTS signal of the UART to drive the RS-485 direction. But I have measured a 3 ms delay for the turnaround on a H3 based Orange Pi One, that delay is too big for my application.
 
So I am finally using a USB-RS485 adapter from Devantech which manage the RS-485 direction automatically. I did not measured the turnaround yet but it worked well for my tests and they advertise a 3uS delay turnaround. But note that this module cost two times the price of my Orange Pi One
http://www.robot-electronics.co.uk/htm/usb_rs485_tech.htm

Same way like above it is easy to expand OPiOne adding missing analog audio, mic and IR receiver.
1 - IR receiver RX line
2,3,4 - MIC1P/MIC1N/MIC-MBIAS
5,6 - LINEOUTR/LINEOUTR
Look at Orange Pi PC schematics to find out what extra components should be used to obtain full OPiPC functionality.

Small update or let's better say a quick look at the direct competition:
 
Banana Pi M2+:
 

 
65x65mm in size, GBit Ethernet, 1 GB RAM, AP6212 WiFi/BT (unlike the Orange's WiFi chip this is already supported with mainline kernel), 8 GB eMMC (they already said they might remove this for a cost down variant). Unfortunately not all 3 USB host ports exposed and still relying on the crappy Micro USB connector to power the board.
 
EDIT: build system prepared for M2+ 3 days ago and M2+ maybe fully supported starting with Armbian 5.05 
 
H3-OLinuXino-NANO:
 

 
Only 50x50mm in size, Fast Ethernet, 512 MB RAM (maybe 1 GB as option/later), also not all 3 USB host ports exposed and using Micro USB for DC-IN
 
Prices/availability yet unknown.
 
Olimex chose to use a fixed voltage on the H3-OLinuXino-NANO so max. cpufreq depends on that (they're still testing). So most probably Orange Pi One will be faster (at least memory bandwidth is 32-bit vs. 16-bit).
 
Regarding Banana Pi M2+ I would be careful unless it's confirmed if/how the CPU's voltage is regulated there and whether they managed to implement a few more design flaws as they did with their last boards.
 
The good news: Since we're already supporting H3 with Armbian only minor modifications should be necessary to support these 2 new boards when they're available.

The Orange Pi One is the most recent SBC from Xunlong. It's clearly the Orange Pi PC's little sibling. In case you haven't read the PC's review already maybe it's time to do it now since here only important differences will be shown.
 
Since it's based on an Allwinner SoC (system on chip) please keep in mind that you will always find the most comprehensive and up-to-date information in the linux-sunxi wiki: http://linux-sunxi.org/Orange_Pi_One
 
The most important differences between One and PC as follows:
Smaller size: the PC used the RPi form factor (85mm x 55mm) while the One is just 69mm x 48mm in size 512MiB instead of 1GiB DRAM (still two DDR3L modules making use of the full 32 bit memory bandwidth) 2 USB host ports less (available through solder points) IR receiver, microphone and TRRS jack for Audio/CVBS video also missing (available through solder points) GPIO header rotated by 180° A different method to regulate the SoC's core voltage (VDD-CPUX) responsible for a few issues currently The One costs $10 whereas the PC is been sold at $15. Since you don't get large volume discounts on shipping you should better compare prices with shipping included and end up now with $13.63 vs. $18.69 if you order directly in Xunlong's aliexpress store.
 
So you get less for less money but should keep in mind that the size reduction has one serious drawback: Due to the height of USB and Ethernet jacks Xunlong chose to rotate the 40 pin GPIO header and now Add-On boards (RPi HATs) project over the board. And while you can combine for example an Orange Pi PC with a 3.2" Touchscreen LCD to a compact package this isn't possible with the One any longer.
 
The Orange Pi PC fits exactly:
 

 
And that's how it looks with the One:
 

 
You should also take care of the header's orientation when trying out GPIO/1-Wire/I2C stuff and especially when you try to power the board through GPIO pins 2/4/6. They are not where you would expect them like on any other board using the RPi connector (except of Lamobo R1) but on the other side of the header (180° rotation).
 
Different voltage regulator and the consequences:
 
Now to the most important change: the different method to switch the SoC's core voltage. What is this switching for? This thing is called dynamic voltage frequency scaling (dvfs) and the idea behind is to keep the voltage of the SoC's core components as low as possible unless needed. If you want to clock the CPU/GPU cores higher you need more voltage to let them work reliably. On the other hand higher voltage negatively affects temperature, consumption and maybe also longevity.
 
Here the combination of cpufreq scaling and dvfs jumps in. When the CPUs are clocked lower also less voltage is used to feed them. And when they're clocked higher the voltage rises automatically to ensure reliable operation. With dvfs a few operating points are defined that specify at which cpufreq traversal which voltage should be used. This looks then like this example for Orange Pi PC.
 
On the Orange Pi PC a voltage regulator called SY8106A adjustable through I2C is used and it's easy to define up to 16 dvfs operating points. On the Orange Pi One this is different and a more simple voltage regulator has been used (according to schematic the SY8113B should be used but users spotted that on their boards in reality the rather similar AX3833 is used). This voltage regulator supports only two states and according to the Orange Pi forums this should be used to switch the voltage between 1.1V at the lowest CPU clockspeed and 1.3V with the higher clockspeeds (confirmed in the meantime to work on at least one board).
 
Fex/script.bin fixes necessary when using OS images for PC:
 
When you're using OS images for Orange Pi PC on the One then due to the different voltage regulator the log gets filled with countless messages like this:
[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! Therefore it's necessary to fix this by tweaking the so called fex file when using OS images that still rely on kernel 3.4.x (applies to all currently). It's necessary to exchange the pmuic_type (2 is I2C, 1 is GPIO) and to define at which clockspeed the regulator should switch between its two states. So the most easy solution seems to define 2 operating points as outlined in the sunxi wiki: http://linux-sunxi.org/Orange_Pi_One#Normal_dvfs_settings
 
At least on one board the real voltages used aren't 1.1V and 1.3V but significantly higher instead. My assumption is based on thermal behaviour: the main heat source is the core voltage (VDD-CPUX). Unfortunately my Multimeter died so we're waiting for others to investigate further by checking the 1V2C and VDD_CPUFB test points on the PCB. There is an active discussion in our developer section regarding this at the moment.
 
So there is at least one board where voltages are significantly higher then they should be (leading to overvolted/overheating behaviour without adjusted fex settings) and there is at least another where everything works as expected (and which runs into stability issues when preventing to switch to the higher voltage). Now it's time to collect feedback from users how many are affected by wrong voltage values.
 
How does voltage switching works on the One?
 
So let's have a closer look how the switch between the two voltages works (regardless of the real voltages used -- they have to be confirmed by measuring the 1V2C and TP1 test points on the PCB). In the fex file after changing the pmuic_type to 1 you can define two voltage values and the switch state:
pmu_level0 = 11300 pmu_level1 = 1100 LV1_freq = 1200000000 LV1_volt = 1300 LV2_freq = 648000000 LV2_volt = 1100 This reads like 648MHz @ 1100mV and 1200MHz @ 1300mV. But you could also write the following into and it would work exactly the same:
pmu_level0 = 15000 pmu_level1 = 1500 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 1500 Now it reads 648MHz @ 1500mV and 1200MHz @ 5000mV (clearly exceeding the max. 1400mV allowed for the H3) but it doesn't matter since this just triggers at which cpufreq change the voltage should be switched between the lower and the higher value. So to stay always on the lower voltage you could use
pmu_level0 = 5000 pmu_level1 = 5000 LV1_freq = 1200000000 LV1_volt = 5000 LV2_freq = 648000000 LV2_volt = 5000 And to always use the higher voltage (necessary in case some users are really affected by undervoltage when using the lower available) it could read:
pmu_level0 = 11000 pmu_level1 = 11000 LV1_freq = 1200000000 LV1_volt = 1000 LV2_freq = 648000000 LV2_volt = 1000 This will prevent using the higher voltage in the former case even if there 5000mV are written to the fex and will force the higher in the 2nd example regardless of the voltage value (1000mV). Only the first bit set or not defined in pmu_level0/pmu_level1 is important.
 
Unless this issue is resolved I would stay away from the device. And if you're already an owner of the Orange Pi One you should check whether you're affected by undervoltage/overvoltage issues.
 
Final chapter: Software support for the Orange Pi One:
 
First of all you could use any of the available OS images for Orange Pi PC but would've to adjust the voltage regulator stuff in script.bin/fex. I already updated my fix-thermal-problems.sh script known from the Orange Pi forums to fix overvolted settings for the older Orange Pis to be useable with Orange Pi One/Lite too.
 
In the meantime Armbian started to support all available H3 Orange Pi boards just recently: http://www.armbian.com/download/ (please don't expect yet too much, we're moving fast but it's still a bit early and a lot of work in progress!)
 
Jernej's OpenELEC port also progresses nicely and fully supports Orange Pi One in the meantime (in fact he helped us a lot to improve Armbian support for the One)
 
It can be expected that a lot of improvements for sun7i (A20 SoC used on Cubieboards, the original Bananas and a few more) will be ported over to sun8i/H3 in the next time.
 
And then mainlining effort for the H3 is still improving more and more. I'm using one Orange Pi PC since weeks as NAS with mainline kernel (4.5) and an USB-to-Ethernet dongle since native Ethernet is still not supported. Same applies to display stuff. You can inform yourself about the status always here: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress
 
Using Orange Pi One with the most recent kernel is already possible combining a few patches and I would suspect that it's just a few weeks until Ethernet and display is working.
 
EDIT: In the meantime enclosures are available (a bit problematic since OPi One suffers from heat issues more than its bigger siblings): laser cut DIY made of 3 mm crystal-clear acrylic and one on Aliexpress.

Cmd for gpio
 
cd /sys/class/gpio
echo X > export
echo out > gpioX/direction
echo 1 > gpioX/value

Regarading Mali at least I did not spend a second on this since our focus was to get a stable base first. When you're really using h3-lichee-1.0.tar.gz you should better walk through all commits made by ssvb/yann|work, maybe the kswapd issue is gone away afterwards.
 
 
Ok, both are signs that files/settings are missing. I forgot yesterday to update orangepione.bin in the test image so please replace /boot/bin/orangepione.bin with http://kaiser-edv.de/tmp/4U4tkD/orangepione.bin
 
The thermal values you get are a clear sign that patching RPi-Monitor's config went wrong. Please do on the Wheezy image the following:
/etc/init.d/rpimonitor stop cd / && wget -O - http://kaiser-edv.de/downloads/RPi-Monitor-for-H3.tgz | tar xzf - update-rc.d rpimonitor-helper defaults 90 10 cd /tmp && nohup /usr/local/sbin/rpimonitor-helper.sh & /etc/init.d/rpimonitor start (this is no general advice useful for others since on Jessie/Trusty the commands look slightly different. The installation script should care of this and I don't know why it didn't work. I updated the script and redirect now installation messages to /var/log/rpi-monitor-install.log so the next one having difficulties can send me the log)
 
The output from cpufreq-ljt-stress-test clearly shows thermal throttling (skipped operating points) and also your CPU cores were shut down due to overheating (reaching/exceeding 90°C). Which is interesting since the results posted before look quite different: http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/?p=5420
 
Please patch RPi-Monitor as outlined above, replace orangepione.bin, check whether (the 2nd) reboot then works and try @jmarcelino's approach to run sysbench in parallel and try out cpufreq-ljt-stress-test again. Then a look at graphs would be helpful

Dear users,
 
you owe us a test!
 
Please have a look at http://linux-sunxi.org/Orange_Pi_One#DRAM_clock_speed_limit
 
It's important to collect data from as much different OPi One as possible. So in case you've another Linux host (might be a small SBC for example like another Orange Pi  ) then please read through the steps, download and extract fel-boot-lima-memtester-on-orange-pi-one-v3.tgz and test your OPi One through FEL boot. You just need another Linux host and an Micro USB cable to be able to use FEL mode. When you're finished please submit your results to the linux-sunxi wiki. Thx!

@tkaiser
Thanks so much for your guidance! Really appreciate it - I may owe you a few beers if you're around Nuremberg :-)
I will follow the steps you suggested this afternoon and report back.
 
This morning I was looking around the board for test points and noticed that while there's lots of mentions of the regulator being a SY8113, the chip on my One didn't match the markings on the datasheet (top mark should be MLxyz, mine is WC5V1)
 
After a bit of smd marking detective work I found out that the regulator on my board is actually an AX3833: http://www.micro-bridge.com/data/Axelite/AX3833.pdf
 
At first glance they seem very similar in specs so maybe 100% compatible, but I wonder if this could explain the differences in operation. Could you check which chip yours' has? Here's a photo of mine:
 

Maybe it's a good idea to enable this by default on the H3 images unless we consider them stable? And maybe adding "disp.screen0_output_mode=10" to boot.cmd (see new pull request)

Yes, just checked, something like this should work
Make backup of you existing /boot/dtb/sun7i-a20-pcduino3-nano.dtb
Decompile:
dtc -I dtb -O dts /boot/dtb/sun7i-a20-pcduino3-nano.dtb -o /tmp/temp.dts Edit /tmp/temp.dts:
Add uart2_pins_a label
uart2_pins_a: uart2@0 { allwinner,pins = "PI16", "PI17", "PI18", "PI19"; allwinner,function = "uart2"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; }; Change serial section:
serial@01c28800 { compatible = "snps,dw-apb-uart"; reg = <0x1c28800 0x400>; interrupts = <0x0 0x3 0x4>; reg-shift = <0x2>; reg-io-width = <0x4>; clocks = <0x2a 0x12>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&uart2_pins_a>; }; Compile it back (assuming you are using non-root user):
sudo dtc -I dts -O dtb /tmp/temp.dts -o /boot/dtb/sun7i-a20-pcduino3-nano.dtb