* [Xenomai] RT FEC net driver for IMX6Q @ 2016-02-03 14:51 Michael Welling 2016-02-03 15:04 ` Gilles Chanteperdrix 0 siblings, 1 reply; 8+ messages in thread From: Michael Welling @ 2016-02-03 14:51 UTC (permalink / raw) To: xenomai Is there any specific reason why the fec driver is restricted to the PPC arcitecture? The driver appears to have bindings for the IMX ARM controllers. Can this driver be used with the IMX6Q processor? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-03 14:51 [Xenomai] RT FEC net driver for IMX6Q Michael Welling @ 2016-02-03 15:04 ` Gilles Chanteperdrix 2016-02-03 15:18 ` Michael Welling 0 siblings, 1 reply; 8+ messages in thread From: Gilles Chanteperdrix @ 2016-02-03 15:04 UTC (permalink / raw) To: Michael Welling; +Cc: xenomai On Wed, Feb 03, 2016 at 08:51:46AM -0600, Michael Welling wrote: > Is there any specific reason why the fec driver is restricted to the PPC > arcitecture? In its current state, the driver does not compile for IMX6. A broken patch has been proposed, my idea is to work on RTnet core before tackling the drivers, but if a patch fixing the build for imx6 is proposed, it could be re-enabled. > > The driver appears to have bindings for the IMX ARM controllers. > > Can this driver be used with the IMX6Q processor? > > > _______________________________________________ > Xenomai mailing list > Xenomai@xenomai.org > http://xenomai.org/mailman/listinfo/xenomai -- Gilles. https://click-hack.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-03 15:04 ` Gilles Chanteperdrix @ 2016-02-03 15:18 ` Michael Welling 2016-02-03 15:33 ` Gilles Chanteperdrix 0 siblings, 1 reply; 8+ messages in thread From: Michael Welling @ 2016-02-03 15:18 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Wed, Feb 03, 2016 at 04:04:48PM +0100, Gilles Chanteperdrix wrote: > On Wed, Feb 03, 2016 at 08:51:46AM -0600, Michael Welling wrote: > > Is there any specific reason why the fec driver is restricted to the PPC > > arcitecture? > > In its current state, the driver does not compile for IMX6. A broken > patch has been proposed, my idea is to work on RTnet core before > tackling the drivers, but if a patch fixing the build for imx6 is > proposed, it could be re-enabled. > What are the issues with the RTnet core? I just found out the hard way that the driver does not compile. I will try my best to update the IMX drivers so that they build with 3.18.20. > > > > The driver appears to have bindings for the IMX ARM controllers. > > > > Can this driver be used with the IMX6Q processor? > > > > > > _______________________________________________ > > Xenomai mailing list > > Xenomai@xenomai.org > > http://xenomai.org/mailman/listinfo/xenomai > > -- > Gilles. > https://click-hack.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-03 15:18 ` Michael Welling @ 2016-02-03 15:33 ` Gilles Chanteperdrix 2016-02-04 19:58 ` Michael Welling 0 siblings, 1 reply; 8+ messages in thread From: Gilles Chanteperdrix @ 2016-02-03 15:33 UTC (permalink / raw) To: Michael Welling; +Cc: xenomai On Wed, Feb 03, 2016 at 09:18:02AM -0600, Michael Welling wrote: > On Wed, Feb 03, 2016 at 04:04:48PM +0100, Gilles Chanteperdrix wrote: > > On Wed, Feb 03, 2016 at 08:51:46AM -0600, Michael Welling wrote: > > > Is there any specific reason why the fec driver is restricted to the PPC > > > arcitecture? > > > > In its current state, the driver does not compile for IMX6. A broken > > patch has been proposed, my idea is to work on RTnet core before > > tackling the drivers, but if a patch fixing the build for imx6 is > > proposed, it could be re-enabled. > > > > What are the issues with the RTnet core? The main issue is that it predates many factorizations in the Linux kernel code and so could be made simpler by relying on them. It open codes linked lists for instance, this is just a random example. Another issue is that keeping the drivers synchronized with their mainline counter-part requires a big maintenance effort. > > I just found out the hard way that the driver does not compile. > I will try my best to update the IMX drivers so that they build > with 3.18.20. A patch has been posted here: https://xenomai.org/pipermail/xenomai/2016-January/035756.html -- Gilles. https://click-hack.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-03 15:33 ` Gilles Chanteperdrix @ 2016-02-04 19:58 ` Michael Welling 2016-02-04 22:07 ` Gilles Chanteperdrix 0 siblings, 1 reply; 8+ messages in thread From: Michael Welling @ 2016-02-04 19:58 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Wed, Feb 03, 2016 at 04:33:41PM +0100, Gilles Chanteperdrix wrote: > On Wed, Feb 03, 2016 at 09:18:02AM -0600, Michael Welling wrote: > > On Wed, Feb 03, 2016 at 04:04:48PM +0100, Gilles Chanteperdrix wrote: > > > On Wed, Feb 03, 2016 at 08:51:46AM -0600, Michael Welling wrote: > > > > Is there any specific reason why the fec driver is restricted to the PPC > > > > arcitecture? > > > > > > In its current state, the driver does not compile for IMX6. A broken > > > patch has been proposed, my idea is to work on RTnet core before > > > tackling the drivers, but if a patch fixing the build for imx6 is > > > proposed, it could be re-enabled. > > > > > > > What are the issues with the RTnet core? > > The main issue is that it predates many factorizations in the Linux > kernel code and so could be made simpler by relying on them. It open > codes linked lists for instance, this is just a random example. > Another issue is that keeping the drivers synchronized with their > mainline counter-part requires a big maintenance effort. > > > > > I just found out the hard way that the driver does not compile. > > I will try my best to update the IMX drivers so that they build > > with 3.18.20. > > A patch has been posted here: > https://xenomai.org/pipermail/xenomai/2016-January/035756.html > So I manually applied the changes posted here. Here is what I did: -- diff --git a/kernel/drivers/net/drivers/Kconfig b/kernel/drivers/net/drivers/Kconfig index 267396c..c4a0abf 100644 --- a/kernel/drivers/net/drivers/Kconfig +++ b/kernel/drivers/net/drivers/Kconfig @@ -129,6 +129,10 @@ config XENO_DRIVERS_NET_DRV_MACB Driver for internal MAC-controller on AT91SAM926x microcontrollers. Porting by Cristiano Mantovani and Stefano Banzi (Marposs SpA). +config XENO_DRIVERS_NET_DRV_FEC + depends on XENO_DRIVERS_NET + tristate "IMX FEC Ethernet" + endif source "drivers/xenomai/net/drivers/experimental/Kconfig" diff --git a/kernel/drivers/net/drivers/fec.c b/kernel/drivers/net/drivers/fec.c index 290b765..fae9e59 100644 --- a/kernel/drivers/net/drivers/fec.c +++ b/kernel/drivers/net/drivers/fec.c @@ -331,7 +331,7 @@ fec_enet_start_xmit(struct rtskb *skb, struct rtnet_device *ndev) if (!fep->link) { /* Link is down or autonegotiation is in progress. */ - printk("%s: tx link down!.\n", ndev->name); + pr_debug("%s: tx link down!.\n", ndev->name); rtnetif_stop_queue(ndev); return 1; /* RTnet: will call kfree_rtskb() */ } @@ -352,7 +352,7 @@ fec_enet_start_xmit(struct rtskb *skb, struct rtnet_device *ndev) /* Ooops. All transmit buffers are full. Bail out. * This should not happen, since ndev->tbusy should be set. */ - printk("%s: tx queue full!.\n", ndev->name); + pr_err("%s: tx queue full!.\n", ndev->name); rtdm_lock_put_irqrestore(&fep->hw_lock, context); return 1; /* RTnet: will call kfree_rtskb() */ } @@ -1047,7 +1047,7 @@ static int fec_enet_mii_probe(struct rtnet_device *ndev) snprintf(phy_name, sizeof(phy_name), PHY_ID_FMT, mdio_bus_id, phy_id); /* attach the mac to the phy using the dummy linux netdev */ - phy_dev = phy_connect(fep->netdev, phy_name, &fec_enet_adjust_link, 0, + phy_dev = phy_connect(fep->netdev, phy_name, &fec_enet_adjust_link, fep->phy_interface); if (IS_ERR(phy_dev)) { printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name); @@ -1266,7 +1266,7 @@ static int fec_enet_alloc_buffers(struct rtnet_device *ndev) bdp = fep->rx_bd_base; for (i = 0; i < RX_RING_SIZE; i++) { - skb = rtnetdev_alloc_rtskb(netdev, FEC_ENET_RX_FRSIZE); /* RTnet */ + skb = rtnetdev_alloc_rtskb(ndev, FEC_ENET_RX_FRSIZE); /* RTnet */ if (!skb) { fec_enet_free_buffers(ndev); return -ENOMEM; -- I tried following the instructions on the RTnet installation guide to test loopback: https://xenomai.org/rtnet-installation/ -- root@somimx6:/usr/xenomai/sbin# ./rtnet start [ 2913.814896] [ 2913.814896] *** RTnet for Xenomai v3.0.1 *** [ 2913.814896] [ 2913.822171] RTnet: initialising real-time networking [ 2913.882229] ------------[ cut here ]------------ [ 2913.886887] WARNING: CPU: 2 PID: 737 at /home/michael/projects/xenomai/imx_xeno/linux-3.18.20/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0xa8/0xe8() [ 2913.900941] Modules linked in: rt_fec(+) rtipv4 rtnet [ 2913.906108] CPU: 2 PID: 737 Comm: modprobe Not tainted 3.18.20 #4 [ 2913.912233] Backtrace: [ 2913.914724] [<80012a88>] (dump_backtrace) from [<80012c94>] (show_stack+0x18/0x1c) [ 2913.922326] r6:80a0a60c r5:00000000 r4:00000000 r3:00000000 [ 2913.928082] [<80012c7c>] (show_stack) from [<807061d4>] (dump_stack+0x8c/0xa4) [ 2913.935353] [<80706148>] (dump_stack) from [<8002c148>] (warn_slowpath_common+0x70/0x94) [ 2913.943470] r6:8001ba5c r5:00000009 r4:00000000 r3:00000000 [ 2913.949212] [<8002c0d8>] (warn_slowpath_common) from [<8002c210>] (warn_slowpath_null+0x24/0x2c) [ 2913.958028] r8:bdae0ea8 r7:bdae0d60 r6:be189000 r5:bdae0ec8 r4:80a481e1 [ 2913.964852] [<8002c1ec>] (warn_slowpath_null) from [<8001ba5c>] (ipipe_set_irq_affinity+0xa8/0xe8) [ 2913.973861] [<8001b9b4>] (ipipe_set_irq_affinity) from [<800a6dfc>] (xnintr_attach+0x34/0xdc) [ 2913.982418] r4:bdae0ea8 [ 2913.984985] [<800a6dc8>] (xnintr_attach) from [<800ba784>] (rtdm_irq_request+0x50/0x7c) [ 2913.993020] r7:bdae0d60 r6:be189000 r5:bdae0ea8 r4:bdae0ea8 [ 2913.998773] [<800ba734>] (rtdm_irq_request) from [<7f026d30>] (fec_probe+0x1dc/0x8d0 [rt_fec]) [ 2914.007419] r5:bdae0c00 r4:bdae0ea8 [ 2914.011059] [<7f026b54>] (fec_probe [rt_fec]) from [<803a3edc>] (platform_drv_probe+0x4c/0xac) [ 2914.019719] r10:bd894008 r9:be04a580 r8:00000007 r7:fffffdfb r6:7f027b98 r5:be189010 [ 2914.027665] r4:80b15b68 [ 2914.030231] [<803a3e90>] (platform_drv_probe) from [<803a2460>] (really_probe+0x80/0x214) [ 2914.038438] r7:7f027b98 r6:00000000 r5:be189010 r4:80b15b68 [ 2914.044206] [<803a23e0>] (really_probe) from [<803a26f0>] (__driver_attach+0xa0/0xa4) [ 2914.052041] r8:809f3fe0 r7:00000000 r6:be189044 r5:7f027b98 r4:be189010 r3:00000007 [ 2914.059916] [<803a2650>] (__driver_attach) from [<803a0934>] (bus_for_each_dev+0x74/0xa8) [ 2914.068123] r6:803a2650 r5:7f027b98 r4:00000000 r3:00001eed [ 2914.073887] [<803a08c0>] (bus_for_each_dev) from [<803a2030>] (driver_attach+0x20/0x28) [ 2914.081895] r6:80a16f70 r5:bd116000 r4:7f027b98 [ 2914.086601] [<803a2010>] (driver_attach) from [<803a1ce4>] (bus_add_driver+0x148/0x1f4) [ 2914.094644] [<803a1b9c>] (bus_add_driver) from [<803a2da8>] (driver_register+0x80/0x100) [ 2914.102771] r7:00000000 r6:7f02a000 r5:809f3fe0 r4:7f027b98 [ 2914.108513] [<803a2d28>] (driver_register) from [<803a3e14>] (__platform_driver_register+0x50/0x64) [ 2914.117588] r5:809f3fe0 r4:bd895f48 [ 2914.121229] [<803a3dc4>] (__platform_driver_register) from [<7f02a018>] (fec_driver_init+0x18/0x24 [rt_fec]) [ 2914.131104] [<7f02a000>] (fec_driver_init [rt_fec]) from [<80008c7c>] (do_one_initcall+0x88/0x1d0) [ 2914.140111] [<80008bf4>] (do_one_initcall) from [<8008a374>] (load_module+0x1824/0x1f84) [ 2914.148232] r10:7f027c6c r9:bda44008 r8:7f027c78 r7:00000001 r6:bda44000 r5:00000001 [ 2914.156180] r4:bd895f48 [ 2914.158743] [<80088b50>] (load_module) from [<8008ac3c>] (SyS_finit_module+0x70/0x80) [ 2914.166602] r10:00000000 r9:bd894000 r8:8000f228 r7:0000017b r6:00eb9200 r5:00000003 [ 2914.174544] r4:00000000 [ 2914.177110] [<8008abcc>] (SyS_finit_module) from [<8000efc0>] (ret_fast_syscall+0x0/0x38) [ 2914.185316] r6:00000000 r5:00000000 r4:00eb9200 [ 2914.189995] ---[ end trace 9b70cb5c60d4bcca ]--- [ 2914.205019] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2914.211649] [drm] No driver support for vblank timestamp query. [ 2914.217993] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) [ 2914.225511] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) [ 2914.233196] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) [ 2914.240718] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) [ 2914.248669] imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 [ 2914.255991] imx-drm display-subsystem: bound 120000.hdmi (ops hdmi_ops) [ 2914.262981] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: could not find display-timings node [ 2914.272043] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: no timings specified [ 2914.279922] imx-drm display-subsystem: failed to bind 2000000.aips-bus:ldb@020e0008 (ops imx_ldb_ops): -517 [ 2914.291233] libphy: fec_enet_mii_bus: probed [ 2914.292327] imx-drm display-subsystem: master bind failed: -517 [ 2914.292355] platform 120000.hdmi: Driver imx-hdmi requests probe deferral [ 2914.308282] RTnet: registered rteth0 [ 2914.314440] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2914.321072] [drm] No driver support for vblank timestamp query. [ 2914.327423] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) [ 2914.335989] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) [ 2914.343787] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) [ 2914.352408] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) [ 2914.359263] initializing loopback... [ 2914.359313] RTnet: registered rtlo [ 2914.367364] imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 [ 2914.374764] imx-drm display-subsystem: bound 120000.hdmi (ops hdmi_ops) [ 2914.380043] RTcfg: init real-time configuration distribution protocol [ 2914.387992] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: could not find display-timings node [ 2914.394963] RTmac: init realtime media access control [ 2914.402225] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: no timings specified [ 2914.408727] RTmac/TDMA: init time division multiple access control mechanism [ 2914.417186] imx-drm display-subsystem: failed to bind 2000000.aips-bus:ldb@020e0008 (ops imx_ldb_ops): -517 [ 2914.427914] imx-drm display-subsystem: master bind failed: -517 [ 2914.433925] platform 120000.hdmi: Driver imx-hdmi requests probe deferral [ 2914.492899] rteth0: Freescale FEC PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1) Waiting for all slaves...[ 2918.492619] rt_fec 2188000.ethernet (unnamed net_device) (uninitialized): Link is Up - 1Gbps/Full - flow control rx/tx ^C root@somimx6:/usr/xenomai/sbin# lsmod Module Size Used by tdma 29250 1 rtmac 10739 1 tdma rtcfg 36854 0 rt_loopback 1110 1 rtpacket 8028 0 rtudp 13866 0 rt_fec 14426 1 rtipv4 32385 2 rtcfg,rtudp rtnet 51285 8 tdma,rtcfg,rtmac,rtudp,rtpacket,rt_fec,rtipv4,rt_loopback root@somimx6:/usr/xenomai/sbin# ./rtifconfig rteth0 Medium: Ethernet Hardware address: 00:14:2D:00:01:02 IP address: 127.0.0.2 Broadcast address: 127.0.0.255 UP BROADCAST RUNNING MTU: 1500 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5501 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:232483 (227.0 Kb) rtlo Medium: Local Loopback IP address: 127.0.0.1 UP LOOPBACK RUNNING MTU: 1500 root@somimx6:/usr/xenomai/sbin# ./rtping 127.0.0.1 Real-time PING 127.0.0.1 56(84) bytes of data. ioctl: Resource temporarily unavailable -- What is the reason for the stacktrace? What would cause the ioctl to fail? strace shows the it is an ioctl to /dev/rtnet open("/dev/rtnet", O_RDWR) = 3 ... ioctl(3, 0xc0500285, 0x11d60) = -1 EAGAIN (Resource temporarily unavailable) ... > -- > Gilles. > https://click-hack.org ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-04 19:58 ` Michael Welling @ 2016-02-04 22:07 ` Gilles Chanteperdrix 2016-02-04 22:20 ` Michael Welling 2016-02-04 23:56 ` Michael Welling 0 siblings, 2 replies; 8+ messages in thread From: Gilles Chanteperdrix @ 2016-02-04 22:07 UTC (permalink / raw) To: Michael Welling; +Cc: xenomai On Thu, Feb 04, 2016 at 01:58:05PM -0600, Michael Welling wrote: > On Wed, Feb 03, 2016 at 04:33:41PM +0100, Gilles Chanteperdrix wrote: > > On Wed, Feb 03, 2016 at 09:18:02AM -0600, Michael Welling wrote: > > > On Wed, Feb 03, 2016 at 04:04:48PM +0100, Gilles Chanteperdrix wrote: > > > > On Wed, Feb 03, 2016 at 08:51:46AM -0600, Michael Welling wrote: > > > > > Is there any specific reason why the fec driver is restricted to the PPC > > > > > arcitecture? > > > > > > > > In its current state, the driver does not compile for IMX6. A broken > > > > patch has been proposed, my idea is to work on RTnet core before > > > > tackling the drivers, but if a patch fixing the build for imx6 is > > > > proposed, it could be re-enabled. > > > > > > > > > > What are the issues with the RTnet core? > > > > The main issue is that it predates many factorizations in the Linux > > kernel code and so could be made simpler by relying on them. It open > > codes linked lists for instance, this is just a random example. > > Another issue is that keeping the drivers synchronized with their > > mainline counter-part requires a big maintenance effort. > > > > > > > > I just found out the hard way that the driver does not compile. > > > I will try my best to update the IMX drivers so that they build > > > with 3.18.20. > > > > A patch has been posted here: > > https://xenomai.org/pipermail/xenomai/2016-January/035756.html > > > > So I manually applied the changes posted here. > > Here is what I did: > > -- > > diff --git a/kernel/drivers/net/drivers/Kconfig b/kernel/drivers/net/drivers/Kconfig > index 267396c..c4a0abf 100644 > --- a/kernel/drivers/net/drivers/Kconfig > +++ b/kernel/drivers/net/drivers/Kconfig > @@ -129,6 +129,10 @@ config XENO_DRIVERS_NET_DRV_MACB > Driver for internal MAC-controller on AT91SAM926x microcontrollers. > Porting by Cristiano Mantovani and Stefano Banzi (Marposs SpA). > > +config XENO_DRIVERS_NET_DRV_FEC > + depends on XENO_DRIVERS_NET > + tristate "IMX FEC Ethernet" > + > endif > > source "drivers/xenomai/net/drivers/experimental/Kconfig" > diff --git a/kernel/drivers/net/drivers/fec.c b/kernel/drivers/net/drivers/fec.c > index 290b765..fae9e59 100644 > --- a/kernel/drivers/net/drivers/fec.c > +++ b/kernel/drivers/net/drivers/fec.c > @@ -331,7 +331,7 @@ fec_enet_start_xmit(struct rtskb *skb, struct rtnet_device *ndev) > > if (!fep->link) { > /* Link is down or autonegotiation is in progress. */ > - printk("%s: tx link down!.\n", ndev->name); > + pr_debug("%s: tx link down!.\n", ndev->name); > rtnetif_stop_queue(ndev); > return 1; /* RTnet: will call kfree_rtskb() */ > } > @@ -352,7 +352,7 @@ fec_enet_start_xmit(struct rtskb *skb, struct rtnet_device *ndev) > /* Ooops. All transmit buffers are full. Bail out. > * This should not happen, since ndev->tbusy should be set. > */ > - printk("%s: tx queue full!.\n", ndev->name); > + pr_err("%s: tx queue full!.\n", ndev->name); > rtdm_lock_put_irqrestore(&fep->hw_lock, context); > return 1; /* RTnet: will call kfree_rtskb() */ > } > @@ -1047,7 +1047,7 @@ static int fec_enet_mii_probe(struct rtnet_device *ndev) > > snprintf(phy_name, sizeof(phy_name), PHY_ID_FMT, mdio_bus_id, phy_id); > /* attach the mac to the phy using the dummy linux netdev */ > - phy_dev = phy_connect(fep->netdev, phy_name, &fec_enet_adjust_link, 0, > + phy_dev = phy_connect(fep->netdev, phy_name, &fec_enet_adjust_link, > fep->phy_interface); > if (IS_ERR(phy_dev)) { > printk(KERN_ERR "%s: could not attach to PHY\n", ndev->name); > @@ -1266,7 +1266,7 @@ static int fec_enet_alloc_buffers(struct rtnet_device *ndev) > > bdp = fep->rx_bd_base; > for (i = 0; i < RX_RING_SIZE; i++) { > - skb = rtnetdev_alloc_rtskb(netdev, FEC_ENET_RX_FRSIZE); /* RTnet */ > + skb = rtnetdev_alloc_rtskb(ndev, FEC_ENET_RX_FRSIZE); /* RTnet */ > if (!skb) { > fec_enet_free_buffers(ndev); > return -ENOMEM; > > -- > > I tried following the instructions on the RTnet installation guide to test loopback: > https://xenomai.org/rtnet-installation/ > > -- > > root@somimx6:/usr/xenomai/sbin# ./rtnet start > [ 2913.814896] > [ 2913.814896] *** RTnet for Xenomai v3.0.1 *** > [ 2913.814896] > [ 2913.822171] RTnet: initialising real-time networking > [ 2913.882229] ------------[ cut here ]------------ > [ 2913.886887] WARNING: CPU: 2 PID: 737 at /home/michael/projects/xenomai/imx_xeno/linux-3.18.20/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0xa8/0xe8() > [ 2913.900941] Modules linked in: rt_fec(+) rtipv4 rtnet > [ 2913.906108] CPU: 2 PID: 737 Comm: modprobe Not tainted 3.18.20 #4 > [ 2913.912233] Backtrace: > [ 2913.914724] [<80012a88>] (dump_backtrace) from [<80012c94>] (show_stack+0x18/0x1c) > [ 2913.922326] r6:80a0a60c r5:00000000 r4:00000000 r3:00000000 > [ 2913.928082] [<80012c7c>] (show_stack) from [<807061d4>] (dump_stack+0x8c/0xa4) > [ 2913.935353] [<80706148>] (dump_stack) from [<8002c148>] (warn_slowpath_common+0x70/0x94) > [ 2913.943470] r6:8001ba5c r5:00000009 r4:00000000 r3:00000000 > [ 2913.949212] [<8002c0d8>] (warn_slowpath_common) from [<8002c210>] (warn_slowpath_null+0x24/0x2c) > [ 2913.958028] r8:bdae0ea8 r7:bdae0d60 r6:be189000 r5:bdae0ec8 r4:80a481e1 > [ 2913.964852] [<8002c1ec>] (warn_slowpath_null) from [<8001ba5c>] (ipipe_set_irq_affinity+0xa8/0xe8) > [ 2913.973861] [<8001b9b4>] (ipipe_set_irq_affinity) from [<800a6dfc>] (xnintr_attach+0x34/0xdc) > [ 2913.982418] r4:bdae0ea8 > [ 2913.984985] [<800a6dc8>] (xnintr_attach) from [<800ba784>] (rtdm_irq_request+0x50/0x7c) > [ 2913.993020] r7:bdae0d60 r6:be189000 r5:bdae0ea8 r4:bdae0ea8 > [ 2913.998773] [<800ba734>] (rtdm_irq_request) from [<7f026d30>] (fec_probe+0x1dc/0x8d0 [rt_fec]) > [ 2914.007419] r5:bdae0c00 r4:bdae0ea8 > [ 2914.011059] [<7f026b54>] (fec_probe [rt_fec]) from [<803a3edc>] (platform_drv_probe+0x4c/0xac) > [ 2914.019719] r10:bd894008 r9:be04a580 r8:00000007 r7:fffffdfb r6:7f027b98 r5:be189010 > [ 2914.027665] r4:80b15b68 > [ 2914.030231] [<803a3e90>] (platform_drv_probe) from [<803a2460>] (really_probe+0x80/0x214) > [ 2914.038438] r7:7f027b98 r6:00000000 r5:be189010 r4:80b15b68 > [ 2914.044206] [<803a23e0>] (really_probe) from [<803a26f0>] (__driver_attach+0xa0/0xa4) > [ 2914.052041] r8:809f3fe0 r7:00000000 r6:be189044 r5:7f027b98 r4:be189010 r3:00000007 > [ 2914.059916] [<803a2650>] (__driver_attach) from [<803a0934>] (bus_for_each_dev+0x74/0xa8) > [ 2914.068123] r6:803a2650 r5:7f027b98 r4:00000000 r3:00001eed > [ 2914.073887] [<803a08c0>] (bus_for_each_dev) from [<803a2030>] (driver_attach+0x20/0x28) > [ 2914.081895] r6:80a16f70 r5:bd116000 r4:7f027b98 > [ 2914.086601] [<803a2010>] (driver_attach) from [<803a1ce4>] (bus_add_driver+0x148/0x1f4) > [ 2914.094644] [<803a1b9c>] (bus_add_driver) from [<803a2da8>] (driver_register+0x80/0x100) > [ 2914.102771] r7:00000000 r6:7f02a000 r5:809f3fe0 r4:7f027b98 > [ 2914.108513] [<803a2d28>] (driver_register) from [<803a3e14>] (__platform_driver_register+0x50/0x64) > [ 2914.117588] r5:809f3fe0 r4:bd895f48 > [ 2914.121229] [<803a3dc4>] (__platform_driver_register) from [<7f02a018>] (fec_driver_init+0x18/0x24 [rt_fec]) > [ 2914.131104] [<7f02a000>] (fec_driver_init [rt_fec]) from [<80008c7c>] (do_one_initcall+0x88/0x1d0) > [ 2914.140111] [<80008bf4>] (do_one_initcall) from [<8008a374>] (load_module+0x1824/0x1f84) > [ 2914.148232] r10:7f027c6c r9:bda44008 r8:7f027c78 r7:00000001 r6:bda44000 r5:00000001 > [ 2914.156180] r4:bd895f48 > [ 2914.158743] [<80088b50>] (load_module) from [<8008ac3c>] (SyS_finit_module+0x70/0x80) > [ 2914.166602] r10:00000000 r9:bd894000 r8:8000f228 r7:0000017b r6:00eb9200 r5:00000003 > [ 2914.174544] r4:00000000 > [ 2914.177110] [<8008abcc>] (SyS_finit_module) from [<8000efc0>] (ret_fast_syscall+0x0/0x38) > [ 2914.185316] r6:00000000 r5:00000000 r4:00eb9200 > [ 2914.189995] ---[ end trace 9b70cb5c60d4bcca ]--- > [ 2914.205019] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 2914.211649] [drm] No driver support for vblank timestamp query. > [ 2914.217993] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) > [ 2914.225511] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) > [ 2914.233196] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) > [ 2914.240718] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) > [ 2914.248669] imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 > [ 2914.255991] imx-drm display-subsystem: bound 120000.hdmi (ops hdmi_ops) > [ 2914.262981] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: could not find display-timings node > [ 2914.272043] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: no timings specified > [ 2914.279922] imx-drm display-subsystem: failed to bind 2000000.aips-bus:ldb@020e0008 (ops imx_ldb_ops): -517 > [ 2914.291233] libphy: fec_enet_mii_bus: probed > [ 2914.292327] imx-drm display-subsystem: master bind failed: -517 > [ 2914.292355] platform 120000.hdmi: Driver imx-hdmi requests probe deferral > [ 2914.308282] RTnet: registered rteth0 > [ 2914.314440] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 2914.321072] [drm] No driver support for vblank timestamp query. > [ 2914.327423] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) > [ 2914.335989] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) > [ 2914.343787] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops ipu_crtc_ops) > [ 2914.352408] imx-drm display-subsystem: bound imx-ipuv3-crtc.5 (ops ipu_crtc_ops) > [ 2914.359263] initializing loopback... > [ 2914.359313] RTnet: registered rtlo > [ 2914.367364] imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1 > [ 2914.374764] imx-drm display-subsystem: bound 120000.hdmi (ops hdmi_ops) > [ 2914.380043] RTcfg: init real-time configuration distribution protocol > [ 2914.387992] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: could not find display-timings node > [ 2914.394963] RTmac: init realtime media access control > [ 2914.402225] /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@0: no timings specified > [ 2914.408727] RTmac/TDMA: init time division multiple access control mechanism > [ 2914.417186] imx-drm display-subsystem: failed to bind 2000000.aips-bus:ldb@020e0008 (ops imx_ldb_ops): -517 > [ 2914.427914] imx-drm display-subsystem: master bind failed: -517 > [ 2914.433925] platform 120000.hdmi: Driver imx-hdmi requests probe deferral > [ 2914.492899] rteth0: Freescale FEC PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1) > Waiting for all slaves...[ 2918.492619] rt_fec 2188000.ethernet (unnamed net_device) (uninitialized): Link is Up - 1Gbps/Full - flow control rx/tx > ^C > root@somimx6:/usr/xenomai/sbin# lsmod > Module Size Used by > tdma 29250 1 > rtmac 10739 1 tdma > rtcfg 36854 0 > rt_loopback 1110 1 > rtpacket 8028 0 > rtudp 13866 0 > rt_fec 14426 1 > rtipv4 32385 2 rtcfg,rtudp > rtnet 51285 8 tdma,rtcfg,rtmac,rtudp,rtpacket,rt_fec,rtipv4,rt_loopback > root@somimx6:/usr/xenomai/sbin# ./rtifconfig > rteth0 Medium: Ethernet Hardware address: 00:14:2D:00:01:02 > IP address: 127.0.0.2 Broadcast address: 127.0.0.255 > UP BROADCAST RUNNING MTU: 1500 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:5501 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 > RX bytes:0 (0.0 b) TX bytes:232483 (227.0 Kb) > > rtlo Medium: Local Loopback > IP address: 127.0.0.1 > UP LOOPBACK RUNNING MTU: 1500 > > root@somimx6:/usr/xenomai/sbin# ./rtping 127.0.0.1 > Real-time PING 127.0.0.1 56(84) bytes of data. > ioctl: Resource temporarily unavailable > > -- > > What is the reason for the stacktrace? As indicated by the message: the code at line 158 in arch/arm/kernel/ipipe.c Which is: if (WARN_ON_ONCE(irq_get_chip(irq)->irq_set_affinity == NULL)) return; That is, the fact that the irq chip does not have an irq_set_affinity callback. > > What would cause the ioctl to fail? The fact that you are missing this commit: https://git.xenomai.org/xenomai-3.git/commit/kernel/drivers/net/drivers/loopback.c?h=next&id=04df10d1fdc32e719b66f02da9117d2783a24bd2 -- Gilles. https://click-hack.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-04 22:07 ` Gilles Chanteperdrix @ 2016-02-04 22:20 ` Michael Welling 2016-02-04 23:56 ` Michael Welling 1 sibling, 0 replies; 8+ messages in thread From: Michael Welling @ 2016-02-04 22:20 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Thu, Feb 04, 2016 at 11:07:29PM +0100, Gilles Chanteperdrix wrote: > As indicated by the message: the code at line 158 in > arch/arm/kernel/ipipe.c > Which is: > if (WARN_ON_ONCE(irq_get_chip(irq)->irq_set_affinity == NULL)) > return; > > That is, the fact that the irq chip does not have an > irq_set_affinity callback. > Hmmm ... Perhaps it has to do with the fact that the irq is -1. [ 35.013157] rteth0: Freescale FEC PHY driver [Micrel KSZ9031 Gigabit PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1) I will take a look at my device tree. > > > > What would cause the ioctl to fail? > > The fact that you are missing this commit: > https://git.xenomai.org/xenomai-3.git/commit/kernel/drivers/net/drivers/loopback.c?h=next&id=04df10d1fdc32e719b66f02da9117d2783a24bd2 > Excellent the ping appears to work now: root@somimx6:/usr/xenomai/sbin# ./rtifconfig rteth0 Medium: Ethernet Hardware address: 00:14:2D:00:01:02 IP address: 127.0.0.2 Broadcast address: 127.0.0.255 UP BROADCAST RUNNING MTU: 1500 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:1283 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX bytes:0 (0.0 b) TX bytes:54256 (52.9 Kb) rtlo Medium: Local Loopback IP address: 127.0.0.1 UP LOOPBACK RUNNING MTU: 1500 root@somimx6:/usr/xenomai/sbin# ./rtping 127.0.0.1 Real-time PING 127.0.0.1 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 time=25.7 us 64 bytes from 127.0.0.1: icmp_seq=2 time=18.0 us 64 bytes from 127.0.0.1: icmp_seq=3 time=16.7 us 64 bytes from 127.0.0.1: icmp_seq=4 time=19.0 us 64 bytes from 127.0.0.1: icmp_seq=5 time=18.3 us 64 bytes from 127.0.0.1: icmp_seq=6 time=17.3 us 64 bytes from 127.0.0.1: icmp_seq=7 time=16.7 us 64 bytes from 127.0.0.1: icmp_seq=8 time=18.0 us 64 bytes from 127.0.0.1: icmp_seq=9 time=18.7 us > -- > Gilles. > https://click-hack.org ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] RT FEC net driver for IMX6Q 2016-02-04 22:07 ` Gilles Chanteperdrix 2016-02-04 22:20 ` Michael Welling @ 2016-02-04 23:56 ` Michael Welling 1 sibling, 0 replies; 8+ messages in thread From: Michael Welling @ 2016-02-04 23:56 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai On Thu, Feb 04, 2016 at 11:07:29PM +0100, Gilles Chanteperdrix wrote: > As indicated by the message: the code at line 158 in > arch/arm/kernel/ipipe.c > Which is: > if (WARN_ON_ONCE(irq_get_chip(irq)->irq_set_affinity == NULL)) > return; > > That is, the fact that the irq chip does not have an > irq_set_affinity callback. > I was registering the external PHY interrupt to the internal controller. This was my fault. > > > > What would cause the ioctl to fail? > > The fact that you are missing this commit: > https://git.xenomai.org/xenomai-3.git/commit/kernel/drivers/net/drivers/loopback.c?h=next&id=04df10d1fdc32e719b66f02da9117d2783a24bd2 > > -- > Gilles. > https://click-hack.org ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-02-04 23:56 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-03 14:51 [Xenomai] RT FEC net driver for IMX6Q Michael Welling 2016-02-03 15:04 ` Gilles Chanteperdrix 2016-02-03 15:18 ` Michael Welling 2016-02-03 15:33 ` Gilles Chanteperdrix 2016-02-04 19:58 ` Michael Welling 2016-02-04 22:07 ` Gilles Chanteperdrix 2016-02-04 22:20 ` Michael Welling 2016-02-04 23:56 ` Michael Welling
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.