MX_Master

@MX_Master If you didn't immediately leave IRC after saying something, I wouldn't have to keep logging in to the forum here 
 
You mentioned using the MSGBOX for communication. I've written drivers for both sides of the MSGBOX (Linux and ARISC) that you can copy/modify from https://github.com/smaeul/linux/tree/msgbox and https://github.com/crust-firmware/crust/blob/master/drivers/msgbox/sunxi-msgbox.c, respectively. If you want to use more code from my firmware, I have a branch at https://github.com/smaeul/crust/tree/feature/more-boards with untested support for H3-based boards.

My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
 
The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.

No, you have to either change u-boot code or edit boot script and add memory write command (mw.l), which writes right value to register.

Yeah, that's tzpc. I forgot to mention, bsp kernel runs in privileged mode and mainline in unpriviledged mode. That's why you see a difference in behaviour.

@MX_Master Try booting with "iomem=relaxed" on your kernel command line. This will allow access to more of the address space from /dev/mem (see https://lwn.net/Articles/302048/).

probably not as long as things do not improve:
Xunlong provides an outdated 3.10.65 kernel (3.10.108 is the newest and reached EOL in Nov 2017), Mainline is... http://linux-sunxi.org/Mainlining_Effort#Status_Matrix on the way. (Edit: but for sure not ready yet, keep going @Icenowy ) There are no schematics released for the OPi One Plus (there are schematics in the 'user manual collection' but they are for the OPi Lite and it locks like copy paste...  (Design name: H6-PROTO, DC-In 12V/1A --> 5V/2A) spottend so far (xunlongs Ubuntu):
Thermal zones are there powering over microUSB 'works' (don't do it, but I've to wait for my second 5V barrel plug..) cpu freq seems to stay at 1800 MHz idle TZ0 48°C (1488MHz stress -c 4 ~10min TZ0: 83°C, TZ1: 69°C) minerd (~5min Total: 4.61 khash/s at 1488MHZ TZ087-89°C,  trip_point_1 would be at 90°C) keep in mind,  those numbers do not benchmark the SoC (it might benchmark the current available combination of OS and SoC). Cause SD-card is near to SoC, I stopped minerd to avoid a SD-Card BBQ... 
 
Hmm.. after minerd, the SoC idles sometimes at 480MHz...  Next topic might be the investigation of the  PMIC (AXP805).

Thanks for noticing that. I've got mine sitting on my desk as a paperweight waiting for someone to release a working Linux distro for it. I'll report back my power consumption and speed measurements later today.
 
Ugh - now I remember why I appreciate Armbian so much. The Linux distro provided by OrangePi is 1.5GB, yet somehow is missing everything I need. This may take a while...
 
Update: The board doesn't really seem to have any advantage over H5 boards. The max CPU frequency in the kernel shows as being 1.8Ghz, with the min set to 480Mhz. When pushed by my gcc_perf test, the results didn't fare much better than an RPI3. The power usage is what's really disappointing. The other H2+/H3/H5 boards I've tested usually max out at about 580mA when all 4 cores are cranking. The H6 is supposed to be a 28nm process and I thought that would mean lower power usage. The Orange Pi One Plus maxes out at 830mA when all 4 cores are stressed by gcc. Can anyone else do some testing to see if it matches my results?

My observations are:
 
- Android distribution: sucks! Very premature. One can not do anything. I was intended to test video playing, but could not get Kodi to run, neither any other app since Google play is not installed. So, even the apps that show up in the menu do not work. So I rapidly gave up on it.
Current when idle seemed stable at around 380mA
 
- Ubuntu server: distro does not boot if you have HDMI plugged in....
Idle current is 410mA
Ethernet seems to be really Gigabit... Results for iperf below.
in this case the current rises to 550mA.
[ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 6.34 GBytes 907 Mbits/sec when using bidirectional simultaneous transfers with the following command:
root@OrangePi:~# iperf -c 192.168.1.100 -t 60 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.1.100, TCP port 5001 TCP window size: 113 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.1.143 port 37423 connected with 192.168.1.100 port 5001 [ 4] local 192.168.1.143 port 5001 connected with 192.168.1.100 port 51684 [ ID] Interval Transfer Bandwidth [ 5] 0.0-60.0 sec 4.56 GBytes 653 Mbits/sec [ 4] 0.0-60.0 sec 4.92 GBytes 705 Mbits/sec  
Then I run the gcc_perf @Larry Bank from here: https://github.com/bitbank2/gcc_perf
Average current was around 560mA, with peak 640mA.
 
My conclusion is: This board makes sense as a remote video player, connected to some TV with Kodi, probably, so that you can stream from your main server. That because it has great ethernet, with great 4K video decoding capabilities....
 
One USB3 would make it a good choice for servers... But no...
 
 
 

Here is attempt to make mainline driver for AR100: https://github.com/mripard/linux/commits/sunxi/wip/ar100 But as branch name says, it's wip and not necessarly working. I didn't try it, I just though it might interest you.

- H6
- 1GB
- gigabit
- 26pin
- powering only via DC input
- PMU AXP805
- 1 x USB2.0 host and 1 x micro USB 2.0
- size: 69x47mm
- weight: 50g
- price USD20-25

Hi, guys. I need some help in understanding of usage AR100 (OpenRISC) coprocessor inside H3 SoC for the own real-time tasks.
 
Now i'm using mainline kernel built with RT-PREEMPT patch. I'm using it with Machinekit (LinuxCNC) software to control stepper drivers/motors via GPIO step/dir pulses. But step pulses frequency is too slow (about 17 kHz) because the RT kernel latency is about 30 us.
 
I think we can use the built-in coprocessor for the realtime GPIO toggling. The AR100 and main Cortex-A7 can talk to each other with built-in MSGBox. And the question is - how to launch my own firmware on the AR100 core?

I'm using Machinekit with my GPIO driver. I have a big CNC machine (4 axes).
 
yep. 2279 microseconds is bad result

If somebody interested, here is a few photos where LinuxCNC running on the Orange Pi One.
Debian Jessie, FULL RT patch.

If somebody interested, here is a few photos where LinuxCNC running on the Orange Pi One.
Debian Jessie, FULL RT patch.

Im running Armbian Debian Stretch mainline  with 4.14.3-rt4 on a NanoPi Neo Plus2 ( Allwinner H5 ).
The patch applied just fine and performance is good.
 
T: 0 ( 1634) P:99 I:1000 C:1810076 Min:      6 Act:    9 Avg:    8 Max:      32
T: 1 ( 1635) P:99 I:1500 C:1206709 Min:      6 Act:    7 Avg:    8 Max:      44
T: 2 ( 1636) P:99 I:2000 C: 905025 Min:      6 Act:    7 Avg:    8 Max:      37
T: 3 ( 1637) P:99 I:2500 C: 724014 Min:      7 Act:    7 Avg:    7 Max:      31
T: 4 ( 1638) P:99 I:3000 C: 603343 Min:      7 Act:    7 Avg:    8 Max:      42
 
uname -a:
Linux nanopineoplus2 4.14.3-rt4-sunxi64 #8 SMP PREEMPT RT Sat Dec 2 22:08:45 CET 2017 aarch64 GNU/Linux
 
 
Latest Armbian = 

On 1st Dec. the latest 4.14 rt patch has been released
-> https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/
So it might be possible to test now with new 5.36 and 'mainline' option.
 

Hey @MX_Master, reporting in with some more numbers with the 4.13 RT stuff. 
 
# uname -a Linux nanopi-neo 4.13.11-rt3 #2 SMP PREEMPT RT Thu Nov 30 11:17:18 CST 2017 armv7l GNU/Linux # cyclictest -a -t -n -p80 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.11 0.10 0.03 1/94 920 T: 0 ( 915) P:80 I:1000 C: 238476 Min: 6 Act: 9 Avg: 9 Max: 38 T: 1 ( 916) P:80 I:1500 C: 158983 Min: 5 Act: 9 Avg: 9 Max: 27 T: 2 ( 917) P:80 I:2000 C: 119238 Min: 8 Act: 9 Avg: 8 Max: 17 T: 3 ( 918) P:80 I:2500 C: 95390 Min: 7 Act: 9 Avg: 9 Max: 16  

I'm using the armbian toolset without any kernel tweaks. Just RT patch, option 5. Without any PREEMPT debug.
I think it's time to make some tweaks to the kernel.. 

Cool, I didn't know RT patches for 4.13 were out already! Thats great news, I should bump up my version. Are you building your kernel using the armbian toolset or your own?
 
Another point is that mine is specifically for the nanopi neo, which doesn't involve any HDMI setup or clocking. I'm not sure if that affects the results of cyclictest, but it might, as the HDMI subsystem must involve interrupts to the kernel. Armbian also ships with irqutils, which balances the irqs over the 4 cores (or 3, as you have one isolated). I have no idea if that matters either. 
 
I'm using my stuff for audio, and having the full RT kernel helps with audio dropouts on my USB device. Using alsa (no jack) I can get it down to ~10ms round trip. Without RT it was more like ~30ms. I've found the best test of any RT system is how it responds with your application.

Thanks, MitchD!
 
 
Your results are very good! I'll try to learn more about your environment.
 
By the way, I found the new RT patch for the mainline kernel 4.13. I build a fresh desktop Ubuntu Xenial image with this RT patch. Setup the isolcpus=3. And my new latency results are
master@orangepione:~/rt-tests$ sudo ./cyclictest -a -t -n -p80 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 4.81 2.25 1.02 6/382 3797 T: 0 ( 3376) P:80 I:1000 C: 237748 Min: 5 Act: 30 Avg: 15 Max: 136 T: 1 ( 3377) P:80 I:1500 C: 158502 Min: 5 Act: 17 Avg: 16 Max: 103 T: 2 ( 3378) P:80 I:2000 C: 118876 Min: 5 Act: 44 Avg: 18 Max: 113 T: 3 ( 3379) P:80 I:2500 C: 95101 Min: 6 Act: 17 Avg: 13 Max: 98 It's much better!

Sure thing! Here are my results:
# cyclictest -p 80 -t5 -n -a # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.12 0.17 0.08 1/93 193           T: 0 (  186) P:80 I:1000 C: 551057 Min:      5 Act:    8 Avg:    8 Max:      29 T: 1 (  187) P:80 I:1500 C: 367371 Min:      5 Act:    8 Avg:    7 Max:      44 T: 2 (  188) P:80 I:2000 C: 275529 Min:      7 Act:    8 Avg:    7 Max:      13 T: 3 (  189) P:80 I:2500 C: 220423 Min:      7 Act:    8 Avg:    7 Max:      11 T: 4 (  190) P:80 I:3000 C: 183685 Min:      5 Act:    8 Avg:    7 Max:      24 I have isolcpus=2,3 running, and I'm running a mainline 4.11 kernel with the rt patch, as well as an ethernet patch and usb otg patch. It is also a buildroot environment, so I'm not sure how much that is skewing these results in my favor. 
# uname -a Linux nanopi-neo 4.11.9-rt7 #1 SMP PREEMPT RT Fri Sep 22 10:38:22 CDT 2017 armv7l GNU/Linux
 

Hi. MitchD. Thanks for the fast reply.
 
I see you got 42 us with cmd cyclictest -p 80 -t5 -n. With same cmd my results is about 250 us.
master@orangepione:~/rt-tests$ sudo ./cyclictest -p 80 -t4 -n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 2.46 1.56 0.66 1/293 4110 T: 0 ( 3498) P:80 I:500 C: 335436 Min: 8 Act: 27 Avg: 24 Max: 235 T: 1 ( 3499) P:80 I:1000 C: 167700 Min: 7 Act: 32 Avg: 27 Max: 158 T: 2 ( 3500) P:80 I:1500 C: 111787 Min: 8 Act: 27 Avg: 24 Max: 128 T: 3 ( 3501) P:80 I:2000 C: 83830 Min: 7 Act: 32 Avg: 25 Max: 150 But when I use the -a parameter ( cyclictest -p 80 -t5 -n -a ) the latency becomes really wild.
Can you test your config with this cmd?
cyclictest -p 80 -t5 -n -a  

You can find discussion about this in another post on this forum: 
 
I find you don't get great latency in the legacy kernel, whereas my post with the mainline kernel has a max latency of 42 us.