The first part of the serial number should be a date code. Anything newer than a specific date should be rev C3, but I need to research the exact date codes. The easy way to recognize them is by looking at the microSD card cage that went end-of-life requiring us to update the design:
Rev C3:
Older revisions:
Note how the newer one’s microSD card cage has gold legs sticking outside the package, whereas they are inside the outline of the package on the older versions.
Some additional information.
The board revision is printed on the bottom side near the barrel jack:
PCB revision C is only used on rev C3 or newer boards. Older rev C, C1, C2 boards used the rev B6 PCB with only BOM updates.
The serial numbers include date codes in them. Seeed was the first to manufacture Rev C3 boards and started doing so in June 2021.
Note: the picture is from the Industrial version (red), but the same PCB is used on the normal version, just is black, instead of red.
A more important question is how U-Boot can recognize rev C3 boards, so that a complete fix for the ethernet phy bug can be implemented using the new phy reset gpio.
On the bright side, that gpio is not used on the older board, it would be safe to toggle…
Regards,
Yes, but that means
while( phy is fucked )
reset phy;
is an infinite loop on pre-C3 boards.
A single reset should make sure the PHY is good., no?
As far as I know it’s the same dice-roll on each PHY reset, whether it’s the initial one at power-on or subsequent manual resets.
TLDR:
Assuming LAN8710 datasheet is correct, then previously the phy reset was implemented in an out-of-spec way, so just a single (compliant) reset signal should be sufficient. It looks to me like this might not happen unless the new GPIO (as implemented on C3 boards) is used.
The following could do with checking…
The following are relevant references:
Schematic for new C3 revision BBB is part of this commit (file BBB_SCH.pdf):
The schematic for the revised board is here as BBB_SCH.pdf:
See changelog entry at bottom of sheet 1…
On page 9, the PHY reset line is now asserted (held low) when either the sys reset signal is low, OR when GPIO1_8 is low (due to the AND gate in the new U1 IC at the bottom of sheet 9).
The AND gate U1 has Schmitt triggers on its inputs, so the length of the assertion of the PHY reset signal is due to the time that GPIO1_8 is held low, and the effect of the new RC network C174 - 4.7 µF - and R33 - 10kΩ.
Datasheet for the Microchip LAN8710A
nRST is a variable-voltage schmitt triggered input with an internal 50µA pull-up (page 12 (table 2-5), page 14 (table 2-9) and which gets de-asserted when it’s input signal rises above a threshold of somewhere between 0.81v and 1.9v (typical 1.65v for the BBB’s 3.3v supply).
Reset signal timing requirements are on page 59 and 60 (section 5.5.3).
In [Resolved] AM3358: BBB reboot issue with Ethernet PHY - Sitara Processors Forum - Sitara™ Processors - TI E2E Community the problem is described by a TI employee as “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).”
… I think this is saying that the violated requirement was that nRST shouldn’t be released less than 25ms after the power supplies go OK (“tpurstd”).
The sys reset signal is held low until the PMIC power good is asserted, and at that point C24 would start to charge, and the line would reach the LAN8710 min/typical/max trigger voltages (0.81v / 1.65v / 1.9v) after 6.2 / 15.3 / 19.9 ms. These are all less than 25ms.
With the new higher value C174, these min/typical/max values become 13.2 / 32.6 / 40.3 ms.
After 25 ms, the voltage should be 1.36v. This assumes that U1 will pull down to 0v (which it won’t completely do), and also disregards the internal pull-up on nRST both of which will cause the voltage to rise quicker, and so release nRST sooner, and also component value tolerances. Other factors could also be favourable of course.
… but because the worst-case the nRST release time looks like it could still be out of spec if the GPIO is not also used, to be on the safe side, the GPIO1_8 should probably be driven low by the bootloader for min 100 µs anyway.
I’m guessing that the code would run more than 25ms after the processor boots (since uboot would be read from flash, and quite a lot of other early init is probably done first).
If we take the LAN8710 datasheet at face value, then this should be sufficient.
Maybe just implement this initially, and see if anyone reports further problems?
Some reasonable looking tests were also reported to check the IC state, so these could be implemented if further problems are reported?
Linux supports reset-gpios device tree properties which can exist in either ethernet phy devicetree nodes, or their parent mdio bus node. Docs: Documentation/devicetree/bindings/net/ethernet-phy.yaml and Documentation/devicetree/bindings/net/mdio.yaml.
I think such a gpio reset gets triggered when the phy is first set up by Linux. I assume that this would also get used if a phy reset was triggered from user space with something like:
ethtool --reset eth0 phy … but I’m not sure if additional work would be needed to enable that in the specific ethernet driver.
It looks like u-boot also supports the same devicetree properties (e.g. see u-boot drivers/net/eth-phy-uclass.c).
Hi Robert,
Thanks for the link. I had started to implement something similar myself (having first checked the mainline kernel), but hadn’t got the additional pinctrl working.
Although the device tree changes are work (reset pin assertion can be seen at kernel startup time with an oscilloscope), I haven’t yet found a way to trigger it from user space (tried mii-tool --reset eth0 and also ethtool --reset eth0 phy).
Also, I think the delay in that git commit is insufficient - having tested with the scope, when reset-delay-us = <2>; the capacitor C174 is only discharged a small amount (typically by about 0.3v, so that it only reaches about 3v) so the voltage on the reset pin doesn’t approach the threshold for a reset.
TLDR: to be conservative, I think it should be:
reset-delay-us = <280>;
How I arrived at that is as-follows:
By experimentation, the minimum time period that the GPIO can be negative so that the reset pin gets down to 0.64v (datasheet table 5-3 “Vilt” (min)) seems to be 140 µs (that is the time from when the voltage starts to fall until the time it reaches 0.64v). Maybe apply a safety-factor of 2x to account for component tolerances, which would give 280 µs.
The minimum assertion time for the RST pin is 100 µs (Table 5-7 “Trstia” (min)), but I think that can be ignored because the combination of C174 and R33 means that it takes several hundred µs for the voltage to subsequently rise above 0.81 v (Table 5-3 “Viht” (min)). If the value of C174 was reduced (or changed to “do not place”) in the future, then Trstia (min) would still be satisfied (280 µs > 100 µs).
Cheers,
Tim.
Hi Robert, would there be any chance of pulling this change forward into v5.10 and newer trees? It only seems to be on v4.19.x-ti-overlays right now.
I went to fork the repo at https://git.beagleboard.org to submit a PR, but it seems I don’t have permissions to create a repo there. 
What’s your username? First signed up individuals don’t have access to the CI till we enable it… (Bot protection)…
Joan Touzet. Hi!
Awesome, your enabled,
The device tree repo is here: BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab
Instead of an overlay, thinking we should just hit the base *.dtsi: src/arm/am335x-bone-common.dtsi · v5.10.x-ti-unified · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab
and enable it for all boards… (at some point that fix will roll into the Green, Industrial, etc…)
Regards,
PR is up, thanks for the support.
Pushed and building: build (#12518) · Jobs · Robert Nelson / ti-linux-kernel-dev · GitLab
Hello, would you like to also send this to upstream?
Looking at the test farm: http://gfnd.rcn-ee.org:81/farm/uptime/192.168.2.23-bbb-5.10.168-ti-r65.log trying to understand the error… “couldn’t get reset GPIO”… wonder if the pinmux didn’t set?
[ 9.716253] mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO
[ 9.724988] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[ 9.731584] cpsw 4a100000.ethernet: ALE Table size 1024
[ 9.737039] cpsw 4a100000.ethernet: cpts: overflow check period 1250 (jiffies)
[ 9.744462] cpsw 4a100000.ethernet: Detected MACID = c8:a0:30:c4:35:e4
Need to push it to a later kernel (6.1.x-ti) and retest…
line 8: "NC" "reset" output active-low [used]
Regards,
This problem would be solved by modifing dts file
&davinci_mdio {
status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
ethphy0: ethernet-phy@0 {
reg = <0>;
// Support GPIO Reset on Rev C3 boards
reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
reset-delay-us = <280>;
};
};