jmarcelino

That means that boot loader is patched / prepared and we did a manual boot. For installer we need to create / adjust scripts and make few tests. This is scheduled for next release - in 2-3 weeks. This info is valuable for users who knows how to do it manually.
 
http://forum.armbian.com/index.php/topic/881-prepare-v51-v201604/

@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:
 

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.

@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:
 

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!

Just to emphasise on this a little. The most important part when running these tests is this:
 
 
That means running cpufreq-ljt-stress-test alone isn't enough on a quad-core H3. You have to use 'cpuburn-a7' or 'stress -c 4' or 'sysbench --test=cpu --cpu-max-prime=100000 run --num-threads=4' running in parallel and it's a good idea to start a few minutes in advance since then the SoC gets closer to worst case conditions.
 
Since you did not apply a heatsink already the whole test is useless since thermal throttling will occur and cpufreq-ljt-stress-test simply isn't able to test the higher operating points (use RPi-Monitor to get a clue). When I ran cpuburn-a7 with overvolted settings and a heatsink the second protection method jumped in: CPU cores got killed, see a few posts before  (always use RPi-Monitor to get a clue)
 
So in your situation without a heatsink the best test would be to set scaling_max_freq to 648000 as already suggested, fire up cpuburn-a7 and start the test script 5 minutes later. If that fails then you've the clear indication that on your Orange Pi One the lower voltage is definitely too low. And fex settings that will feed the SoC always with the higher voltage might be an idea. Something like (the voltage value being without any meaning only the 1st bit being important):
pmu_level0 = 11300 pmu_level1 = 11300 LV1_volt = 1300 LV2_volt = 1300 

Schematic for Orange Pi ONE is available now - it should help to solve some issues with voltage. There is 1V2C test point on PCB - it is the right place to check 1.1V / 1.3V switching
 
ORANGE_PI-ONE-V1_1.pdf

So I reverted config/orangepione.fex back to 80e7d5a while keeping the rest of the tree up to date and my Orange Pi One is now happy again, booting correctly, has network.
 
Boot log: http://pastebin.com/AdfaAUYe
 
I'll see if I can narrow it further.

Can confirm this. To check whether my display is working correctly I used loboris' Ubuntu 15.04 Mate image and connected it (with script.bin fixes for DVI applied). Worked flawlessly.
 
Then I made his image 'hybrid':
cd /tmp && wget http://kaiser-edv.de/tmp/4U4tkD/kernel_5.01_h3.tgz tar xf kernel_5.01_h3.tgz dpkg -i linux-headers-sun8i_5.01_armhf.deb linux-image-sun8i_5.01_armhf.deb mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n "Armbian-sun8i-3.4.110" -d /boot/vmlinuz-3.4.110-sun8i /media/boot/uImage.armbian shutdown -r now And loaded our kernel in u-boot manually. Et voilà: HDMI works with '2011.09-rc1' and our latest kernel. And surprisingly the SoC's temperature is now also reported in the 'usual' range and not way off as when booting mainline u-boot (currently testing)