You can call the PHY Ethernet ioctl() commands directly from board
specific code. Many things you can implement application can also be
implemented inside the board-specific logic -- with the caveat that you
have to use some different interfaces.
The PHY driver ioctl commands are in include/nuttx/net/ioctl.h:
91 /* MDIO/MCD
*****************************************************************/
92
93 #define SIOCMIINOTIFY _SIOC(0x0023) /* Receive notificaion via
signal on
94 * PHY state change */
95 #define SIOCGMIIPHY _SIOC(0x0024) /* Get address of MII
PHY in use */
96 #define SIOCGMIIREG _SIOC(0x0025) /* Get a MII register
via MDIO */
97 #define SIOCSMIIREG _SIOC(0x0026) /* Set a MII register
via MDIO */
You would open the driver using file_open() (not open()) and invoke the
command using file_ioctl() (not ioctl()).
Since you inside the OS in board logic that is permitted direct access
to architecture interfaces, you could probably even simplify that and
just call the lower-half PHY interfaces directly from board-specific
code. Such board-level, internal hooks are non-standard and would vary
from architecture to architecture. The driver interface is modular and
somewhat portable.
On 2/20/2021 7:48 AM, Fotis Panagiotopoulos wrote:
The highest level (and maybe the only available), is the application itself.
This is what I want to avoid.
I don't want the application to mess with the specific peculiarities of
this hardware.
It harms the overall architecture I think, makes porting more difficult.
Following this procedure, I would end up with a mess of a code, with lots
of conditionals to adapt the logic to every used target board.
Of course, I will also not be able upstream this in any way, if it is
application logic.
This is why I am looking for something at a lower-level.
To keep hardware peculiarities transparent to the end application, and to
enhance reusability of this logic.
In any case, the board level may be the most appropriate generally.
Only the board knows how this specific hardware works, for example if there
is a hardware reset line, if there are any interrupt lines, if any other
hardware initialization is needed after reset etc etc.
Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr <gebbe...@gmail.com> έγραψε:
I cannot offer you help on the main topic but I'd like to offer an opinion
on the level thing:
The higher the level, the better. If possible, do it at the general level
Why? Because that way, your work is useful to most people and you avoid
increasing NuttX fragmentation. Many drivers are created or configured at
board level and that work must be duplicated even when peripherals are
using standard interfaces like SPI or I2C
I have some old LAN8187 (hopefully I could manage to solder them to an
adapter) and I could do some testing of your work if that helps you
El sáb, 20 feb 2021 a las 6:45, Fotis Panagiotopoulos (<
f.j.pa...@gmail.com>)
escribió:
Anyone on this?
I am using the LAN8720A Ethernet PHY.
I realized that this IC in some rare cases may get stuck. The Ethernet
LEDs
blink erratically, and no Ethernet communication is possible.
The only way to recover from this state is to reset the PHY. (MIIM works
in
this case)
To diagnose the issue, I monitor the MII_LAN8720_SECR register (symbol
error count). This register typically contains a very small value.
Usually
0, or something close to that.
When the problem occurs, this value increases very very rapidly
(something
like thousands of errors per second).
I need to monitor this register for excessive error count, and if the
problem occurs to reset the PHY.
I believe that the correct place to do so is in board logic.
1. Is there a way to do so?
2. Would it be more appropriate to do so in the arch low-level driver? I
could find any function that can monitor this periodically.
3. Is it actually needed? Is there any error handling logic anywhere that
will bring the interface down in case of MII-level errors? (Then I could
just reset it during ifdown)
Στις Κυρ, 14 Φεβ 2021 στις 2:36 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:
Hi everybody,
I am trying to perform some reads/writes to my Ethernet PHY (LAN8720A)
in
board-level.
I am pretty confused on what is the correct interface to use for this
purpose.
As far as I can tell, it is only possible to perform MII read/writes
through ioctl's in application code.
How can the board logic control the PHY? Is this possible?
