Hi @dieterv what does:
dmesg | grep phy
Show on 5.4.x?
Regards,
So, I can fix this by compiling and using a U-Boot version that incorporates the patch that sort-of replaces the hack?
Output from dmesg |grep phy
[ 0.000000] Booting Linux on physical CPU 0x0
[ 2.076724] libphy: Fixed MDIO Bus: probed
[ 2.131964] libphy: 4a101000.mdio: probed
[ 2.150557] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 2.167139] am335x-phy-driver 47401300.usb-phy: 47401300.usb-phy supply vcc not found, using dummy regulator
[ 2.175536] am335x-phy-driver 47401b00.usb-phy: 47401b00.usb-phy supply vcc not found, using dummy regulator
[ 65.800241] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
Hum… that looks fine… we can also look at cpsw (in 5.4.x)
[ 2.985679] libphy: Fixed MDIO Bus: probed
[ 3.034311] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[ 3.042068] libphy: 4a101000.mdio: probed
[ 3.065034] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 3.074649] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[ 3.081273] cpsw 4a100000.ethernet: ALE Table size 1024
[ 3.086730] cpsw 4a100000.ethernet: cpts: overflow check period 1250 (jiffies)
[ 3.094176] cpsw 4a100000.ethernet: Detected MACID = c8:a0:30:c4:35:e4
i would have expected to see the ‘not found on slave 0’ with dmesg | phy, but it didn’t show…
Regards,
dmesg |grep cpsw output:
[ 2.150761] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[ 2.150773] cpsw 4a100000.ethernet: ALE Table size 1024
[ 2.150938] cpsw 4a100000.ethernet: cpts: overflow check period 1250 (jiffies)
[ 2.151019] cpsw 4a100000.ethernet: Detected MACID = fc:69:47:45:96:5e
[ 65.724447] cpsw 4a100000.ethernet: initializing cpsw version 1.12 (0)
The message “not found on slave 0” where there is no network connectivity anymore comes up from time to time (I don’t know yet what triggers it) and -so far- it seems that if it happens I can only get the network working again by doing a power cycle. Just rebooting the boards seems not to help.
So right now the board has been power cycled (I do have the full dmesg output from when it wasn’t working, if that helps) and the network is up.
Maybe this is another issue than the one in this topic?
That smells like PHY reset… I’ll need to correct my prior comment, don’t upgrade to 5.4.x-ti or mainline 5.10.x/5.10.x-ti your 5.4.x-ti is running the updated ti cpsw driver that TI eventually submitted mainline…
The randomness is part of the problem with this bug… The MDIO bus is hard-wired on the board, the PHY’s configuration is hard-coded with pull-up/down’s, yet some boards will have an SMSC phy come up in a broken state.
The kernel hack, basically asks the phy, what address are you at, i’ll just use that. (instead of how it was physically wired and setup…)
The RevC3 has two fixes, removing C24, which seemed to help some users on older board designs, and wiring a gpio directly to the reset on the SMSC phy… So far i haven’t found a RevC3 that shows the old issue, so i haven’t personally been able to verify the gpio-reset would fix it…
If you have a board that is showing random mdio address, first remove C24 and re-test…
Regards,
Robert,
Thanks.
That actually explains what happens (in a way that I understand). Interesting… I can’t imagine how one would start troubleshooting this after customer complaints…
These current boards are REV B (they procured about 20 of them at one point), I’ll try to get the users to not use these boards anymore but replace them with REV C. The cost of additional service trips to the measurement platforms greatly exceeds the cost of a BBB…
RCN,
Upgrading my host computer to Ubuntu 20.04 fixed the build problem. I also found that I could build the BB-DT on my BBB revC3 because it has DTC 1.4.7 installed.
Thank you. Now on to the next step.
The BBB revC3 came with kernel 4.19.94-ti-r42 so I choose the BB-DT v4.19.94.x-ti-overlays to build. I built the files and copied am335x-boneblack-uboot-univ.dtb to the BBBrC3. Connected an o-scope to U1 pin-1 (ETH_RST_GPIO1_8). Powered on the BBB and noticed pin-1 stayed high (3.3v) during boot.
Changes to am335x-bone-common.dtsi
&am33xx_pinmux {
davinci_mdio_default: davinci_mdio_default {
pinctrl-single,pins = <
/* MDIO */
AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
// added to support gpio controlled PHY reset
AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT_PULLUP, MUX_MODE7)
>;
};
davinci_mdio_sleep: davinci_mdio_sleep {
pinctrl-single,pins = <
/* MDIO reset value */
AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
// added to support gpio controlled PHY reset
AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE7)
>;
};
};
&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
// added to support gpio controlled PHY reset
reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;
};
Again, I built the files and copied am335x-boneblack-uboot-univ.dtb to the BBBrC3. Pressed reset button on the BBB. I noticed during kernel loading that pin-1 toggled low for approx 4us.
There is not an entry in dmesg showing that gpio1_8 reset-gpios was toggled. It would be nice for the kernel to report a message.
I have more questions but I am not sure if I should create a new ‘BBB revC3 reset-gpio phy hardware fix’ topic or continue to hijack this topic. I don’t know if there is another forum where this topic is already being discussed.
Should I create another topic, continue to post in this topic or move to another forum?
Thank you,
I have been successful in editing the am335x-bone-common.dtsi file to cause the kernel to trigger the reset. Now I am trying to create a ‘BB-phy-gpio-reset’ device-tree overlay. Here is my overlay.dts file.
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>
/*
* Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
*/
&{/chosen} {
overlays {
BB-phy-gpio-reset.kernel = __TIMESTAMP__;
};
};
&am33xx_pinmux {
davinci_mdio_default: davinci_mdio_default {
pinctrl-single,pins = <
// added to support gpio controlled PHY reset
AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT_PULLUP, MUX_MODE7)
>;
};
davinci_mdio_sleep: davinci_mdio_sleep {
pinctrl-single,pins = <
// added to support gpio controlled PHY reset
AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE7)
>;
};
};
&davinci_mdio {
// added to support gpio controlled PHY reset
reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;
};
I created the file in the BB-DT overlays folder and the file builds a BB-phy-gpio-rest.dtbo. The .dtbo file is copied to BBB revC3 /lib/firmware folder. I pause u-boot and type
Press SPACE to abort autoboot in 0 seconds
=>
=>
=> setenv uboot_overlay_addr4 /lib/firmware/BB-phy-gpio-reset.dtbo
=> boot
board_name=[A335BNLT] ...
board_rev=[00C0] ...
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
gpio: pin 55 (gpio 55) value is 1
2062 bytes read in 13 ms (154.3 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
gpio: pin 56 (gpio 56) value is 1
Running uname_boot ...
loading /boot/vmlinuz-4.19.94-ti-r42 ...
10095592 bytes read in 653 ms (14.7 MiB/s)
debug: [enable_uboot_overlays=1] ...
debug: [enable_uboot_cape_universal=1] ...
debug: [uboot_base_dtb_univ=am335x-boneblack-uboot-univ.dtb] ...
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot-univ.dtb] ...
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot-univ.dtb ...
loading /boot/dtbs/4.19.94-ti-r42/am335x-boneblack-uboot-univ.dtb ...
167492 bytes read in 42 ms (3.8 MiB/s)
uboot_overlays: [fdt_buffer=0x60000] ...
uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
867 bytes read in 31 ms (26.4 KiB/s)
uboot_overlays: loading /lib/firmware/BB-phy-gpio-reset.dtbo ...
960 bytes read in 106 ms (8.8 KiB/s)
uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
1584 bytes read in 110 ms (13.7 KiB/s)
uboot_overlays: loading /lib/firmware/BB-HDMI-TDA998x-00A0.dtbo ...
4915 bytes read in 47 ms (101.6 KiB/s)
uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo ...
3801 bytes read in 249 ms (14.6 KiB/s)
loading /boot/initrd.img-4.19.94-ti-r42 ...
7418142 bytes read in 482 ms (14.7 MiB/s)
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1
M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet] ...
debug: [bootz 0x82000000 0x88080000:71311e 88000000] ...
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8f8ec000, end 8ffff11e ... OK
Loading Device Tree to 8f85f000, end 8f8ebfff ... OK
Starting kernel ...
[ 0.002308] timer_probe: no matching timers found
[ 0.195524] l4_wkup_cm:clk:0010:0: failed to disable
[ 1.275954] davinci_mdio 4a101000.mdio: prop pinctrl-0 index 0 invalid phandle
[ 1.423908] omap_voltage_late_init: Voltage driver support not added
rootfs: clean, 86673/231536 files, 527319/924672 blocks
[ 24.729586] libphy: PHY 4a101000.mdio:00 not found
[ 24.771726] net eth0: phy "4a101000.mdio:00" not found on slave 0, err -19
U-boot appears to load the overlay but the kernel complains about invalid phandle. Also the o-scope shows that gpio1_8 is held high and not toggling.
Is there something wrong with the syntax of my overlay file?
Thank you
i’ve never had much luck with an overlay ‘appending’ inside a node, just copy the default pins and add yours…
&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;
status = "okay";
};
RCN,
Copying the node worked! Here is my working overlay file. Maybe you can add it to your BB-DT repo for safe keeping.
Thank you,
dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>
/*
* Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
*/
&{/chosen} {
overlays {
BB-PHY-GPIO-RESET.kernel = __TIMESTAMP__;
};
};
&am33xx_pinmux {
davinci_mdio_default: davinci_mdio_default {
pinctrl-single,pins = <
/* MDIO */
AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLUP | SLEWCTRL_FAST, MUX_MODE0)
AM33XX_PADCONF(AM335X_PIN_MDC, PIN_OUTPUT_PULLUP, MUX_MODE0)
// added to support gpio controlled PHY reset
AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_OUTPUT_PULLUP, MUX_MODE7)
>;
};
davinci_mdio_sleep: davinci_mdio_sleep {
pinctrl-single,pins = <
/* MDIO reset value */
AM33XX_PADCONF(AM335X_PIN_MDIO, PIN_INPUT_PULLDOWN, MUX_MODE7)
AM33XX_PADCONF(AM335X_PIN_MDC, PIN_INPUT_PULLDOWN, MUX_MODE7)
// added to support gpio controlled PHY reset
AM33XX_PADCONF(AM335X_PIN_UART0_CTSN, PIN_INPUT_PULLDOWN, MUX_MODE7)
>;
};
};
&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
// added to support gpio controlled PHY reset
reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
reset-delay-us = <2>;
};
Out of curiosity…
Is there a know reason why some boards would show this behaviour and some don’t? Or are all boards susceptible and do users just reboot every once in a while when there board comes up without Ethernet, not realizing they are seeing a known issue?
thanks @jakthree and pushed… GPIO PHY reset on RevC3 boards:... (74d3055c) · Commits · BeagleBoard.org / BeagleBoard-DeviceTrees · GitLab it’s safe to enable by default.
Regards,
I believe it’s a tolerance issue, with how much capacitance was on the reset line, which is why removing C24 seems to fix it for some users. Where previously it was borderline for the external PHY, but after removing C24, it’s now far low enough to work…
Regards,
HI @dieterv found another ‘buggy’ BeagleBone Green in my hardware collection… Removed C24, and it’s now working again on bootup, correctly…
Regards,
That is reassuring… I’m wondering if I should look into this software based solution.
Creating my own device tree is something that will take a while to get there…
What is the correct way to update the bootloader?
I found
- Your digikey page
- eLinux using the bb-u-boot-am335x-evm package (Nice and easy way, but likely too easy)
- On the same page, it mentions another way (seemingly loosely based on another page I found made by you) crosscompiling it on another system.
If I follow the first option (your page), do I still need to use the v2022.04 branch and pull the https://git.beagleboard.org/beagleboard/u-boot.git v2022.04-bbb.io-am335x-am57xx patch?
I know these might be very obvious questions, but this is my first time doing these kind of things and there’s an incredible amount of outdated information available.
I already tried following your guide which worked up until the end, but I couldn’t get the sd card image copied to the onboard eMMC.
Hi @dieterv ,
So bb-u-boot-am335x-evm is a production pre-packaged version of the top of branch (v2022.04-bbb.io-am335x-am57xx) of: BeagleBoard.org / u-boot · GitLab
The directions are really set for 2 audiences, those that like to learn how each piece comes together (this forum) and those that just want it to work (bb-uboot-am335x-evm)…
During development/testing we use the git repo, for production updates the native pacakge.
Regards,
Trying to understand what happens here.
If I look at the schematics, it seems like the ball on E18 (UART0_CTSN/UART4_RXD/DCAN1_TX/I2C1_SDA/SPI1_D0/TIMER7/PR1_EDC_SYNC0_OUT/GPIO1_8) is not connected to anything:
What does your overlay do then? Something internally?
Gpio1_8 was never used in designs prior to rev c3, which made this pin perfect for the fix…