hm2_eth: Xenomai4 OOB improvements

[hdiethelm]

While creating Xenomai3 support, a better way to do the initialization without needing to first use posix and then switch to OOB was discovered: By attaching also rtapi_app to the EVL core, OOB functions can also be used in rtapi_app_main.

This should have no side effects due to SCHED_WEAK is used for rtapi_app: https://v4.xenomai.org/core/user-api/scheduling/index.html#SCHED_WEAK. But it gets rid of the realtime-init function which is deprecated.

This PR also moves the firewall init / cleanup from the Ethernet implementations out to hm2_eth.c. This slightly alters the calling order but should have no side effects, simplifies the code and allows support library's with less shared symbols.

Tested:

• Firewall config with nft and iptables are equal before and after this PR
• Posix and Xenomai4 hm2_eth still works fine
• No difference in realtime performance observed
• Test with Modbus (Thanks @zz912)

Open:

• realtime-init is deprecated now. Should I just fully remove it? I guess not that many people use this already but the few that do will run into trouble. So deprecating it for some time might be better.
• Are there applications where multiple mesa cards are connected over a switch to a single Ethernet port? This might be an issue with the actual way of initializing the interfaces for Xenomai4. Different ports should work but I have no way of testing this due to I have only one card. Theoretically fixed. But I can not test it.

[hdiethelm]

@zz912 Can you test if this branch works on your setup?
initf hm2_eth.realtime-init servo-thread is not needed any more which simplifies the configuration.

[zz912]

I commented:
#initf hm2_eth.realtime-init servo-thread

It works:

zdenek@cnc:~/linuxcnc/linuxcnc-fork-hm2_eth_oob_improvements/scripts$ ./linuxcnc
LINUXCNC - 2.10.0~pre1
Machine configuration directory is '/home/zdenek/linuxcnc/configs/DedaCNC-013'
Machine configuration file is 'DedaCNC-013.ini'
Starting LinuxCNC...
Note: Using XENOMAI4 EVL realtime
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./DedaCNC-013.hal
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: 10.10.10.10: INFO: init board (Xenomai EVL)
hm2_eth: 10.10.10.10: INFO: enable OOB for board on if enp1s0f0
hm2_eth: 10.10.10.10: INFO: Hardware address (MAC): 00:60:1b:16:80:30
hm2_eth: discovered 7I96S
hm2/hm2_7i96s.0: Low Level init 0.15
hm2/hm2_7i96s.0: created PktUART Interface function hm2_7i96s.0.pktuart.0.
hm2/hm2_7i96s.0: 51 I/O Pins used:
hm2/hm2_7i96s.0:     IO Pin 000 (TB3-01): InM Input Module #0, pin in0,enca0 (Input)
hm2/hm2_7i96s.0:     IO Pin 001 (TB3-02): InM Input Module #0, pin in1,encb0 (Input)
hm2/hm2_7i96s.0:     IO Pin 002 (TB3-03): InM Input Module #0, pin in2,enca1 (Input)
.......

[hdiethelm]

It works:

Thanks for testing!

[hdiethelm]

The last commit should theoretically solve the issue when two boards are on the same Ethernet interface using a switch. By first sending reset and then switching all interfaces from OOB to Posix, there should be no issue if the same interface is used for two boards. It also removes some duplicated code. But I can not test two boards, I have only one.

The way Xenomai4 is implemented, there is no error if you switch an interface twice to OOB or twice to Posix.

Tested again with posix and evl including the error cleanup case. I call this ready.

[hdiethelm]

Rebased to master

I found 2 mistakes fixed in 4abb47c

Both should not have any influence except in edge cases.

Set back to draft until I have completed testing again.

[hdiethelm]

So, tested again, still works.

I fixed two mistakes from #4199:

• 1e9 should have been 1000000000. No noticeable influence expected except using more CPU cycles than needed.
• read_deadline was not taken into consideration which could be before now + timeout. This could have an effect if read-request is used and something between read-request and read takes some time. It could result in a thread time violation. Mostly theoretical, it this happens, the timing is anyway rather critical.