OpenRISC core (AR100) for the real-time tasks


MX_Master
 Share

4 4

Recommended Posts

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?

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

There are some people in the linux-sunxi community that have started writing custom firmware for the AR100, do you follow #linux-sunxi on freenode? For hard real-time applications I would personally go for a setup where the motor control is done by a MCU (Cortex-Mx, AVR32...) and the high level stuff by a SBC...

Link to post
Share on other sites

47 minutes ago, Xalius said:

There are some people in the linux-sunxi community that have started writing custom firmware for the AR100, do you follow #linux-sunxi on freenode?

yep, I'm already there

 

53 minutes ago, Xalius said:

For hard real-time applications I would personally go for a setup where the motor control is done by a MCU (Cortex-Mx, AVR32...) and the high level stuff by a SBC...

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. 

Link to post
Share on other sites

1 hour ago, smaeul said:

@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/).

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

Link to post
Share on other sites

1 hour ago, MX_Master said:

Is anybody knows how to edit TZPC registers?

 

They are set in U-Boot. Just search through the code. For first try, you could even try with "mw.l" command from boot script. AFAIK, U-Boot runs on trusted level, but before starting Linux, it drops privileges.

Link to post
Share on other sites

24 minutes ago, jernej said:

They are set in U-Boot. Just search through the code. For first try, you could even try with "mw.l" command from boot script. AFAIK, U-Boot runs on trusted level, but before starting Linux, it drops privileges.

 

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

2 hours ago, MX_Master said:

run the ARISC core

Sorry for my question, can you ping a website regularly or a database on the device and if it doesn't reply write to the log and restart a service or the whole device ?

 

Beside the above, what is your use case?

Link to post
Share on other sites

6 hours ago, Tido said:

Sorry for my question, can you ping a website regularly or a database on the device and if it doesn't reply write to the log and restart a service or the whole device ?

 

Beside the above, what is your use case?

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. 

Link to post
Share on other sites

1 hour ago, kotc said:

@MX_Master: so, did you find what was off in armbian's uboot/kernel? because right now you are only sidestepping problem by loading via uboot

 

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.

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

4 4