[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-discuss
Subject:    Re: MCIMX6UL EVK QEMU Ethernet
From:       Sean Nyekjaer <sean () geanix ! com>
Date:       2020-06-04 13:33:17
Message-ID: 00170024-bd94-873d-3599-d838905ea01e () geanix ! com
[Download RAW message or body]



On 02/06/2020 19.44, Jean-Christophe DUBOIS wrote:
> Hello Sean,
>
> I believe that one problem might be that the Ethernet PHY 
> implementation is not "complete" in Qemu.
>
> Actually the i.MX FEC driver implement a PHY (LAN911x from SMSC 
> borrowed from another Qemu Ethernet emulator) that is not present on 
> the i.MX6UL EVK board (it has a micrel PHY)
>
> With your actual device tree the linux kernel is certainly expecting 
> that when a link state changes, it get notified by the PHY through 
> some GPIO/interrupt and then can react to this (as most PHY do today).
>
> The wiring between the Ethernet PHY device and the processor GPIO is 
> not implemented in Qemu (even if the LAN911X would be able to raise an 
> interrupt on event, but anyway this particular PHY is not even in your 
> device tree).
>
> Therefore your linux kernel never get notified when the PHY get the 
> link up (and it does get to this state by default).
>
> So I believe you would have a better chance if you were disabling the 
> interrupt from the PHY inside the kernel (through the DTS tree) to get 
> to poling mode.
>
> As a matter of fact, for an embedded application using µCOS (not 
> linux), I recently had to use the generic µCOS PHY driver (limited to 
> IEEE defined registers) that run in polling mode to get it working on 
> Qemu.
>
> So I think you should tweak your device tree to change the way linux 
> handle the PHY so that it default to polling mode.
>
> On a related note, the imx_fec emulator expect the PHY to be the first 
> device (0) on the MDIO bus (and ignore any request for other devices 
> on the MDIO bus). But in the actual linux DTS tree the 2 PHY devices 
> are at location (1) and (2). I have a patch lying around to address 
> this point.
>
> JC

Hi Jean-Christophe,

Logs from a real device:
root@mermaid:/data/root# dmesg | grep -i net
[    0.112869] NET: Registered protocol family 16
[    0.513730] NET: Registered protocol family 31
[    0.974893] NET: Registered protocol family 2
[    0.983511] NET: Registered protocol family 1
[    1.091419] NET: Registered protocol family 38
[    1.332397] fec 2188000.ethernet: 2188000.ethernet supply phy not 
found, using dummy regulator
[    1.333086] fec 2188000.ethernet: Linked as a consumer to regulator.0
[    1.341272] libphy: fec_enet_mii_bus: probed
[    1.353170] fec 2188000.ethernet eth0: registered PHC device 0
[    1.686031] NET: Registered protocol family 10
[    1.718592] NET: Registered protocol family 17
[    1.718742] can: controller area network core (rev 20170425 abi 9)
[    1.719292] NET: Registered protocol family 29
[    1.719856] can: netlink gateway (rev 20170425) max_hops=1
[   19.983072] IPv6: ADDRCONF(NETDEV_UP): can0: link is not ready
[   19.989135] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[   20.111539] IPv6: ADDRCONF(NETDEV_UP): can1: link is not ready
[   21.059359] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready
[   24.904531] Micrel KSZ8081 or KSZ8091 2188000.ethernet-1:01: attached 
PHY driver [Micrel KSZ8081 or KSZ8091] 
(mii_bus:phy_addr=2188000.ethernet-1:01, irq=POLL)

Logs from a QEMU boot:
/ # dmesg | grep -i net
[    0.135471] NET: Registered protocol family 16
[    0.402281] NET: Registered protocol family 31
[    0.637948] NET: Registered protocol family 2
[    0.649080] NET: Registered protocol family 1
[    0.713418] NET: Registered protocol family 38
[    0.850696] libphy: fec_enet_mii_bus: probed
[    0.865434] fec 20b4000.ethernet eth0: registered PHC device 0
[    0.946979] libphy: fec_enet_mii_bus: probed
[    0.950231] fec 2188000.ethernet eth1: registered PHC device 1
[    1.396172] NET: Registered protocol family 10
[    1.412807] NET: Registered protocol family 17

Looks like it probes for a phy.

I have also tried this patch for the devicetree:
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi 
b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 265bf4108cb6..557ccce609a8 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -168,15 +168,15 @@ mdio {
                 #address-cells = <1>;
                 #size-cells = <0>;

-               ethphy0: ethernet-phy@2 {
-                       reg = <2>;
+               ethphy0: ethernet-phy@1 {
+                       reg = <1>;
                         micrel,led-mode = <1>;
                         clocks = <&clks IMX6UL_CLK_ENET_REF>;
                         clock-names = "rmii-ref";
                 };

-               ethphy1: ethernet-phy@1 {
-                       reg = <1>;
+               ethphy1: ethernet-phy@0 {
+                       reg = <0>;
                         micrel,led-mode = <1>;
                         clocks = <&clks IMX6UL_CLK_ENET2_REF>;
                         clock-names = "rmii-ref";

Best regards
Sean Nyekjær


>
> Le 02/06/2020 à 12:45, Sean Nyekjaer a écrit :
>> Hi
>>
>>
>>
>> I'm very new to QEMU and having trouble with the iMX6ul EVK QEMU 
>> variant.
>>
>>
>>
>> We are starting QEMU with:
>>
>> % qemu-system-arm \
>>
>>
>> -d trace:usb_port_attach \
>>
>>
>> -machine mcimx6ul-evk \
>>
>>
>> -m 256 \
>>
>>
>> -no-reboot \
>>
>>
>> -nographic \
>>
>>
>> -serial mon:stdio \
>>
>>
>> -kernel ./zImage \
>>
>>
>> -drive 
>> if=sd,id=sd0,format=raw,file=./cc-image-dev-iwg26-20200505081306.rootfs.wic 
>> \
>>
>>
>> -device sd-card,id=sd0 \
>>
>>
>> -dtb ./imx6ul-14x14-evk.dtb \
>>
>>
>> -append "root=/dev/mmcblk0p3 ro quiet 
>> systemd.setenv=SYSTEMD_FSTAB=/etc/fstab.qemu ip=::::qemu::none" \
>>
>>
>> -nic 
>> user,mac=02:ca:fe:f0:0d:01,id=u1,net=192.168.60.0/24,dhcpstart=192.168.60.9 
>> \
>>
>>
>> -nic 
>> user,mac=02:ca:fe:f0:0d:02,id=u2,net=192.168.70.0/24,dhcpstart=192.168.70.9
>>
>>
>>
>> But the Ethernet devices never gets a "link up"
>>
>>
>>
>> root@qemu:/data/root# ip link
>>
>>
>>
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
>> mode DEFAULT group default qlen 1000
>>
>>
>>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>
>>
>> 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel 
>> state DOWN mode DEFAULT group default qlen 1000
>>
>>
>>     link/ether 02:ca:fe:f0:0d:02 brd ff:ff:ff:ff:ff:ff
>>
>>
>> 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel 
>> state DOWN mode DEFAULT group default qlen 1000
>>
>>     link/ether 02:ca:fe:f0:0d:01 brd ff:ff:ff:ff:ff:ff
>>
>>
>>
>>
>>
>> I have tried with a 4.19.x and a 5.6 kernel.
>>
>> Qemu v4.2 and v5.0
>>
>>
>>
>> Can you steer me in the correct direction?
>>
>>
>> Best regards,
>> Sean Nyekjaer
>
>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic