Real time operating system

[Alyn]

Need to know if there is any real time operating system for nanopi M1 plus.

[Igor]

You can build one with Armbian build system + RT patches from here: https://rt.wiki.kernel.org/index.php/Main_Page

[Hu12]

Thanks for your help ! Working on it

[Alyn]

Oh then there is no ready real time os i have to add a patch file then it will act as a real time os ! 

Thanks

[mycnc]

 

On 9/5/2019 at 1:47 AM, Igor said:

You can build one with Armbian build system + RT patches from here: https://rt.wiki.kernel.org/index.php/Main_Page

Hi there.

I remember there were "disabled" RT patch included. Did you remove it from the package?

[Igor]

4 minutes ago, mycnc said:

Did you remove it from the package?

 

We remove legacy kernels - where patch was a part of the patchset. With modern, you go and grab one from RT pages and add to user patches. We don't maintain this part.

[mycnc]

Thanks for reply.

I've done RT kernel 3 years ago, works fine for me, 

but now found a bug with RTS/CTS for H3 uart and need to update.

 

I see the latest RT patches 4.19.106, but Armbian uses 4.19.115.

Is any way to roll back Armbian to 4.19.106 ?

 

I'm going to check "current" branch now.

 

 

[mycnc]

the same about "current" version - 

Armbian 5.4.32 and the latest RT patch 5.4.28

 

Please any advice how to rollback Armbian kernel?

Maybe some archive with 4.19.106 (or 5.4.28) kernel with Armbian patches?

 

[Igor]

You will need to build a specific version by building with a parameter KERNELBRANCH="tag:v5.4.32" and hope that patches will not have troubles to apply.

[mycnc]

I run 

 

./compile.sh  KERNELBRANCH="tag:v5.4.28"
 

but looks like the option is ignored and 5.4.32 downloaded.

Any advice?

[Igor]

Try to put this parameter to userpatches/lib.config

[mycnc]

34 minutes ago, Igor said:

Try to put this parameter to userpatches/lib.config

yes, this works. Now I'm able to play with the patches. Thank you for help.

[indianajones]

I realize it's almost exactly one year later,  but I'm trying to same thing for nanopineo.  I copied patch-5.4.28-rt19.patch (to userpatches/kernel/sunxi-legacy),  and put KERNELBRANCH="tag:v5.4.28" into lib.config, and the build tool says that tag v.5.4.28 doesn't exist:

 

[ o.k. ] Using config file [ /home/armbian/build/userpatches/config-example.conf ]
[ o.k. ] Command line: setting BOARD to [ nanopineo ]
[ o.k. ] Command line: setting BRANCH to [ legacy ]
[ o.k. ] Command line: setting RELEASE to [ focal ]
[ o.k. ] Command line: setting KERNEL_ONLY to [ no ]
[ o.k. ] Command line: setting BUILD_MINIMAL to [ yes ]
[ o.k. ] Command line: setting BUILD_DESKTOP to [ no ]
[ o.k. ] Command line: setting KERNEL_CONFIGURE to [ yes ]
[ o.k. ] Command line: setting DEFAULT_HOSTNAME to [ eid-00000000 ]
[ o.k. ] Command line: setting AUFS to [ no ]
[ o.k. ] Using user configuration override [ /home/armbian/build/userpatches/lib.config ]
[ o.k. ] Preparing [ host ]
[ o.k. ] Build host OS release [ focal ]
[ o.k. ] Syncing clock [ host ]
[ o.k. ] Checking for external GCC compilers 
[ o.k. ] Downloading sources 
[ o.k. ] Checking git sources [ u-boot v2021.04 ]
[ .... ]  Cleaning ....  [ 99 files ]
[ o.k. ] Checking git sources [ linux-mainline v5.4.28 ]
[ .... ] Fetching updates 
fatal: couldn't find remote ref tags/v5.4.28

 

Can anyone tell what I'm doing wrong?  Thanks.

 

PS - these tools are awesome

[Igor]

2 hours ago, indianajones said:

Can anyone tell what I'm doing wrong? 

Build script told you  For sunxi we don't use mainline Linux directly:
https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi_common.inc#L16

There those tags doesn't exists. You will need to solve this differently. Quick way is to pick a ="commit:ID"

[Dante Alighieri]

Why bother with this garbage? Get a proper machine with PROPER software instead of this waste of time

[guidol]

1 hour ago, Dante Alighieri said:

Why bother with this garbage? Get a proper machine with PROPER software instead of this waste of time

because we can
If you dont like other SBCs like the RPi (I did read all your content on this forum) then do ua a favour and use only RPI-SBCs.
If you also could see we didnt support here the RPi.
If you want to help us its OK, but only to tell that we use "garbage" SBCs isnt helpful. And many here can use this "garbage" very well and

they arent a copy, because they use very different hardware.
If they were a cop they could use the "great Raspbian".

But for us armbian is mostly better. The Raspberry and Raspbian has a much wider user-base and more support from companys - thats right, but also

they doesnt do all things right ans so for some soultion a alternativ SBC and OS is better for some of us.

[NicoD]

2 hours ago, Dante Alighieri said:

Why bother with this garbage? ...waste of time

I was thinking exactly the same question. Why do you bother and waste your time here if you don't like Armbian?
Lately I've red few complaints of people who have "many years of experience". But they don't want to bother reading and learning new skills. 
Experience is not the same as knowledge
As knowledge is not the same as experience

With experience you can have gained knowledge about much but not being specialized at one thing, or know a lot about a small section of the industry and be blind to all other.

Thousands of people happily use Armbian on their devices and for 99% of the usecases everything is fine. The other 1% we try to help here. 

I've made tons of informative videos about SBCs. I show how to do all the basic stuff, and some more advanced things. 

https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg/search?query=armbian
The forum also has the Reviews, Tutorials and Hacks section where almost everything you could want to learn about Armbian is explained.
https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/
Then there is Armbian Docs also full of information.
https://docs.armbian.com/

All these things have cost us time, and so also money. We are here to serve. And then you say our work is "garbage".
Sorry, but I do not take that lightly.

You can't teach someone who is convinced to know it all. Greetings.

[indianajones]

6 hours ago, Igor said:

Build script told you  For sunxi we don't use mainline Linux directly:
https://github.com/armbian/build/blob/master/config/sources/families/include/sunxi_common.inc#L16

There those tags doesn't exists. You will need to solve this differently. Quick way is to pick a ="commit:ID"

 

So that explains the reference to https://github.com/megous/linux/tree/orange-pi-5.4 inside sunxi_common.inc.   I assume this also means that since I'm trying using an RT patch file on a fork of mainline Linux rather than the actual mainline Linux, that there's a good chance that the patch will produce a compiler error.  (As an aside, I wonder how @mycnc was able to use "tag:v5.4.28" successfully since he was also using the AllWinner H3.)

 

Now that I understand why I got this error, I'll see if I can resolve it.  Thanks, Igor.

[indianajones]

50 minutes ago, NicoD said:

I was thinking exactly the same question. Why do you bother and waste your time here if you don't like Armbian?
Lately I've red few complaints of people who have "many years of experience". But they don't want to bother reading and learning new skills. 
Experience is not the same as knowledge
As knowledge is not the same as experience

With experience you can have gained knowledge about much but not being specialized at one thing, or know a lot about a small section of the industry and be blind to all other.

Thousands of people happily use Armbian on their devices and for 99% of the usecases everything is fine. The other 1% we try to help here. 

I've made tons of informative videos about SBCs. I show how to do all the basic stuff, and some more advanced things. 

https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg/search?query=armbian
The forum also has the Reviews, Tutorials and Hacks section where almost everything you could want to learn about Armbian is explained.
https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/
Then there is Armbian Docs also full of information.
https://docs.armbian.com/

All these things have cost us time, and so also money. We are here to serve. And then you say our work is "garbage".
Sorry, but I do not take that lightly.

You can't teach someone who is convinced to know it all. Greetings.

 

NicoD, your YouTube videos are why I chose Armbian.  I think the Armbian tools are awesome, and I'm grateful to those who created and maintain it.

[Igor]

30 minutes ago, indianajones said:

I assume this also means that since I'm trying using an RT patch file on a fork of mainline Linux rather than the actual mainline Linux

Code difference is mainly in Allwinner specific areas which RT patch doesn't adjust. If you need more challenges that are aligned with our wishes - create and move diff between this fork and mainline to patches and change to mainline source.

[indianajones]

1 hour ago, Igor said:

Code difference is mainly in Allwinner specific areas which RT patch doesn't adjust. If you need more challenges that are aligned with our wishes - create and move diff between this fork and mainline to patches and change to mainline source.

 

C language was all I did - last century! I'd love to contribute any changes I need to make, but at the moment, the language is barely recognizable anymore. Such a shame.

[Werner]

Maybe some day we can switch back to mainline for Allwinner but at this moment it makes more sense to use megi's pre-patched sources.

[lanefu]

Here's an example of adding RT patches to allwinner build.

https://github.com/lanefu/build/commits/RTAttempt

[tparys]

Are the existing real time classes in the CPU and I/O schedulers not enough in the standard kernel?

 

Substantial portions of the RT patch set were merged back in kernel 2.6, and we're substantially past that point now.

[indianajones]

13 minutes ago, tparys said:

Are the existing real time classes in the CPU and I/O schedulers not enough in the standard kernel?

 

Substantial portions of the RT patch set were merged back in kernel 2.6, and we're substantially past that point now.

 

Thanks for the link and information.  To be honest, I'm approaching this from a position of ignorance.  I need to be able to read wiegand data from GPIO pins on the H3, but (a) I'm not creating some toy with a while() loop, I'm creating a real product that will be doing real things while reading wiegand data, and (b) I assume that RT will give me the most reliable determinism for reading pins at 50-200uS timings that wiegand uses.  I believe that one way to do that is with a more deterministic kernel.  I've tried 5.4 and 5.10 variants, and all of them fail to compile when I include an RT patch, regardless of which RT patch version I pick.  Do you think v5.10 includes sufficient improvements for GPIO pin reading?

[tparys]

1 hour ago, indianajones said:

 

most reliable determinism for reading pins at 50-200uS timings that wiegand uses.

 

You might be in microcontroller territory at those signaling rates. I've done something similar with the stock Ubuntu 16.04 (4.4) kernel, but I'm not going to say it's the most reliable, and I'm not sure I'd recommend it. If you must do that, I'd also suggest locking your application to a single core with sched_setaffinity(), and avoid any calls to sleep(), usleep(), or nanosleep(). The kernel scheduler does not have the granularity you want. Hammer gettimeofday() in a busy loop to do your timing.

[indianajones]

3 hours ago, tparys said:

 

You might be in microcontroller territory at those signaling rates. I've done something similar with the stock Ubuntu 16.04 (4.4) kernel, but I'm not going to say it's the most reliable, and I'm not sure I'd recommend it. If you must do that, I'd also suggest locking your application to a single core with sched_setaffinity(), and avoid any calls to sleep(), usleep(), or nanosleep(). The kernel scheduler does not have the granularity you want. Hammer gettimeofday() in a busy loop to do your timing.

 

I've thought using a PIC chip as a dedicated wiegand-to-serial converter, then just read serial off the H3 GPIO.  Maybe that's my best bet after all, as I do need reliability.

[indianajones]

I was able to successfully build and run PREEMPT_RT with a current kernel running Ubuntu focal on a nanopineo, getting these results in cyclictest:

sudo cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 1.41 1.40 1.11 1/154 3261          

T: 0 ( 3242) P:80 I:200 C:4589037 Min:     18 Act:   30 Avg:   25 Max:     125
T: 1 ( 3243) P:80 I:200 C:4588573 Min:     17 Act:   23 Avg:   26 Max:     105
T: 2 ( 3244) P:80 I:200 C:4588088 Min:     18 Act:   32 Avg:   27 Max:     111
T: 3 ( 3245) P:80 I:200 C:4587408 Min:     18 Act:   30 Avg:   25 Max:     105

 

Steps to build your own:

 

1. Build a normal armbian image, using current kernel and ubuntu focal for nanopineo (or your board), mostly to discover the full kernel version that gets built.  Note that, as is mentioned in this thread, the AllWinner-based boards do not get their code from the mainline Linux github repo, but rather from a forked repo at https://github.com/megous/linux/.  This repo is specified in ~/build/config/sources/families/include/sunxi_common.inc.  You do not need to make any changes to that file, I'm just noting it as an FYI.

./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=no AUFS=no

 

2. Check the kernel version from the build output.  Currently, that version is 5.10.21.  Download the PREEMPT_RT patch that most closely matches the kernel version.  NOTE: maybe you can download *any* RT patch file version that's at least the same or newer, but I went with the same because it makes sense to me:

cd build/userpatches/kernel/sunxi-current    # You'll probably have to mkdir the sunxi-current folder the first time
wget https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.21-rt34.patch.gz
gunzip patch-5.10.21-rt34.patch.gz

 

3.  Build another armbian image, this time with an extra parameter, EXTRAWIFI=no.  I've discovered that the patch-5.10.xx-rtYY.patch files somehow cause at least one of the Realtek Wifi drivers to throw a compiler error (in the rt_spinlock code).  If you need Realtek Wifi (and any other Wifi built by EXTRAWIFI=yes, you'll have to find another solution.  Sorry.

 

Also, I now set KERNEL_CONFIGURE=yes because I think that it won't let  you choose "Full PREEMPT_RT" without you setting KERNEL_CONFIGURE=yes.  So when prompted during the build, choose option 4 (full PREEMPT):

./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=yes AUFS=no EXTRAWIFI=no

 

4. From there, just deploy the image like you do any other image.

uname -a
Linux nanopineo 5.10.21-rt34-sunxi #trunk SMP PREEMPT_RT Sun Apr 18 22:21:06 EDT 2021 armv7l armv7l armv7l GNU/Linux

 

Note that I also created a ~/build/userpatches/lib.config file that limited the CPU frequency to a paltry 480Mhz fixed value because I don't have a heat sink on the H3:

GOVERNOR=performance
CPUMIN=480000
CPUMAX=480000

 

 

Q: Is this possible with the legacy kernel?

A: Probably, if you use EXTRAWIFI=no, but I haven't tested it.  Both legacy and current kernels had compiler failures for various reasons, but most frequently with RealTek.

 

Q: Will this work for any AllWinner SoC?

A: I'm pretty sure that any H2/H3 AllWinner will work, as they are the same chipset as the nanopineo I'm using.  I don't know about H5 or A-series.

 

Q: I thought tparys told you that any version of PREEMPT_RT might not give you the determinism you need to read wiegand?

A: Yes, and I still agree, but this was just bugging me that I couldn't successfully build one.

 

[tparys]

Neato. Thanks for documenting this process. Hopefully will help others.

 

When you get to it, would be interested to see if the PREEMPT_RT patches make a difference for you.

[indianajones]

22 hours ago, tparys said:

Neato. Thanks for documenting this process. Hopefully will help others.

 

When you get to it, would be interested to see if the PREEMPT_RT patches make a difference for you.

Indeed.  I am still curious.