Hello, Coming back to this issue.
Looking at STM32F4DISCOVERY code, I could see that the NETINIT_THREAD is disabled because the IRQ pin from the PHY is not available. It happens when the RMII configuration is set and the IRQ pin is also used as REFCLK0. This is also the situation with my hardware. Considering this scenario, is there any alternative approach that I could use to have this detection? Polling the phy, or something similar? Best regards, Flavio Em qua., 14 de abr. de 2021 às 11:45, Flavio Castro Alves Filho <flavio.al...@gmail.com> escreveu: > > Gregory, > > Thank you for your support. I will work on this. > > Best regards. > > Flavio > > Em qua., 14 de abr. de 2021 11:09, Gregory Nutt <spudan...@gmail.com> > escreveu: >> >> You board must provide CONFIG_ARCH_PHY_INTERRUPT: >> >> $ find boards/ -name Kconfig | xargs grep ARCH_PHY_INTERRUPT >> boards/Kconfig: select ARCH_PHY_INTERRUPT >> boards/Kconfig: select ARCH_PHY_INTERRUPT if SAMA5_EMACA || >> SAMA5_EMAC0 || SAMA5_EMAC1 || SAMA5_GMAC >> boards/Kconfig: select ARCH_PHY_INTERRUPT >> boards/Kconfig: select ARCH_PHY_INTERRUPT >> boards/Kconfig: select ARCH_PHY_INTERRUPT >> boards/Kconfig: select ARCH_PHY_INTERRUPT >> boards/Kconfig: select ARCH_PHY_INTERRUPT >> >> and you must implement PHY interrupt handling as documented in >> include/nuttx/arch.h: >> >> >> /**************************************************************************** >> * Name: arch_phy_irq >> * >> * Description: >> * This function may be called to register an interrupt handler >> that will >> * be called when a PHY interrupt occurs. This function both >> attaches >> * the interrupt handler and enables the interrupt if 'handler' >> is non- >> * NULL. If handler is NULL, then the interrupt is detached and >> disabled >> * instead. >> * >> * The PHY interrupt is always disabled upon return. The caller must >> * call back through the enable function point to control the >> state of >> * the interrupt. >> * >> * This interrupt may or may not be available on a given platform >> depending >> * on how the network hardware architecture is implemented. In a >> typical >> * case, the PHY interrupt is provided to board-level logic as a GPIO >> * interrupt (in which case this is a board-specific interface >> and really >> * should be called board_phy_irq()); In other cases, the PHY >> interrupt >> * may be cause by the chip's MAC logic (in which case >> arch_phy_irq()) is >> * an appropriate name. Other other boards, there may be no PHY >> interrupts >> * available at all. If client attachable PHY interrupts are >> available >> * from the board or from the chip, then >> CONFIG_ARCH_PHY_INTERRUPT should >> * be defined to indicate that fact. >> * >> * Typical usage: >> * a. OS service logic (not application logic*) attaches to the PHY >> * PHY interrupt and enables the PHY interrupt. >> * b. When the PHY interrupt occurs: (1) the interrupt should be >> * disabled and () work should be scheduled on the worker >> thread (or >> * perhaps a dedicated application thread). >> * c. That worker thread should use the SIOCGMIIPHY, SIOCGMIIREG, >> * and SIOCSMIIREG ioctl calls** to communicate with the PHY, >> * determine what network event took place (Link Up/Down?), and >> * take the appropriate actions. >> * d. It should then interact the PHY to clear any pending >> * interrupts, then re-enable the PHY interrupt. >> * >> * * This is an OS internal interface and should not be used from >> * application space. Rather applications should use the >> SIOCMIISIG >> * ioctl to receive a signal when a PHY event occurs. >> * ** This interrupt is really of no use if the Ethernet MAC driver >> * does not support these ioctl calls. >> * >> * Input Parameters: >> * intf - Identifies the network interface. For example >> "eth0". Only >> * useful on platforms that support multiple Ethernet >> interfaces >> * and, hence, multiple PHYs and PHY interrupts. >> * handler - The client interrupt handler to be invoked when the PHY >> * asserts an interrupt. Must reside in OS space, but can >> * signal tasks in user space. A value of NULL can be >> passed >> * in order to detach and disable the PHY interrupt. >> * arg - The argument that will accompany the interrupt >> * enable - A function pointer that be unused to enable or >> disable the >> * PHY interrupt. >> * >> * Returned Value: >> * Zero (OK) returned on success; a negated errno value is >> returned on >> * failure. >> * >> >> ****************************************************************************/ >> >> #ifdef CONFIG_ARCH_PHY_INTERRUPT >> int arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> phy_enable_t *enable); >> #endif >> >> >> Lots of examples. Note that it already exists for STM32F4 Discovery: >> >> $ find boards/ -name "*.c" | xargs grep arch_phy_irq >> boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: * Name: >> arch_phy_irq >> boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c: * may be >> cause by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/imxrt/imxrt1020-evk/src/imxrt_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c: * Name: >> arch_phy_irq >> boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c: * may be >> cause by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/imxrt/imxrt1050-evk/src/imxrt_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/imxrt/imxrt1060-evk/src/imxrt_ethernet.c: * Name: >> arch_phy_irq >> boards/arm/imxrt/imxrt1060-evk/src/imxrt_ethernet.c: * may be >> cause by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/imxrt/imxrt1060-evk/src/imxrt_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/imxrt/teensy-4.x/src/imxrt_ethernet.c: * Name: arch_phy_irq >> boards/arm/imxrt/teensy-4.x/src/imxrt_ethernet.c: * may be cause >> by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/imxrt/teensy-4.x/src/imxrt_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/sam34/sam4e-ek/src/sam_ethernet.c: * Name: arch_phy_irq >> boards/arm/sam34/sam4e-ek/src/sam_ethernet.c: * may be cause by >> the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/sam34/sam4e-ek/src/sam_ethernet.c:int arch_phy_irq(FAR >> const char *intf, xcpt_t handler, void *arg, >> boards/arm/sama5/sama5d2-xult/src/sam_ethernet.c: * Name: arch_phy_irq >> boards/arm/sama5/sama5d2-xult/src/sam_ethernet.c: * may be cause >> by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/sama5/sama5d2-xult/src/sam_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/sama5/sama5d3-xplained/src/sam_ethernet.c: * Name: >> arch_phy_irq >> boards/arm/sama5/sama5d3-xplained/src/sam_ethernet.c: * may be >> cause by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/sama5/sama5d3-xplained/src/sam_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/sama5/sama5d3x-ek/src/sam_ethernet.c: * Name: arch_phy_irq >> boards/arm/sama5/sama5d3x-ek/src/sam_ethernet.c: * may be cause by >> the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/sama5/sama5d3x-ek/src/sam_ethernet.c:int arch_phy_irq(FAR >> const char *intf, xcpt_t handler, void *arg, >> boards/arm/sama5/sama5d4-ek/src/sam_ethernet.c: * Name: arch_phy_irq >> boards/arm/sama5/sama5d4-ek/src/sam_ethernet.c: * may be cause by >> the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/sama5/sama5d4-ek/src/sam_ethernet.c:int arch_phy_irq(FAR >> const char *intf, xcpt_t handler, void *arg, >> boards/arm/samv7/same70-xplained/src/sam_ethernet.c: * Name: >> arch_phy_irq >> boards/arm/samv7/same70-xplained/src/sam_ethernet.c: * may be >> cause by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/samv7/same70-xplained/src/sam_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> boards/arm/samv7/samv71-xult/src/sam_ethernet.c: * Name: arch_phy_irq >> boards/arm/samv7/samv71-xult/src/sam_ethernet.c: * may be cause by >> the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/samv7/samv71-xult/src/sam_ethernet.c:int arch_phy_irq(FAR >> const char *intf, xcpt_t handler, void *arg, >> boards/arm/stm32/stm32f4discovery/src/stm32_ethernet.c: * Name: >> arch_phy_irq >> boards/arm/stm32/stm32f4discovery/src/stm32_ethernet.c: * may be >> cause by the chip's MAC logic (in which case arch_phy_irq()) is >> boards/arm/stm32/stm32f4discovery/src/stm32_ethernet.c:int >> arch_phy_irq(FAR const char *intf, xcpt_t handler, void *arg, >> >> >> On 4/14/2021 7:59 AM, Flavio Castro Alves Filho wrote: >> > The netinit_monitor code is self-explanatory :-/ >> > >> > I could understand what must be done ... and, naturally, it is in >> > accord with the documents. >> > >> > In my case, I cannot easily enable it from menuconfig ... as far as I >> > understood. >> > >> > Em qua., 14 de abr. de 2021 às 10:49, Gregory Nutt >> > <spudan...@gmail.com> escreveu: >> >> This is very out of date, but 90% accurate: >> >> >> >> https://cwiki.apache.org/confluence/display/NUTTX/Network+Link+Management >> >> https://cwiki.apache.org/confluence/display/NUTTX/NSH+Network+Link+Management >> >> >> >> This was not updated after the network initialization and network >> >> monitor were removed from NSH and made a separate feature. It needs so >> >> clean-up. >> >> >> >> On 4/14/2021 7:40 AM, Alan Carvalho de Assis wrote: >> >>> I think this is kind of question that should be in some FAQ or in our >> >>> documentation, it is asked often... >> >>> >> >>> Is there some only place in our Documentation where we could include it? >> >>> >> >>> BR, >> >>> >> >>> Alan >> >>> >> >>> On 4/14/21, Gregory Nutt <spudan...@gmail.com> wrote: >> >>>> Normally this is done using the PHY driver at >> >>>> nuttx/drivers/net/phy_notify.c that provides PHY-related events to >> >>>> applications via signals. It requires board-level support to handle PHY >> >>>> interrupts. >> >>>> >> >>>> The network monitor thread at apps/netutils/netinit (see >> >>>> CONFIG_NETINIT_MONITOR) will handle taking the network down if the cable >> >>>> is unplugged and bringing it back up when the cable is restored. >> >>>> >> >>>> On 4/14/2021 7:24 AM, Flavio Castro Alves Filho wrote: >> >>>>> Hello, >> >>>>> >> >>>>> I am implementing an application using NuttX where I need to detect if >> >>>>> the network cable is plugged or not in my board. >> >>>>> >> >>>>> Today I implemented the function netlib_getifstatus(), which automates >> >>>>> the read of SIOCGIFFLAGS, similar to what we have in Linux. >> >>>>> >> >>>>> But, in my tests, it seems that it is not working correctly. >> >>>>> >> >>>>> What is the recommended approach to have this feature implemented? >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Flavio >> >>>>> >> > >> -- Flavio de Castro Alves Filho flavio.al...@gmail.com Twitter: http://twitter.com/#!/fraviofii LinkedIn profile: www.linkedin.com/in/flaviocastroalves
