MX_Master

Members
  • Content count

    19
  • Joined

  • Last visited

  1. OpenRISC core (AR100) for the real-time tasks

    jernej is right. And your uboot config has the option CONFIG_OLD_SUNXI_KERNEL_COMPAT=y that is why you can edit the secure R_... registers from userspace loader in any mainline kernel.
  2. OpenRISC core (AR100) for the real-time tasks

    Thanks, I will try your drivers soon
  3. OpenRISC core (AR100) for the real-time tasks

    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.
  4. OpenRISC core (AR100) for the real-time tasks

    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.
  5. OpenRISC core (AR100) for the real-time tasks

    Thanks, I'll try these methods soon
  6. OpenRISC core (AR100) for the real-time tasks

    Is it possible to use device tree and some overlays to enable editing of the R_CPUCFG?
  7. OpenRISC core (AR100) for the real-time tasks

    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?
  8. OpenRISC core (AR100) for the real-time tasks

    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
  9. OpenRISC core (AR100) for the real-time tasks

    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.
  10. OpenRISC core (AR100) for the real-time tasks

    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.
  11. 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?
  12. I'm using Machinekit with my GPIO driver. I have a big CNC machine (4 axes). yep. 2279 microseconds is bad result
  13. If somebody interested, here is a few photos where LinuxCNC running on the Orange Pi One. Debian Jessie, FULL RT patch.
  14. 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..
  15. 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!