WG: Where to start with Kernel config for Atom (64bit) Xenomai4 (evl)

["Steub, Peter" <Peter.Steub@baumueller.com>]

> > Hi all,
> >
> > I like to get evl running on a quadcore Atom box. I started with a 
> > standard ubuntu 20.04 installation
> 
> Which will almost never work out of the box on x86. Some options 
> commonly selected there will likely cause issues with any real-time infrastructure.

Can you give me an example, the Xenomai3 setup that I use very successfully, is based on a Ubuntu 16.04 desktop, although it is pretty old already, so I may have forgotten what I did exactly back then to make it work.

> > and build a kernel from ,v5.15.y-evl-rebase' branch with evl enabled 
> > and things that ,evl check -file' told me disabled.
> 
> What do you mean? "evl check" is about verifying a configuration, not 
> giving any runtime status. The output is a set of hints about kernel 
> options that should appear as indicated in the submitted .config file, but do not.

Exactly, I did run "evl check" on the kernel config before I build the kernel. So ACPI_PROCESSOR_IDLE is deactivated as well.

> > Also ,evl test' tells me:
> > *** stack smashing detected ***: terminated Aborted (core dumped)
> > ** poll-multiple: BROKEN
> 
> # gdb /usr/evl/tests/poll-multiple
> 
> may help, running it then asking for a backtrace when it breaks. I 
> could have a look at the backtrace output to figure out what happens, 
> since I cannot reproduce this on any of my fixtures ATM, so this may 
> depend on a glibc setup.

(gdb) run
Starting program: /usr/evl/tests/poll-multiple [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7d8b700 (LWP 3404)]
[New Thread 0x7ffff7d7a700 (LWP 3412)]
[Thread 0x7ffff7d8b700 (LWP 3404) exited]
*** stack smashing detected ***: terminated [Thread 0x7ffff7d7a700 (LWP 3412) exited]

Thread 1 "poll-multi:3400" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7db1859 in __GI_abort () at abort.c:79
#2  0x00007ffff7e1c29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7f4608f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7ebeaea in __GI___fortify_fail (msg=msg@entry=0x7ffff7f46077 "stack smashing detected") at fortify_fail.c:26
#4  0x00007ffff7ebeab6 in __stack_chk_fail () at stack_chk_fail.c:24
#5  0x0000555555557941 in main (argc=1, argv=0x7fffffffe558) at ../../home/bm_user/nas/libevl-master/tests/poll-multiple.c:163

> > I'm also interested in the Raspberry PI port, but I don't like to 
> > try it all out again for myself, a kernel-config or in case of the 
> > PI even a binary or a hole Image would be great!
> 
> Which PI? All PI kernels can be built using the default mainline 
> config for the architecture at hand. This is actually the ones I'm using.
> e.g. ARCH=arm64 defconfig for PI3/64bit and PI4/64bit, or 
> multi_v7_defconfig for 32bit (including PI0 and PI2).

Ok I started over with the kernel and now that I have done it, it seems obvious. Maybe someone could put a small list like this on the "Building the core" site so the next one who does not know how to start knows:
# ARCH=x86_64 make defconfig
# make menuconfig
	-> Processor type and features -> EVL real-time core				Enabled
	-> Processor type and features -> CPU core prioroties scheduler support	Disable
	-> Power management -> CPU Frequency scaling 				Disable
	-> Power management -> ACPI support -> Processor 				Disable
	->Kernel hacking -> Tracers 							Disable
	#######Add addition Hardware support######### # make clean # make bindeb-pkg (or just make...)

The result looks very promising, on an isolated core I get worst user values at around 3, on a non isolated core I get like 20. I haven't tested for long and not with different kind of loads but still it looks a lot better than before.  Now I need to port my application from X3 to X4 but those questions deserve a separate email.

Thank you

Peter Steub
> 
> [1] https://evlproject.org/core/caveat/
> 
> --
> Philippe.