[lwip 2/2] Move and rename sys_arch_data_sync_barier()

[Pavel Pisa]

Hello Sebastian,

On Friday 24 of March 2023 11:43:02 Sebastian Huber wrote:
> it seems we have two different MDIO services:

not not nice to have two different APIs...

In general it would be great to have actual MDIO PHY chips drivers
in a separate folder(s) and actual NIC driver should provide
only MDIO access routines through some unified API.

> cpsw/src/include/mdio.h:extern unsigned int MDIOPhyRegRead(unsigned int
> baseAddr, unsigned int phyAddr,
>
> uLan/ports/driver/tms570_emac/ti_drv_mdio.h:MDIOPhyRegRead(volatile
> tms570_mdio_t *baseAddr, uint32_t phyAddr,
>

None of these two definitions is ideal

  uint32_t
  MDIOPhyRegRead(volatile tms570_mdio_t *baseAddr, uint32_t phyAddr,
                 uint32_t regNum, volatile unsigned short *dataPtr)

  extern unsigned int MDIOPhyRegRead(unsigned int baseAddr, unsigned int phyAddr,
                                     unsigned int regNum, volatile unsigned short *dataPtr);

Same for write etc...

If the generic mdio.h and PHY chip drivers should be used for multiple
NICs, then some prototype like

  uint32_t
  MDIOPhyRegRead(mdiophy_state_t *mdiophyst, uint32_t phyAddr,
                 uint32_t regNum, volatile unsigned short *dataPtr)


should be used and and mdiophy_state_t should provide actual
pointers to the routines specific for given NIC as well as base
address. That way multiple instances of even different MDIO
interfaces can be supported.

I would like to see something like Linux struct mdio_if_info

  https://elixir.bootlin.com/linux/latest/source/include/linux/mdio.h#L133

or some BSD equivalent. I see that in BSD based RTEMS TCP/IP stack
is struct rtems_mdio_info defined

  https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/rtems/rtems_mii_ioctl.h

May it be it could be reused there even that I do not like that
pointer to struct rtems_mdio_info structure is not passed into
rtems_mdio_read_func() and rtems_mdio_write_func() functions.

So generally it would be great if this part can be sorted
and cleaned... I hope to have more time during winter term...

On Wednesday 29 of March 2023 13:43:28 Sebastian Huber wrote:
> > up. I would like to test code on TMS570LS3137 when I find
> > time and on TMS570LC43 one day...
>
> I work currently with these chips.

Nice to know, I have EDKs for both at home...

We have developed really advanced solution to combine
N2HET, DMAs and integrated D-CAN controllers to
achieve time triggered CAN operation with these
with maximal CPU offloading. So if there is interrest
we can try to port that solution to RTEMS...

We have Matlab/Simulink target for that TMS570LS3137
built as well and lot can be ported to RTEMS.

We have even done design of experimental ECU based
on TMS570LS3137 with my colleague from PiKRON company
for Porsche... So we can share knowledge...

TMS570LC4357 is even more interesting, becase it
has more RAM which could allow better TCP/IP
experience even without external RAM.

Best wishes,

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa at cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home