MX_Master

Service monitoring and restart functionality can be made by any ARM Linux program or script. If you want to be shure that Linux OS is running normally, you can use a combination of ARM Linux program and ARISC program. If linux program didn't answering to ping from ARISC program, the ARISC program can restart whole device. I will use the ARISC firmware just for GPIO toggling. My ARM Linux program periodically will send to ARISC a commands to generate exact number of pulses on the specific GPIO pins, with specific frequency rate.

Thanks again to the jernej. Finally i got what i want. Now I can upload a firmware and run the ARISC core without any problems with armbian mainline kernel. Here is a test firmware source - https://github.com/MX-Master/h3-firmware/blob/test_3/main.c (simple leds blinking) Here is the uboot script source - https://github.com/MX-Master/h3-firmware/blob/test_3/fixup.cmd If somebody wants to test it.. the firmware blob and compiled uboot script can be found here https://github.com/MX-Master/h3-firmware/raw/test_3/h3-firmware.zip Tested with Orange Pi One and Armbian mainline image.

Thanks, I'll try these methods soon

Is it possible to use device tree and some overlays to enable editing of the R_CPUCFG?

I found this code in the uboot - https://github.com/RobertCNelson/u-boot/blob/master/arch/arm/cpu/armv7/sunxi/tzpc.c I have the CONFIG_MACH_SUN8I_H3 enabled in my armbian's uboot config. And how to make R_CPUCFG accessible from linux mainline? Rebuild the uboot with own code changes? Or we have an another way?

Thanks, I will try this right now.. Just checked this on armbian's mainline. No effect. I think I found a possible reason of my fails with ARISC core on the armbian's mainline. The R_CPUCFG (H3, 0x01F01C00) block of registers isn't accessible for reading/writing from userland. The SMTA (TZPC) (H3, 0x01C23400) block of registers isn't accessible too. I think R_CPUCFG is marked as secure, that is why I can't assert/de-assert reset for the ARISC core. Is anybody knows how to edit TZPC registers? * TZPC / SMTA = Trust Zone Protection Controller / Secure Memory Touch Arbiter

yep, I'm already there It's not a problem to wire some cheap STM32 boards via SPI to H3 boards. But we already have a co-processor inside the SoC. And this ARISC core not used in mainline kernel at all.

Found the way to load an ARISC blob to the SRAM A2. Here the loader - https://github.com/MX-Master/opi1_devmem_write. ARISC firmware code for testing - https://github.com/MX-Master/h3-firmware. Works fine with Armbian legacy kernel. No effect with Armbian mainline kernels.

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.

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..

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!

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

Has anybody a good latency after the RT-PREEMPT patch? I'm using Orange Pi One (H3), Ubuntu Desktop and legacy 3.4.113 kernel patched with 30-real-time143-full-plus-rt-fixes.patch. Also I have the isolcpus=3 enabled. And latency test results for this config is master@orangepione:~/rt-tests$ sudo ./cyclictest -a -t -n -p99 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 2.18 2.49 1.19 1/299 3693 T: 0 ( 3034) P:99 I:1000 C: 364441 Min: 7 Act: 31 Avg: 23 Max: 3655 T: 1 ( 3035) P:99 I:1500 C: 242985 Min: 7 Act: 32 Avg: 23 Max: 3578 T: 2 ( 3036) P:99 I:2000 C: 182252 Min: 7 Act: 43 Avg: 20 Max: 2198 T: 3 ( 3037) P:99 I:2500 C: 145802 Min: 9 Act: 30 Avg: 23 Max: 195 Max latency is about 3500 us. It's a bad result. So I tried this test with same config but without RT patched kernel. And results are master@orangepione:~/rt-tests$ sudo ./cyclictest -a -t -n -p99 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 2.32 2.57 1.45 3/270 3437 T: 0 ( 3034) P:99 I:1000 C: 561884 Min: 7 Act: 31 Avg: 23 Max: 3716 T: 1 ( 3035) P:99 I:1500 C: 374713 Min: 7 Act: 32 Avg: 23 Max: 3966 T: 2 ( 3036) P:99 I:2000 C: 281162 Min: 7 Act: 43 Avg: 20 Max: 2247 T: 3 ( 3037) P:99 I:2500 C: 26364 Min: 9 Act: 30 Avg: 23 Max: 97 Max latency is almost the same. Any ideas? If somebody using the RT kernel, please, show your latency results here. Thanks.

tmp solution is CONFIG_SECURITY_APPARMOR=n

Hi. I want to build a full RT legacy kernel using RT patch 30-real-time143-full-plus-rt-fixes.patch (option 5) for my Orange Pi One. While building I got the error at this line /sun8i/security/apparmor/sid.c#L28 static DEFINE_SPINLOCK(sid_lock); security/apparmor/sid.c:28:28: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘__cacheline_aligned_in_smp’ static DEFINE_SPINLOCK(sid_lock); ^ As seen in the patch file, top line's macro must be translated to static spinlock_t sid_lock __cacheline_aligned_in_smp = __SPIN_LOCK_UNLOCKED(sid_lock); ^ But at this moment I got the error. Any help?