Nice @Stat_headcrabed ! i’ll move those and push out…
Regards,
1 Like
Wait, seems we can’t use reset-delay-us here? Maybe reset-assert-us? Not sure…
Oh Fun: yeah the davinci_mdio settings i think we should use…
examples:
- |
davinci_mdio: mdio@5c030000 {
reg = <0x5c030000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio2 5 1>;
reset-delay-us = <2>;
ethphy0: ethernet-phy@1 {
reg = <1>;
};
ethphy1: ethernet-phy@3 {
reg = <3>;
};
};
vs
ethernet {
#address-cells = <1>;
#size-cells = <0>;
ethernet-phy@0 {
compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c45";
interrupt-parent = <&PIC>;
interrupts = <35 1>;
reg = <0>;
resets = <&rst 8>;
reset-names = "phy";
reset-gpios = <&gpio1 4 1>;
reset-assert-us = <1000>;
reset-deassert-us = <2000>;
Regards,
1 Like
Compatible item is not needed since the phy would report it’s id correctly.
Btw could you also apply this vcc-supply to dts? It would reduce spamming about eeprom regulator in dmesg.
baseboard_eeprom: baseboard_eeprom@50 {
compatible = "atmel,24c256";
reg = <0x50>;
vcc-supply = <&ldo4_reg>;
#address-cells = <1>;
#size-cells = <1>;
baseboard_data: baseboard_data@0 {
reg = <0 0x100>;
};
};
After some testing, seems reset-deassert-us needs a REALLY large value to make it work correctly. 5000 is not enough but 10000 seems ok on my board; better to test on more devices to see if 10000 is ok.
Edit: 5500 is not enough but 6000 is ok. I think maybe 6500 is enough for all devices? I’m working on a patch to upstream mainline kernel now.
1 Like
Hello @RobertCNelson
Is this patch part of the current bbb images? Or is something i need to implement over standard images?
Couple variations have been pushed to both our 5.10.x branch and mainline: am335x-bone-common.dtsi: more reset-assert-us/reset-deassert-us fixup for C3,... (fe6a775f) · Commits · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab
and; kernel/git/torvalds/linux.git - Linux kernel source tree
Regards,
Thank you @RobertCNelson
Do you consider this is a critical patch and that last commit fixed it?
I have some C3 boards running in a installation that don’t have this last change fe6a775f (reset time/delay and vcc-supply) and wanted to know if i should apply it to get more reliable Ethernet.
Maybe i’m going to say something dumb but as a extra check at my side, if the board boots without eth0 device and i reboot the os… it might have a chance to boot correctly? or is need to recycle power supply, in my use my boards are not accessible so trying to think in a extra way to check for eth0 as cycle power is not an option.
I’m curious, all the beaglebone boards variant are affected by this ethernet behaviour?
with v5.10.x-ti: if this doesn’t happen:
[ 11.023883] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 31.444781] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
Then your phy wasn’t detected…
Then reboot…
Regards,
Thank you so much @RobertCNelson
Just to be sure i understand.
Software reboot can work (using v5.10.x-ti kernel) because v5.10.x-ti implemented the “basic” reset fix. So if you boot and get no phy, a reboot must fix it as it will try again to reset. Correct?
And what those last changes solved is that “occasionally” the phy reset failed and setting those “delays” ensure the cap can be low enough to ensure the reset, correct?
Regards,
Jose
I also found this necessary in HW testing here, as 6500 was insufficient for a number of boards in our production line.
I’ve submitted a PR to bump the deassert time to 10000.
Having real data is awesome, can you also submit to tony: am335x-bone-common.dtsi « omap « ti « dts « boot « arm « arch - kernel/git/torvalds/linux.git - Linux kernel source tree
Regards,