[RESEND] Ethernet phy ID u-boot fix

GoogleGroups
1

Hi there,

My BeagleBone Green has had major problems with the Ethernet phy since I
got it many years ago. There is a patch for Linux here:

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v5.3/patches/drivers/ti/cpsw/0001-cpsw-search-for-phy.patch

I asked in #beagle on FreeNode IRC about this some months ago, after
finally getting around to building my device. Here is an abridged log,
which will save me rewriting it:

<+rcn-ee[m]> rah: that's fixed in u-boot... it'll be going away..
<+rcn-ee[m]> rah: here is the u-boot fix: (which is better then the
kernel fix)
https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L629-L700
<+rcn-ee[m]> rah: thus the only reason i still carry the patch, is for
user still running old u-boot..
<+rcn-ee[m]> Here's the commit:
https://github.com/u-boot/u-boot/commit/20c37fb1bfb9f20804645b2199699cd815a4d55c
< rah> U-Boot 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 -0500),
Build: jenkins-github_Bootloader-Builder-128
< rah> github seems to think that patch went into 2019.10
< rah> is there a beaglebone image with a later u-boot image that I can
flash?
<+rcn-ee[m]> rah: special build for you: sudo
/opt/scripts/tools/developers/update_bootloader.sh --beta
<+rcn-ee[m]> rah: , there should be a new print: printf("fixing up
phy_id for %s, old: %d, new: %d\n",
< rah> rcn-ee[m]: it looks like I was wrong about the release version
though, it looks like this patch went in from v2018.11-rc1 onwards
< rah> rcn-ee[m]: I'm not seeing this printf:
https://paste.debian.net/1111765/
<+rcn-ee[m]> rah: ugh CONFIG_OF_BOARD_SETUP, that's the fdt path, we are
still using the classic board path..
<+rcn-ee[m]> i'll need to do some testing, the last time i tried
switching over the fdt path, it was a shit show...
<+rcn-ee[m]> atleast now, we spec a larger hole at the start of the
partition.
< rah> ok, that's all going over my head but I get that you can't sort
it out now :slight_smile:
< rah> thanks anyway

I've been waiting patiently for months to hear more but nothing has
materialised. I've been waiting in #beagle to pounce on rcn-ee but he
has not appeared.

I just downloaded the latest Debian image, wrote it to the eMMC, booted
it, ran

$ sudo /opt/scripts/tools/developers/update_bootloader.sh --beta

and this is the resulting version:

U-Boot 2019.04-00002-g31a8ae0206 (May 13 2020 - 09:26:17 -0500), Build:
jenkins-github_Bootloader-Builder-139

Which apparently still does not contain the fix:

[ 23.440684] cpsw 4a100000.ethernet: phy
"/ocp/interconnect@4a000000/segment@0/target-module@100000/ethernet@0/mdio@1000/ethernet-phy@0"
not found on slave 0

Can anyone tell me whether the fix is going to appear in u-boot?

Thanks,

Bob Ham

2

The fix has been in u-boot for a few years.

It relies on the device-tree path, we are still shipping the old
"board" file path in u-boot.

I've been very busy with my day job, so I haven't had any free time to
re-test every board combination in u-boot to convert to a newer
version.

Regards,

3

Robert, thanks for your response.

Could you possibly explain a little more about what you mean here? What
are the device-tree path and the board file path? What can I change in
order to get this to work?

Thanks,

Bob

4

Step 1, configure your image for extlinux.conf booting..

cd /opt/scripts/tools/
git pull
sudo ./generate_extlinux.sh

Step 2, build u-boot master

Use this version of gcc:
https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-ARMCrossCompiler:GCC

git clone https://github.com/u-boot/u-boot --depth=1
cd u-boot/

make ARCH=arm CROSS_COMPILE=${CC} distclean
make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_defconfig
make ARCH=arm CROSS_COMPILE=${CC}

Then write these files to your microSD card:

sudo dd if=./MLO of=/dev/sdb count=1 seek=1 bs=128k
sudo dd if=./u-boot.img of=/dev/sdb count=2 seek=1 bs=384k

Regards,

5

Thanks for your instructions, they're useful for one instance. However,
what I meant was: what can I change in order to get this to work for
everyone? :slight_smile: What needs to be patched? I have no idea what the
"device-tree path" is you mentioned before so I've no idea where it
resides and hence what I can fix and send a patch for.

Thanks,

Bob

6

https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L938-L957

We need device-tree's for: BeagleBone Blue, BeagleBone Green Wireless,
BeagleBone Green Gateway, BeagleBone Black Wireless, SanCloud, Generic
eMMC target.

Regards,

7

What can I change in order to get this to work?

Step 1, configure your image for extlinux.conf booting..

Thanks for your instructions, they're useful for one instance. However,
what I meant was: what can I change in order to get this to work for
everyone? :slight_smile: What needs to be patched? I have no idea what the
"device-tree path" is you mentioned before so I've no idea where it
resides and hence what I can fix and send a patch for.

u-boot/board/ti/am335x/board.c at master · u-boot/u-boot · GitHub

Thanks for your answer. However, I'm a bit confused by this. As I
mentioned, I'm using a BeagleBone Green which seems to be accounted for
in this function.

You previously said:

The fix has been in u-boot for a few years.

It relies on the device-tree path, we are still shipping the old
"board" file path in u-boot.

which implies this 'old "board" file path' is what needs to be updated
for the fix to work but I still don't understand what the '"board" file
path' is. Could you possibly say what you meant by that?

Thanks again,

Bob

8

*ping*?

To be clear, the critical information I need is: what were you referring
to as 'old "board" file path'?

9

*ping*?

To be clear, the critical information I need is: what were you referring
to as 'old "board" file path'?

  Just jumping in... I would interpret

The fix has been in u-boot for a few years.

It relies on the device-tree path, we are still shipping the old
"board" file path in u-boot.

which implies this 'old "board" file path' is what needs to be updated
for the fix to work but I still don't understand what the '"board" file
path' is. Could you possibly say what you meant by that?

to mean that the u-boot being shipped contains a (hard-coded) path
specifying the older device tree file. In either event, you likely have to
examine anything in u-boot that loads device trees to see which device tree
file it is loading.

10

I would interpret

Thanks but I don't think there's any need for us to try and interpret
someone's words when the person is right here and can speak for themselves.

The fix has been in u-boot for a few years.

It relies on the device-tree path, we are still shipping the old
"board" file path in u-boot.

which implies this 'old "board" file path' is what needs to be updated
for the fix to work but I still don't understand what the '"board" file
path' is. Could you possibly say what you meant by that?

to mean that the u-boot being shipped contains a (hard-coded) path
specifying the older device tree file.

We're not talking about the u-boot being shipped with boards. The
problem is with mainline u-boot.

11

*ping* ?