[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MCIMX6UL EVK QEMU Ethernet
|
From: |
Sean Nyekjaer |
|
Subject: |
Re: MCIMX6UL EVK QEMU Ethernet |
|
Date: |
Thu, 4 Jun 2020 15:33:17 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 |
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