MX_Master

Members
  • Content Count

    20
  • Joined

  • Last visited

About MX_Master

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. MX_Master

    wlan0 only works when eth0 plugged in

    /etc/network/interfaces # ... auto eth0 no-auto-down eth0 # ...
  2. MX_Master

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

    OpenRISC core (AR100) for the real-time tasks

    Thanks, I will try your drivers soon
  4. MX_Master

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

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

    OpenRISC core (AR100) for the real-time tasks

    Thanks, I'll try these methods soon
  7. MX_Master

    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?
  8. MX_Master

    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?
  9. MX_Master

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

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

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