If anyone has any further information on the software fix/patch for this issue I would be very interested in hearing about it (and backporting into the kernel from late last year I am using) - or even the best way to search for patches to particular files.
Regards, Andrew. On 12 March 2014 11:41, Loren Amelang <[email protected]> wrote: > Got it! (Chrome print to PDF, copy from the print...) > > ----- > 3.7.1 PHYAD[2:0]: PHY Address Configuration > > The PHYAD[2:0] configuration straps are driven high or low to give each PHY > a unique address. This address is latched into an internal register at the > end of a hardware reset (default = 000b). In a multitransceiver application > (such as a repeater), the controller is able to manage each transceiver via > the unique address. Each transceiver checks each management data frame for a > matching address in the relevant bits. When a match is recognized, the > transceiver responds to that particular frame. The PHY address is also used > to seed the scrambler. In a multi-transceiver application, this ensures that > the scramblers are out of synchronization and disperses the electromagnetic > radiation across the frequency spectrum. > > The device's SMI address may be configured using hardware configuration to > any value between 0 and 7. The user can configure the PHY address using > Software Configuration if an address greater than 7 is required. The PHY > address can be written (after SMI communication at some address is > established) using the PHYAD bits of the Special Modes Register. The > PHYAD[2:0] configuration straps are multiplexed with other signals as shown > in Table 3.5. > ----- > > > From my A5C Schematic, showing processor names = LAN8710A names = Microchip > names: > > GMII1_RXERR/RMII1_RXERR/SPI1_D1/I2C1_SCL/MCASP1_FSX/UART5_RTSN/UART2_TXD/GPIO3_2 > = RXER/PHYAD0 = RXER/RXD4/PHYAD0 > > GMII1_RXCLK/UART2_TXD/RGMII1_RCLK/MMC0_DAT6/MMC1_DAT1/UART1_DSRN/MCASP0_FSX/GPIO3_10 > = REFCLKO = RXCLK/PHYAD1 > > GMII1_RXCLK/UART2_TXD/RGMII1_RCLK/MMC0_DAT6/MMC1_DAT1/UART1_DSRN/MCASP0_FSX/GPIO3_10 > = RXD3/PHYAD2 = RXD3/PHYAD2 > > > Obviously a lot of multiplexed uses there! Microchip says, "This address is > latched into an internal register at the end of a hardware reset (default = > 000b)." But their reset is "SYS_RESETn", right? The same reset caused by the > user reset button? How is the processor supposed to control those three > signals while it is reset? > > So how do three bits default to "000b"? I guess they are counting the > address bits you can only program in software? But if those default to 000b, > how does my chip end up as phy[0]? > > Maybe that's where the mask comes in? Mine works with mask fffffffe: > [ 2.482812] davinci_mdio 4a101000.mdio: detected phy mask fffffffe > [ 2.490309] libphy: 4a101000.mdio: probed > [ 2.494577] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, > driver SMSC LAN8710/LAN8720 > [ 2.504409] Detected MACID = 90:59:af:4d:71:eb > ... > [ 5.854282] libphy: PHY 4a101000.mdio:01 not found > [ 5.859335] net eth0: phy 4a101000.mdio:01 not found on slave 1 > > While I see reports above in this thread that > On Tuesday, November 26, 2013 2:22:42 PM UTC-8, AndrewTaneGlen wrote: > On a good phy boot I see the following: > [ 2.810749] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 > [ 2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe > ... > On a 'bad phy' boot I see the following (differences highlighted): > [ 2.806763] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 > [ 2.813213] davinci_mdio 4a101000.mdio: detected phy mask fffffffb > > > I'm betting the "fe" mask eliminates the default "000b" bits that are not > set by hardware, allowing the good boot. > > Of the hardware set bits, it seems my chip must get address zero, so all > three signals must be zero when reset ends. With mask "fe", only the > hardware lines are checked. > > But... Where does the mask come from? I'm not finding it in the boot > environment settings. It looks like it is read from the chip: > [ 2.817206] davinci_mdio 4a101000.mdio: detected phy mask fffffffe > But it is not mentioned that I see in the Microchip doc. > > Always another mystery... > > > > > On Tuesday, March 11, 2014 12:56:43 PM UTC-7, Gerald wrote: >> >> Look in the LAN 8710A data sheet from SMSC. I would cut an paste it, but >> Microchip has cut and paste blocked. >> >> http://www.microchip.com/wwwproducts/Devices.aspx?product=LAN8710A Section >> 3.7.1 >> >> >> Gerald >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
