[Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Xenomai] Xenomai on Cortex R (or Rreal Time) family

[mobin Motallebizadeh]

 Hi
can I build xenomai for armv7-r architecture? 
I can't see this mentioned anywhere (surprisingly!)
Is it same as other MMU-less archs(nios II ,e.g.)?
thanks in advance 		 	   		  

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Lennart Sorensen]

On Thu, Oct 02, 2014 at 02:28:33PM +0000, mobin Motallebizadeh wrote:
> can I build xenomai for armv7-r architecture? 
> I can't see this mentioned anywhere (surprisingly!)
> Is it same as other MMU-less archs(nios II ,e.g.)?
> thanks in advance 		 	   		  

Cortex-R (armv7-r) is MMU-less, so it would have to run a kernel with
no mmu enabled (which linux does support for arm as far as I recall).

I see xenomai works with blackfin which is MMU-less.  Not sure if anyone
has used xenomai with arm without an mmu, but at least in theory it
could be done then.

-- 
Len Sorensen

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Philippe Gerum]

On 10/02/2014 04:41 PM, Lennart Sorensen wrote:
> On Thu, Oct 02, 2014 at 02:28:33PM +0000, mobin Motallebizadeh wrote:
>> can I build xenomai for armv7-r architecture? 
>> I can't see this mentioned anywhere (surprisingly!)
>> Is it same as other MMU-less archs(nios II ,e.g.)?
>> thanks in advance 		 	   		  
> 
> Cortex-R (armv7-r) is MMU-less, so it would have to run a kernel with
> no mmu enabled (which linux does support for arm as far as I recall).
> 
> I see xenomai works with blackfin which is MMU-less.  Not sure if anyone
> has used xenomai with arm without an mmu, but at least in theory it
> could be done then.
> 

There is absolutely no issue with running Xenomai 2.6.x or 3.x/cobalt
over mmu-less, it's a maintained configuration (bfin has been supported
since ages). The "only" issue, is to get a proper kernel implementing
the I-pipe which may require some work with vendor-originated kernels.

-- 
Philippe.

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Gilles Chanteperdrix]

On 10/02/2014 04:28 PM, mobin Motallebizadeh wrote:
>  Hi
> can I build xenomai for armv7-r architecture? 
> I can't see this mentioned anywhere (surprisingly!)
> Is it same as other MMU-less archs(nios II ,e.g.)?

The first question to ask is: do you have a Linux kernel for this
processor? because Xenomai needs Linux to run.


-- 
                                                                Gilles.

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[mobin Motallebizadeh]

> On 10/02/2014 04:28 PM, mobin Motallebizadeh wrote:
> >  Hi
> > can I build xenomai for armv7-r architecture? 
> > I can't see this mentioned anywhere (surprisingly!)
> > Is it same as other MMU-less archs(nios II ,e.g.)?
> 
> The first question to ask is: do you have a Linux kernel for this
> processor? because Xenomai needs Linux to run.
> 
> 
> -- 
>                                                                 Gilles.

there's uClinux which can support xenomai (as u mentioned in docs) and cortex-r family is limited to.
 		 	   		  

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Gilles Chanteperdrix]

On Fri, Oct 03, 2014 at 03:50:10AM +0000, mobin Motallebizadeh wrote:
>
>
>
>
> > On 10/02/2014 04:28 PM, mobin Motallebizadeh wrote:
> > >  Hi
> > > can I build xenomai for armv7-r architecture?
> > > I can't see this mentioned anywhere (surprisingly!)
> > > Is it same as other MMU-less archs(nios II ,e.g.)?
> >
> > The first question to ask is: do you have a Linux kernel for this
> > processor? because Xenomai needs Linux to run.
> >
> >
>
> there's uClinux which can support xenomai (as u mentioned in docs) and cortex-r family is limited to.

If it is not the mainline Linux, and it does not share code with the
ARM Linux port, then as Philippe indicated a new port of the I-pipe
patch is needed, but that is doable.

--
					    Gilles.

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Richard Cochran]

On Thu, Oct 02, 2014 at 04:48:16PM +0200, Gilles Chanteperdrix wrote:
> On 10/02/2014 04:28 PM, mobin Motallebizadeh wrote:
> >  Hi
> > can I build xenomai for armv7-r architecture? 
> > I can't see this mentioned anywhere (surprisingly!)
> > Is it same as other MMU-less archs(nios II ,e.g.)?
> 
> The first question to ask is: do you have a Linux kernel for this
> processor? because Xenomai needs Linux to run.

There is some main line support for Cortex-M3, for the Energy Micro
development kit. See Uwe Kleine-König's tree at

   http://git.pengutronix.de/?p=ukl/linux.git

I have never heard of Linux running on a Cortex-R at all.

HTH,
Richard

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Gilles Chanteperdrix]

On 10/10/2014 03:25 PM, Richard Cochran wrote:
> On Thu, Oct 02, 2014 at 04:48:16PM +0200, Gilles Chanteperdrix wrote:
>> On 10/02/2014 04:28 PM, mobin Motallebizadeh wrote:
>>>  Hi
>>> can I build xenomai for armv7-r architecture? 
>>> I can't see this mentioned anywhere (surprisingly!)
>>> Is it same as other MMU-less archs(nios II ,e.g.)?
>>
>> The first question to ask is: do you have a Linux kernel for this
>> processor? because Xenomai needs Linux to run.
> 
> There is some main line support for Cortex-M3, for the Energy Micro
> development kit. See Uwe Kleine-König's tree at
> 
>    http://git.pengutronix.de/?p=ukl/linux.git

Well, if it is someone's (other than Linus') tree, it is not mainline :-)

I have worked with Cortex-M3 (TI stellaris family), and as far as I
remember, it has very different behaviour from cortex-A for exceptions,
irqs (the irq controller is integrated in the processor irq path, there
is one irq address for each irq in the vector table, much like x86), and
the like. So, at minimum some changes in entry.S would be needed for
Xenomai to run.


-- 
                                                                Gilles.

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Richard Cochran]

On Fri, Oct 10, 2014 at 05:10:37PM +0200, Gilles Chanteperdrix wrote:
> Well, if it is someone's (other than Linus') tree, it is not mainline :-)

Just to be clear: I think most everything has gone main line.  But if
anything is missing, check Uwe's tree.  Also, you still need a simple
boot loader and user land, so try this:

http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary

Anyhow, about Cortex-R, I can offer this:

1. Cortex-M is now working in main line for efm32.
2. No one is interested in Linux Cortex-M (seems to me)
3. Cortex-R is not supported in any Linux at all (AFAICT)

Thanks,
Richard

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Gilles Chanteperdrix]

On Sat, Oct 11, 2014 at 08:54:04PM +0200, Richard Cochran wrote:
> On Fri, Oct 10, 2014 at 05:10:37PM +0200, Gilles Chanteperdrix wrote:
> > Well, if it is someone's (other than Linus') tree, it is not mainline :-)
> 
> Just to be clear: I think most everything has gone main line.  But if
> anything is missing, check Uwe's tree.  Also, you still need a simple
> boot loader and user land, so try this:
> 
> http://git-public.pengutronix.de/?p=OSELAS.BSP-EnergyMicro-Gecko.git;a=summary
> 
> Anyhow, about Cortex-R, I can offer this:
> 
> 1. Cortex-M is now working in main line for efm32.
> 2. No one is interested in Linux Cortex-M (seems to me)

Well, a lot of Cortex M are running code from very small NOR
flashes, with very little RAM as well. So, they definitely can not
run Linux. Having worked with such processors, and with FreeRTOS, let
us just say I was motivated by a port of Xenomai POSIX skin on bare
metal. But this has probably become a little harder with Xenomai 3
than with Xenomai 2. And I never found time to do it anyway.

> 3. Cortex-R is not supported in any Linux at all (AFAICT)

I thought so, but mobin seems to say a uCLinux port exists.

This page:
http://elinux.org/Processors

mentions it.

-- 
					    Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 04:57:34PM +0200, Gilles Chanteperdrix wrote:
> On 10/01/2014 04:24 PM, Lennart Sorensen wrote:
> > I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
> > 
> > [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
> > [58531.105521]         into a regular Linux service
> > [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> > [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> > [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> > [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
> > [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
> > [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
> > [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
> > [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> > [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> > [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> > [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> > [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> > [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> > [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> > [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> > [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> > [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> > [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> > [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> > [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
> > [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
> > [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
> > [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
> > [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
> > [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
> > [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
> > [58531.106718] ------------[ cut here ]------------
> > [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
> > )
> > [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
> > pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
> > nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
> > ol dwc3_omap lm75 [last unloaded: xfrm_user]
> > [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
> > [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
> > [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
> > [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
> > [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
> > [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
> > [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
> > 
> > I saw ipipe patches in the gpio-omap.c but maybe something is still
> > missing.
> > 
> > Any ideas?
> > 
> > Of course it may be that our code is used to running on an older xenomai
> > where it first called request_irq and then xenomai took over the irq
> > handling.  I wish the person that wrote that code still worked here to
> > explain why that was done.
> > 
> > If I don't use the gpio irq but instead use an irq that is one level
> > lower, then I get no such error message (although the pin isn't setup
> > properly either then so it doesn't actually work either).
> > 
> This is a simple warning which should be harmless, it should not prevent
> the irq from working. Now we had an old issue on ARM, which is that an
> irq line should be enabled before using it, the simplest way to get it
> enabled being to call request_irq before rtdm_irq_request. Maybe this
> issue we believed fixed is still there?

Or maybe I still haven't got the gpio bank configured correctly to
actually be an interrupt pin.  It looked like the omap-gpio driver did
that all correctly, but with all the registers on these chips, who knows.

We are currently doing request_irq first, and it still doesn't see any
interrupts on the line.

So is this message a case of the gpio driver doing some setup that ipipe
thinks should only be done from linux while doing the irq reqeust from
xenomai's domain?

I wish the message had told me which linux thing I called that it didn't
think I should have.  That would have been helpful.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 05:02 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 04:57:34PM +0200, Gilles Chanteperdrix wrote:
>> On 10/01/2014 04:24 PM, Lennart Sorensen wrote:
>>> I tried using an omap-gpio as an interrupt in xenomai and got this message when registering it:
>>>
>>> [58531.105521] I-pipe: Detected illicit call from head domain 'Xenomai'
>>> [58531.105521]         into a regular Linux service
>>> [58531.105538] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
>>> [58531.105558] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>>> [58531.105577] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>>> [58531.105594] [<c0440784>] (dump_stack+0x70/0x8c) from [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c)
>>> [58531.105611] [<c001a55c>] (ipipe_test_and_stall_root+0x8/0x8c) from [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c)
>>> [58531.105626] [<c04449c4>] (_raw_spin_lock_irqsave+0xc/0x4c) from [<c0016238>] (unwind_frame+0x2c4/0x49c)
>>> [58531.105641] [<c0016238>] (unwind_frame+0x2c4/0x49c) from [<c0016490>] (unwind_backtrace+0x80/0xf8)
>>> [58531.105657] [<c0016490>] (unwind_backtrace+0x80/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>>> [58531.105673] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>>> [58531.105689] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
>>> [58531.105705] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
>>> [58531.105721] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
>>> [58531.105783] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
>>> [58531.105907] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
>>> [58531.106009] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
>>> [58531.106124] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
>>> [58531.106198] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
>>> [58531.106216] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
>>> [58531.106233] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
>>> [58531.106336] [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus]) from [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native])
>>> [58531.106434] [<bf1510cc>] (rt_intr_create+0x258/0x4cc [xeno_native]) from [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native])
>>> [58531.106538] [<bf132de8>] (__rt_intr_create+0x9c/0x124 [xeno_native]) from [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus])
>>> [58531.106609] [<bf0c2658>] (hisyscall_event+0x184/0x34c [xeno_nucleus]) from [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8)
>>> [58531.106626] [<c00afb9c>] (ipipe_syscall_hook+0x68/0xa8) from [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408)
>>> [58531.106641] [<c00ae698>] (__ipipe_notify_syscall+0x170/0x408) from [<c000eefc>] (pipeline_syscall+0x8/0x24)
>>> [58531.106652] ---[ end trace dff1d3990fff1b03 ]---
>>> [58531.106718] ------------[ cut here ]------------
>>> [58531.106729] WARNING: CPU: 0 PID: 9816 at /tmp/linux/linux-3.12.27.rr1/arch/arm/kernel/ipipe.c:158 ipipe_set_irq_affinity+0x98/0xd8(
>>> )
>>> [58531.106738] Modules linked in: 8021q garp stp mrp llc l2tp_eth l2tp_netlink l2tp_core ip_gre ip_tunnel gre macvlan ti_pru_eth rcksa
>>> pi_layer2(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack dummy xeno_posix xeno_rtdm xeno_native xeno_
>>> nucleus max6369_wdt iptable_filter ip_tables x_tables xhci_hcd dwc3 ahci_platform omap_aes phy_omap_usb2 phy_omap_pipe3 phy_omap_contr
>>> ol dwc3_omap lm75 [last unloaded: xfrm_user]
>>> [58531.106980] CPU: 0 PID: 9816 Comm: StartTask Tainted: G           O 3.12-1-am5726 #1 Debian 3.12.27-0.1RR6
>>> [58531.106990] [<c0016410>] (unwind_backtrace+0x0/0xf8) from [<c001286c>] (show_stack+0x10/0x14)
>>> [58531.106998] [<c001286c>] (show_stack+0x10/0x14) from [<c0440784>] (dump_stack+0x70/0x8c)
>>> [58531.107007] [<c0440784>] (dump_stack+0x70/0x8c) from [<c0040060>] (warn_slowpath_common+0x68/0x8c)
>>> [58531.107016] [<c0040060>] (warn_slowpath_common+0x68/0x8c) from [<c00400a0>] (warn_slowpath_null+0x1c/0x24)
>>> [58531.107025] [<c00400a0>] (warn_slowpath_null+0x1c/0x24) from [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8)
>>> [58531.107034] [<c001a308>] (ipipe_set_irq_affinity+0x98/0xd8) from [<bf0a689c>] (xnintr_attach+0x2c/0x39c [xeno_nucleus])
>>>
>>> I saw ipipe patches in the gpio-omap.c but maybe something is still
>>> missing.
>>>
>>> Any ideas?
>>>
>>> Of course it may be that our code is used to running on an older xenomai
>>> where it first called request_irq and then xenomai took over the irq
>>> handling.  I wish the person that wrote that code still worked here to
>>> explain why that was done.
>>>
>>> If I don't use the gpio irq but instead use an irq that is one level
>>> lower, then I get no such error message (although the pin isn't setup
>>> properly either then so it doesn't actually work either).
>>>
>> This is a simple warning which should be harmless, it should not prevent
>> the irq from working. Now we had an old issue on ARM, which is that an
>> irq line should be enabled before using it, the simplest way to get it
>> enabled being to call request_irq before rtdm_irq_request. Maybe this
>> issue we believed fixed is still there?
> 
> Or maybe I still haven't got the gpio bank configured correctly to
> actually be an interrupt pin.  It looked like the omap-gpio driver did
> that all correctly, but with all the registers on these chips, who knows.
> 
> We are currently doing request_irq first, and it still doesn't see any
> interrupts on the line.

Do you use gpio_to_irq to obtain the irq number?

> 
> So is this message a case of the gpio driver doing some setup that ipipe
> thinks should only be done from linux while doing the irq reqeust from
> xenomai's domain?
> 
> I wish the message had told me which linux thing I called that it didn't
> think I should have.  That would have been helpful.

Actually, it tells you that you called rt_intr_create from user-space,
which ends-up calling ipipe_set_irq_affinity, which is not happy because
it is not called from Linux domain. We modified ipipe_virtualize_irq to
avoid that (only checking for root domain when CONFIG_IPIPE_LEGACY is
not set), but we probably forgot the SMP case with ipipe_set_irq_affinity.

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 05:28:35PM +0200, Gilles Chanteperdrix wrote:
> Do you use gpio_to_irq to obtain the irq number?

Yes.  I tried doing request_irq from a dummy linux driver and I managed
to get an interrupt.  I can't seem to get xenomai to see the interrupt
though.  Hmm.

I see this:

root@len-rx1400:~# cat /proc/xenomai/irq 
IRQ         CPU0        CPU1
 30:     2294394     1660178         [timer]
398:           0           0         0000002d
1031:           0           0         [sync]
1032:           1           0         [timer-ipi]
1033:         531           1         [reschedule]
1034:           0           0         [virtual]
1038:      535719         531         [virtual]

398 is the IRQ for GPIO bank 7 pin 14.  The linux driver test got an
interrupt from the device on that pin, but when I use xenomai I am so
far not getting the interrupt as far as I can tell.

Maybe I should try and no longer call request_irq first.

> Actually, it tells you that you called rt_intr_create from user-space,
> which ends-up calling ipipe_set_irq_affinity, which is not happy because
> it is not called from Linux domain. We modified ipipe_virtualize_irq to
> avoid that (only checking for root domain when CONFIG_IPIPE_LEGACY is
> not set), but we probably forgot the SMP case with ipipe_set_irq_affinity.

Oh.  Well if you have a patch I can test that.  Or a suggestion for
where to go and try to fix it.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 11:46:41AM -0400, Lennart Sorensen wrote:
> Yes.  I tried doing request_irq from a dummy linux driver and I managed
> to get an interrupt.  I can't seem to get xenomai to see the interrupt
> though.  Hmm.
> 
> I see this:
> 
> root@len-rx1400:~# cat /proc/xenomai/irq 
> IRQ         CPU0        CPU1
>  30:     2294394     1660178         [timer]
> 398:           0           0         0000002d
> 1031:           0           0         [sync]
> 1032:           1           0         [timer-ipi]
> 1033:         531           1         [reschedule]
> 1034:           0           0         [virtual]
> 1038:      535719         531         [virtual]
> 
> 398 is the IRQ for GPIO bank 7 pin 14.  The linux driver test got an
> interrupt from the device on that pin, but when I use xenomai I am so
> far not getting the interrupt as far as I can tell.
> 
> Maybe I should try and no longer call request_irq first.

That didn't seem to make any difference except of course now the IRQ
doesn't get listed in /proc/interrupts anymore.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 11:52:52AM -0400, Lennart Sorensen wrote:
> That didn't seem to make any difference except of course now the IRQ
> doesn't get listed in /proc/interrupts anymore.

Question:

When I do request_irq I can specify IRQF_TRIGGER_HIGH.  How does one do
the same thing for rt_intr_create?  After all that is an important thing
to tell the irq controller in this case.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 06:02 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 11:52:52AM -0400, Lennart Sorensen wrote:
>> That didn't seem to make any difference except of course now the IRQ
>> doesn't get listed in /proc/interrupts anymore.
> 
> Question:
> 
> When I do request_irq I can specify IRQF_TRIGGER_HIGH.  How does one do
> the same thing for rt_intr_create?  After all that is an important thing
> to tell the irq controller in this case.
> 
I guess you have to manually call irq_set_irq_type, that being said, if
you used request_irq, the GPIO should be configured and the type set. If
you register the Xenomai interrupt after that, it should get the
interrupt, if it does not get it, it probably means that you have an
issue in the gpio demuxing code.

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 07:31:53PM +0200, Gilles Chanteperdrix wrote:
> I guess you have to manually call irq_set_irq_type, that being said, if
> you used request_irq, the GPIO should be configured and the type set. If
> you register the Xenomai interrupt after that, it should get the
> interrupt, if it does not get it, it probably means that you have an
> issue in the gpio demuxing code.

So I found now that if I do request_irq first and then rt_intr_create,
then if I pass TRIGGER_HIGH or TRIGGER_LOW, then the system hangs as
soon as rt_intr_create is called (right after dumping the nice message
from ipipe I had in the first email).  If I do request_irq without that,
then it does not hang.  How odd.

If I don't use rt_intr_create and just have a dummy handler in linux
with request_irq, then I get a triggered interrrupt.

Of course if request_irq doesn't specify, then the default is
IRQF_TRIGGER_NONE, which in the gpio-omap driver means not calling
either of handle_level_irq or handle_edge_irq, so it probably isn't doing
anything in that case.  Passing in a trigger makes it call one of those
two functions depending on the trigger type requested.

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 07:40 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 07:31:53PM +0200, Gilles Chanteperdrix wrote:
>> I guess you have to manually call irq_set_irq_type, that being said, if
>> you used request_irq, the GPIO should be configured and the type set. If
>> you register the Xenomai interrupt after that, it should get the
>> interrupt, if it does not get it, it probably means that you have an
>> issue in the gpio demuxing code.
> 
> So I found now that if I do request_irq first and then rt_intr_create,
> then if I pass TRIGGER_HIGH or TRIGGER_LOW, then the system hangs as
> soon as rt_intr_create is called (right after dumping the nice message
> from ipipe I had in the first email).  If I do request_irq without that,
> then it does not hang.  How odd.

Are you sure you are not simply getting an interrupt and failing to
clear the interrupt condition?

Are you sure that the GPIO demuxing code calls ipipe_handle_demuxed_irq
instead of generic_handle_irq?

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 07:46:31PM +0200, Gilles Chanteperdrix wrote:
> Are you sure you are not simply getting an interrupt and failing to
> clear the interrupt condition?

I won't claim to be sure yet.

> Are you sure that the GPIO demuxing code calls ipipe_handle_demuxed_irq
> instead of generic_handle_irq?

Well gpio-omap has this:

        if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_LEVEL_HIGH))
                __irq_set_handler_locked(d->irq, handle_level_irq);
        else if (type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
                __irq_set_handler_locked(d->irq, handle_edge_irq);


So I imagine it would call handle_level_irq in my case.  When I don't
specify HIGH or LOW, it would call neither and I get no hang.  I did
not try FALLING or RISING yet, although currently I suspect those would
hang too.

I also see:

                        ipipe_handle_demuxed_irq
                                (irq_find_mapping(bank->domain, bit));

That's in gpio-omap as well.  I see no calls to generic_handle_irq?

-- 
Len Sorensen

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Gilles Chanteperdrix]

On 10/01/2014 07:54 PM, Lennart Sorensen wrote:
> On Wed, Oct 01, 2014 at 07:46:31PM +0200, Gilles Chanteperdrix wrote:
>> Are you sure you are not simply getting an interrupt and failing to
>> clear the interrupt condition?
> 
> I won't claim to be sure yet.

Well, what is on the other end of the GPIO ? If this is a button, you
may want to set the interrupt type to edge, otherwise the interrupt will
remain asserted as long as you press the button, and you will get an
interrupt storm. If it is another GPIO, then you should reset that GPIO
state in the irq handler.

Also, it may actually be simpler to write an RTDM driver than to use the
deprecated, error-prone rtintr API.

-- 
                                                                Gilles.

Re: [Xenomai] I-pipe error when requesting irq that is on omap gpio

[Lennart Sorensen]

On Wed, Oct 01, 2014 at 11:39:26PM +0200, Gilles Chanteperdrix wrote:
> Well, what is on the other end of the GPIO ? If this is a button, you
> may want to set the interrupt type to edge, otherwise the interrupt will
> remain asserted as long as you press the button, and you will get an
> interrupt storm. If it is another GPIO, then you should reset that GPIO
> state in the irq handler.

No it is a marvell switch chip.  And it is in fact level triggered.
And it does clear when handled.

And I could probably get a button hooked up for testing, and just use
the debouncing feature in the gpio system to make it more manageable.

I am still not convinced the gpio-omap doesn't have a problem, but maybe
it is OK.

> Also, it may actually be simpler to write an RTDM driver than to use the
> deprecated, error-prone rtintr API.

Fair enough.  May have to consider that.  At the moment the system is
polling the switch chip given the IRQ isn't working yet, so idially we
want it working, but it isn't preventing things from working completely.

I will have a look at the rtdm stuff.

-- 
Len Sorensen

[Xenomai] Xenomai on Cortex R (or Rreal Time) family

[mobin Motallebizadeh]

Hi
can I build xenomai for armv7-r architecture? 
I can't see this mentioned anywhere (surprisingly!)
Is it same as other MMU-less archs(nios II ,e.g.)?
thanks in advance
 		 	   		  

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Gilles Chanteperdrix]

On 10/02/2014 03:56 PM, mobin Motallebizadeh wrote:
> Hi
> can I build xenomai for armv7-r architecture? 
> I can't see this mentioned anywhere (surprisingly!)
> Is it same as other MMU-less archs(nios II ,e.g.)?
> thanks in advance

This is a very legitimate question, but why are you hi-jacking a
discussion thread to ask it? Please do not reply a mail from another
discussion to ask a new question, this breaks archives for people who
want to browse the archives by discussion thread.

-- 
                                                                Gilles.

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[mobin Motallebizadeh]

 
> Date: Thu, 2 Oct 2014 16:00:57 +0200
> From: gilles.chanteperdrix@xenomai.org
> To: mobin.seven@live.com; xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family
> 
> On 10/02/2014 03:56 PM, mobin Motallebizadeh wrote:
> > Hi
> > can I build xenomai for armv7-r architecture? 
> > I can't see this mentioned anywhere (surprisingly!)
> > Is it same as other MMU-less archs(nios II ,e.g.)?
> > thanks in advance
> 
> This is a very legitimate question, but why are you hi-jacking a
> discussion thread to ask it? Please do not reply a mail from another
> discussion to ask a new question, this breaks archives for people who
> want to browse the archives by discussion thread.
> 
> -- 
>                                                                 Gilles.
 OMG! where should I ask it? I sent this to xenomai_at_org mail.sorry I always did this way!! 		 	   		  

Re: [Xenomai] Xenomai on Cortex R (or Rreal Time) family

[Lennart Sorensen]

On Thu, Oct 02, 2014 at 02:22:35PM +0000, mobin Motallebizadeh wrote:
>  OMG! where should I ask it? I sent this to xenomai_at_org mail.sorry I always did this way!!

Well you did it by replying to a thread rather than sending a new message
to xenomai@xenomai.org (changing the subject is NOT the same thing as
creating a new thread).  When you hit reply your email client inserts
a tag in the mssage saying which other message it was a reply to.

-- 
Len Sorensen