Skip to main content
C
CMase.1
Visitor II
March 19, 2020
Solved

STM32MP1xx: Ethernet assignment to cortex-M4 core?

  • March 19, 2020
  • 3 replies
  • 1518 views

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

    This topic has been closed for replies.
    Best answer by PatrickF

    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.

    3 replies

    P
    PatrickF
    Technical Moderator
    March 19, 2020

    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

    C
    CMase.1Author
    Visitor II
    March 20, 2020

    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.

    P
    PatrickFAnswer
    Technical Moderator
    March 20, 2020

    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.

    C
    CMase.1Author
    Visitor II
    March 20, 2020

    Ok Patrick,

    thank you very much for your suggestions.

    Best regards,

    Cesare

    Terms & ConditionsAccessibility statement