Wow, thx for the comprehensive test and the confirmation that it works on your board 'just as it should'. In the meantime I would assume that my Orange Pi One is defective.

 

I set cpufreq_max to 648 MHz with a fex setting allowing only the lower voltage, then started sysbench and within minutes the reported temperature reaches 65°C (with heatsink!) -- IMO this is a clear sign that at least on my board higher voltages are used. I will try to get a Multimeter to verify the next days.

 

Based on your results it should be perfectly OK to allow 1200 MHz again (while I could also give 1.5GHz a try -- when using a fan and if that test passes this is also a clear sign for heavy overvolting). Regarding DRAM clockspeed it's up to all Orange Pi One users to contribute NOW: http://linux-sunxi.org/Orange_Pi_One#DRAM_clock_speed_limit

 

The more users provide results soon the higher the chances are that Orange Pi One will get 672 MHz by default when included in u-boot.

 

Now I'm curious about feedback regarding the 5.03 Armbian release for Orange Pi One. The fex we shipped only allows the lower voltage so all users with correctly working voltage switching as on your board should experience the same stability issues/crashes due to undervoltage. I hope they get back to us with reports and do not silently drop Armbian instead...

Hi, for what it's worth, I measured the TP1 under load and in idle with older armbian image (where the switching is enabled), and I measured 1.1V and 1.3V. I have the Orange Pi ONE with AX3833 regulator.

 

So hopefully the overvolting is not a systematic issue.

 

Ad: Power consumtion is 1W in idle, and 2-2.5x more during some load.

I measured the TP1 under load and in idle with older armbian image (where the switching is enabled), and I measured 1.1V and 1.3V. I have the Orange Pi ONE with AX3833 regulator.

 

Thx for the feedback. Seems really just my board is defective.

 

Here's the fixed script.bin for Orange Pi One to be useable with the latest Armbian image: http://kaiser-edv.de/tmp/4U4tkD/orangepione.bin(MD5: b8397d78f76f1517fd496fae7b4b7bc2)

Hi,

 

My board is also OK - stable 1.1V / 1.3V and on PCB is AX3833 too.

I'm very curious what are the voltages on your board.

Thx for the feedback also regarding the AX8388.

 

Care to try out lima-memtester as outlined in Linux-sunxi wiki? We need many testers trying out reliability of DRAM clock settings!

Seems we found the reboot problems: http://kaiser-edv.de/tmp/4U4tkD/

 

Exchanging script.bin is necessary. For PC, One and 2 you find correct versions above (no fix needed for Plus).

 

Would be helpful if users of the 2, 2 Mini, Plus or Plus 2 can try out the preliminary unified OS image that you also find there. This is an attempt to auto detect the board we're running on. There will be error messages on any board != 2 but after the first automatic reboot everything should work as expected (One back at 1200 MHz).

 

In this image kernel outputs to serial console therefore having a serial adapter would be helpful. Beware: this is just for testing purposes but you would really help us trying this out and getting back to us.

Just got my orange pi one today!

Thank you for your wonderful work, I will try to help in what I can!

 

Seems we found the reboot problems: http://kaiser-edv.de/tmp/4U4tkD/

Exchanging script.bin is necessary. For PC, One and 2 you find correct versions above (no fix needed for Plus).

Tested and the reboot seems to work now

Seems we found the reboot problems: http://kaiser-edv.de/tmp/4U4tkD/

 

 

What was it ? (Since in my case the issue disappeared, is it simply because I'm using your latest FEX ?)

Would be helpful if users of the 2, 2 Mini, Plus or Plus 2 can try out the preliminary unified OS image that you also find there.

 

I can confirm that new script.bin solves reboot issue on OPi2.

 

BTW: Did anyone look into suspend issue?

What was it ? (Since in my case the issue disappeared, is it simply because I'm using your latest FEX ?)

 

It seems the sunxi_gmac driver on PC/One/2 gets stuck and prevents full power-off when in the fex file 'gmac_phy_power_en = port:...' is defined. We tried first to use an unused pin to be able to use one kernel binary for all OPi (the only difference here being external GbE PHY on the Plus and all other Oranges using the internal Fast Ethernet PHY). But this didn't worked and I didn't noticed since I converted between fex and script.bin the last days at least a few hundred times.

 

The background is to try to provide one single OS image for all H3 Oranges (later Olimex boards automagically too) that sets up everything correctly after the initial boot: https://github.com/igorpecovnik/lib/pull/173

 

BTW: Did anyone look into suspend issue?

 

Which suspend issue?

 

BTW: If we succeed with such a 'one size fits it all' solution OpenELEC might benefit too. Be prepared that as soon as the Olimex H3 boards are out you get two new 'devices' as pull requests (that differ only regarding script.bin, maybe /etc/modules and maybe cpufreq settings)

Which suspend issue?

 

BTW: If we succeed with such a 'one size fits it all' solution OpenELEC might benefit too. Be prepared that as soon as the Olimex H3 boards are out you get two new 'devices' as pull requests (that differ only regarding script.bin, maybe /etc/modules and maybe cpufreq settings)

 

Hm... Issue went away by itself Interesting, OpenELEC has basically the same kernel, but it has severe issues at waking up from suspend. Any idea? My use case: go to sleep with "systemctl suspend" and then wake up with power button.

 

Supporting different boards is no problem for me. As you said, different script.bin's, maybe module loading and boot.cmd. Currently I'm in a bad mood because I can't figure this suspend...

 

What about having commong H3 linux repository? I know that there is not much interest because mainline H3 support is progressing nicely, but multimedia distribution like OpenELEC would benefit.

go to sleep with "systemctl suspend" and then wake up with power button.

 

LOL! Now I know what your 'support power button' commit was about. I'll try this out when I'm back at home.

 

Regarding a kernel repo. Good idea but we need someone who will maintain that. I would suspect H3 gets more popular the next time and then you'll have to deal with pull requests all the time. So out strategy is to collect moronically patches on top and wait until something breaks. And then start to think about a solution. If I understood Igor correctly he refrains from maintaining the kernel, same do I.

 

But I agree it would be useful, especially since the kernel base we're currently using is still missing a lot of the early contributions from Orange Pi forums (eg. camera support -- there were patches available in the OPi forums but they disappeared so now we would have to compare loboris' sources and ours to recreate a patch to get the camera module working)

Regarding a kernel repo. Good idea but we need someone who will maintain that. I would suspect H3 gets more popular the next time and then you'll have to deal with pull requests all the time. So out strategy is to collect moronically patches on top and wait until something breaks. And then start to think about a solution. If I understood Igor correctly he refrains from maintaining the kernel, same do I.

 

But I agree it would be useful, especially since the kernel base we're currently using is still missing a lot of the early contributions from Orange Pi forums (eg. camera support -- there were patches available in the OPi forums but they disappeared so now we would have to compare loboris' sources and ours to recreate a patch to get the camera module working)

 

Currently I feel like Frankestein who's creating his own monster. Kernel includes so many backports and ports already that I'm surprised it's still working. Yeah, I concur that maintaining such a repo would be a nightmare. But maybe if there is a team of few people, it would be manageble...

 

BTW: I took a quick look at Armbian and I'm surprised there is no kswapd issue. Did you do anything about that or there wasn't any from the beginning?

BTW: I took a quick look at Armbian and I'm surprised there is no kswapd issue. Did you do anything about that or there wasn't any from the beginning?

 

We started to use https://github.com/ssvb/linux-sunxi/tree/20151207-embedded-lima-memtester-h3as base and then I switched to Yann's h3-wip branch: https://github.com/O-Computers/linux-sunxi/commits/h3-wip -- on what is OpenELEC based?

 

Can't remember whether we had this issue in the beginning but at least after switching to Yann's repo it never occured. Regarding 3.4 for H3: For me this is just an intermediate step to be able to use the devices now. As soon as mainline kernel support is ready for most of the use cases 3.4 will be completely irrelevant (pretty different situation as yours I bet

 

On the other hand I'm still interested in getting things up and running like the camera module... and CSI support is still missing in mainline. Difficult.

 

BTW: Since you mentioned the new A64 BSP. Simon put the list of changes online: http://paste.ubuntu.com/15174117/(sun8iw10/sun8iw11?! WTF?!). And I've to admit this looks really interesting from the H3 perspective.

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!

We started to use https://github.com/ssvb/linux-sunxi/tree/20151207-embedded-lima-memtester-h3as base and then I switched to Yann's h3-wip branch: https://github.com/O-Computers/linux-sunxi/commits/h3-wip -- on what is OpenELEC based? [...]

 

BTW: Since you mentioned the new A64 BSP. Simon put the list of changes online: http://paste.ubuntu.com/15174117/(sun8iw10/sun8iw11?! WTF?!). And I've to admit this looks really interesting from the H3 perspective.

 

I really don't remember now, I think I searched for some H3 source on net and took the newest I could find. Maybe even from orangepi forum. Maybe it's time to switch to another, probably it would be best if we have same codebase. At least your kernel don't show any problems which mine have. I'm a bit woried about mali driver. Which version of binary blob do you have? I'm using fbdev version...

 

I saw that (I'm tracking IRC just not talking). Frankly speaking, I was very excited at first, but then I saw that all driver configuration is based on device tree. I'm not sure if there is any point putting so much work into porting that... Don't get me wrong, I would like to have better sound drivers among other things.

 

EDIT: I think I'm using sources from h3-lichee-1.0.tar.gz

Hi everyone,
I am following this thread since I have ordered my Orange Pi One and I could see that the things progress quite fast!
I have now the board in my hands and ready to do some tests.

I have started by doing my duties, donate to the project then I have run the DRAM test and reported them on the Wiki.

 

I have downloaded tkaiser's unified image of Armbian_5.03 from his server this evening and installed Rpi-Monitor using the script provided on the same server.

But I have never used Rpi-Monitor before and it seems that I need a configuration file because I do not have a graph with all the infos in one place like the screenshot posted before by others. And the Core temperature is not in degrees as it only changes between 0.04 and 0.09.

About the reboot, I could not manage to reboot the board. The reboot command only halt the board and I have to power it off and on to make it boot again.

 

For the voltage, I have tested TP1 and I get 1,09 V on idle and 1.29 V while running cpuburn-a7. I did not find TP2 and 1V2C on the silkscreen of the board to test them.

 

About the benchmarks, I am not sure which one needs to be run. A simple how-to would be welcomed I think if you want to compare the results from several users.

 

I have run cpuburn-a7 in parallel with cpufreq-ljt-stress-test. I post the output below in case it could interest someone:

 

 

 

root@orangepione:~/cpuburn-arm# ./cpufreq-ljt-stress-test
The cjpeg and djpeg tools from libjpeg-turbo are not found.
Trying to download and compile them.  
CPU stress test, which is doing JPEG decoding by libjpeg-turbo
at different cpufreq operating points.

Testing CPU 0
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz SKIPPED
 1104 MHz SKIPPED
 1008 MHz SKIPPED
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 1
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz SKIPPED
  912 MHz SKIPPED
  816 MHz SKIPPED
  720 MHz SKIPPED
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 2
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz SKIPPED
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz SKIPPED
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 3
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz ................taskset: failed to set pid 0's affinity: Invalid argument
 FAILED
  912 MHz SKIPPED
  816 MHz SKIPPED
  720 MHz SKIPPED
  648 MHz SKIPPED
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Overall result : FAILED

 

 

During the test, it seems that some cpu were killed according to the output of the serial port:

 

 

[...]
[  972.590143] [ddrfreq] temperature=82 C, ddr freq up
[  973.090183] [ddrfreq] temperature=85 C, ddr freq up
[  975.090198] [ddrfreq] temperature=84 C, ddr freq up
[  975.590132] [ddrfreq] temperature=82 C, ddr freq up
[  978.090189] [ddrfreq] temperature=85 C, ddr freq up
[  978.590162] [ddrfreq] temperature=83 C, ddr freq up
[  979.090137] [ddrfreq] temperature=85 C, ddr freq up
[  980.090191] CPU Budget:Try to down cpu 3, cluster0 online 4, limit 1
[  980.231929] CPU3: shutdown
[  980.235027] [hotplug]: cpu(0) try to kill cpu(3)
[  980.270113] [hotplug]: cpu3 is killed! .
[  980.290172] CPU Budget:Try to down cpu 2, cluster0 online 4, limit 1
[  980.391117] IRQ105 no longer affine to CPU2
[  980.396776] CPU2: shutdown
[  980.399820] [hotplug]: cpu(0) try to kill cpu(2)
[  980.405820] [hotplug]: cpu2 is killed! .
[  980.440175] CPU Budget:Try to down cpu 1, cluster0 online 4, limit 1
[  980.541113] IRQ106 no longer affine to CPU1
[  980.547149] CPU1: shutdown
[  980.555389] [hotplug]: cpu(0) try to kill cpu(1)
[  980.590160] [hotplug]: cpu1 is killed! .
[  981.110156] [ddrfreq] temperature=84 C, ddr freq up
[  981.610127] [ddrfreq] temperature=78 C, ddr freq up
[  982.110111] [ddrfreq] temperature=74 C, ddr freq up
[  984.110102] [ddrfreq] temperature=69 C, ddr freq up

 

 

 I'm a bit woried about mali driver. Which version of binary blob do you have? [...] I think I'm using sources from h3-lichee-1.0.tar.gz

 

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.

 

And the Core temperature is not in degrees as it only changes between 0.04 and 0.09.

About the reboot, I could not manage to reboot the board

 

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!

 

Hi,

I've just checked mine Orange Pi One  - it is stable at 720MHz (test runned about 1h), and crashed after ~ 1m on 744MHz. Memories / CPU without heatsink.

LOL! Now I know what your 'support power button' commit was about. I'll try this out when I'm back at home.

Kinda offtopic, but if you are talking about these commits, this is for safe shutdown by single short press of hardware power button, mostly for A10/A20 devices; suspend or power-on shouldn't depend on this.

I've just checked mine Orange Pi One  - it is stable at 720MHz (test runned about 1h), and crashed after ~ 1m on 744MHz. Memories / CPU without heatsink.

 

Thx, please add this to the Wiki (creating an account is easy and fast and you'll need it anyway to write tutorials there later ) and also mention please which version of lima-memtester you used: pc or one (they just differ by the fex file used)

 

Kinda offtopic, but if you are talking about these commits, this is for safe shutdown by single short press of hardware power button, mostly for A10/A20 devices; suspend or power-on shouldn't depend on this.

 

No I was referring to Jernej's commit. I adopted the settings and pressed cluelessly the power button a few times. Now I know that I would have to send the board to suspend before (or better not according to Jernej's last comments here)

I was hoping to test out Armbian, but I keep running into issues. Following the directions on the main page, I write the .raw to my sdcard and insert it into the OrangePi One. I'm using the Armbian_5.03_Orangepione_Debian_jessie_3.4.110.raw version. I got similar results with the 5.01 version.

 

I've got the serial console working, but I don't get any output after the U-Boot:

MKernel image @ 0x48000000 [ 0x000000 - 0x49a658 ]
Using machid 0x1029 from environment

Starting kernel ...

[sun8i_fixup]: From boot, get meminfo:
      Start:  0x40000000
      Size:   512MB
ion_carveout reserve: 160m@0 256m@0 130m@1 200m@1
ion_reserve_common: ion reserve: [0x56000000, 0x60000000]!

Sometimes there output on HDMI, sometimes not. When I get output, there are often many error messages. Sometimes about mmcblk corruption. Really, too many to list here. It would be helpful for me to get that output on the serial port.

 

I feel like I'm missing something obvious.

 

James

I prepared 3 new test images, two for Orange Pi One/PC/2 and one for the Plus (MD5 sum and image name): http://kaiser-edv.de/tmp/4U4tkD/

 

2fe714c80d035de6035dfe04cd07b309  Armbian_5.03_Orangepi2_PC_One_Debian_jessie_3.4.110.zip

128001930a180168dff043fc11b4b634  Armbian_5.03_Orangepi2_PC_One_Ubuntu_trusty_3.4.110_desktop.zip

cbd303d71da6207e727f60c5943954ff  Armbian_5.03_Orangepih3_Debian_jessie_3.4.110.zip

71087e71c0ab226f15800b29a648ffcb  Armbian_5.03_Orangepih3_Debian_wheezy_3.4.110.zip

9459673a680eb8bfa3c33f48d4481a13  Armbian_5.03_Orangepiplus_Debian_jessie_3.4.110_desktop.zip

f20bb8476788e4b5c0f5fbd7b874e6ea  Armbian_5.03_Orangepiplus_Debian_wheezy_3.4.110.zip

ccf10f46206b916c556374aaa0378179  Armbian_5.03_Orangepih3_Debian_jessie_4.4.2.zip

1a73e031fb106eb3b96265572630c37d  Armbian_5.03_Orangepiplus_Debian_jessie_4.4.2.zip

 

EDIT: Images are available from now on at the usual location: http://www.armbian.com/download/

 

Don't try to run those for One/PC/2 on the Plus and vice versa!

 

We tried to provide a single OS image that detects on which board it's running at first boot but due to the horrible code quality of this 3.4.x kernel we got from Allwinner it seems not possible (if you're interested in details, follow this discussion TL;DR: It's not working, without further wasting more time we now plan to provide one OS image for One/PC/2 and later the Lite and a separate for the Plus)

 

Serial console is disabled there (mostly by accident and also to prevent One users from crying, they'll see prior to the first reboot countless 'ARISC ERROR' messages that will magically disappear after the first reboot). Please be patient and don't touch the system for the first 3 or even up to 5 minutes since the first boot takes longer and then an automated reboot will happen.

 

If you want to have (extensive) output on the serial console, then please edit /boot/boot.cmd so that the kernel cmd_line arguments read:

setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup-enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 panic=10 consoleblank=0 enforcing=0 loglevel=8"

Afterwards it's necessary to run

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

In case you want to try out a kernel with CONFIG_DEBUG_BUGVERBOSE=y please download and extract kernel_5.03_h3_unified_verbose_debug.tgz and use dpkg -i *sun8i*.deb afterwards.

 

In case you want to get an idea what's going on with your board, think about installing RPi-Monitor. See a few posts/pages before or have a look at install-rpi-monitor-for-h3.sh.

 

And most importantly please keep in mind that these are test versions only. Not intended for any sort of productive use, they're just there to get feedback from you to help us improve things. Igor is out of lab this week, me then too. We just want to collect some feedback in the meantime and will release new images later that will be more user friendly.

 

In case you want to change the display resolution (720p is currently default) you'll have to tweak fex settings. You might use the h3disp script skeleton for this purpose and adjust lines 63/64, execute it (set DVIUsed=FALSE when you use no HDMI-to-DVI converter and HDMIMode according to the following table) and reboot. In the meantime I improved h3disp -- see next post below.

 

Please be prepared that none of the images is ready yet, we're still busy nailing down really basic problems and had no time/motivation to tune GUI/desktop stuff. This will take still some time.

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.

I adopted the settings and pressed cluelessly the power button a few times. Now I know that I would have to send the board to suspend before (or better not according to Jernej's last comments here)

 

If you want something useful, you should add udev rule:

SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="sunxi-gpiokey", TAG+="power-switch"

However, this will shutdown your board, because it sends KEY_POWER. I think kernel patch is needed if you want to change it to KEY_SLEEP. Waking from suspend should work flawlessy now on Armbian.

 

I reorganized all patches in OpenELEC and kernel configuration so the kernels are more similar now. I still have CMA/kswapd issue, but I still have one idea what to change. In the process, I found the reason why suspend on OpenELEC doesn't work. It works when CMA is enabled

 

Nice progress in unifying all the images. Did you consider porting MMC driver from mainline kernel to solve the issues?

SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="sunxi-gpiokey", TAG+="power-switch"

However, this will shutdown your board, because it sends KEY_POWER. I think kernel patch is needed if you want to change it to KEY_SLEEP. Waking from suspend should work flawlessy now on Armbian.

For Jessie (headless) you can change action in /etc/systemd/logind.conf (option HandlePowerKey)

On wheezy/trusty you should be able to change some settings in acpi scripts (or creating custom script) in /etc/acpi/ (if I remember correctly)

Did you consider porting MMC driver from mainline kernel to solve the issues?

 

At least I lack both skills/time and motivation. As soon as mainline kernel is ready for H3 I will leave the 3.4 boat immediately

 

For Jessie (headless) you can change action in /etc/systemd/logind.conf (option HandlePowerKey)

On wheezy/trusty you should be able to change some settings in acpi scripts (or creating custom script) in /etc/acpi/ (if I remember correctly)

 

Well, powering down when touching the button would be already worst case scenario for my use cases (server/controller). I'll have a look into this to use the power button for some sort of user interaction instead

At least I lack both skills/time and motivation. As soon as mainline kernel is ready for H3 I will leave the 3.4 boat immediately

 

Yeah, I'm also thinking about it, but your mainline goal will be reached sooner I guess.

 

BTW: I think Armbian could have kswapd issue too if some memory heavy process is run.

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

 

Thanks a lot Tkaiser for your quick feedback.

 

I have done the several steps you mentioned and I have now a working RPi-Monitor with correct values for the temperature. The reboot works great now.

 

I have run cpufreq-ljt-stress-test in parallel with sysbench then with sysbench and cpuburn-a7 in parallel. This time, the two cpufreq-ljt-stress-test passed and no cpu were killed according to the serial console.

 

This is the output of cpufreq-ljt-stress-test if it is useful:

 

 

 

root@orangepione:~/cpuburn-arm# ./cpufreq-ljt-stress-test
The cjpeg and djpeg tools from libjpeg-turbo are not found.
Trying to download and compile them.  
CPU stress test, which is doing JPEG decoding by libjpeg-turbo
at different cpufreq operating points.

Testing CPU 0
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz SKIPPED
 1104 MHz SKIPPED
 1008 MHz ............................................................ OK
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 1
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz ............................................................ OK
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 2
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz SKIPPED
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 3
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz ............................................................ OK
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Overall result : PASSED
root@orangepione:~/cpuburn-arm# ./cpufreq-ljt-stress-test
The cjpeg and djpeg tools from libjpeg-turbo are not found.
Trying to download and compile them.
CPU stress test, which is doing JPEG decoding by libjpeg-turbo
at different cpufreq operating points.

Testing CPU 0
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz ............................................................ OK
  912 MHz ............................................................ OK
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 1
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz ............................................................ OK
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz ............................................................ OK
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 2
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz SKIPPED
  912 MHz SKIPPED
  816 MHz ............................................................ OK
  720 MHz SKIPPED
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Testing CPU 3
 1536 MHz SKIPPED
 1440 MHz SKIPPED
 1344 MHz SKIPPED
 1296 MHz SKIPPED
 1200 MHz ............................................................ OK
 1104 MHz SKIPPED
 1008 MHz SKIPPED
  912 MHz SKIPPED
  816 MHz SKIPPED
  720 MHz SKIPPED
  648 MHz ............................................................ OK
  600 MHz SKIPPED
  504 MHz SKIPPED
  480 MHz SKIPPED
  408 MHz SKIPPED
  312 MHz SKIPPED
  240 MHz SKIPPED
  120 MHz SKIPPED
   60 MHz SKIPPED

Overall result : PASSED

 

 

 

I wonder why the 1200 MHz test was skipped the first time on the cpu 0?

 

And now, a capture of the graph:

This time, the two cpufreq-ljt-stress-test passed

 

Thx for the feedback, especially the perfectly formatted graph!

 

That the test passed is unfortunately wrong since throttling occured (visible in both the graphs and the 'SKIPPED' messages)

 

It seems we need to adopt this test to the current situation with thermal throttling jumping in now and then and we need also improved documentation. And also it seems to be necessary to grep 'dmesg' afterwards with this 3.4.x kernel. I ran some tests today with strange results just to realise that oom-killer killed some tasks.

 

I'll have a look into it in maybe a week. In the meantime I had a short laugh remembering:

 

Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C.

(quoted from: http://www.brendangregg.com/activebenchmarking.html )