Of all the gin joints in all the towns in all the world, Andrew Fish had to walk into mine at 15:42:46 on Monday 25 May 2015 and say:
> > On May 25, 2015, at 7:44 AM, Sharma Bhupesh > > <bhupesh.sha...@freescale.com> wrote: > > > > Hi Andrew, > > > > Thanks for the reply. > > > > AFAICR the ARMv8 Juno/foundation model platforms support the SMSC-911c > > integrated MAC + PHY controller which is available as a single composite > > module. > > > > However usually on ARM platforms there can be a Ethernet MAC controller + > > some discrete PHY components available from various PHY vendors. In such > > a case a MDC/MDIO bus usually needs to be used/programmed to get the PHY > > link status and/or frame reception/transmission. > > > > The UEFI specification 2.4 has standards dedicated for the SNP, Managed > > network and like, but we cannot find any specific information required > > to maintain PHY states or the MDC/MDIO information. Even if the initial > > PHY configuration is left upto the chip-specific init-code, how should > > we manage the run-time PHY states/errors etc. > > I assume the NIC would just return an EFI_DEVICE_ERROR. While this information about error reporting is nice an all, it's secondary to the main issue which is how to handle the case where the PHY is not a direct child device of the MAC. It's very common to have an SoC with internal ethernet MACs and external PHY chips. Exactly why it's done that way I'm not entirely sure (I'm not an SoC designer), but likely reasons are power consumption/heat dissipation concerns, the desire to allow customers to choose what kind of media to use (fiber or copper) and that the SoC designer may not actually own any PHY IP. Anyway, having external PHY chips means you have to wire them to the SoC somehow, and at that point the designer has to worry about pin usage. SerDes interfaces are becoming more common because they minimize the number of RX/TX pins you need. But that's just for exchanging frame data. You also have to manage the PHYs (issue reset, set up autonegotiation, check link state, work around errata, etc...) For management, you need two pins per PHY (one data pin, one clock pin). If you have four MACs in your chip, that means you might need up to 8 pins. However, most SoCs have so many integrated peripherals that they can't spare that many. To deal with this, they only reserve 2 pins for MDIO and wire all the PHY clock and data pins together in parallel. The MII specification allows you to do this: you can address up to 32 separate PHYs that are all connected to the same MII bus. Technically, I think this is an abuse of the design. The original intent was to allow a single MAC to potentially have more than one physical layer -- for example you could have a NIC that has both copper and fiber ports on it. If you only have one MAC, then you can't use both the copper and fiber connections at the same time, but you can switch between them. (You can isolate one PHY's RX/TX pins from the MAC, allowing only the other to operate.) The shared management interface allows you to access the management registers of either PHY by specifying the address of the PHY you want to talk to (a value from 0 to 31) when you issue a read or write request. I don't think it was ever intended that this scheme be used to have multiple MACs and multiple PHYs to share one set MDIO pins, but that's what ended up happening. (Hardware designers are prone to making choices like this and leaving it to the software people to deal with the fallout.) I've worked with may SoCs based on PPC. MIPS and ARM that are designed this way, from various vendors (including Freescale). It's very common practice. Sometimes it can be very messy: I've worked on one board where managing the PHYs required using MDIO pins, GPIO pins and I2C. (Ever see those 1000baseT SFP modules? They have a Marvell 88E1111 chip inside, and you talk to them using I2C. But they're all configured to respond to the same I2C address. With the board I worked on, they dealt with this by using GPIO pins to control multiplexing logic to choose which of the SFP modules was connected to the SoC's I2C bus at any one time.) Anyway, this creates two major problems for the driver designer: 1) Registers used to access the MDIO pins are sometimes distinct from the register bank belonging to the MAC. If you have a bunch of Intel PRO/1000 NICs, each MAC has a couple of MDIO access registers, so each driver instance can privately manage its own PHY. With an SoC design, you might have a bank of registers for the ethernet MAC at one base address, and the MDIO access registers at one be somewhere entirely different. They might just be GPIO registers (in which case you have to write your own bitbang code to do the PHY reads and writes). When you write a driver, you tend to say: this driver is responsible for managing this bank of device registers, and nothing else. If the MDIO access is performed using a distinct set of registers from the MAC, then technically that means you have two devices, which should each be managed by separate drivers. But one depends on the other, so somehow they have to work together. 2) Sometimes there are multiple MACs, but only one set of MDIO registers (because all the PHY's MDIO pins are tied to the same clock/data pins on the SoC). Now you have several NIC instances that have to share access to the same set of registers. Since reading/writing PHY registers is not an atomic operation, you some sort of arbitration must be enforced. This is not something that tends to happen in the Intel world. You usually have PCI devices, and each PCI NIC is a complete standalone device, with MAC and PHY together. There is a nice, neat hierarchy: the MAC is a child of the PCI bus, and the PHY is a child of the MAC. This is an artifact of the evolution of the PC world: at first, all network adapters were plug-in cards, and today, from a software perspective, they still like that way. With SoCs, it's not that simple. The MAC and PHY are more like sibling devices than parent and child. And if there are multiple MACs, they will all end up sharing one MDIO port. Honestly, I don't know if the EDK has an officially sanctioned way of dealing with this. There probably should be though, UEFI is to be used on ARM to any great extent. If you consider the MDIO port as a separate device, then somehow the NIC driver has to acquire a handle to the MDIO "device" in order to issue PHY read/write requests to it. This means there would be interactions between sibling device nodes, which may be undesirable. Also, there is the question of ordering: you have to instantiate the MDIO device node first, so that the NIC node can use it later. And lastly, the MDIO driver must use mutual exclusion to guard access to the MDIO registers so that you avoid overlapped accesses. (Maybe this isn't an issue with the EDK, since I don't think it's an SMP environment, but for OS-level software, this is definitely a concern.) If you don't want to have sibling nodes reference each other, then you probably need to have the MDIO logic be part of some parent node to which the child nodes can issue requests. This requires some careful planning of your overall platform design. Also, it should be noted that the question of which PHY goes with which MAC is not something that can be autoprobed. With the typical plug-in NIC design, you expect that the MAC will only have one PHY device. You don't necessarily have to know ahead of time what it is: you can just probe all 32 possible device addresses until you find one where a PHY responds to you. But with the SoC case, if you resort to auto-discovery, you will find multiple PHYs. How do you know which one goes with which MAC? Really, it was the board designer that decided this when they created the board wiring layout. You might say "well, can't I assume that the first PHY goes with the first MAC, and the second PHY goes with the second MAC, and so on?" No, you can't assume that. There's no guarantee that the board designer was that nice. Maybe the PHYs addresses are assigned in reverse order. (Note that the board designer is also responsible for setting the strapping pins on the PHYs to select what addresses they respond to.) This is basically just an aspect of the board design that you have to know ahead of time. It has to be baked into the code or saved in NVRAM somewhere. (The latter case may be simpler if you expect to have several variants of the same basic board design.) And lastly, you can't really say "just have some platform code initialize the PHY at start up and leave it alone after that." Another concern is that you might have to program the MAC to to match the speed/duplex settings that were negotiated by the PHY when it brought up the link. You might have to set a register in the MAC to select the link speed (10, 100, 1000Mbps) and duplex setting (full, half), and in order to know that, you have to query the status registers in the PHY. And you can't say "well, can't we just negotiate the link at start-up and save the link parameters somewhere for the MAC driver to read later?" No, you can't do that either, because that won't handle on-the- fly unplug/replug events. If don't track link state changes, and I boot up with the system connected to a 100Mbps link, and I then connect it to a 1000Mbps link without rebooting, I will lose connectivity. Oh yeah, sometimes the PHY will have an interrupt pin too, so that they can signal link state changes immediately. I usually ignore them and resort to using a background task to poll the link state periodically. The problem with using the interrupts is that you have to access PHY registers to cancel them when they occur, and remember that those accesses are not atomic and must be guarded with a mutual exclusion mechanism to protect against overlapped accesses. If you use interrupts, then you have to perform PHY reads/writes from the interrupt handler, and the only way to guard access correctly in that case is to use spinlocks. Long story short, I think it's generally left up to the driver writer to deal with this in whatever way they deem is least offensive. There isn't a good way to handle this stuff: only the least awful way. I don't think the EDK specification will ever directly address this as it's considered an implementation detail, though a little guidance would be nice. -Bill > For extensible error reporting you would need to look at: > https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/Driv > erDiagnostics2.h > <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/Dr > iverDiagnostics2.h> > https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/Dri > verHealth.h > <https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/Dr > iverHealth.h> > > > Thanks, > > Andrew Fish > > > Regards, > > Bhupesh > > > > From: Andrew Fish [mailto:af...@apple.com] > > Sent: Wednesday, May 20, 2015 8:36 PM > > To: edk2-devel@lists.sourceforge.net > > Subject: Re: [edk2] Phy support > > > > > > On May 19, 2015, at 10:44 PM, Meenakshi Aggarwal > > <meenakshi.aggar...@freescale.com > > <mailto:meenakshi.aggar...@freescale.com>> wrote: > > > > Hi All, > > > > Kindly help. > > > > > > There is no industry standard for adding PHY support. You will need to > > look at the driver for the MAC. Or it could be part of the chipset init > > code. > > > > Thanks, > > > > Andrew Fish > > > > > > > > Regards > > Meenakshi > > > > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@freescale.com > > <mailto:meenakshi.aggar...@freescale.com>] Sent: Monday, May 18, 2015 > > 9:32 AM > > To: edk2-devel@lists.sourceforge.net > > <mailto:edk2-devel@lists.sourceforge.net> Subject: [edk2] Phy support > > > > Hi, > > > > > > I need to add support of PHY driver without integrated MAC controller. > > > > Please suggest if I can have anything for reference. > > > > If reference code is not available then please suggest the protocol I > > need to implement. > > > > > > > > > > Thanks & regards > > Meenakshi Aggarwal > > > > ------------------------------------------------------------------------- > > ----- One dashboard for servers and applications across > > Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ > > applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y__________________ > > _____________________________ > > <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y________________ > > _______________________________> edk2-devel mailing list > > edk2-devel@lists.sourceforge.net > > <mailto:edk2-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > <https://lists.sourceforge.net/lists/listinfo/edk2-devel> > > > > ------------------------------------------------------------------------- > > ----- One dashboard for servers and applications across > > Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ > > applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y__________________ > > _____________________________ edk2-devel mailing list > > edk2-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/edk2-devel -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
