* Does Xenomai 3.2.x work with 4.14.x kernels? @ 2022-04-13 9:25 Scott Reed 2022-04-13 18:57 ` Jan Kiszka 0 siblings, 1 reply; 3+ messages in thread From: Scott Reed @ 2022-04-13 9:25 UTC (permalink / raw) To: xenomai Hello, I am trying to build a 4.14.110 kernel+ipipe+xenomai_3.2.7 and running into issues when trying to compile. Namely, the 4.14.x kernel does not seem to understand the "__kernel_timespec" struct. Is it known if Xenomai 3.2.x works with 4.14.x kernels? Some background information --------------------------- Our platform is based on an ARM iMx6q. I have tried to move to a 5.4.x kernel, but ran into another issue in that we have an RTDM driver which uses PCI MSI interrupts and when I try to register the interrupt with rtdm_irq_request the function returns EINVAL(-22). When working with a vanilla 5.4.x kernel and non-RTDM version of the driver, there are no issues when registering the interrupt. I started to dive into this problem, but saw that as of kernel 4.16, the PCI MSI interrupts for our platform have been changed to be handled as chained interrupts. In this forum, I have seen multiple discussions and patches regarding chained interrupts for X86, but not for ARM and began to think that maybe chained interrupt support in xenomai is not complete for ARM. Could this be the case? For this reason, I backed down to the 4.14.x kernel, but now have run into the compiling issue as mentioned at the start of this email. One last piece of background information, my initial motivation to move to a new xenomai was that we moved to GCC 10.2 (in the meantime GCC 11.1) and I was concerned regarding the ARM r7 register clobbering issues/patches posted to the forum as I am fighting against a bug in our system where registers get corrupted albeit not r7 (typically r0 with a value of 0xFFFFFFFA (-38)). This problem seems to have come in after we upgraded to GCC 10.2 Thanks for any help, Scott ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Does Xenomai 3.2.x work with 4.14.x kernels? 2022-04-13 9:25 Does Xenomai 3.2.x work with 4.14.x kernels? Scott Reed @ 2022-04-13 18:57 ` Jan Kiszka 2022-04-14 16:18 ` Scott Reed 0 siblings, 1 reply; 3+ messages in thread From: Jan Kiszka @ 2022-04-13 18:57 UTC (permalink / raw) To: Scott Reed, xenomai On 13.04.22 11:25, Scott Reed via Xenomai wrote: > Hello, > > I am trying to build a 4.14.110 kernel+ipipe+xenomai_3.2.7 and running into > issues when trying to compile. Namely, the 4.14.x kernel does not seem > to understand the "__kernel_timespec" struct. > > Is it known if Xenomai 3.2.x works with 4.14.x kernels? We stopped supporting 4.14.x actively, and we apparently broke backward compatibility at some point. Locally likely fixable, but not maintainable for upstream anymore. > > Some background information > --------------------------- > Our platform is based on an ARM iMx6q. > > I have tried to move to a 5.4.x kernel, but ran into another issue > in that we have an RTDM driver which uses PCI MSI interrupts and > when I try to register the interrupt with rtdm_irq_request the > function returns EINVAL(-22). > > When working with a vanilla 5.4.x kernel and non-RTDM version of > the driver, there are no issues when registering the interrupt. > > I started to dive into this problem, but saw that as of kernel > 4.16, the PCI MSI interrupts for our platform have been changed > to be handled as chained interrupts. > > In this forum, I have seen multiple discussions and patches regarding > chained interrupts for X86, but not for ARM and began to think that > maybe chained interrupt support in xenomai is not complete for ARM. > > Could this be the case? In fact, those patches are for ARM and not x86 (the latter was always fine). Please check latest ipipe-arm releases, or even dovetail (5.10+). > > For this reason, I backed down to the 4.14.x kernel, but now have run > into the compiling issue as mentioned at the start of this email. When starting something new, do not use outdated kernels anymore. > > One last piece of background information, my initial motivation to move > to a new xenomai was that we moved to GCC 10.2 (in the meantime GCC 11.1) > and I was concerned regarding the ARM r7 register clobbering issues/patches > posted to the forum as I am fighting against a bug in our system where > registers get corrupted albeit not r7 (typically r0 with a value of > 0xFFFFFFFA (-38)). This problem seems to have come in after we upgraded > to GCC 10.2 If you are in hurry and have a working version based on older things, moving backward can be a valid intermediate options. But thinking ahead, using a mixture of old (kernel) and new (xenomai, toolchain) components is almost never a good idea: You are to far from mainstream, and piece will fill off left and right. Jan -- Siemens AG, Technology Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Does Xenomai 3.2.x work with 4.14.x kernels? 2022-04-13 18:57 ` Jan Kiszka @ 2022-04-14 16:18 ` Scott Reed 0 siblings, 0 replies; 3+ messages in thread From: Scott Reed @ 2022-04-14 16:18 UTC (permalink / raw) To: Jan Kiszka, xenomai On 4/13/22 8:57 PM, Jan Kiszka wrote: > On 13.04.22 11:25, Scott Reed via Xenomai wrote: >> Hello, >> >> I am trying to build a 4.14.110 kernel+ipipe+xenomai_3.2.7 and running into >> issues when trying to compile. Namely, the 4.14.x kernel does not seem >> to understand the "__kernel_timespec" struct. >> >> Is it known if Xenomai 3.2.x works with 4.14.x kernels? > > We stopped supporting 4.14.x actively, and we apparently broke backward > compatibility at some point. Locally likely fixable, but not > maintainable for upstream anymore.> OK, so Xenomai 3.2.x does not work with Linux 4.14.x. I am out of the office the next bit of time, but when I get back I will check how easy local fixes are. >> >> Some background information >> --------------------------- >> Our platform is based on an ARM iMx6q. >> >> I have tried to move to a 5.4.x kernel, but ran into another issue >> in that we have an RTDM driver which uses PCI MSI interrupts and >> when I try to register the interrupt with rtdm_irq_request the >> function returns EINVAL(-22). >> >> When working with a vanilla 5.4.x kernel and non-RTDM version of >> the driver, there are no issues when registering the interrupt. >> >> I started to dive into this problem, but saw that as of kernel >> 4.16, the PCI MSI interrupts for our platform have been changed >> to be handled as chained interrupts. >> >> In this forum, I have seen multiple discussions and patches regarding >> chained interrupts for X86, but not for ARM and began to think that >> maybe chained interrupt support in xenomai is not complete for ARM. >> >> Could this be the case? > > In fact, those patches are for ARM and not x86 (the latter was always > fine). Please check latest ipipe-arm releases, or even dovetail (5.10+). > The patches I was referring to have to do with the handling of chained interrupts and not specifically PCIe MSI interrupts (which I understood work well on x86). The connection for me between ARM PCIe MSI interrupt handling and chained interrupts is that since Kernel 4.18 (misspoke above with 4.16), the DWC PCIe host driver handles PCIe MSI interrupts as chained interrupts. The patches have to do with chained interrupts and gpio RTDM driver which I think up until now was the only RTDM driver using chained interrupts. I am thinking that the reason why when I try to register my PCIe MSI interrupt from my RTDM driver the rtdm_irq_request it returns EINVAL(-22) is tied to the fact that it is now chained interrupt. Just a theory. The patches I was referencing are: - [PATCH 3/6] x86/ipipe: fix chained irq handling https://xenomai.org/pipermail/xenomai/2020-September/043392.html - [PATCH 2/6] gpio: omap: irq_pipeline: enable out-of-band interrupt handling https://xenomai.org/pipermail/xenomai/2021-July/045935.html Dealing with this seemed non-trivial to me and thus the back peddle to a pre-4.18 kernel namely 4.14. >> >> For this reason, I backed down to the 4.14.x kernel, but now have run >> into the compiling issue as mentioned at the start of this email. > > When starting something new, do not use outdated kernels anymore. > OK, I was not aware that 4.14.x is considered outdated. >> >> One last piece of background information, my initial motivation to move >> to a new xenomai was that we moved to GCC 10.2 (in the meantime GCC 11.1) >> and I was concerned regarding the ARM r7 register clobbering issues/patches >> posted to the forum as I am fighting against a bug in our system where >> registers get corrupted albeit not r7 (typically r0 with a value of >> 0xFFFFFFFA (-38)). This problem seems to have come in after we upgraded >> to GCC 10.2 > > If you are in hurry and have a working version based on older things, > moving backward can be a valid intermediate options. But thinking ahead, > using a mixture of old (kernel) and new (xenomai, toolchain) components > is almost never a good idea: You are to far from mainstream, and piece > will fill off left and right. > > Jan > Thanks for the prompt reply and advice! Short-term I need to get a version recipe that is stable for me which I was hoping would be 4.14.x + Xenomai 3.2.1. Maybe still possible with local changes as mentioned above. Middle-term I want to get closer to mainstream and tried a month back - 5.10 + dovetail, but did not get far as with a vanilla 5.10 kernel my FEC port on my SECO iMx6q SOC did not work (bits on the line flipped. Maybe a clock issue??). - 5.4 + ipipe: Registering my RTDM interrupt fails (see above). Chained interrupt issue?? Not familiar with chained interrupts so looks for me to be non-trivial. Scott ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-04-14 16:18 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-13 9:25 Does Xenomai 3.2.x work with 4.14.x kernels? Scott Reed 2022-04-13 18:57 ` Jan Kiszka 2022-04-14 16:18 ` Scott Reed
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.