Does anyone happen to know if the 3.8 kernel compiled as per these instructions here http://eewiki.net/display/linuxonarm/BeagleBone+Black also contains the fix? I have a root file system already that I want to use but would like to update my kernel to fix this problem.
Thanks. On Tuesday, March 11, 2014 5:50:48 PM UTC-6, Gerald wrote: > > 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 > <[email protected]<javascript:> > > 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 <[email protected] <javascript:>> >> 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 >> > [email protected] <javascript:>. >> > 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] <javascript:>. >> 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.
