STM32MP1xx: Ethernet assignment to cortex-M4 core?

[CMase.1]

Hello,

we are going to develop an application which requires the usage of a cortex-m core that communicates through ethernet.

Both the wiki and the migration guide (AN5253) from cortex-m4 to MP1 says this is not possibile. Is it really true? Looking at the reference manual this is not clear. Moreover, if I look at this page, https://wiki.st.com/stm32mpu/wiki/File:STM32MP1IPsOverview.png in old Overviews, back to 2018, it seems possibile to use the eth module via the cortexM4.

Can anybody help? Thank you very much, best regards.

Cesare

[PatrickF]

Hi.

Although in HW, there is nothing avoiding the Cortex-M4 to setup the ETH IP, there is no SW support in CubeMP1 (HAL) for the ETH GMAC IP.

The ETH master need to access buffers in DDR, which are not accessible by Cortex-M4. SYSRAM is probably also not an option as Linux uses it.

Furthermore, it is expected that all clocking is set-up and control by Linux.

It is probably easier to put an external GMAC + PHY, e.g. connected on FMC (i.e. KS8851-16MLL). Here again, no SW available from ST, but almost no system dependencies with Linux.

Another out of the box solution could be to use OpenAMP/RpMsg to exchange buffers with Linux and give Linux the full ETH control as of today.

Regards

[CMase.1]

Hello Patrick,

thank you for your prompt response. Unfortunately, both external MAC or OpenAMP are not viable solutions due to the hard-real time nature of our application.

One last question about direct control of ETH IP from Cortex-M4: from page 122 of the reference manual it seems that the ETH master can also access SRAM blocks through AHB matrix, am I correct? Do you think this is a viable solutions albeit with no software support? Do you think it could be reasonably practicable?

Thank you very much, best regards.

[PatrickF · Accepted solution]

Yes, I forgot the path to SRAM. For those one, there is additional delay going to AHB (async bridges), which may create bandwith issues for Gigabit data/control.

Anyway, I still think that for SW point of view, would be almost impossible to be sure you could end up to something reliable for Cortex-M4 as there is no SW available and such complex IP uses a 3rd party/community driver on Linux.

Personally, I will not start in that direction if it there a chance that it could be a dead end.

[CMase.1]

Ok Patrick,

thank you very much for your suggestions.

Best regards,

Cesare