GENET and UNIMAC MDIO probe issue?

GENET and UNIMAC MDIO probe issue?

[Maxime Ripard]

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

Hi Florian, Doug,

I'm currently trying to make the RaspberryPi CM4 IO board probe its
ethernet controller, and it looks like genet doesn't manage to find its
PHY and errors out with:

[    3.240435] libphy: Fixed MDIO Bus: probed
[    3.248849] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[    3.259118] libphy: bcmgenet MII bus: probed
[    3.278420] mdio_bus unimac-mdio--19: MDIO device at address 1 is missing.
[    3.285661] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus

....

[   13.082281] could not attach to PHY
[   13.089762] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
[   74.739621] could not attach to PHY
[   74.746492] bcmgenet fd580000.ethernet eth0: failed to connect to PHY

Here's the full boot log:
https://pastebin.com/8RhuezSn

It looks like it's related to the following bugzilla entry:
https://bugzilla.kernel.org/show_bug.cgi?id=213485

However, that commit has been merged for a while apparently, and even
next-20211022 shows that behavior, both with the drivers built-in or as
modules. The other suggested fix to set probe_type to
PROBE_FORCE_SYNCHRONOUS doesn't seem to fix it either.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: GENET and UNIMAC MDIO probe issue?

[Stefan Wahren]

Hi Maxime,

Am 22.10.21 um 16:33 schrieb Maxime Ripard:
> Hi Florian, Doug,
>
> I'm currently trying to make the RaspberryPi CM4 IO board probe its
> ethernet controller, and it looks like genet doesn't manage to find its
> PHY and errors out with:
>
> [    3.240435] libphy: Fixed MDIO Bus: probed
> [    3.248849] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
> [    3.259118] libphy: bcmgenet MII bus: probed
> [    3.278420] mdio_bus unimac-mdio--19: MDIO device at address 1 is missing.
> [    3.285661] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
>
> ....
>
> [   13.082281] could not attach to PHY
> [   13.089762] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
> [   74.739621] could not attach to PHY
> [   74.746492] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
>
> Here's the full boot log:
> https://pastebin.com/8RhuezSn

looks like you are using the vendor DTB, please use the upstream DTB
from linux-next:

bcm2711-rpi-cm4-io.dtb

>
> It looks like it's related to the following bugzilla entry:
> https://bugzilla.kernel.org/show_bug.cgi?id=213485
>
> However, that commit has been merged for a while apparently, and even
> next-20211022 shows that behavior, both with the drivers built-in or as
> modules. The other suggested fix to set probe_type to
> PROBE_FORCE_SYNCHRONOUS doesn't seem to fix it either.
>
> Maxime

Re: GENET and UNIMAC MDIO probe issue?

[Maxime Ripard]

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

Hi Stefan,

On Fri, Oct 22, 2021 at 05:35:50PM +0200, Stefan Wahren wrote:
> Hi Maxime,
> 
> Am 22.10.21 um 16:33 schrieb Maxime Ripard:
> > Hi Florian, Doug,
> >
> > I'm currently trying to make the RaspberryPi CM4 IO board probe its
> > ethernet controller, and it looks like genet doesn't manage to find its
> > PHY and errors out with:
> >
> > [    3.240435] libphy: Fixed MDIO Bus: probed
> > [    3.248849] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
> > [    3.259118] libphy: bcmgenet MII bus: probed
> > [    3.278420] mdio_bus unimac-mdio--19: MDIO device at address 1 is missing.
> > [    3.285661] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
> >
> > ....
> >
> > [   13.082281] could not attach to PHY
> > [   13.089762] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
> > [   74.739621] could not attach to PHY
> > [   74.746492] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
> >
> > Here's the full boot log:
> > https://pastebin.com/8RhuezSn
> 
> looks like you are using the vendor DTB, please use the upstream DTB
> from linux-next:
> 
> bcm2711-rpi-cm4-io.dtb

I thought upstream_kernel would be enough, but following your message
I forced it using device_tree, and indeed it works.

But I'm confused now, I don't have any other DTB for the CM4 on that
boot partition, where is that other device tree coming from?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: GENET and UNIMAC MDIO probe issue?

[Florian Fainelli]

On 10/22/21 8:35 AM, Stefan Wahren wrote:
> Hi Maxime,
> 
> Am 22.10.21 um 16:33 schrieb Maxime Ripard:
>> Hi Florian, Doug,
>>
>> I'm currently trying to make the RaspberryPi CM4 IO board probe its
>> ethernet controller, and it looks like genet doesn't manage to find its
>> PHY and errors out with:
>>
>> [    3.240435] libphy: Fixed MDIO Bus: probed
>> [    3.248849] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
>> [    3.259118] libphy: bcmgenet MII bus: probed
>> [    3.278420] mdio_bus unimac-mdio--19: MDIO device at address 1 is missing.
>> [    3.285661] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
>>
>> ....
>>
>> [   13.082281] could not attach to PHY
>> [   13.089762] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
>> [   74.739621] could not attach to PHY
>> [   74.746492] bcmgenet fd580000.ethernet eth0: failed to connect to PHY
>>
>> Here's the full boot log:
>> https://pastebin.com/8RhuezSn
> 
> looks like you are using the vendor DTB, please use the upstream DTB
> from linux-next:
> 
> bcm2711-rpi-cm4-io.dtb

Stefan beat me to it, but yes, it looked like you had an Ethernet PHY at
MDIO address 25, when arch/arm/boot/dts/bcm2711-rpi-cm4.dtsi indicates
that it should be at address 0, therefore it won't work.

The issue with mdio-bcm-unimac not being loaded would only be applicable
in a modular case anyway, when it is built-in, there would be no such
problem. Let me know if there are other changes that are necessary, DTS
or else.
-- 
Florian

Re: GENET and UNIMAC MDIO probe issue?

[Cyril Brulebois]

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

Hi,

Maxime Ripard <maxime@cerno.tech> (2021-10-22):
> > looks like you are using the vendor DTB, please use the upstream DTB
> > from linux-next:
> > 
> > bcm2711-rpi-cm4-io.dtb
> 
> I thought upstream_kernel would be enough, but following your message
> I forced it using device_tree, and indeed it works.
> 
> But I'm confused now, I don't have any other DTB for the CM4 on that
> boot partition, where is that other device tree coming from?

It seems to be using the DTB for the Pi 4 B instead, at least judging
by:

    # tr '\0' '\n' < /proc/device-tree/compatible
    raspberrypi,4-model-b
    brcm,bcm2711

For the avoidance of doubt, the relevant /boot/firmware has those files,
copied from the linux-image package without any name changes:

    /boot/firmware/bcm2711-rpi-4-b.dtb
    /boot/firmware/bcm2711-rpi-400.dtb
    /boot/firmware/bcm2711-rpi-cm4-io.dtb
    /boot/firmware/bcm2837-rpi-3-a-plus.dtb
    /boot/firmware/bcm2837-rpi-3-b-plus.dtb
    /boot/firmware/bcm2837-rpi-3-b.dtb
    /boot/firmware/bcm2837-rpi-cm3-io3.dtb

so maybe some fallback to the Pi 4 B happened via the more generic
brcm,bcm2711 compatible fragment?


Initially I was wondering whether there might be some things on the
EEPROM side that might need an update, but wading through some issues
in the raspberrypi/rpi-eeprom repository[1], it seems start.elf is
responsible for passing the dtb file and a quick look into it suggests
there might be a single format string for that: bcm%d-rpi-%s.dtb

 1. https://github.com/raspberrypi/rpi-eeprom

I'm also seeing filename fragments, but nothing that ressembles the io
suffix that's being used for the CM4 upstream DTB.


Since it seems that the bootloader might be expecting “vendor DTB” and
the kernel might use different names when it comes to “upstream DTB”,
are users/distributions expected to set the proper filename via
device_tree= all the time? If that's the case, I hadn't noticed until
now since we used to have things like this in Debian to put files into
place under the “expected filenames”:

    cp <packaged>/bcm2837-rpi-cm3-io3.dtb /boot/firmware/bcm2710-rpi-cm3.dtb

Nowadays, our raspi-firmware package is just copying the DTB files (as
shipped by linux-image packages, meaning “upstream DTB” names without
any renaming), so we might have failed to notice a possible need for
this device_tree parameter…


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]