--
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/groups/opt_out.
--
Try removing C24. See if that helps.
We saw the same problem. After removing C24 and C30 it seems to be solved!
Our board is revision B.
Robert
--
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.
Correct. You can also solve the issue by using the correct SW as well. The issue is that the processors interferes with the default address settings when the PHY reads the pins. If the SW looks for the other addresses, it works fine.Also, removing these caps will also create issues where the board does not boot at all. Not exactly a good trade.
I got my Ubuntu 12.04 from here: http://www.armhf.com/index.php/download/
When I searched for "beaglebone+ubuntu" I got many results. So its hard to find the "correct" software.
So where can I find it? Do you have a link?
Thanks - Robert
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.
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