Jump to content

Testers wanted Real Time Kernel image builds for H3 boards


markbirss

Recommended Posts

Hi All

 

The "real time" kernel patches are included in Igor's Armbian build tools, but are disabled by default.

 

Enabling them are simple. (Thanks Igor)

 

Build "real time" kernel images by doing the following:

 

refer to

https://github.com/igorpecovnik/lib

Execution

apt-get -y install git
git clone https://github.com/igorpecovnik/lib--depth 1
cp lib/compile.sh .

mv ./lib/patch/kernel/sun7i-default/0014-patch-3.4.108-rt136.patch.disabled ./lib/patch/kernel/sun7i-default/0014-patch-3.4.108-rt136.patch

./compile.sh
user@uservm:~/armbian$ ./compile.sh 
[ warn ] This script requires root privileges
[sudo] password for user: 
[ o.k. ] This script will try to update
Already up-to-date.
[ warn ] Can't update since you made changes to: 
patch/kernel/sun7i-default/0014-patch-3.4.108-rt136.patch.disabled
Press <Ctrl-C> to abort compilation, <Enter> to ignore and continue

 

Press "Enter" to continue

 

Confirm you are running a RT kernel by checking "uname -a" output for PREEMPT

 

e.g

 

Linux orangepiplus2e 3.4.112-sun8i #8 SMP PREEMPT Wed Oct 12 22:04:24 SAST 2016 armv7l GNU/Linux

 

 

Further reading

 

 

Benchmark with

tar xvfz  rt-tests-1.0.tar.gz
cd rt-tests
make
sudo ./cyclictest -p 80 -t5 -n

Your feedback on tests are welcomed

Enjoy

Link to comment
Share on other sites


nanopineo login: root

Password:

Last login: Tue Nov 8 13:30:15 EET 2016 on ttyS0

Linux nanopineo 3.4.113-rt143-sun8i #20 SMP PREEMPT RT Tue Nov 8 11:40:48 EET 2016 armv7l

_ _ ____ _ _ _

| \ | | __ _ _ __ ___ | _ \(_) | \ | | ___ ___

| \| |/ _` | '_ \ / _ \| |_) | | | \| |/ _ \/ _ \

| |\ | (_| | | | | (_) | __/| | | |\ | __/ (_) |

|_| \_|\__,_|_| |_|\___/|_| |_| |_| \_|\___|\___/

 

 

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.113-rt143-sun8i

System load: 0.16 Up time: 17 min

Memory usage: 10 % of 490Mb IP:

CPU temp: 44°C

Usage of /: 7% of 15G

 

root@nanopineo:~# rt-tests-1.0/cyclictest -p 80 -t5 -n

# /dev/cpu_dma_latency set to 0us

policy: fifo: loadavg: 0.03 0.22 0.19 1/119 1750

 

T: 0 ( 1743) P:80 I:1000 C: 72501 Min: 33 Act: 55 Avg: 55 Max: 144

T: 1 ( 1744) P:80 I:1500 C: 48334 Min: 35 Act: 56 Avg: 57 Max: 178

T: 2 ( 1745) P:80 I:2000 C: 36250 Min: 34 Act: 46 Avg: 55 Max: 149

T: 3 ( 1746) P:80 I:2500 C: 29000 Min: 33 Act: 45 Avg: 59 Max: 156

T: 4 ( 1747) P:80 I:3000 C: 24166 Min: 39 Act: 47 Avg: 54 Max: 201

 

 

Link to comment
Share on other sites

It was reported working few weeks ago - do some search on forum for more info.

 

You have to enable patch and recompile kernel but ... IIRC one RT configuration is broken, while others works. 

Link to comment
Share on other sites

Hi all,

i use SPI to connect Nanopi-Zero with FPGA on my board.

Mainline kernel SPI driver works much better for me, but I still have some critical lags in SPI communications.

Is RT patch available for mainline linux (i have 4.11.9-sun8i) ?

 

thank you.

Link to comment
Share on other sites

If you want the cyclictest results from a mainline kernel, here are mine:

 

Linux nanopi-neo 4.11.9-rt7 #2 SMP PREEMPT RT Mon Aug 7 21:41:13 CDT 2017 armv7l GNU/Linux

 

# cyclictest -p 80 -t5 -n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.05 0.05 0.01 1/96 220          

T: 0 (  208) P:80 I:1000 C: 572399 Min:      5 Act:    6 Avg:    8 Max:      42
T: 1 (  209) P:80 I:1500 C: 381600 Min:      6 Act:    9 Avg:    8 Max:      34
T: 2 (  210) P:80 I:2000 C: 286200 Min:      5 Act:    9 Avg:    7 Max:      25
T: 3 (  211) P:80 I:2500 C: 228960 Min:      6 Act:    9 Avg:    8 Max:      29
T: 4 (  212) P:80 I:3000 C: 190800 Min:      5 Act:   11 Avg:    8 Max:      30
 

Link to comment
Share on other sites

I've managed to patch armbian kernel. At first glance looks ok, need to do more tests. I haven't work with Linux RT before

 

Linux nanopineo 4.11.12-rt13-sun8i #5 SMP PREEMPT RT Sun Sep 10 20:19:58 CDT 2017 armv7l armv7l armv7l GNU/Linux

Link to comment
Share on other sites

On 2017/9/11 at 10:37 AM, mycnc said:

I've managed to patch armbian kernel. At first glance looks ok, need to do more tests. I haven't work with Linux RT before

 

Linux nanopineo 4.11.12-rt13-sun8i #5 SMP PREEMPT RT Sun Sep 10 20:19:58 CDT 2017 armv7l armv7l armv7l GNU/Linux

 

I've been struggling patching the vendor kernel. Did you have any issues patching the armbian mainline kernel?

Link to comment
Share on other sites

Hello.

Thanks for the posts, very helpfull

For sun8i, there is no 0014 patch (RT). I want to use it for an Orange pi zero SoC (which uses the H2+ (similar to H3 processor)). So is the path the same (i dont think so???), and would it work to download the patch form the RT project page (kernel.org....), and us it???

Thanks in advance.

 

Link to comment
Share on other sites

Hi,

i tested my application with mainline kernel and found RT mode does not work properly.

Looks like RT features are not enabled despite on correct "uname -a" output.

 

Right now i'm waiting next Armbian release in hope Armbian team have got solution.

Legacy kernel RT works fine, but SPI driver is not suitable for me.

 

Any advice very appreciated since i've passed deadline quite long ago

Link to comment
Share on other sites

On 11/7/2017 at 1:02 AM, Igor said:

Have you try those perhaps:

 

 

Hi, thanks for the message.

 

I tried and have got -

 

sudo ./cyclictest -p 80 -t5 -n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.39 3.37 1.95 1/143 1871          

T: 0 ( 1857) P:80 I:1000 C:   5309 Min:     12 Act:   17 Avg:   59 Max:    1987
T: 1 ( 1858) P:80 I:1500 C:   3560 Min:     12 Act:   18 Avg:   67 Max:    2705
T: 2 ( 1859) P:80 I:2000 C:   2673 Min:     13 Act:   25 Avg:   75 Max:    3456
T: 3 ( 1860) P:80 I:2500 C:   2140 Min:     13 Act:   21 Avg:   68 Max:    2712
T: 4 ( 1861) P:80 I:3000 C:   1784 Min:     13 Act:   25 Avg:   78 Max:    2601

 

About the same result for idle & heavy load.

 

For normal kernel I have Max=6-7ms while idle and up to 50ms while heavy loading.

So looks like RT path works, but works not really good and much worse than legacy kernel.

 

Any advice ? or wait next releases ?

 

 

 

Link to comment
Share on other sites

Hi all,

 

Just wanted to share that I got the realtime patch working on an Orange Pi Zero on 4.18.8

I used the armbian build environment and the official RT patch.

 

A few tricky points were the CPU govenor and CPU operating points automatically switching by default, causing the realtime behavior to be really bad (max spikes around 3000 in cpu test).

By patching the device tree to only use a fixed operating point, I achieve the following output:

Linux orangepizero 4.14.8-rt9-sunxi #1 SMP PREEMPT RT Sat Jan 6 14:36:31 CET 2018 armv7l armv7l armv7l GNU/Linux
/root/rt-tests/cyclictest -p 80 -t5 –n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.85 0.49 0.22 4/168 3083

T: 0 ( 3079) P:80 I:1000 C:   3297 Min:      8 Act:   17 Avg:   16 Max:      66
T: 1 ( 3080) P:80 I:1500 C:   2198 Min:      8 Act:   24 Avg:   15 Max:      50
T: 2 ( 3081) P:80 I:2000 C:   1648 Min:      8 Act:   11 Avg:   16 Max:      60
T: 3 ( 3082) P:80 I:2500 C:   1318 Min:      8 Act:   12 Avg:   15 Max:      44
T: 4 ( 3083) P:80 I:3000 C:   1098 Min:      9 Act:   17 Avg:   18 Max:      57

 

If anyone is interested, I used this realtime kernel to run a virtual wifi guitar amplifier on the orange pi zero.

I documented the entire thing on http://arre234.blogspot.be/2018/02/linux-portable-wifi-guitar-amp-on.html , including the device tree and cpu govenor stuff.

 

Hope this helps anyone

 

Arnout

Link to comment
Share on other sites

On 24/02/2018 at 2:02 PM, arre said:

Olá a todos,

 

Só queria compartilhar que recebi o patch em tempo real trabalhando em um Orange Pi Zero em 4.18.8

Usei o ambiente de compilação de armbian e o patch RT oficial.

 

Alguns pontos complicados foram o CPU govenor e os pontos de operação da CPU alternando automaticamente por padrão, fazendo com que o comportamento em tempo real seja realmente ruim (max pontos em torno de 3000 no teste de CPU).

Ao corrigir a árvore do dispositivo para usar apenas um ponto de operação fixo, eu consigo a seguinte saída:



 

Se alguém estiver interessado, usei esse kernel em tempo real para executar um amplificador de guitarra virtual wifi na laranja pi zero.

Eu documentei o assunto inteiro em  http://arre234.blogspot.be/2018/02/linux-portable-wifi-guitar-amp-on.html  , incluindo a árvore do dispositivo e o material do cpu govenor.

 

Espero que isso ajude alguém

 

Arnout

Hi Arnout I am very appreciate your work, but i have a question. I don't understand the part of Doing a small patch, is edited the 4.18.8-RT 9.patch? how to make this?
Thank you and sorry my ingles!!!

Link to comment
Share on other sites

@andreluiz109 : 

 

I did a small patch to the build system, to force it to not take the latest linux kernel, but a specific one. Perhaps there was an option in the armbian build system to specify this but I did not immediately find it.

The reason why this is important, is that the linux RT patches are only applicable to a very specific kernel version. (e:g: the 4.18.8-RT 9 patch MUST be applied to the linux kernel 4.18.8 tag). 

That's why I did the following patch to the armbian build system (armbian build-system tag 9531d1bc7ecd0f468e29e402ba00cbc7b7dd683f) :

 

diff --git a/config/sources/sunxi_common.inc b/config/sources/sunxi_common.inc
index 4fc872f..aae8829 100644
--- a/config/sources/sunxi_common.inc
+++ b/config/sources/sunxi_common.inc
@@ -24,7 +24,8 @@ case $BRANCH in

        next)
        KERNELSOURCE=$MAINLINE_KERNEL_SOURCE
-       KERNELBRANCH='branch:linux-4.14.y'
+       #KERNELBRANCH='branch:linux-4.14.y'
+       KERNELBRANCH='tag:v4.14.8'
        KERNELDIR=$MAINLINE_KERNEL_DIR

        GOVERNOR=ondemand

 

The easiest way to apply this patch is .. to edit sunxi_common.inc, comment the kernel branch and force it to a fixed version.   

This patch has nothing to do with the actual linux RT patch, which you can just place in the correct directory, and armbian will apply it for you.

 

Anyway, I'd recommend the following approach if you want to build the kernel yourself:

- First see that you can build -a- armbian kernel (you should find enough documentation online for this)

- Then try and build a specific linux kernel version (e.g. the 4.18.8 if you want to reproduce my build)

- Then build it while applying the 4.18.8-RT 9 patch (by putting the patch file in userpatches/kernel/sunxi-next/patch-4.14.8-rt9.patch), and applying the correct config setings when prompted

 

Note that if you have never built a kernel before, this can be a bit daunting, but you'll get there eventually. Alternatively, you can just take the precompiled image from my blog's site (SD card image), and work from there.

 

Good luck!

Link to comment
Share on other sites

On 22/04/2018 at 10:45 AM, arre said:

@andreluiz109 : 

 

I did a small patch to the build system, to force it to not take the latest linux kernel, but a specific one. Perhaps there was an option in the armbian build system to specify this but I did not immediately find it.

The reason why this is important, is that the linux RT patches are only applicable to a very specific kernel version. (e:g: the 4.18.8-RT 9 patch MUST be applied to the linux kernel 4.18.8 tag). 

That's why I did the following patch to the armbian build system (armbian build-system tag 9531d1bc7ecd0f468e29e402ba00cbc7b7dd683f) :

 


diff --git a/config/sources/sunxi_common.inc b/config/sources/sunxi_common.inc
index 4fc872f..aae8829 100644
--- a/config/sources/sunxi_common.inc
+++ b/config/sources/sunxi_common.inc
@@ -24,7 +24,8 @@ case $BRANCH in

        next)
        KERNELSOURCE=$MAINLINE_KERNEL_SOURCE
-       KERNELBRANCH='branch:linux-4.14.y'
+       #KERNELBRANCH='branch:linux-4.14.y'
+       KERNELBRANCH='tag:v4.14.8'
        KERNELDIR=$MAINLINE_KERNEL_DIR

        GOVERNOR=ondemand

 

The easiest way to apply this patch is .. to edit sunxi_common.inc, comment the kernel branch and force it to a fixed version.   

This patch has nothing to do with the actual linux RT patch, which you can just place in the correct directory, and armbian will apply it for you.

 

Anyway, I'd recommend the following approach if you want to build the kernel yourself:

- First see that you can build -a- armbian kernel (you should find enough documentation online for this)

- Then try and build a specific linux kernel version (e.g. the 4.18.8 if you want to reproduce my build)

- Then build it while applying the 4.18.8-RT 9 patch (by putting the patch file in userpatches/kernel/sunxi-next/patch-4.14.8-rt9.patch), and applying the correct config setings when prompted

 

Note that if you have never built a kernel before, this can be a bit daunting, but you'll get there eventually. Alternatively, you can just take the precompiled image from my blog's site (SD card image), and work from there.

 

Good luck!

I'm really finding it complicated to compile the kernel with the RT patch. At the end of the build, will I generate a .deb file to be installed on the system already in use? (eg I installed the Armbian_5.35_Orangepizero_Ubuntu_xenial_next_4.13.16.img image on my SD card, so if I have the .deb kernel already compiled with the RT patch I can have my RT system PREEMPT ???
I tried to modify its already compiled image of the blog but I could not, I could not uninstall the guitar modulator and etc, because my project would not be necessary in these programs. Would there be some other way to help me or some things I can read to help me make my RT kernel for orenge pi zero H2 + ?? Thank you very much everyone's attention. sorry to be noob!!!

Link to comment
Share on other sites

I just install armbian on orangepizero, and get this,

uname -a

Linux orangepizero 3.4.113-sun8i #18 SMP PREEMPT Wed Jan 24 22:10:49 CET 2018 armv7l armv7l armv7l GNU/Linux

 

does this mean, this patch is enabled by default now ?
 

Link to comment
Share on other sites

20 hours ago, arre said:

There is a difference between PREEMPT and PREEMPT RT. So no, the real time patch was not enabled on your kernel

I Just complie the kernel and uboot  in virtualbox,

and I copied the output file "linux-image-sun8i_5.45_armhf.deb" to the orange pi zero,

in orange pi zero,I run "dpkg -i linux-image-sun8i_5.45_armhf.deb",

After this ,I rebooted,

and then i run "uname -a ",

but I still get the same output "Linux orangepizero 3.4.113-sun8i #4 SMP PREEMPT Sun May 27 11:03:31 CST 2018 armv7l armv7l armv7l GNU/Linux".

 

Have I missed any steps ?

 

Link to comment
Share on other sites

Hello, I'm trying to apply the described procedure to OrangePrime. Unfortunatly it tries to download kernel packages. I've tried the patch with no luck. Afterwards, I've downloaded a kernel and matching RT patch, put in /build directory and edited /config/lib/configuration.sh to change REVISION="5.45XX" to "5.41", to match downloaded kernel (4.14.18).

Selected PREEMPT_RT_FULL and got:

 

kernel/softirq.c:806:2: error: #else without #if
 #else /* PREEMPT_RT_FULL */
  ^~~~
kernel/softirq.c:807:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]

 

What should I do?

 

Thanks in advance,

Link to comment
Share on other sites

So I am a NOOB to RT, and it has been a few years since I compiled a kernel

 

I am trying to compile PREEMPT RT for NanoPi NEO 2 (H5) or NanoPi NEO AIR (H3).

 

Do I need to

(1) rename 30-real-time143-full-plus-rt-fixes.patch.disabled

AND

(2) extract patches-4.14.52-rt34.tar.gz into userpatches ?

 

Using just option (1) I don't get a modified kernel .config file, so cannot select  Fully Preemptive.

 

I have modified config-default.conf. KERNEL_ONLY, KERNEL_CONFIGURE and KERNEL_KEEP_CONFIG are all "yes"

config-default.conf:

# Read build script documentation http://www.armbian.com/using-armbian-tools/
# for detailed explanation of these options and for additional options not listed here

KERNEL_ONLY="yes"                       # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
KERNEL_CONFIGURE="yes"                  # leave empty to select each time, set to "yes" or "no" to skip dialog prompt
CLEAN_LEVEL="make,debs,oldcache"        # comma-separated list of clean targets: "make" = make clean for selected kernel and u-boot,
                                        # "debs" = delete packages in "./output/debs" for current branch and family,
                                        # "alldebs" = delete all packages in "./output/debs", "images" = delete "./output/images",
                                        # "cache" = delete "./output/cache", "sources" = delete "./sources"
                                        # "oldcache" = remove old cached rootfs except for the newest 6 files

DEST_LANG="en_US.UTF-8"                 # sl_SI.UTF-8, en_US.UTF-8

BOARD=""

# advanced
KERNEL_KEEP_CONFIG="yes"                        # do not overwrite kernel config before compilation
EXTERNAL="yes"                          # build and install extra applications and drivers
EXTERNAL_NEW="prebuilt"                 # compile and install or install prebuilt additional packages
CREATE_PATCHES="no"                     # wait that you make changes to uboot and kernel source and creates patches
BUILD_ALL="no"                          # cycle through available boards and make images or kernel/u-boot packages.
                                        # set KERNEL_ONLY to "yes" or "no" to build all packages/all images

BSPFREEZE=""                            # freeze armbian packages (u-boot, kernel, dtb)
INSTALL_HEADERS=""                      # install kernel headers package
LIB_TAG="master"                        # change to "branchname" to use any branch currently available.

After compiling (admittedly on Ubuntu  16.04.4 x64, not Ubuntu Bionic 18.04 x64) I scp the resulting .deb's to the board (NanoPi NEO 2 shown), then

pi@nanopineo2:~$ sudo dpkg -i *.deb
(Reading database ... 52634 files and directories currently installed.)
Preparing to unpack linux-dtb-next-sunxi64_5.50_arm64.deb ...
Unpacking linux-dtb-next-sunxi64 (5.50) over (5.50) ...
Preparing to unpack linux-headers-next-sunxi64_5.50_arm64.deb ...
Unpacking linux-headers-next-sunxi64 (5.50) over (5.50) ...
Preparing to unpack linux-image-next-sunxi64_5.50_arm64.deb ...
Unpacking linux-image-next-sunxi64 (5.50) over (5.50) ...
Preparing to unpack linux-source-next-sunxi64_5.50_all.deb ...
Unpacking linux-source-4.14.52-next-sunxi64 (4.14.52-next-sunxi64+5.50) over (4.14.52-next-sunxi64+5.50) ...
Preparing to unpack linux-u-boot-next-nanopineo2_5.50_arm64.deb ...
Unpacking linux-u-boot-nanopineo2-next (5.50) over (5.50) ...
Setting up linux-dtb-next-sunxi64 (5.50) ...
Setting up linux-headers-next-sunxi64 (5.50) ...
Compiling headers - please wait ...
Setting up linux-image-next-sunxi64 (5.50) ...
update-initramfs: Generating /boot/initrd.img-4.14.52-rt34-sunxi64
update-initramfs: Converting to u-boot format
Setting up linux-source-4.14.52-next-sunxi64 (4.14.52-next-sunxi64+5.50) ...
Setting up linux-u-boot-nanopineo2-next (5.50) ...
Updating u-boot on /dev/mmcblk0

Using either just option (2), or both (1) and (2) combined, I get similar results :

pi@nanopineo2:~/rt-tests-1.0$ sudo ./cyclictest -p 80 -t5 -n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.08 0.10 0.05 1/126 1901

T: 0 ( 1873) P:80 I:1000 C:  22898 Min:      7 Act:   10 Avg:  103 Max:    2070
T: 1 ( 1874) P:80 I:1500 C:  15409 Min:      7 Act:   11 Avg:  110 Max:    2004
T: 2 ( 1875) P:80 I:2000 C:  11570 Min:      7 Act:    9 Avg:  113 Max:    2197
T: 3 ( 1876) P:80 I:2500 C:   9257 Min:      7 Act:    8 Avg:  129 Max:    1938
T: 4 ( 1877) P:80 I:3000 C:   7714 Min:      7 Act:   10 Avg:  129 Max:    1969

These results suggest to me that I don't have an RT kernel. however uname says different:

pi@nanopineo2:~/rt-tests-1.0$ uname -a
Linux nanopineo2 4.14.52-rt34-sunxi64 #15 SMP PREEMPT RT Mon Jul 2 08:58:04 AWST 2018 aarch64 aarch64 aarch64 GNU/Linux

 

As I said in the first line NOOB here. Where have I gone wrong?

Edited by ITNavigate
Added "?" to first question :-)
Link to comment
Share on other sites

So I found the answers to my questions:

11 hours ago, ITNavigate said:

Do I need to

(1) rename 30-real-time143-full-plus-rt-fixes.patch.disabled

AND

(2) extract patches-4.14.52-rt34.tar.gz into userpatches ?

 

My experience says that only step 2 is required.

 

11 hours ago, ITNavigate said:

Using either just option (2), or both (1) and (2) combined, I get similar results :


pi@nanopineo2:~/rt-tests-1.0$ sudo ./cyclictest -p 80 -t5 -n
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.08 0.10 0.05 1/126 1901

T: 0 ( 1873) P:80 I:1000 C:  22898 Min:      7 Act:   10 Avg:  103 Max:    2070
T: 1 ( 1874) P:80 I:1500 C:  15409 Min:      7 Act:   11 Avg:  110 Max:    2004
T: 2 ( 1875) P:80 I:2000 C:  11570 Min:      7 Act:    9 Avg:  113 Max:    2197
T: 3 ( 1876) P:80 I:2500 C:   9257 Min:      7 Act:    8 Avg:  129 Max:    1938
T: 4 ( 1877) P:80 I:3000 C:   7714 Min:      7 Act:   10 Avg:  129 Max:    1969

These results suggest to me that I don't have an RT kernel. however uname says different:


pi@nanopineo2:~/rt-tests-1.0$ uname -a
Linux nanopineo2 4.14.52-rt34-sunxi64 #15 SMP PREEMPT RT Mon Jul 2 08:58:04 AWST 2018 aarch64 aarch64 aarch64 GNU/Linux

 

As I said in the first line NOOB here. Where have I gone wrong?

 

Where did I go wrong?? I didn't read @arre's wonderful blog (http://arre234.blogspot.com/2018/02/linux-portable-wifi-guitar-amp-on.html) properly. He clearly states in his earlier post in this thread :

Quote

A few tricky points were the CPU govenor and CPU operating points automatically switching by default, causing the realtime behavior to be really bad (max spikes around 3000 in cpu test).

By patching the device tree to only use a fixed operating point, I achieve the following output:

 

In the blog post he details how he resolved these issues.

Setting the scaling governor to userspace, and specifying the freq and speed resolved my issues.

 

I still need to investigate how to remove the operation points from the device tree, but that should just be a little searching and reading.

 

Link to comment
Share on other sites

your progress is awesome, im a newbie in that topic.

 

i've tried the machinekit distro from http://orange-cnc.ru/ its in russian by default so i had to change language first to try. 

 

could you guys make a flashable IMG for the OrangePI ONE, im trying to implement a new CNC machine. The image form the russian webpage has very bad latency results. there is something written about a coprocessor that supports good stepping pulses but i dont understand whats ment. :)

 

i'm looking forward to use linuxcnc, because i think its just much better than MACH3. cheers

Link to comment
Share on other sites

2 hours ago, maxias said:

i've tried the machinekit distro from http://orange-cnc.ru/ its in russian by default so i had to change language first to try. 

 

could you guys make a flashable IMG for the OrangePI ONE, im trying to implement a new CNC machine. The image form the russian webpage has very bad latency results. there is something written about a coprocessor that supports good stepping pulses but i dont understand whats ment. :)

 

i'm looking forward to use linuxcnc, because i think its just much better than MACH3. cheers

 

Try this one - https://github.com/orange-cnc/armbian_build/releases/tag/v2018.07.opi1

Image, based on Debian Jessie, has the best latency values. About 30-50 us.

 

orange-cnc - it's my free project, co-processor driver for the Machinekit has "work in progress" state

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines