We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
Robert, Rev C3 looks like a controlled reset on the PHY. So what was the issue with the PHY 1*) having a hardware issue of not connecting only fix, resetting with new gpio, and read address to see if it booted right, 2*) Resets too early before power stabilized, 3*) We don’t know, but now we can reset without doing a full power reboot?
Depending on the answer implies that s/w control will need different solutions, I have an older board design that needs to implement these changes, so it brings up a few questions.
Will the new Rev C3’s work with the old software, when the GPIO controlling the reset is not configured in old BBB(AOSP) design
What software changes need to be implemented to use this new h/w control
2a) Based on 1* above - A lot more code need to read the PHY address to see if it booted correctly
2b) Based on 2* above, simple hold the reset off a little longer on the PHY and no need to read address because it will just work
2c) Based on 3* A combination of both 2a and 2b
I’m looking for the detail of all the s/w changes that are needed, and will need to look into our old BBB(aosp) that you did a long time ago, and see how to add into that code. Sorry, I’m more of an embedded micrcontroller engineer, and inherited the BBB linux from another no longer contractor, and we are looking how to get 100% ethernet boot. Is there a provider of the industrial version Ver C3 boards that you know of? Thanks
There are two fixes on the RevC3 to fix (or help fix) the 8710A random startup conditions…
The first was to remove C24 from the design, this helped some of the boards that had shown issues:
The second was wire up a “new spare” gpio to physically reset the phy on startup.
The first doesn’t require any software update, and works on any image you are using today…
The second would need a u-boot change, but to test i need a RevC3 board that normally fails to verify it actually does something… So yeah, that u-boot change hasn’t been written or tested yet…
The PCB needed a new spin for our microSD cage that went EOL, so we added all the fixes we could with backup options if more fixes where still needed (gpio - phy - reset)…
Seeed’s version of the Industrial should use the RevC3 pcb, as once they ran out of microSD cages, they had no options to build older PCB’s…
Short answer, if you have a board with this problem, de-populate C24, there is a good chance the Ethernet PHY will be fixed…
For an existing image in the field, RevC3 should be a seamless upgrade…
Thank you for the quick response. I can’t seem to find a Seeed Industrial BBB, do you know the orderable Digikey or Seeed part number, or at least a link to an Industrial Temp version?
RCN,
I received my BBB C3 today from digikey. The eMMC came loaded with
cat /proc/version
Linux version 4.19.94-ti-r42 (voodoo@x3-am57xx-beagle-x15-2gb) (gcc version 8.3.0 (Debian 8.3.0-6)) #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020
cat /etc/debian_version
10.3
# snippet from
sudo cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 32-63, parent: platform/4804c000.gpio, gpio-32-63:
gpio-32 (GPMC_AD0 |P8_25 ) in lo
gpio-33 (GPMC_AD1 |P8_24 ) in lo
gpio-34 (GPMC_AD2 |P8_05 ) in lo
gpio-35 (GPMC_AD3 |P8_06 ) in lo
gpio-36 (GPMC_AD4 |P8_23 ) in lo
gpio-37 (GPMC_AD5 |P8_22 ) in lo
gpio-38 (GPMC_AD6 |P8_03 ) in lo
gpio-39 (GPMC_AD7 |P8_04 ) in lo
gpio-40 (UART0_CTSN )
gpio-41 (UART0_RTSN )
gpio-42 (UART0_RXD )
gpio-43 (UART0_TXD )
The BBB C3 uses gpio1_8 (gpio-40) to control the PHY reset signal. I am able to toggle gpio1_8 like this,
# connect RJ45 on BBB to an ethernet switch and observe the leds are lighted
cd /sys/class/gpio
echo 40 > export
echo high > gpio40/direction
# set gpio1_8 low
echo 0 > gpio40/value
# observe the RJ45 leds are not lighted
# set gpio1_8 high
echo 1 > gpio40/value
# observe the RJ45 leds are lighted
Now I want to edit the BBB device tree to add reset-gpios to &davinci_mdio and add pinmux for UART_CTSN so that I can test how/when the kernel controls gpio1_8.
Where do I find the source .dts/.dtsi files used to create the /boot/dtbs/4.19.94-ti-r42/am335x-boneblack-uboot-univ.dtb blob?
I changed from the 4.19.x kernel. I want to use kernel 5.19.3 because it is first kernel with built-in frame buffer driver for i2c ssd1307fb OLED display. I have downloaded/built/installed the 5.19.3 kernel. I found a am335x-boneblack.dtb that was created during the build. I could not find am335x-boneblack-uboot-univ.dtb or any of the .dtbo overlay files. I admit that I am confused. I downloaded/extracted the files, found here, into an empty folder.
I don’t know what to do with the extracted v5.19.x files.
Do I copy the files in the extracted …v5.19.x/src/arm folder into the kernel arch/arm/boot/dts folder and rebuild the kernel?
Thank you,
cpsw 4a100000.ethernet: phy “/ocp/interconnect@4a000000/segment@0/target-module@100000/ethernet@0/mdio@1000/ethernet-phy@0” not found on slave 0
on a couple of rev B boards with 5.4.70-ti-r19, U-Boot version 2019.04-00002. These boards are installed on offshore measuring stations, so having issues with network connectivity is quite disastrous.
I don’t have any experience compiling or setting up U-Boot/custom device trees/… so most of the above conversation goes above my head. However, I am willing to learn if necessary to get my systems back up to a state where they can be relied upon.
It is not completely clear to me which board revisions suffer from this issue and when the newer U-Boot or the cap removal should help. From what I read above (if I understand correctly), this issue shouldn’t even exist with this kernel.
I looked at the schematics and the board and found the C24 cap on the reset line. Would removing this cap help my REV B boards as well?
Pretty much every boards prior to the RevC3 may show the issue. It’s rare, but still when you have a board it’s an issue… In my CI testing farm for BeagleBoard.org i have a couple dozen boards running 24/7… If a specific board shows the issue, it always has the issue… I haven’t seen any that were good for years all of suddenly stop…
I’d say the biggest issue, our ‘hack’ for the driver only works on 3.14.x → 5.x-ish… TI rewrote the cpsw driver to better support newer devices, and removed the trick our hacked worked with.
So far on testing RevC3 i haven’t found a board that shows the issue… So it seems removing C24 has fixed the main issue. (reminds me, i need to order a few more, to keep up with my random samples per year…)
Side note, i did have one board i tried removing C24, a few months ago as that board wasn’t coming up… However in a brain fart move, i had just rewired my CI enclosure, and i didn’t notice i was one port short… Yeah the Ethernet wasn’t even wired to that board… Anywho, the board still works great, just never needed to remove C24 on it…
The thing is that, for stations that are not serviced by myself but scientists, I cannot ask them to remove a 0402 (0201?) cap from a pcb. I can make a new image and explain them how to put it on the BBB, so if U-Boot is an option, then that’s the way to go.
With the help from the linked DigiKey page one the BBB, I should be able to get a new version of U-Boot ready and on the boards (at least, if that would help).
There is no U-Boot fix for this. There is a git commit in mainline u-boot that reads the mdio address and patches the device-tree… This is exactly what the hack use to do…
If your board is one of these boards that has the mdio issue, and is running v4.19.x or 5.4.x, don’t upgrade to 5.10.x (in which the hack no longer applies nor does it work…)
I do have the issue with these REV B boards running 5.4.70, but according to your last message (unless I -likely- misunderstand), I shouldn’t be seeing this issue?
