AM4376: porting PRU-ICSS Ethernet/IP on Nucleus RTOS

Hi,

The relevant packages for the PRU-ICSS-EthernetIP_Adapter_01.00.03.04 can be found in projectCreate.bat script from the release or its CCS project->Properties->CCS General->Products:

• pdk_am437x_1_0_12
• xdctools_3_50_07_20_core
• edma3_lld_2_12_05_30
• ndk_3_40_01_01
• bios_6_73_00_12

- As noted in the Ethernet/IP 1.0.3.4 user guide, section 3.1.3. System Requirements: 1.0.3 release uses the PROCESSOR-SDK-RTOS 05_01_00_11 which includes the packages as listed here - http://software-dl.ti.com/processor-sdk-rtos/esd/docs/05_01_00_11/rtos/Release_Specific.html#processor-sdk-rtos-release-notes

The modules/drivers from processor SDK that the Ethernet/IP project uses are listed in the examples\ethernetip_adapter\am437x_app.cfg:

var Uart = xdc.loadPackage('ti.drv.uart');
var I2c = xdc.loadPackage('ti.drv.i2c');
var Pruss = xdc.loadPackage('ti.drv.pruss');
var Gpio = xdc.loadPackage('ti.drv.gpio');
var Spi = xdc.loadPackage('ti.drv.spi');

in addition to EDMA, NDK, TI-RTOS modules. These drivers are not dependent on TI-RTOS.

NDK is TI-RTOS based, so you have to replace the IPv4/UDP stack with the one from your OS. The following modules from TI-RTOS listed in the m437x_app.cfg should be taken care by your OS as well.

var Clock = xdc.useModule('ti.sysbios.knl.Clock');
var Swi = xdc.useModule('ti.sysbios.knl.Swi');
var Task = xdc.useModule('ti.sysbios.knl.Task');
var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');
var Mailbox = xdc.useModule('ti.sysbios.knl.Mailbox');
var ti_sysbios_hal_Hwi = xdc.useModule('ti.sysbios.hal.Hwi');
var Timer = xdc.useModule('ti.sysbios.hal.Timer');

-  OSAL provides operating system abstraction layer API sample implementations that are required for processor SDK drivers. TI-RTOS and bare-metal OSAL implementations are currently supported in Processor SDK, and you can refer to them for Nucleus OS implementation.

- "By design, CSL APIs follow a consistent style, uniformly across Processor Instruction Set Architecture and are independent of the OS. ", see http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_device_drv.html. Alternatively you may refer to the driver implementation from Nucleus-TI-AM335x (https://www.mentor.com/embedded-software/nucleus/readystart/readystart-nucleus-ti/ti-sitara-am335x), for example, in spi_tgt.h from the Nucleus-TI-AM335x, it has similar implementation of register access as in CSL.

#define SPI_ANDOUTBYTE(reg, data) \
((*((UINT8 *)(reg))) = \
(UINT8)(SPI_INBYTE(reg) & (data)))

The previous comments may be beneficial to other customers:

-          Key modules to be ported are in PDK’s OSAL layer (example path: C:\TI\pdk_am335x_1_0_12\packages\ti\osal)

-          End user needs to create wrapper API to interface with these module APIs used by all the PDK LLD. Wrapper API would handle the custom OS specific interfacing details:

•             HwiP (Hardware Interrupt creation)

•             MuxIntcP (Interrupt Controller Mux module)

•             SemaphoreP (Semaphore management)

•             CacheP (Cache management)                                     

•             TimerP.h (timer configuration)

•             RegisterIntr.h (Interrupt interface with Scheduler)

•             Queue.h (Queue Handling)

-          For reference, users can look at how the SDK implements this interface so that the driver works in bare-metal as well as in TI RTOS context. For Eg : OSAL has common HWIp_create for both baremetal and TI RTOS so when application links to bare-metal code the API calls into HWIp_create  in OSAL bare_metal library and when the application used TI RTOS it makes the call to HWIp_create  in OSAL TI RTOS library.

-          While the OSAL guidance works for most of the Jellybean drivers (UART, SPI, I2C etc) with regards to networking, display/UI and filesystem stack support, there may be additional effort required as our SDK offering is designed for NDK support for networking and FATFS support for filesystem

Regards,

Garrett

Hello Garrett,

thank you for the detailed description. So far I have imported the denoted sources into our product platform and started porting the OSAL layer to Nucleus RTOS.

Modules like "Hwi" or "Semaphore" seems to be no problem to port. But I am uncertain about modules "Timer" and "Clock":

When searching for dependencies, it seems that only the PRU-ICSS-EthernetIP_Adapter_01.00.03.04 uses the "Clock" module. I did not find a reference (PRU-ICSS, ICSS_EMAC, NIMU_ICSS) where "Timer" is used in a direct way. Is this correct?

Within the SYS/BIOS API documentation I found, that "Clock" functions run in the context of a software interrupt. Further it seems to me, that "Clock" is completely operationg on system timer resolution. So is it possible to implement the "Clock" module based on a Nucleus software timer that has a resolution of 1 ms?

Thanks you in advance

Stefan

Stefan,

It's true that timer is not required for PRU-ICSS, ICSS_EMAC and NIMU_ICSS.

Molex stack needs 500us tick to support 1ms RPI. If you have a full stack from Molex, you may be able to work around it with 1ms resolution clock from Nucleus.

Regards,

Garrett

Hello Garrett,

thanks for the quick reply.

Best regards,

Stefan

Hello Garrett,

I have a another question regarding the Hwi module of the OSAL.

In which context shall the entry function (HwiP_Fxn) of the hardware interrupt be called?
In an unmanaged context or in the managed context of the RTOS, where some low-level RTOS functions are available (e.g. unlocking a mutex)?

From the API point of view, I would guess that entry functions are unmanaged. But when having a look at the DLR implementation (icss_dlr.c), I can see some calls that I would not expect in an unmanaged context.

Example: EIP_DLR_beaconTimeoutISR_P0

• ClockP_stop

SYS/BIOS documentation says "start" and "stop" of the "Clock" module are allowed to be called from a Hwi context. In our case, ClockP is based on software timer, that is only allowed to be used in a managed context (e.g. Swi, task, event handler).

• ICSS_EmacIoctl

SYS/BIOS documentation says "Hwis must not use the Chip Support Library (CSL) for the target" due to possible incompatibilities with the SYS/BIOS.

If entry functions are unmanaged, our implementation of Clock/ClockP module has to be changed (e.g. by using hardware timers).
Otherwise, the use of the CSL should be verified.

Thanks you in advance

Stefan

Stefan,

HwiP_Fxn function is called when the event (evtId) defined by the HwiP_Params occurs. In the case of EIP_DLR_beaconTimeoutISR_P0, 

hwiParams.arg = (xdc_UArg)dlrHandle;
hwiParams.eventId = dlrHandle->dlrObj->beaconTimeoutIntNum_P0;

Hwi_create(dlrHandle->dlrObj->beaconTimeoutIntNum_P0,
(IHwi_FuncPtr)EIP_DLR_beaconTimeoutISR_P0,
&hwiParams, &eb);

The DLR interrupt for beacon timeout for Port 0 (beaconTimeoutIntNum_P0) is confgiured to in EIP_configureInterrupts()

dlrHandle->dlrObj->beaconTimeoutIntNum_P0 = EIP_BEACON_TIMEOUT_INT_NUM_P0;

where #define EIP_BEACON_TIMEOUT_INT_NUM_P0   56

if then look into the AM437x TRM, event 56 is PRU_ICSS1_EVTOUT4....

An overview of Hwi module in TI-RTOS is outlined here - http://processors.wiki.ti.com/images/b/b2/Hwis.pdf

Regards,

Garrett