| Message ID | 20210106063504.10841-4-bmeng.cn@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hw/arm: sabrelite: Improve emulation fidelity to allow booting upstream U-Boot | expand |
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 ? Thanks, Guenter
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? Regards, Bin
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? > I don't have access to real hardware, sorry. Guenter
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: 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. Guenter
On 5/1/21 10:12 PM, Guenter Roeck 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. Correct. > This helps: > > 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. Correct. This should be a trace event instead.
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
On 5/1/21 2:40 PM, Philippe Mathieu-Daudé wrote: > On 5/1/21 10:12 PM, Guenter Roeck 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. > > Correct. > I'll send a patch. Next question is why the Ethernet interfaces on mcimx6ul-evk and mcimx7d-sabre don't work. I either get no connectivity at all (similar to the above) or something like fec 2188000.ethernet eth1: Unable to connect to phy ifconfig: SIOCSIFFLAGS: No such device Any idea ? Thanks, Guenter
On Sun, May 2, 2021 at 7:21 AM Guenter Roeck <linux@roeck-us.net> wrote: > > On 5/1/21 2:40 PM, Philippe Mathieu-Daudé wrote: > > On 5/1/21 10:12 PM, Guenter Roeck 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. > > > > Correct. > > > > I'll send a patch. Next question is why the Ethernet interfaces on mcimx6ul-evk > and mcimx7d-sabre don't work. I either get no connectivity at all (similar to > the above) or something like > > fec 2188000.ethernet eth1: Unable to connect to phy > ifconfig: SIOCSIFFLAGS: No such device > > Any idea ? I don't see these 2 are supported targets of QEMU: https://wiki.qemu.org/Documentation/Platforms/ARM Regards, Bin
On 5/1/21 5:24 PM, Bin Meng wrote: > On Sun, May 2, 2021 at 7:21 AM Guenter Roeck <linux@roeck-us.net> wrote: >> >> On 5/1/21 2:40 PM, Philippe Mathieu-Daudé wrote: >>> On 5/1/21 10:12 PM, Guenter Roeck 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. >>> >>> Correct. >>> >> >> I'll send a patch. Next question is why the Ethernet interfaces on mcimx6ul-evk >> and mcimx7d-sabre don't work. I either get no connectivity at all (similar to >> the above) or something like >> >> fec 2188000.ethernet eth1: Unable to connect to phy >> ifconfig: SIOCSIFFLAGS: No such device >> >> Any idea ? > > I don't see these 2 are supported targets of QEMU: > https://wiki.qemu.org/Documentation/Platforms/ARM > Reality says otherwise. $ qemu-system-arm --version QEMU emulator version 6.0.0 (v6.0.0-25-geac5bb0cc1-dirty) Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers $ qemu-system-arm -M ? | grep mcim mcimx6ul-evk Freescale i.MX6UL Evaluation Kit (Cortex A7) mcimx7d-sabre Freescale i.MX7 DUAL SABRE (Cortex A7) Guenter
On 5/1/21 6:37 PM, Guenter Roeck wrote: > On 5/1/21 5:24 PM, Bin Meng wrote: >> On Sun, May 2, 2021 at 7:21 AM Guenter Roeck <linux@roeck-us.net> wrote: >>> >>> On 5/1/21 2:40 PM, Philippe Mathieu-Daudé wrote: >>>> On 5/1/21 10:12 PM, Guenter Roeck 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. >>>> >>>> Correct. >>>> >>> >>> I'll send a patch. Next question is why the Ethernet interfaces on mcimx6ul-evk >>> and mcimx7d-sabre don't work. I either get no connectivity at all (similar to >>> the above) or something like >>> >>> fec 2188000.ethernet eth1: Unable to connect to phy >>> ifconfig: SIOCSIFFLAGS: No such device >>> >>> Any idea ? >> >> I don't see these 2 are supported targets of QEMU: >> https://wiki.qemu.org/Documentation/Platforms/ARM >> > > Reality says otherwise. > > $ qemu-system-arm --version > QEMU emulator version 6.0.0 (v6.0.0-25-geac5bb0cc1-dirty) > Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers > $ qemu-system-arm -M ? | grep mcim > mcimx6ul-evk Freescale i.MX6UL Evaluation Kit (Cortex A7) > mcimx7d-sabre Freescale i.MX7 DUAL SABRE (Cortex A7) > Anyway, the underlying problem is that the phy chips are not connected to the MDIO bus associated with each Ethernet controller. In other words, unlike the current imx fec emulation suggests, there is no 1:1 connection between Ethernet and phy. This is even mentioned in commit 461c51ad42 ("Add a phy-num property to the i.MX FEC emulator"): "As an example with the i.MX6UL the NXP SOC has 2 Ethernet devices but only one MDIO bus on which the 2 related PHY are connected but at unique addresses." Unfortunately that commit doesn't actually solve the problem where 2 Ethernet devices are connected to a single MDIO bus; it just adds support for setting the phy address. I have no idea how to solve that in a clean way in qemu. Guenter
diff --git a/hw/arm/sabrelite.c b/hw/arm/sabrelite.c index 91d8c43a7e..a3dbf85e0e 100644 --- a/hw/arm/sabrelite.c +++ b/hw/arm/sabrelite.c @@ -51,6 +51,10 @@ static void sabrelite_init(MachineState *machine) s = FSL_IMX6(object_new(TYPE_FSL_IMX6)); object_property_add_child(OBJECT(machine), "soc", OBJECT(s)); + + /* Ethernet PHY address is 6 */ + object_property_set_int(OBJECT(s), "fec-phy-num", 6, &error_fatal); + qdev_realize(DEVICE(s), NULL, &error_fatal); memory_region_add_subregion(get_system_memory(), FSL_IMX6_MMDC_ADDR,