Beaglebone Black Ethernet Failures

Beaglebone Black Ethernet Failures

[Dave Tucker]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

I have been using a Beaglebone Black for a project for years.  I recently upgraded from Dunfell to Gatesgarth and again began experiencing a problem with the ethernet interface failing to come online 10% of the time, a problem which can only be fixed by a power cycle (not a reboot).  This is a well known problem documented by this thread ( https://groups.google.com/g/beagleboard/c/9mctrG26Mc8 ) going back over 7 years.  It's a hardware problem, but it does have a software fix.  But that fix must have been left out of recent meta-bbb builds.  I believe previous fixes have been something like this patch ( https://github.com/RobertCNelson/bb-kernel/blob/607ae2e36477357a4bb222f285fd7460d5230ab9/patches/net/0009-cpsw-search-for-phy.patch ).  That old patch targets the 3.15 kernel and I believe Gatesgarth is using 5.10.  Should I expect that patch to work unmodified on 5.10?  I don't know low level kernel mechanics well enough to understand what it's really doing.  If that patch won't work, does anyone know how I could proceed to get ethernet working on the Beaglebone Black with current versions of Yocto?

Dave

[-- Attachment #2: Type: text/html, Size: 1320 bytes --]

Re: [meta-ti] Beaglebone Black Ethernet Failures

[Nishanth Menon]

On 05:27-20210310, Dave Tucker wrote:
> I have been using a Beaglebone Black for a project for years.  I recently upgraded from Dunfell to Gatesgarth and again began experiencing a problem with the ethernet interface failing to come online 10% of the time, a problem which can only be fixed by a power cycle (not a reboot).  This is a well known problem documented by this thread ( https://groups.google.com/g/beagleboard/c/9mctrG26Mc8 ) going back over 7 years.  It's a hardware problem, but it does have a software fix.  But that fix must have been left out of recent meta-bbb builds.  I believe previous fixes have been something like this patch ( https://github.com/RobertCNelson/bb-kernel/blob/607ae2e36477357a4bb222f285fd7460d5230ab9/patches/net/0009-cpsw-search-for-phy.patch ).  That old patch targets the 3.15 kernel and I believe Gatesgarth is using 5.10.  Should I expect that patch to work unmodified on 5.10?  I don't know low level kernel mechanics well enough to understand what it's really doing.  If that patch won't work, does anyone know how I could proceed to get ethernet working on the Beaglebone Black with current versions of Yocto?
> 
> Dave


Probably addressed in u-boot instead by [1] ?

[1] https://source.denx.de/u-boot/u-boot/-/commit/20c37fb1bfb9f20804645b2199699cd815a4d55c


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: Beaglebone Black Ethernet Failures

[Dave Tucker]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

I applied this patch and it failed to compile after that, I assume because I'm running a later version of u-boot.  But more importantly, it looks like this fix is already included in the u-boot source code.  I see all the code in board.c about fixing the ethernet phy on the beaglebone family.  But I'm still having this ethernet issue so it's failing to fix the problem.

[-- Attachment #2: Type: text/html, Size: 388 bytes --]

Re: Beaglebone Black Ethernet Failures

[Dave Tucker]

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

Actually, looking back at it, this was a commit, not a patch.  So yes, it is in the u-boot code already.  But it's failing to perform somehow.

[-- Attachment #2: Type: text/html, Size: 154 bytes --]

Re: [meta-ti] Beaglebone Black Ethernet Failures

[Nishanth Menon]

On 14:19-20210311, Dave Tucker wrote:
> Actually, looking back at it, this was a commit, not a patch.  So yes, it is in the u-boot code already.  But it's failing to perform somehow.

Interesting. I'd suggest reaching out to linux-omap@vger.kernel.org and
cc beagle list to see what the recommendation is. The rationale of doing
in u-boot is that kernel folks dont like modifying device tree blobs
after kernel has started booting up..

If a patch is known, then usually stable-kernel rules should kick in and
should help percolate the patch back to 5.10 and other stable kernels.

I was glancing through kernelci.org upstream test logs[1] and i had'nt
noticed anything specific on this failure, so it will be interesting to
get a wider viewpoint.. Do be sure to paste the full bootlog (all the
way from u-boot's first print) in pastebin.ubuntu.com or a similar site
when sending the report to the kernel mailing list.

https://kernelci.org/soc/omap2/job/stable/kernel/v5.10.23/plan/baseline-nfs/

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Re: [meta-ti] Beaglebone Black Ethernet Failures

[Robert Nelson]

On Thu, Mar 11, 2021 at 4:19 PM Dave Tucker <theaethereal@gmail.com> wrote:
>
> Actually, looking back at it, this was a commit, not a patch.  So yes, it is in the u-boot code already.  But it's failing to perform somehow.

For the am335x target, u-boot supports two path's, legacy "board" path
and newer "device tree" path.. That fixup only applies if your build
of u-boot uses the new "device tree" path..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: Beaglebone Black Ethernet Failures

[Dave Tucker]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Robert,

Thank you so much for the reply.  Do you know of a reference that explains this distinction between board and devicetree paths?  My google-fu is failing me.

I am loading a dtb file, but I don't know if that means I'm on the "devicetree path".  I've configured u-boot to load from a uEnv.txt which looks like this, and that loads the dtb from the first partition, and I know that part works:

bootfile=zImage
fdtfile=am335x-boneblack.dtb
loadaddr=0x80007fc0
fdtaddr=0x80F80000
console=ttyO0,115200
mmcroot=/dev/mmcblk1p2
mmcrootfstype=ext4
loadfdt=fatload mmc 1:1 ${fdtaddr} ${fdtfile}
loaduimage=fatload mmc 1:1 ${loadaddr} ${bootfile}
mmc_args=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}
fdtboot=run mmc_args; bootz ${loadaddr} - ${fdtaddr}
uenvcmd=mmc rescan; run loaduimage; run loadfdt; run fdtboot

Thank you so much,

Dave

[-- Attachment #2: Type: text/html, Size: 1004 bytes --]