jpearn

Nightly builds are automated - for developers and testing - and sometimes things go wrong. Try updating once again in approximately 6 hours from now.

Will be fixed eventually. Some files are being moved from one package to another, and currently there are some missing relationships between those packages.

That was pure coincidence. We are preparing to put out update for all images and I made first test build two days ago. Kernel on those images (the one you downloaded) is having higher kernel number but lower package version number than nightly builds ... which are currently on hold due to changes on download server. 
 
In any case, don't bother with that
 
 

Yes, boot environment configuration should survive kernel upgrade.
 
BTW: I notify Solidrun about this issue.

OK, my i2 cubox uses the imxq dtb not imxdl so it has started booting the kernel after going back to the boot.cmd !
 
It's booting to a login with no errors, so have a look after Sunday lunch Thanks for the help !

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.