Re: [PATCH v3 3/4] hw/arm: sabrelite: Connect the Ethernet PHY at address 6

[Bin Meng]

On Sun, May 2, 2021 at 4:12 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 4/30/21 9:28 PM, Bin Meng wrote:
> > On Fri, Apr 30, 2021 at 10:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Jan 06, 2021 at 02:35:03PM +0800, Bin Meng wrote:
> >>> From: Bin Meng <bin.meng@windriver.com>
> >>>
> >>> At present, when booting U-Boot on QEMU sabrelite, we see:
> >>>
> >>>   Net:   Board Net Initialization Failed
> >>>   No ethernet found.
> >>>
> >>> U-Boot scans PHY at address 4/5/6/7 (see board_eth_init() in the
> >>> U-Boot source: board/boundary/nitrogen6x/nitrogen6x.c). On the real
> >>> board, the Ethernet PHY is at address 6. Adjust this by updating the
> >>> "fec-phy-num" property of the fsl_imx6 SoC object.
> >>>
> >>> With this change, U-Boot sees the PHY but complains MAC address:
> >>>
> >>>   Net:   using phy at 6
> >>>   FEC [PRIME]
> >>>   Error: FEC address not set.
> >>>
> >>> This is due to U-Boot tries to read the MAC address from the fuse,
> >>> which QEMU does not have any valid content filled in. However this
> >>> does not prevent the Ethernet from working in QEMU. We just need to
> >>> set up the MAC address later in the U-Boot command shell, by:
> >>>
> >>>   => setenv ethaddr 00:11:22:33:44:55
> >>>
> >>
> >> With this patch in place, the standard Ethernet interface no longer works 
> >> when
> >> booting sabrelite Linux images directly (without u-boot) using the 
> >> following
> >> qemu command.
> >>         qemu-system-arm -M sabrelite -kernel arch/arm/boot/zImage
> >>         ...
> >>
> >> The Ethernet interface still instantiates, but packet transfer to the host
> >> no longer works. Reverting this patch fixes the problem for me.
> >>
> >> Is there a qemu command line parameter that is now necessary to instantiate
> >> the Ethernet interface when booting Linux ?
> >
> > Enabling "guest_errors" shows that Linux kernel fec driver is trying
> > to read PHY at address 0, which is not what we want.
> >
> > [imx.fec.phy]imx_phy_read: Bad phy num 0
> >
> > The device tree blob of the sabrelite does not contain a node for the
> > ethernet phy specifying phy address, so I suspect Linux kernel driver
> > is using default phy address 0 instead.
> >
> > Could you please test on a real hardware to see what happens?
> >
>
> The problem is that qemu returns 0 when the OS tries to read from a
> non-existing PHY. Linux expects it to return 0xffff, and believes that
> a PHY is there if 0 is returned. This helps:

Good catch! Please send a patch for this.

>
> diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
> index f03450c028..3c90c38e26 100644
> --- a/hw/net/imx_fec.c
> +++ b/hw/net/imx_fec.c
> @@ -285,7 +285,7 @@ static uint32_t imx_phy_read(IMXFECState *s, int reg)
>      if (phy != s->phy_num) {
>          qemu_log_mask(LOG_GUEST_ERROR, "[%s.phy]%s: Bad phy num %u\n",
>                        TYPE_IMX_FEC, __func__, phy);
> -        return 0;
> +        return 0xffff;
>      }
>
> Note that this is not really a guest error; any OS can and likely
> will scan the MII bus for connected phy chips.

Agree.

Regards,
Bin