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: p...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel