Le Mardi, Octobre 01, 2019 16:37 CEST, Jan Kiszka <[email protected]> a écrit: On 01.10.19 15:26, François Legal wrote: > Hello, > > Could you please clarify what "upstream" is ? RTNet project ? There does not > seem to be activity there since 2012 ?
RTnet was merged into Xenomai 2014. I thought you knew when you were posting here ;).That's what I though, but I was surprised by the mention to "upstream". > I'll be happy to contribute on this. You mention "glue scripting", could you > be > more precise to let me try to fix that part too. xenomai/utils/net/rtnet.in. But I suspect that will be rather simple.So the attached patch (against master) allows one to get the RTNet code builtin, plus the rtnet script modified to take that into account. I can make a patch to 3.0.9 available if that's needed. About the stable init that does not depend on link order, I'll be glad to work on that, but I need some hints on where to start if possible. More tricky is a stable init ordering, ideally something that does not depend on link ordering. And maybe there is more. > > Shall I send the patch to this list ? Exactly. Against the master branch. If it's a fix, we can consider backporting to 3.0.x and 3.1.x (3.1 is already in feature freeze state). Jan > > Thanks > > François > > Le Mardi, Octobre 01, 2019 15:10 CEST, Jan Kiszka <[email protected]> a > écrit: >> On 01.10.19 15:04, François Legal via Xenomai wrote: >> > >> > Hello list, >> > >> > I've been struggling to get the RTNet + RTIPv4 part to work on a Zynq 7000 >> board. Using source code from stable Xenomai 3.0.9 tarball, and patching a >> vanilla 4.4.189 linux. >> > I consistently had the kernel crash (0 pointer dereference error) at >> > startup >> when enabling either RTIPv4, RTCFG or RTMAC. >> > >> > I finally found that there "might" be a problem with the Makefile >> in kernel/drivers/net/stack. >> > It turns out that (on my system at least), the order in which the protocol >> stacks appear in the Makefile is wrong because (I running a kernel with >> everything builtin, no modules) the protocols are loaded in that order, and >> thus, (in my case) RTIPv4 gets initialized before stack_mgr does which cause >> it to fail while registering (calling __rtdev_add_pack with a not >> initialized rt_packets array). >> > >> > When I reorder the protocols in the Makefile, everything works flawlessly. >> > >> > I can provide a patch if this needs to be fixed. >> > >> >> Upstream does not support built-in RTnet. I suspect we need to sort this and >> more issues out systematically in order to permit that. Also, the glue >> scripting >> will need adjustments because of assumptions that RTnet comes in modules. >> >> That said, contributions in that directions are welcome! >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE >> Corporate Competence Center Embedded Linux > > > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-builtin Type: application/octet-stream Size: 6156 bytes Desc: not available URL: <http://xenomai.org/pipermail/xenomai/attachments/20191002/5549df57/attachment.obj>
