RTOS Porting

[hayashi-90]

@Bosch-SW

When porting below modules to an RTOS (especially Zephyr),

linux-iccom/include/linux/iccom.h
linux-iccom/src/iccom_socket_if.c 
linux-iccom/src/iccom.c
linux-symspi/src/symspi.c
linux-symspi/src/symspi.h

what considerations should be taken ?

Also, if there are any useful OSS references,
or any porting guides to other operating systems, could you share them ?

My understanding is below:

Part 1 of my understanding :

Since the subsystems differ between Zephyr and Linux, in practice,
it will become necessary to implement the driver from scratch in compliance with the ICCOM protocol.

Part 2 of my understanding (for each files):

linux-iccom/src/iccom_socket_if.c

• Interacting with the API of linux-iccom/src/iccom.c and receives callbacks.

• Since the NETLINK domain socket that iccom_socket_if.c depends on does not exist in Zephyr, it is necessary to implement a custom NETLINK-compatible socket.

• The goal is to port iccom_socket_if.c using a NETLINK-compatible socket (mostly from scratch).

linux-iccom/src/iccom.c

• H/W independent. Processes data reception callbacks from the transport layer and triggers the sending.

• Implement this (mostly from scratch ).

linux-symspi/src/symspi.c

• HW independent, mainly dependent on the OS's SPI/GPIO subsystem API.

• Call the API SPI/GPIO subsystem of Zephyr (which is different from the Linux Kernel)

• Implement this (mostly from scratch ).

thank you.

[Bosch-SW]

@hayashi-90 , hello

When porting below modules to an RTOS (especially Zephyr), what considerations should be taken ?

Currently I would recommend to wait a bit, cause we're planning to release the RTOS counterpart drivers to the public as well.
This includes the linux-iccom/src/iccom.c counterpart and probably the linux-symspi/src/symspi.c counterpart. The timeline is couple of months (expected).

it will become necessary to implement the driver from scratch in compliance with the ICCOM protocol.

In general RTOS internal API is pretty different relative to the Linux kernel internal API, so, yes, RTOS implementation differs significantly (while some parts surely retain same local logic). I would recommend you to wait us to release the RTOS versions of the drivers, so this would save you quite an effort in writing them yourself.

your technical overview of the files seems to be correct in general.

Feel free to ask further questions, I will try to answer them as well.

[Bosch-SW]

@hayashi-90 , hello

Sorry for pretty a delay: summer and autumn were dedicated to the priority topics, but now we got back on the track.

The current status of the RTOS port is the following:

• we have it working for the Autosar Environment (not yet published, but runs in some SOPs already).
• the final cleanup and release for an RTOS is expected in range of 6-8 weeks (it is mostly not about making it buildable for specific OS, but really clean it up and be capable to cover anything from Autosar to Zephyr to FreeRTOS).

Please let me know if it is of interest, so I will prioritize it for this timing.