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.On Tue, Mar 11, 2014 at 6:16 PM, Andrew Glen <andrewt...@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.
> You received this message because you are subscribed to a topic in the
On 12 March 2014 11:41, Loren Amelang <lorena...@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=LAN8710A Section
>> 3.7.1
>>
>>
>> Gerald
>>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> 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...@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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The 5V is fine (maybe a little spike of 0.8V after 60 ms PS).
However, the 3.3V gives a strange 2-stage powerup cycle. I compared a revision A5C to a revision A6, see plots below.
As can be seen the A5C has a 'normal ' powerup cycle on the 3.3V, but the A6 a 2-stage powerup cycle. May this cause any problems with PHY?
Hello,I have noticed very rare cases (~1/50) of the ethernet phy on the Beaglebone Black not being detected on boot, and requiring a hard reset (as opposed to calling 'reset' from the command line) to get it to work/be detected again.This problem has been mentioned in a couple of other threads (below) concerning different topics (i.e. problems getting the BBB to boot, and the ethernet phy 'dying' some time after initially working fine), with no solution/workaround for this specific problem being suggested - so I thought I'd start a thread specifically for it.In the first thread mlc/Mike discussed his response to the problem as follows:"I had issues with the network not coming up on boot, and it was traced
down to problems with the SYS_RESETn line.
I had a level translator connected to SYS_RESETn, to drive a 5V chip.
It was powered by a 5V rail. If the 5V rail powered up "differently"
than the 3.3V rail (not sure of the exact relationship), I guess it
pulled the SYS_RESETn line to weird levels that affected the network
chip but not the main processor. I'm now using a GPIO to drive the
external 5V chip now, instead of the SYS_RESETn line.
Anyway, the moral is be very, very careful with SYS_RESETn, because it
can cause hard-to-trace problems with networking."I see that the A6 Revision of the Beaglebone Black has some changes to the SYS_RESETn line:"Based on notification from TI, in random instances there could be a glitch in the SYS_RESETn signal from the processor where the SYS_RESETn signal was taken high for a momentary amount of time before it was supposed to. To prevent this, the signal was ORed with the PORZn (Power On reset)." (http://elinux.org/Beagleboard:BeagleBoneBlack#Revision_A6_.28Production_Version.29)Is it likely that this modification will improve/resolve the issue I am seeing with the ethernt phy not resetting/powering-up correctly?, seeing as the SYS_RESETn signal also feeds into the nRST pin on the ethernet phy (The SYS_RESETn line is left untouched in my application).Some additional observations from dmesg concerning this use:
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
[ 2.833517] libphy: 4a101000.mdio: probed
[ 2.837871] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver unknown
Followed later by:
[ 21.286920] net eth0: initializing cpsw version 1.12 (0)
[ 21.301166] net eth0: phy found : id is : 0x7c0f1
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
[ 2.829512] libphy: 4a101000.mdio: probed
[ 2.833875] davinci_mdio 4a101000.mdio: phy[2]: device 4a101000.mdio:02, driver unknown
Followed later by:
[ 21.346861] net eth0: initializing cpsw version 1.12 (0)
[ 21.354379] libphy: PHY 4a101000.mdio:00 not found
[ 21.359469] net eth0: phy 4a101000.mdio:00 not found on slave 0So it looks like the 'davinci_mdio_reset' function see the phy in both instances, but reports differently on the bad boot. I am not sure what to make of this.I am using the Debian 7.2 Rootfs and the 'RobertCNelson' kernel '3.12.0-bone8'.Regards,Andrew.
Update. I have now witnessed the problem on RCS's 3.13.x kernels :(
I have encountered the same issue(s) on A6A boards.
I couldn't find a patch, so I wrote this patch to update the device tree in the davinci_mdio driver in the 3.15.1 tree, it seems to correct it. I would welcome any input on a different approach.
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 0cca9de..e5a9cdc 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -39,6 +39,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/pinctrl/consumer.h>
+#include <linux/phy.h>
/*
* This timeout definition is a worst-case ultra defensive measure against
@@ -97,6 +98,10 @@ struct davinci_mdio_data {
unsigned long access_time; /* jiffies */
};
+#if IS_ENABLED(CONFIG_OF)
+static void davinci_mdio_update_dt_from_phymask(u32 phy_mask);
+#endif
+
static void __davinci_mdio_reset(struct davinci_mdio_data *data)
{
u32 mdio_in, div, mdio_out_khz, access_time;
@@ -150,6 +155,11 @@ static int davinci_mdio_reset(struct mii_bus *bus)
/* restrict mdio bus to live phys only */
dev_info(data->dev, "detected phy mask %x\n", ~phy_mask);
phy_mask = ~phy_mask;
+
+ #if IS_ENABLED(CONFIG_OF)
+ davinci_mdio_update_dt_from_phymask(phy_mask);
+ #endif
+
} else {
/* desperately scan all phys */
dev_warn(data->dev, "no live phy, scanning all\n");
@@ -312,6 +322,79 @@ static int davinci_mdio_probe_dt(struct mdio_platform_data *data,
}
#endif
+#if IS_ENABLED(CONFIG_OF)
+static void davinci_mdio_update_dt_from_phymask(u32 phy_mask)
+{
+ int i, len;
+ u32 addr;
+ __be32 *old_phy_p, *phy_id_p;
+ struct property *phy_id_property = NULL;
+ struct device_node *node_p, *slave_p;
+
+ addr = 0;
+
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ if ((phy_mask & (1 << i)) == 0) {
+ addr = (u32) i;
+ break;
+ }
+ }
+
+ for_each_compatible_node(node_p, NULL, "ti,cpsw") {
+ for_each_node_by_name(slave_p, "slave") {
+
+ old_phy_p = (__be32 *) of_get_property(slave_p, "phy_id", &len);
+
+ if (len != (sizeof(__be32 *) * 2))
+ goto err_out;
+
+ if (old_phy_p) {
+
+ phy_id_property = kzalloc(sizeof(*phy_id_property), GFP_KERNEL);
+
+ if (! phy_id_property)
+ goto err_out;
+
+ phy_id_property->length = len;
+ phy_id_property->name = kstrdup("phy_id", GFP_KERNEL);
+ phy_id_property->value = kzalloc(len, GFP_KERNEL);
+
+ if (! phy_id_property->name)
+ goto err_out;
+
+ if (! phy_id_property->value)
+ goto err_out;
+
+ memcpy(phy_id_property->value, old_phy_p, len);
+
+ phy_id_p = (__be32 *) phy_id_property->value + 1;
+
+ *phy_id_p = cpu_to_be32(addr);
+
+ of_update_property(slave_p, phy_id_property);
+
+ ++addr;
+ }
+ }
+ }
+
+ return;
+
+err_out:
+
+ if (phy_id_property) {
+ if (phy_id_property->name)
+ kfree(phy_id_property->name);
+
+ if (phy_id_property->value)
+ kfree(phy_id_property->value);
+
+ if (phy_id_property)
+ kfree(phy_id_property);
+ }
+}
+#endif
+
static int davinci_mdio_probe(struct platform_device *pdev)
{
struct mdio_platform_data *pdata = dev_get_platdata(&pdev->dev);
Hello,I'm on the Kernel 3.8.13-bone56 and I've still this problem :Scanning for Btrfs filesystemssystemd-fsck[202]: rootfs: clean, 110431/966656 files, 771069/3864576 blocks[ 7.665617] libphy: PHY 4a101000.mdio:00 not found[ 7.670642] net eth0: phy 4a101000.mdio:00 not found on slave 0[ 7.676834] libphy: PHY 4a101000.mdio:01 not found[ 7.681844] net eth0: phy 4a101000.mdio:01 not found on slave 1
I've to reboot many times to get lucky .....
Well, we made our own rs485 cap, and it also power the cap ( we took example of the lcd7). But I don't why it will make problem....
Well, we made our own rs485 cap, and it also power the lcd7 and the beagle ( we took example of the lcd7). But I don't why it will make problem...
Hello John,Thanks for info.I found below configs are not set in 3.15 by default which were set in 3.8. If we set below configs in 3.15, it works including NFS.CONFIG_IP_PNP=yCONFIG_IP_PNP_DHCP=yCONFIG_ROOT_NFS=yoptional:CONFIG_IP_PNP_BOOTP=yCONFIG_IP_PNP_RARP=y
Hello John,Thanks for info.I found below configs are not set in 3.15 by default which were set in 3.8. If we set below configs in 3.15, it works including NFS.CONFIG_IP_PNP=yCONFIG_IP_PNP_DHCP=yCONFIG_ROOT_NFS=yoptional:CONFIG_IP_PNP_BOOTP=yCONFIG_IP_PNP_RARP=y