davids5 commented on pull request #1273:
URL: https://github.com/apache/incubator-nuttx/pull/1273#issuecomment-647018437
> Probably no need.. My paranoia is not founded on anything of substance.
I do not see it as paranoia, it is a good thing to ensure it is correct.
Thank you for raising it.
To that end, when I dug into enabling NETINIT_MONITOR I found that the
ARCH_PHY_INTERRUPT is not lit. More digging led to the readme for the K66.
(Thank you again Greg for documenting it)
I have copied the readme from the k66 here for some context and advise.
**As far as this PR: I think it is safe to bring it in**. It it an
improvement in that the MAC will not get stuck as it was. But **long term this
driver should support the NETINIT_MONITOR**
```
Network Monitor
---------------
By default the network initialization thread will bring-up the network
then exit, freeing all of the resources that it required. This is a
good behavior for systems with limited memory.
If the CONFIG_NSH_NETINIT_MONITOR option is selected, however, then the
network initialization thread will persist forever; it will monitor the
network status. In the event that the network goes down (for example, if
a cable is removed), then the thread will monitor the link status and
attempt to bring the network back up. In this case the resources
required for network initialization are never released.
Pre-requisites:
- CONFIG_NSH_NETINIT_THREAD as described above.
- The K64F EMAC block does not support PHY interrupts. The KSZ8081
PHY interrupt line is brought to a jumper block and it should be
possible to connect that some some interrupt port pin. You would
need to provide some custom logic in the Freedcom K64F
configuration to set up that PHY interrupt.
- In addtion to the PHY interrupt, the Network Monitor also requires the
following setting:
CONFIG_NETDEV_PHY_IOCTL. Enable PHY IOCTL commands in the Ethernet
device driver. Special IOCTL commands must be provided by the
Ethernet
driver to support certain PHY operations that will be needed for link
management. There operations are not complex and are implemented for
the Atmel SAMA5 family.
CONFIG_ARCH_PHY_INTERRUPT. This is not a user selectable option.
Rather, it is set when you select a board that supports PHY
interrupts. For the K64F, like most other architectures, the PHY
interrupt must be provided via some board-specific GPIO. In any
event, the board-specific logic must provide support for the PHY
interrupt. To do this, the board logic must do two things: (1) It
must provide the function arch_phy_irq() as described and prototyped
in the nuttx/include/nuttx/arch.h, and (2) it must select
CONFIG_ARCH_PHY_INTERRUPT in the board configuration file to
advertise that it supports arch_phy_irq().
One other thing: UDP support is required (CONFIG_NET_UDP).
Given those prerequisites, the network monitor can be selected with these
additional settings.
System Type -> Kinetis Ethernet Configuration
CONFIG_ARCH_PHY_INTERRUPT=y : (auto-selected)
CONFIG_NETDEV_PHY_IOCTL=y : (auto-selected)
Application Configuration -> NSH Library -> Networking Configuration
CONFIG_NSH_NETINIT_THREAD : Enable the network
initialization thread
CONFIG_NSH_NETINIT_MONITOR=y : Enable the network monitor
CONFIG_NSH_NETINIT_RETRYMSEC=2000 : Configure the network monitor
as you like
CONFIG_NSH_NETINIT_SIGNO=18
```
The board we are working, does have a GPIO connected to the phy. But it is
not defined or used. I believe @PetervdPerk-NXP integrated the T1 phy into the
eth driver. So I it would be good to get his input on this.
Since the T1 phy is incorporated in the eth driver, and it already uses pins
from the board.h, for enable and INH. We should be able to hook phy interrupt
in the it in the driver as well unless there is a compelling reason to have it
in board logic.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]