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
CONFIG_MAILBOX=y |
# CONFIG_OMAP_MBOX is not set |
# CONFIG_OMAP2PLUS_MBOX is not set |
# CONFIG_OMAP_MBOX_KFIFO_SIZE is not set |
The davinci mdio driver should report a phymask and that value is used to update the device tree.
I also remove the second phy slave from the device tree.
As far as I know, and as already documented in this thread, the only reliable fix is to remove C24 and C30.
--
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...@googlegroups.com.
As far as I know, and as already documented in this thread, the only reliable fix is to remove C24 and C30.
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.
Yes, and reading the thread even more fully you'll find my report of running thousands of automated test restarts with these parts removed, with a 100% success rate.
We use these boards a lot, running 24-7 in this configuration, and have had zero hardware faults. With any luck we have nearly exhausted Murphy's law with our software.
Andrew.
Yes, and reading the thread even more fully you'll find my report of running thousands of automated test restarts with these parts removed, with a 100% success rate.
We use these boards a lot, running 24-7 in this configuration, and have had zero hardware faults. With any luck we have nearly exhausted Murphy's law with our software.
The mode pin setting for mode bit 2 connects to the wrong pin on the LAN8710. It goes to pin 15 and should go to pin 14 instead. This should not cause any operational issues as the internal registers are set correctly in Uboot by the default SW that is provided. If you are not using UBoot or have a custom UBoot, you will need to set the register inside the LAN8710 for proper operation. There is a preepmtion issue in SW that is currently being worked. There was a theory that this error was causing the issue. As long as you set the correct values in your initialzation code, this will not cause this issue and as the default UBoot correctly sets the register correctly for all modes and auto negotiate enabled which is what the default mode was intended to be.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
On Dec 9, 2014, at 3:40 PM, alexschn...@gmail.com wrote:
--
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...@googlegroups.com.
The topic starter there reported that a reboot via watchdog didn't work.
Another idea: the TPS65217C data sheet describes various ways to perform the "power up sequence" (page 18), and it can be done from ACTIVE state too, by setting the SEQUP bit of the SEQ6 register to 1. I'm trying to understand now, whether this can cause a processor power cycle (and thus, drive the nRESETIN_OUT low), because some power rails are not affected by the "power up sequence".
So far, the only working solution seems to be removing C24 and C30 capacitors, which is not good for a variety of reasons, as was mentioned in some previous messages here.
--
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.
--
Once in a while this happens too soon and the PHY doesn't come out of reset correctly.
correct:
[ 1.206085] CAN bus driver for Bosch D_CAN controller 1.0
[ 1.253601] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[ 1.260040] davinci_mdio davinci_mdio.0: detected phy mask fffffffe
[ 1.267333] davinci_mdio.0: probed
[ 1.270874] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver SMSC LAN8710/LAN8720
wrong:
[ 1.186248] CAN bus driver for Bosch D_CAN controller 1.0
[ 1.233612] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
[ 1.240051] davinci_mdio davinci_mdio.0: detected phy mask fffffffb
[ 1.247283] davinci_mdio.0: probed
[ 1.250823] davinci_mdio davinci_mdio.0: phy[2]: device 0:02, driver SMSC LAN8710/LAN8720
--
This is a known issue. The problem is that the AM335X nRESET_INOUT (or warm reset) is released at approximately the moment that the PHY latches internally it's bootstrap resistors. Once in a while this happens too soon and the PHY doesn't come out of reset correctly. This can be avoided if the PHY reset is tied to a processor GPIO (it's important that the GPIO stays in low state during reset and at reset release time).
Regards
Alex
We have also made many variation boards, including 2 PHY design, dual gigabit phy, etc. |
--
--
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+unsubscribe@googlegroups.com.
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...@googlegroups.com.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.