El sáb, 20 feb 2021 a las 8:16, Fotis Panagiotopoulos (<f.j.pa...@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 <gebbe...@gmail.com> έγραψε: > > > El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (< > > f.j.pa...@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 <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? > > > > > > > > > > > > > > > > > > > > >
