tkaiser

I agree. And I would also think about controlling the LEDs by us to provide user feedback at least the 1st time an image is booted. For the H3 boards we implemented it now this way:
red led constant on from the moment when u-boot starts as an 'it works' indicator when firstrun is active then we let the red led blink through sysfs ('there's something going on!' indicator) after the first reboot we do the same with the green led. Let it blink for 30 seconds unless the user logged in at least once, after this it only blinks for 3 seconds to not annoy users that much I had the hope we get some feedback from Orange Pi users (but it seems most of them just download and forget) and wanted to discuss this behaviour internally if the majority of 'user grade' boards feature at least a green and a red led (we won't need that 'led user feedback' stuff for ie. the Clearfog -- there the users should be able able to read documentation and stay patient for at least 3 minutes)

Yes, if you have a local working copy of kernel repository, you just make necessary adjustments and execute in repository root directory
git diff <path> specifying path for git diff reduces time needed for finding changed files, especially in huge repositories
for example
git diff arch/arm/boot/dts > leds-for-bananapro.patch You can fork and make a pull request for Igor's repo, but some triggers (especially heartbeat) are quite annoying with bright SMD LEDs to have them by default.

Orange Pi One PCB is designed to easy add almost all removed features from Orange Pi PC. Currently only RAM expansion is unprofitable.
To add 2 removed USB ports just solder wires to solder points as shown below on the photo:
Data lines for USB #3: points 1,2
Data lines for USB #2: points 3,4
Power can be taken directly from GPIO header or DC socket. OPiOne has no separate voltage regulators for USB ports like previous boards used to have.
This way I want to solder mini WiFi dongle (after removing the case and USB port) directly to the PCB.
 

@tkaiser,  many thanks for the files Your work is excellent . At the  moment it is working, sound is decent with my cheap i2s Dac but i had to use some dirty tricks, i am using an old .bin file. I think the gpio pins are sorted in a different way on armbian..
 
Before i am writing a small tutorial i will have a look at the pins..
 
Regards

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.

... or in new Armbian mainline kernel with my patch it can be activated by writing "1" to "/sys/power/axp_pmu/control/charge_rtc_battery"
 
I cheched AXP datasheet and battery (at least model mentioned in cubietruck schematics) datasheet, and if all AXP registers were reset, default values for voltage and current should be safe.

I won! I used cpuburn-a8 to heat a Pine64+ up to 105°Ca few hours ago (then I stopped the cpuburn-a8 tasks since I have only 2 Pine64 to play with)
 
 
Then the next one is asking why the OS image he downloaded for Marvell Clearfog does not run when inserting the card into a Banana Pi
 
I understand fully your concerns since it seems enticing to switch SD cards between OPi PC and One (in fact Xunlong tells users to do so, they simply renamed their download section for the PC to One/PC with causes all sorts of troubles on the One due to different voltage regulator and default 'up to 1.6 GHz' settings -- but their users are clueless, they fried their boards happily with wrong dvfs/thermal settings for months -- why should that change now with the One?).
 
But we already thought about that and maybe we'll add a check for a mismatch between board and actual settings (printing out a warning from motd at login for example). But definitely not for Orange Pi PC vs. One and now. We support a wide variety of boards and the Oranges are definitely not the most important ones. This will be a generic approach but not a quick hack (we already implemented too much of them to get support for H3 in this short time).
 
Anyway: If you plan to exchange SD cards between both types of boards simply exchange/relink script.bin and adjust the minimum cpufreq settings in /etc/defaults/cpufreq-utils prior to switching the card (I did that the last weeks maybe 50 times or even more).

I won! I used cpuburn-a8 to heat a Pine64+ up to 105°Ca few hours ago (then I stopped the cpuburn-a8 tasks since I have only 2 Pine64 to play with)
 
 
Then the next one is asking why the OS image he downloaded for Marvell Clearfog does not run when inserting the card into a Banana Pi
 
I understand fully your concerns since it seems enticing to switch SD cards between OPi PC and One (in fact Xunlong tells users to do so, they simply renamed their download section for the PC to One/PC with causes all sorts of troubles on the One due to different voltage regulator and default 'up to 1.6 GHz' settings -- but their users are clueless, they fried their boards happily with wrong dvfs/thermal settings for months -- why should that change now with the One?).
 
But we already thought about that and maybe we'll add a check for a mismatch between board and actual settings (printing out a warning from motd at login for example). But definitely not for Orange Pi PC vs. One and now. We support a wide variety of boards and the Oranges are definitely not the most important ones. This will be a generic approach but not a quick hack (we already implemented too much of them to get support for H3 in this short time).
 
Anyway: If you plan to exchange SD cards between both types of boards simply exchange/relink script.bin and adjust the minimum cpufreq settings in /etc/defaults/cpufreq-utils prior to switching the card (I did that the last weeks maybe 50 times or even more).

i would say, similar behavior...
 
new highscore. 92° celsius

"Time" is always the "missing ingredient" ...
But at least, there is some existing documentation, although a bit outdated : http://linux-sunxi.org/I2Cdev
Maybe I will try to get chance to contribute in this page by adding some testing python code for controlling a GPIO expander such MCP23017.
 
EDIT : For SPI, there is a simlar page : http://linux-sunxi.org/SPIdev
 
EDIT2 : I've ran successfully this quick SPI test : https://raw.githubusercontent.com/loboris/OrangePI-Kernel/master/linux-3.4/Documentation/spi/spidev_test.c

Using 3.4 kernel and trying to follow tutorials for mainline kernel will not work. Try to read from here on http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_on_sunxi-3.4
 
And since you're using Jessie it should work to do a 
apt-get install sunxi-tools to get the necessary tools. In case you're still stuck it might be a good idea to post the GPIO configuration from script.bin after translated through bin2fex.

You could grab the latest available Jessie image for the Plus (untested since Igor's not in the lab this week) from here http://forum.armbian.com/index.php/topic/617-wip-orange-pi-one-support-for-the-upcoming-orange-pi-one/?p=5476 and if's not already coming up with a desktop then follow the steps outlined in our  documentation to add a normal user and upgrade to a desktop environement:
apt-get -y install xorg lightdm xfce4 tango-icon-theme gnome-icon-theme reboot and report then back in the aforementioned thread. Please also have a look in our new H3 Mini FAQ in the meantime. I would also suspect that you have to adjust /boot/boot.cmd so that it reads
setenv bootargs "console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup-enable=memory swapaccount=1 sunxi_fb_mem_reserve=32 hdmi.audio=EDID:0 panic=10 consoleblank=0 enforcing=0 loglevel=1" (use mkimage afterwards as outlined in the documentation -- link above)

This is awesome, thanks, I tried this on Orange PI 2, and it works great, first time I ever see Orange PI on other resolution.

Another update. To change easily the HDMI resolution and take care of HDMI-to-DVI converters (they need special settings otherwise display shows wrong colors), I improved h3disp a bit. Unless this is part of new OS images you can grab it at the usual location: http://kaiser-edv.de/tmp/4U4tkD/h3disp.sh
 
8c17768ba915c63df1354d1e524bc350  h3disp.sh
 
If called without arguments it just outputs a help text now. But you can specify display resolution and whether you've to use DVI or HDMI on the command line:
root@orangepione:~# h3disp.sh -m 348974398 /usr/local/bin/h3disp.sh: Illegal video mode "-m 348974398". Try one of the following: 480i use "-m 480i" or "-m 0" 576i use "-m 576i" or "-m 1" 480p use "-m 480p" or "-m 2" 576p use "-m 576p" or "-m 3" 720p50 use "-m 720p50" or "-m 4" 720p60 use "-m 720p60" or "-m 5" 1080i50 use "-m 1080i50" or "-m 6" 1080i60 use "-m 1080i60" or "-m 7" 1080p24 use "-m 1080p24" or "-m 8" 1080p50 use "-m 1080p50" or "-m 9" 1080p60 use "-m 1080p60" or "-m 10" Two examples: h3disp -m 1080p60 -d' (1920x1080@60Hz DVI) h3disp -m 720i' (1280x720@30Hz HDMI) Simply save it as /usr/local/bin/h3disp.sh, make it executable (chmod 755 /usr/local/bin/h3disp.sh) and enjoy resolution switching the easy way (just kidding -- but at least it's easier than tweaking fex files manually -- our goal is still to provide a solution to use any display resolution sometimes in the future).
 
BTW: The script should also work with Xunlong's or loboris' OS images but untested there. Feedback welcome.

Another update. To change easily the HDMI resolution and take care of HDMI-to-DVI converters (they need special settings otherwise display shows wrong colors), I improved h3disp a bit. Unless this is part of new OS images you can grab it at the usual location: http://kaiser-edv.de/tmp/4U4tkD/h3disp.sh
 
8c17768ba915c63df1354d1e524bc350  h3disp.sh
 
If called without arguments it just outputs a help text now. But you can specify display resolution and whether you've to use DVI or HDMI on the command line:
root@orangepione:~# h3disp.sh -m 348974398 /usr/local/bin/h3disp.sh: Illegal video mode "-m 348974398". Try one of the following: 480i use "-m 480i" or "-m 0" 576i use "-m 576i" or "-m 1" 480p use "-m 480p" or "-m 2" 576p use "-m 576p" or "-m 3" 720p50 use "-m 720p50" or "-m 4" 720p60 use "-m 720p60" or "-m 5" 1080i50 use "-m 1080i50" or "-m 6" 1080i60 use "-m 1080i60" or "-m 7" 1080p24 use "-m 1080p24" or "-m 8" 1080p50 use "-m 1080p50" or "-m 9" 1080p60 use "-m 1080p60" or "-m 10" Two examples: h3disp -m 1080p60 -d' (1920x1080@60Hz DVI) h3disp -m 720i' (1280x720@30Hz HDMI) Simply save it as /usr/local/bin/h3disp.sh, make it executable (chmod 755 /usr/local/bin/h3disp.sh) and enjoy resolution switching the easy way (just kidding -- but at least it's easier than tweaking fex files manually -- our goal is still to provide a solution to use any display resolution sometimes in the future).
 
BTW: The script should also work with Xunlong's or loboris' OS images but untested there. Feedback welcome.

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!

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)

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.

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.

Yes of course, use the photo as you please. Thanks for all your help so far, I'm learning a lot too.
 
Just measured the 1V2C test point and seeing it at 1.11 V @ 648 Mhz and switch to 1.31 V for higher speeds and under load - this is of course with the old .fex.
 
TP1 point is showing very similar values, just very slightly lower (less than 0.002V difference)

Ok, then on your board everything works as expected and my proposed 'fix' leads to the undervoltage situation and the crashes. So something's wrong with my board instead and both my fix-thermal-problems.sh script and the fex settings our Orange Pi One image uses are counterproductive.
 
I believe we would need some more feedback from users now. And at least my board seems to be overvolted. I can run the cpufreq-ljt-stress-test test on the 'lower' voltage even with 1200MHz while running cpuburn-a7 in parallel. But on the higher voltage level it's impossible since then throttling occurs and CPU cores are shut down.

The most interesting thing on this schematic is that feedback voltage for CPU power regulator comes from separate H3 pins (VDD-CPUFB and GND-CPUFB) and there are test points for these pins too. I would recommend measuring VDD_CPUFB voltage too (test point is marked TP1 on schematic, page 6, top right corner).

EDIT: Schematic has been released: http://linux-sunxi.org/File:ORANGE_PI-ONE-V1_1.pdf
 
 
To be clear. The 1270 is just a value without any meaning. Could also be 2000 or 50 instead. It's 1270 since based on my experiments I fear the lower voltage available is close to 1.3V (to be able to compare graphs in RPi-Monitor). The fex fixes just should prevent switching from the lower voltage to the higher, this is just a binary switch.
 
Measuring 60°C when running cpuburn-a7 on an overvolted H3 when only 1 CPU core is active is pretty normal. Please do that test again and check with 'grep -c ^processor /proc/cpuinfo' afterwards (In my opinion doing such tests without RPi-Monitor is useless since you always overlook too many things)
 
Would be great if you can try out the tests points. Please have a look into the schematic for VDD-CPUX. I would set performance governor and then switch between a low and a high cpufreq since this triggers the binary switch for the voltage:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 1104000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # measure echo 648000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # measure again It would also be very interesting whether cpufreq-ljt-stress-test passes when you set scaling_max_freq to 648000 (you know that it's not enough to run cpufreq-ljt-stress-test alone, you'll have to start in another shell session cpuburn-a7 already a few minutes before. Without running cpuburn-a7 in parallel the results of cpufreq-ljt-stress-test are meaningless!).
 
Since what you describe sounds like on your Orange Pi One voltages are different than on mine (yours are lower so you run in instability issues when staying at the lower voltage, the old settings you now use again lead to being on the higher voltage when not totally idle).
 
 
This sounds like the usual 'default gateway' bug/feature.
 
 
Would you please put your fex on pastebin.com or similar to be able to merge your changes? Thx!