You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Fotis Panagiotopoulos <f....@gmail.com> on 2021/02/14 12:36:30 UTC
Board-level Ethernet PHY operations in STM32.
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?
Re: Board-level Ethernet PHY operations in STM32.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
> I don't know of any other way to do that other than with a dedicated
> kernal thread and some timer. Wouldn't you have this same issue if you
> were implementing this logic in application space? No real difference
> other than the form of the APIs.
If this is handled in application, I would use an existing network-related
thread, to not waste RAM in a new stack.
But all this started as I wanted to add the board-specific logic to the
board-specific code.
I was hoping that this simple read/write operation to the MIIM would be
possible to be done in board_timerhook, in a watchdog, or at least in a
worker.
It seems that there is no other way, than to move this back to application
space.
Στις Κυρ, 21 Φεβ 2021 στις 10:10 μ.μ., ο/η Grr <ge...@gmail.com> έγραψε:
> psock_/file_ API is public API for kernel space component, not internal to
> > socket/file subsystem.
> >
>
> I was referring to what Gregory Nutt said, which was
>
> " It would be best to use the internal OS socket interfaces directly"
>
>
> > SPI peripheral driver(e.g. sensor) should call SPI_SELECT to control the
> > chip select, it's the responsibility of SPI bus
> driver(spi_dev_s/spi_ops_s)
> > to do the real action:
> > 1.Control the SPI hardware register to change CS signal
> > 2.Or control the GPIO hardware register
> >
>
> The reference to SPI involves a number of implications from a previous
> discussion about the SPI subsystem:
>
> 1-Several peripherals in a bus, which force to use GPIOs as CSs
> 2-SPI bus drivers which work independent of peripheral drivers
> 3-SPI peripheral drivers which are _not_ limited to one peripheral and
> hardwired to one board
> 4-In such situation, the need to have a better, more general control for
> GPIOs than what ioexpander can offer without practically redoing it anyways
>
> That list pose a number of fundamental changes to several current systems,
> which is what I'm referring to
>
> >
> > > El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
> > > escribió:
> > >
> > > >
> > > > > I suggested using file_open() and file_ioctl() in a previous email.
> > > > > That is wrong. file_ioctl() cannot be used to access
> > > > > socket_ioctls(). You would have to use psock_ioctl().
> > > >
> > > > Because the socket interface goes though the network, there are some
> > > > hand shakes and interlocks to prevent network activity while
> accessing
> > > > the PHY interface. I think using a custom interface would be
> > > > problematic. It would be best to use the internal OS socket
> > > > interfaces directly. They prototyped and described in
> > include/nuttx/net/net.h.
> > > > For example, instead of using socket() you would use psock_socket(),
> > > > instead of using bind(), you would use psock_bind(), instead of using
> > > > ioctl(), you would use psock_ioctl().
> > > >
> > > > The APIs are the same as the user space APIs exception that: (1) the
> > > > are prefaced with psock_ and (2) the do not use an int socket
> > > > descriptor. Rather, they use a pointer to the internal socket
> > > > structure struct socket *
> > > >
> > > >
> > > >
> > > >
> >
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Grr <ge...@gmail.com>.
psock_/file_ API is public API for kernel space component, not internal to
> socket/file subsystem.
>
I was referring to what Gregory Nutt said, which was
" It would be best to use the internal OS socket interfaces directly"
> SPI peripheral driver(e.g. sensor) should call SPI_SELECT to control the
> chip select, it's the responsibility of SPI bus driver(spi_dev_s/spi_ops_s)
> to do the real action:
> 1.Control the SPI hardware register to change CS signal
> 2.Or control the GPIO hardware register
>
The reference to SPI involves a number of implications from a previous
discussion about the SPI subsystem:
1-Several peripherals in a bus, which force to use GPIOs as CSs
2-SPI bus drivers which work independent of peripheral drivers
3-SPI peripheral drivers which are _not_ limited to one peripheral and
hardwired to one board
4-In such situation, the need to have a better, more general control for
GPIOs than what ioexpander can offer without practically redoing it anyways
That list pose a number of fundamental changes to several current systems,
which is what I'm referring to
>
> > El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
> > escribió:
> >
> > >
> > > > I suggested using file_open() and file_ioctl() in a previous email.
> > > > That is wrong. file_ioctl() cannot be used to access
> > > > socket_ioctls(). You would have to use psock_ioctl().
> > >
> > > Because the socket interface goes though the network, there are some
> > > hand shakes and interlocks to prevent network activity while accessing
> > > the PHY interface. I think using a custom interface would be
> > > problematic. It would be best to use the internal OS socket
> > > interfaces directly. They prototyped and described in
> include/nuttx/net/net.h.
> > > For example, instead of using socket() you would use psock_socket(),
> > > instead of using bind(), you would use psock_bind(), instead of using
> > > ioctl(), you would use psock_ioctl().
> > >
> > > The APIs are the same as the user space APIs exception that: (1) the
> > > are prefaced with psock_ and (2) the do not use an int socket
> > > descriptor. Rather, they use a pointer to the internal socket
> > > structure struct socket *
> > >
> > >
> > >
> > >
>
>
RE: Board-level Ethernet PHY operations in STM32.
Posted by Xiang Xiao <xi...@gmail.com>.
> -----Original Message-----
> From: Grr <ge...@gmail.com>
> Sent: Sunday, February 21, 2021 3:07 AM
> To: dev@nuttx.apache.org
> Subject: Re: Board-level Ethernet PHY operations in STM32.
>
> When is using internal OS interfaces from another OS subsystem (or an app) OK and not modularity rape?
>
psock_/file_ API is public API for kernel space component, not internal to socket/file subsystem.
Functions declaration under nuttx/include/ can be used outside the subsystem which implement them.
Subsystem internal functions normally declared in the source code folders, e.g.:
https://github.com/apache/incubator-nuttx/blob/master/fs/inode/inode.h
https://github.com/apache/incubator-nuttx/blob/master/net/socket/socket.h
> For example (and following my development line), if a SPI peripheral driver needs to access GPIO data structure in order to control chip
> select, is it more problematic than an app talking directly to a PHY or less?
>
SPI peripheral driver(e.g. sensor) should call SPI_SELECT to control the chip select, it's the responsibility of SPI bus driver(spi_dev_s/spi_ops_s) to do the real action:
1.Control the SPI hardware register to change CS signal
2.Or control the GPIO hardware register
> El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
> escribió:
>
> >
> > > I suggested using file_open() and file_ioctl() in a previous email.
> > > That is wrong. file_ioctl() cannot be used to access
> > > socket_ioctls(). You would have to use psock_ioctl().
> >
> > Because the socket interface goes though the network, there are some
> > hand shakes and interlocks to prevent network activity while accessing
> > the PHY interface. I think using a custom interface would be
> > problematic. It would be best to use the internal OS socket
> > interfaces directly. They prototyped and described in include/nuttx/net/net.h.
> > For example, instead of using socket() you would use psock_socket(),
> > instead of using bind(), you would use psock_bind(), instead of using
> > ioctl(), you would use psock_ioctl().
> >
> > The APIs are the same as the user space APIs exception that: (1) the
> > are prefaced with psock_ and (2) the do not use an int socket
> > descriptor. Rather, they use a pointer to the internal socket
> > structure struct socket *
> >
> >
> >
> >
Re: Board-level Ethernet PHY operations in STM32.
Posted by Gregory Nutt <sp...@gmail.com>.
On 2/21/2021 1:34 PM, Fotis Panagiotopoulos wrote:
>> You would not want to use the high priority work queue; that would
>> interfere with real time behavior. Nor would you want to use the low
>> priority work queue because that is used by most network drivers and so
>> would probably result in deadlocks.
> Oh, I wouldn't imagine that... That's bad.
>
>> Why no create your own dedicated kernel thread?
> Because I am quite short of RAM, and I wouldn't like to waste any memory in
> a thread's stack.
> I would prefer to somehow reuse RAM, as the workers do.
>
> Will a deadlock in LPWORK happen even if CONFIG_SCHED_LPNTHREADS == 1?
>
> Do I have any other way to poll the PHY?
It might not deadlock if CONFIG_SCHED_LPNTHREADS > 1. It depends on the
particular sequence of events and how the locks are held and the fact
that work queues are FIFO. If CONFIG_SCHED_LPNTHREADS > 1, then things
will no longer run FIFO. That might be worth a try.
Fo CONFIG_SCHED_LPNTHREADS > 1, I would expect the sequence of events like:
1. Network operation starts on an LP thread.
2. It locks the network and initiates and operation
3. Then it unlocks the network and waits for the response (hanging that
first LP thread)
4. The driver responds and runs on a different LP thread. That logic
locks the network, provides the response, wakes up the thread, then
unlocks then network.
5. The first LP thread runs, retakes the lock, and completes the operation.
6. The first LP thread then release the lock and terminates.
But I might be missing something so that is risky. If
CONFIG_SCHED_LPNTHREADS == 1, then the single LP thread is blocked at
step 3 and the driver response cannot be received and that would lead to
the deadlock.
I don't know of any other way to do that other than with a dedicated
kernal thread and some timer. Wouldn't you have this same issue if you
were implementing this logic in application space? No real difference
other than the form of the APIs.
Re: Board-level Ethernet PHY operations in STM32.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
> You would not want to use the high priority work queue; that would
> interfere with real time behavior. Nor would you want to use the low
> priority work queue because that is used by most network drivers and so
> would probably result in deadlocks.
Oh, I wouldn't imagine that... That's bad.
> Why no create your own dedicated kernel thread?
Because I am quite short of RAM, and I wouldn't like to waste any memory in
a thread's stack.
I would prefer to somehow reuse RAM, as the workers do.
Will a deadlock in LPWORK happen even if CONFIG_SCHED_LPNTHREADS == 1?
Do I have any other way to poll the PHY?
Στις Κυρ, 21 Φεβ 2021 στις 9:23 μ.μ., ο/η Gregory Nutt <sp...@gmail.com>
έγραψε:
> You would not want to use the high priority work queue; that would
> interfere with real time behavior. Nor would you want to use the low
> priority work queue because that is used by most network drivers and so
> would probably result in deadlocks.
>
> Why no create your own dedicated kernel thread?
>
> On 2/21/2021 11:49 AM, Fotis Panagiotopoulos wrote:
> > Thank you very much!
> >
> > The interface psock_* seems good.
> >
> > However, I need it to be called periodically. board_timerhook and
> watchdogs
> > cannot call this interface.
> > I guess, a work queue is my only option for this task?
> >
> > Στις Σάβ, 20 Φεβ 2021 στις 9:07 μ.μ., ο/η Grr <ge...@gmail.com>
> έγραψε:
> >
> >> When is using internal OS interfaces from another OS subsystem (or an
> app)
> >> OK and not modularity rape?
> >>
> >> For example (and following my development line), if a SPI peripheral
> driver
> >> needs to access GPIO data structure in order to control chip select, is
> it
> >> more problematic than an app talking directly to a PHY or less?
> >>
> >> El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
> >> escribió:
> >>
> >>>> I suggested using file_open() and file_ioctl() in a previous email.
> >>>> That is wrong. file_ioctl() cannot be used to access
> >>>> socket_ioctls(). You would have to use psock_ioctl().
> >>> Because the socket interface goes though the network, there are some
> >>> hand shakes and interlocks to prevent network activity while accessing
> >>> the PHY interface. I think using a custom interface would be
> >>> problematic. It would be best to use the internal OS socket interfaces
> >>> directly. They prototyped and described in include/nuttx/net/net.h.
> >>> For example, instead of using socket() you would use psock_socket(),
> >>> instead of using bind(), you would use psock_bind(), instead of using
> >>> ioctl(), you would use psock_ioctl().
> >>>
> >>> The APIs are the same as the user space APIs exception that: (1) the
> >>> are prefaced with psock_ and (2) the do not use an int socket
> >>> descriptor. Rather, they use a pointer to the internal socket structure
> >>> struct socket *
> >>>
> >>>
> >>>
> >>>
>
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Gregory Nutt <sp...@gmail.com>.
You would not want to use the high priority work queue; that would
interfere with real time behavior. Nor would you want to use the low
priority work queue because that is used by most network drivers and so
would probably result in deadlocks.
Why no create your own dedicated kernel thread?
On 2/21/2021 11:49 AM, Fotis Panagiotopoulos wrote:
> Thank you very much!
>
> The interface psock_* seems good.
>
> However, I need it to be called periodically. board_timerhook and watchdogs
> cannot call this interface.
> I guess, a work queue is my only option for this task?
>
> Στις Σάβ, 20 Φεβ 2021 στις 9:07 μ.μ., ο/η Grr <ge...@gmail.com> έγραψε:
>
>> When is using internal OS interfaces from another OS subsystem (or an app)
>> OK and not modularity rape?
>>
>> For example (and following my development line), if a SPI peripheral driver
>> needs to access GPIO data structure in order to control chip select, is it
>> more problematic than an app talking directly to a PHY or less?
>>
>> El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
>> escribió:
>>
>>>> I suggested using file_open() and file_ioctl() in a previous email.
>>>> That is wrong. file_ioctl() cannot be used to access
>>>> socket_ioctls(). You would have to use psock_ioctl().
>>> Because the socket interface goes though the network, there are some
>>> hand shakes and interlocks to prevent network activity while accessing
>>> the PHY interface. I think using a custom interface would be
>>> problematic. It would be best to use the internal OS socket interfaces
>>> directly. They prototyped and described in include/nuttx/net/net.h.
>>> For example, instead of using socket() you would use psock_socket(),
>>> instead of using bind(), you would use psock_bind(), instead of using
>>> ioctl(), you would use psock_ioctl().
>>>
>>> The APIs are the same as the user space APIs exception that: (1) the
>>> are prefaced with psock_ and (2) the do not use an int socket
>>> descriptor. Rather, they use a pointer to the internal socket structure
>>> struct socket *
>>>
>>>
>>>
>>>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
Thank you very much!
The interface psock_* seems good.
However, I need it to be called periodically. board_timerhook and watchdogs
cannot call this interface.
I guess, a work queue is my only option for this task?
Στις Σάβ, 20 Φεβ 2021 στις 9:07 μ.μ., ο/η Grr <ge...@gmail.com> έγραψε:
> When is using internal OS interfaces from another OS subsystem (or an app)
> OK and not modularity rape?
>
> For example (and following my development line), if a SPI peripheral driver
> needs to access GPIO data structure in order to control chip select, is it
> more problematic than an app talking directly to a PHY or less?
>
> El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
> escribió:
>
> >
> > > I suggested using file_open() and file_ioctl() in a previous email.
> > > That is wrong. file_ioctl() cannot be used to access
> > > socket_ioctls(). You would have to use psock_ioctl().
> >
> > Because the socket interface goes though the network, there are some
> > hand shakes and interlocks to prevent network activity while accessing
> > the PHY interface. I think using a custom interface would be
> > problematic. It would be best to use the internal OS socket interfaces
> > directly. They prototyped and described in include/nuttx/net/net.h.
> > For example, instead of using socket() you would use psock_socket(),
> > instead of using bind(), you would use psock_bind(), instead of using
> > ioctl(), you would use psock_ioctl().
> >
> > The APIs are the same as the user space APIs exception that: (1) the
> > are prefaced with psock_ and (2) the do not use an int socket
> > descriptor. Rather, they use a pointer to the internal socket structure
> > struct socket *
> >
> >
> >
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Grr <ge...@gmail.com>.
When is using internal OS interfaces from another OS subsystem (or an app)
OK and not modularity rape?
For example (and following my development line), if a SPI peripheral driver
needs to access GPIO data structure in order to control chip select, is it
more problematic than an app talking directly to a PHY or less?
El sáb, 20 feb 2021 a las 12:30, Gregory Nutt (<sp...@gmail.com>)
escribió:
>
> > I suggested using file_open() and file_ioctl() in a previous email.
> > That is wrong. file_ioctl() cannot be used to access
> > socket_ioctls(). You would have to use psock_ioctl().
>
> Because the socket interface goes though the network, there are some
> hand shakes and interlocks to prevent network activity while accessing
> the PHY interface. I think using a custom interface would be
> problematic. It would be best to use the internal OS socket interfaces
> directly. They prototyped and described in include/nuttx/net/net.h.
> For example, instead of using socket() you would use psock_socket(),
> instead of using bind(), you would use psock_bind(), instead of using
> ioctl(), you would use psock_ioctl().
>
> The APIs are the same as the user space APIs exception that: (1) the
> are prefaced with psock_ and (2) the do not use an int socket
> descriptor. Rather, they use a pointer to the internal socket structure
> struct socket *
>
>
>
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Gregory Nutt <sp...@gmail.com>.
> I suggested using file_open() and file_ioctl() in a previous email.
> That is wrong. file_ioctl() cannot be used to access
> socket_ioctls(). You would have to use psock_ioctl().
Because the socket interface goes though the network, there are some
hand shakes and interlocks to prevent network activity while accessing
the PHY interface. I think using a custom interface would be
problematic. It would be best to use the internal OS socket interfaces
directly. They prototyped and described in include/nuttx/net/net.h.
For example, instead of using socket() you would use psock_socket(),
instead of using bind(), you would use psock_bind(), instead of using
ioctl(), you would use psock_ioctl().
The APIs are the same as the user space APIs exception that: (1) the
are prefaced with psock_ and (2) the do not use an int socket
descriptor. Rather, they use a pointer to the internal socket structure
struct socket *
Re: Board-level Ethernet PHY operations in STM32.
Posted by Gregory Nutt <sp...@gmail.com>.
> Board should export/expose resources in a general way so drivers can use
> them in a common, transparent way. That's the point of a portable OS
>
> If there's not a standard way in NuttX to export R/MII (I haven't looked at
> it), maybe you need to create it
The PHY R/MII interface is exported via a socket ioctl() interface.
The PHY interface is typically controlled by the Ethernet driver using
PHY hooks. See, for example, arch/arm/src/stm32/stm32_eth.c, PHY ioctl
functions . It accessed by a user-space ioctl() command on a socket
descriptor. The network stack forwards device-related ioctl() commands
to the Ethernet device driver ioctl() functionis.
I suggested using file_open() and file_ioctl() in a previous email.
That is wrong. file_ioctl() cannot be used to access socket_ioctls().
You would have to use psock_ioctl().
Re: Board-level Ethernet PHY operations in STM32.
Posted by Grr <ge...@gmail.com>.
El sáb, 20 feb 2021 a las 8:16, Fotis Panagiotopoulos (<f....@gmail.com>)
escribió:
> Low-level is close to the hardware. Think arch.
> High-level is away from the hardware. Think app.
> This is a standard industry convention, and it is followed in NuttX too.
>
Then we were talking the same from the beginning. I was implying that more
general OS interfaces, closer to app, are higher level
And you were talking about bypassing network system by using MII directly
from the app. That's why I talked about doing it at the highest level
possible, meaning constructing an upper-half driver for R/MII (and possibly
also a lower-half one if it doesn't exist)
Of course time constraints are a PITA
>
> Στις Σάβ, 20 Φεβ 2021 στις 4:04 μ.μ., ο/η Grr <ge...@gmail.com> έγραψε:
>
> > El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (<
> > f.j.panag@gmail.com>)
> > escribió:
> >
> > > 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.
> > >
> >
> > We're thinking level in the opposite way. I said
> >
> > "The higher the level, the better. If possible, do it at the general
> level"
> >
> > meaning that general level (common to all archs) is the highest.
> >
> > Adopting your convention, do it at the lowest, trying to do it at the
> > general, "common to all archs" level
> >
> > 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.
> > >
> >
> > That's what I'm calling for. That's why I talked about SPI and I2C
> problems
> >
> > >
> > > 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.
> > >
> >
> > No. That's a contradiction of your previous idea.
> >
> > Board should export/expose resources in a general way so drivers can use
> > them in a common, transparent way. That's the point of a portable OS
> >
> > If there's not a standard way in NuttX to export R/MII (I haven't looked
> at
> > it), maybe you need to create it
> >
> >
> > >
> > >
> > > Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr <ge...@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.panag@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.panag@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?
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
Low-level is close to the hardware. Think arch.
High-level is away from the hardware. Think app.
This is a standard industry convention, and it is followed in NuttX too.
> 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
The thing is that this issue is extremely difficult to reproduce in the lab.
And it may be specific to the LAN8720A silicon...
> If there's not a standard way in NuttX to export R/MII (I haven't looked
at
> it), maybe you need to create it
Unfortunately, I don't have the resources available at the moment to do so.
But still, I would like to have the opinion of someone more knowledgeable
on this aspect of the kernel.
Στις Σάβ, 20 Φεβ 2021 στις 4:04 μ.μ., ο/η Grr <ge...@gmail.com> έγραψε:
> El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (<
> f.j.panag@gmail.com>)
> escribió:
>
> > 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.
> >
>
> We're thinking level in the opposite way. I said
>
> "The higher the level, the better. If possible, do it at the general level"
>
> meaning that general level (common to all archs) is the highest.
>
> Adopting your convention, do it at the lowest, trying to do it at the
> general, "common to all archs" level
>
> 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.
> >
>
> That's what I'm calling for. That's why I talked about SPI and I2C problems
>
> >
> > 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.
> >
>
> No. That's a contradiction of your previous idea.
>
> Board should export/expose resources in a general way so drivers can use
> them in a common, transparent way. That's the point of a portable OS
>
> If there's not a standard way in NuttX to export R/MII (I haven't looked at
> it), maybe you need to create it
>
>
> >
> >
> > Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr <ge...@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.panag@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.panag@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?
> > > > >
> > > >
> > >
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Grr <ge...@gmail.com>.
El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (<f....@gmail.com>)
escribió:
> 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.
>
We're thinking level in the opposite way. I said
"The higher the level, the better. If possible, do it at the general level"
meaning that general level (common to all archs) is the highest.
Adopting your convention, do it at the lowest, trying to do it at the
general, "common to all archs" level
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.
>
That's what I'm calling for. That's why I talked about SPI and I2C problems
>
> 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.
>
No. That's a contradiction of your previous idea.
Board should export/expose resources in a general way so drivers can use
them in a common, transparent way. That's the point of a portable OS
If there's not a standard way in NuttX to export R/MII (I haven't looked at
it), maybe you need to create it
>
>
> Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr <ge...@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.panag@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.panag@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?
> > > >
> > >
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Gregory Nutt <sp...@gmail.com>.
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 <ge...@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.panag@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.panag@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?
>>>>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
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 <ge...@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.panag@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.panag@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?
> > >
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Grr <ge...@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....@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.panag@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?
> >
>
Re: Board-level Ethernet PHY operations in STM32.
Posted by Fotis Panagiotopoulos <f....@gmail.com>.
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.panag@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?
>