I know what I have seen. I know what I have replicated. And I know the SW fix takes care of it.
I also know it does not happen on every board and doe snot happen every time. Do keep in mind that the board reset is not a HW reset. It is a SW reset. The fix is in the latest image from Robert. http://beagleboard.org/latest- images/ Gerald On Tue, Mar 11, 2014 at 6:16 PM, Andrew Glen <andrewtaneg...@gmail.com>wrote: > 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 <lorenamel...@gmail.com> 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=LAN8710ASection > >> 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 > > beagleboard+unsubscr...@googlegroups.com. > > 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 beagleboard+unsubscr...@googlegroups.com. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
